Recently in Security Category

When you wonder why your known_hosts file has changed or you don't find your hosts:

|1|AEf8B/QCP+1wRKA761Cq/woad4s=|HVEWXKDdRpZmO3GeQ5T37xCFwgE= ssh-rsa AAAAB3NzaC1
yc2EAAAABIwAAAQEAt20HN/iasjy9KEW/BGjtxlsy8oebyEEnZvKAnjMck0EEVbA5rtE4dzisnbrYwZ4
67JP+p9UGZDQa4jbVo2ZHmz28nQapmw1WpLBD2wSN66PsMk5QCxICxBC6PDCOlwakQvLNES2B9R2cuev
G9Ag2ni+2Qdb17gEkkh2MZ91INylAzM7QWW7soGoSf1TsshSHexfMt12zb6kWxRuRCeT4fOzlJNOmPgr
uE3wTt/kfEbvPBZwDyUbEKApfYIxO8ic+FyO7qFEjHkhqT7px/oJMLS279uUHlhG+KWtPxYPhWaYulPZ
hhdn4D6pR+6shjPsH4VTyAUGwf7usKUvJZP59Ww==

Then your ssh server software is a new version which hashes the known hosts file entries. To remove entries from there because the host key differs (you installed the host completely from scratch), just type:

ssh-keygen -R hostname

or

ssh-keygen -R ipadress

That's it.

If you have a new ssh package, you may hash yourself your known_hosts file by typing:

ssh-keygen -H

A real case of RTFM of OpenSSL ...

After un upgrade of OpenSSL to Version 1.0.0 (from 0.9.8) the certificate authority chain of my certificate did not show up any more (was not given by the TLS server). A look in the OpenSSL manual could have helped to save 20 minutes of error searching :)

A

for i in *.pem; do ln -s $i `openssl x509 -noout -subject_hash -in $i`.0; done

was enough to restore the hash index links for my CA certs (the files did not have any whitespace or punctuation marks in their filename so $i was enough).

The manual states:

-subject_hash
outputs the ``hash'' of the certificate subject name. This is used in OpenSSL to form an index to allow certificates in a directory to be lookedup by subject name.

-subject_hash_old
outputs the ``hash'' of the certificate subject name using the olde ralgorithm as used by OpenSSL versions before 1.0.0.

As you know, kissmetrics' tracking algorithm is based on the ETag resource sent along with every document from http servers. Its normal use is to distinguish cached documents from new versions, if the document to be delivered has altered a new ETag is generated. In web caches every cached resource is stored with its ETag.

For a request on a resource stored in the web cache a http header line like

If-None-Match: "H33jh3gggIU§gug3kjhgHhjbkc3"

will be added to the request which means "please send out the document only if its ETag is no longer H33jh3gggIU§gug3kjhgHhjbkc3".

kissmetrics generates ETags as User-IDs to be tracked and every site which uses kissmetrics to analyze web traffic data will include a small kissmetrics.com-request in their web site. The web browser cache will cache this little resource along with its ETag which is NOT its calculated ETag but the kissmetrics "user id". So on every site with a kissmetrics "bug" the request gets done with the

If-None-Match: "your_kissmetrics_user_id"

And voilà, you're tracked. Deleting cookies does not help. You have to clear your cache in your web browser after every site visited. Not very useful.

A possible solution would be to use a web proxy like squid which can easily filter out the "ETag" headers. So web browsers will use the "If-Modified-Since:"-method to make web servers to deliver documents only if they have changed. This will not work on most dynamic web sites however as web application programmers often forget to set and to honor this request header (using the last changed timestamp of the displayed data for example).