< Kaminsky's DNS Flaw Exploit has been Released | Dan Kaminsky's BlackHat USA '08 Talk on the DNS Flaw >
I've got an SSL cert I use for back-end stuff. If I mistakenly link to the HTTPS version, or you wear as much tinfoil as me, here's a brief explanation.
UPDATE 11 Feb 2016: I've upgraded to a Lets Encrypt certificate. The fingerprints in the sidebar have been updated, but will likely disagree with cache'd versions for a little bit.
I use TLS much like SSH uses host keys. I don't want to shell out for a proper cert, and validate only by key fingerprints. I check these once, then tell my browser to save the cert as valid for all eternity. The fingerprints are on the left if you are looking for them. This gives me identification and encryption, as best the security I can get out of TLS.
The cert is expired, and not signed, but that's not required for the type of validation I use it for. It is expired because I don't want any reliance to be placed on the expiry date, and I don't think maximum expiry certs are a good idea.
I realise someone MITM'ing the site could alter the fingerprints displayed, but the fingerprints will be cached around the intertubes if additional verification is required.
I don't use a CACert because it does not buy me anything other than involving a third party for no good reason. If CACert's root cert is generally accepted one day, then I will switch.
I realise this isn't very 'usable' but I am not interested in making it easy for the average person, just for me and fellow security people. The average user of my blog should be happy viewing it in the clear and, unless I slip up, nothing should link to the HTTPS version explicitly.
It has been pointed out that on the surface a security person using an invalid cert looks like hypocrisy. However, there is nothing insecure about my non-traditional use of the cert, and I'd argue that those people either don't understand my use or TLS or both.
Tracked: Dec 30, 23:25