Skip to main content

Fwd: "Introduction to Chinese Chess (Xiangqi) for International Chess Players" published, recommended

A document that I was privileged to access pre-release snapshots of has now been published:

Introduction to Chinese Chess (Xiangqi) for International Chess Players A Comparison of Chess and Xiangqi By xq_info(add)gmx.de (a bit shy about his real name) 98 pages

You may like the self-assessment puzzles aspect about it, but not only that. Recommended! It's up here:

http://wxf.ca/wxf/doc/book/xiangqi_introduction_chessplayers_20150323.pdf

Best, Sebastian

"Your browser fingerprint appears to be unique among the 5,198,585 tested so far". What?!

While https://panopticlick.eff.org/ is not really new, I learned about that site only recently. And while I knew that browser self-identification would reduce my anonymity on the Internet, I didn't expect this result:

Your browser fingerprint appears to be unique among the 5,198,585 tested so far.

Wow. Why? Let's try one of the others browsers I use. "Appears to be unique", again (where Flash is enabled). What's so unique about my setup? The two reports say about my setup:

Characteristic One in x browsers have this value
Browser Firefox
36.0.1
Google Chrome
42.0.2311.68
Chromium
41.0.2272.76
User Agent 2,030.70 472,599.36 16,576.56
HTTP_ACCEPT Headers 12.66 5477.97 5,477.97
Browser Plugin Details 577,620.56 259,929.65 7,351.75
Time Zone 6.51 6.51 6.51
Screen Size and Color Depth 13.72 13.72 13.72
System Fonts 5,198,585.00 5,198,585.00 5.10
(Flash and Java disabled)
Are Cookies Enabled? 1.35 1.35 1.35
Limited supercookie test 1.83 1.83 1.83

User agent and browser plug-ins hurt, fonts alone kill me altogether. Ouch. Update:

  • It's the very same when browsing with an incognito window. Re-reading, what that feature is officially intended to do (being incognito to your own history), that stops being a surprise.
  • Chromium (with Flash/Java disabled) added

Thoughts on fixing this issue:

I'm not sure about how I want to fix this myself. Faking popular values (in a popular combination to not fire back) could work using a local proxy, a browser patch, a browser plug-in maybe. Obtaining true popular value combinations is another question. Fake values can reduce the quality of the content I am presented, e.g. I would not fake my screen resolution or be sure to not deviate by much, probably.

Sending e-mail on successful SSH login / detecting SSH log-ins

First, there are longer articles on this very subject if you are looking for something more elaborate. This is my take at a condensed version.

I have a script at /usr/local/bin/on_ssh_login.sh like this:

#! /usr/bin/env bash
if [ "${PAM_TYPE}" != "open_session" ]; then
    exit 0
fi

cat <<BODY | mailx -s "Log-in to ${PAM_USER:-???}@$(hostname -f) \
(${PAM_SERVICE:-???}) detected" mail@hostname.invalid
# $(LC_ALL=C date +'%Y-%m-%d %H:%M (UTC%z)')
$(env | grep '^PAM_' | sort)
BODY

exit 0

It uses command mailx of S-Nail to send e-mail. A config file for S-Nail at /root/.mailrc as simple as two lines total like…

set smtp-use-starttls
set smtp=your-smtp-server-here.invalid

…made it send e-mail for me, but if you need a different port, TLS rather than STARTTLS and/or logging in with SMTP as a specific user, some of these docs [1] [2] [3] [4] should have you covered.

The script can and should first be tested like this:

# PAM_TYPE=open_session /usr/local/bin/on_ssh_login.sh

Once that worked, we can make PAM call out to the script for every login to SSH by appending line…

session  required pam_exec.so /usr/local/bin/on_ssh_login.sh

to file /etc/pam.d/sshd.

NOTE: Be sure to keep a second SSH shell session open while trying out if a new login to SSH sends e-mail to you as expected.

Done. Cheers!

SSLV3_ALERT_HANDSHAKE_FAILURE from dev-libs/openssl[bindist]

Hi! On a rather young Gentoo setup of mine I ran into SSLV3_ALERT_HANDSHAKE_FAILURE from rss2email. Plain Python showed it, too:

# python -c "import urllib2; \
    urllib2.urlopen('https://twitrss.me/twitter_user_to_rss/?user=...')" \
    |& tail -n 1
urllib2.URLError: <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] \
    sslv3 alert handshake failure (_ssl.c:581)>

On other machines this yields

urllib2.HTTPError: HTTP Error 403: Forbidden

instead. It turned out I overlooked USE="bindist ..." in /etc/portage/make.conf which is sitting there by default. On OpenSSL, bindist disables elliptic curve support. So that is where the SSLV3_ALERT_HANDSHAKE_FAILURE came from.

Apache AddHandler madness all over the place

Hi! A friend of mine ran into known (though not well -known) security issues with Apache's AddHandler directive. Basically, Apache configuration like

# Avoid!
AddHandler php5-fcgi .php

applies to a file called evilupload.php.png, too. Yes. Looking at the current Apache documentation, it should clearly say that AddHandler should not be used any more for security reasons. That's what I would expect. What I find as of 2015-02-15 looks different:

Maybe that's why AddHandler is still proposed all across the Internet:

And maybe that's why it made its way into app-admin/eselect-php (bug #538822) and a few more. Please join the fight. Time to get AddHandler off the Internet!