Skip navigation

Category Archives: SSL

Both Candidates Weak On [SSL] Security

UPDATE: Fixed link to cached Obama image thx to notice from JB

While the two front-running candidates engaged in a bizarre, Klingon-esque ritual of hubris regarding which one was the better killer, their respective technical campaign staffers were failing to make the grade on security when it comes to taking your donations.

Earlier this week, I mentioned the most excellent Qualys SSL Certificate Tester and thought it would be interesting to try it on the two front-running US Presidential candidates online donation forms, especially since both candidates are focusing on how much they want to protect the American public.

Let’s just say that the results aren’t stellar, but they are better than I expected.

You can view the results directly from the SSL Labs site by hitting the following links:

While I’m not exactly hopeful either staff will end up fixing the SSL configurations, in the event they do, here are image-cached results of the scans I ran on Saturday, May 5, 2012:

But, you don’t want links, you want results, so here’s the top-level summary comparison:

Mitt Romney

Barack Obama

So, both candidates earn a “C” with Obama’s team scoring 10 total points higher than Romney, but let’s look at the details (only comparing the “bad” categories):

Candidate SSL Configuration Comparison

Romney
Obama
Issuer
USERTrust Legacy
Secure Server CA
Go Daddy Secure
Certification Authority
Supports Insecure SSL 2.0
Number Of Weak Cipher Suites
7
3
Vulnerable to the BEAST
Weak Ephemeral DH
Chart made with CompareNinja

While it’s somewhat ironic that Romney is vulnerable to the BEAST, both candidates show their true cipher weakness. Ultimately, though, I have to agree with the numerical results (Obama coming out the least bad of the two) if not solely based on Romney supporting insecure SSL 2.0 connections.

Given that the Trustworty Internet Movement‘s SSL Pulse Report made tech headlines just recently and that both the scan and the fixes take about 10 minutes to complete, these results are just, plain sad.

Hopefully no one decided to donate to either candidate while sipping their quad grande no-whip mocha macchiatos at Starbucks.

“Repairing” Strict Transport Security in Chrome on OS X

One of my subdomains is for mail and I was using an easy DNS hack to point it to my hosted Gmail setup (just create a CNAME pointing to ghs.google.com). This stopped working for some folks this week and I’ve had no time to debug exactly why so I decided to go back to a simple HTTP 301 redirect to avoid any glitches (for whatever reason) in the future – or, at least ensure the glitches were due to any ineptness on my part. Unfortunately, this created an interesting problem that I had not foreseen.

I started playing with Strict Transport Security (HSTS) a while ago and – for kicks & some enhanced WordPress & Drupal cookie security – moved a couple domains to it. I neglected to actually pay for a cert that would give me wildcard subdomain usage and only put in a couple domains for the cert request. I neglected to put the mail one in and that caused Chrome to not honor the redirect due to the certificate not being valid for the mail domain.

I tweaked theStrict-Transport-Security header setting in my nginx config to not include subdomains, but it seems Chrome had already tucked the entry into (on OS X):

[code padlinenumbers=”false” gutter=”false”]~/Library/Application Support/Google/Chrome/Default/TransportSecurity[/code]

and was ignoring the new expiration and subdomain settings I was now sending. Again, no time to research why as I really just needed to get the mail redirect working. I guessed that removing the entry would be the easiest way to bend Chrome to my will but it turns out that it’s not that simple since the browser seems to hash the host value:

[code]"wA9USN1KVIEHgBTF9j2q0wPLlLieQoLrXKheK9lkgl8=": {
"created": 1300919611.230054,
"expiry": 1303563439.443086,
"include_subdomains": true,
"mode": "strict"
},[/code]

(I have no idea which host that is, btw.)

I ended up backing up the TransportSecurity file and removing all entries from it. Any site I visit that has the cookie will re-establish itself and it cleared up the redirect issue. I still need to get a new certificate, but that can wait for another day.

Windows and Linux folk should be able to find that file pretty easily in their home directories if they are experiencing any similar issue. If you can’t find it, drop a note in the comments and I’ll dig out the locations.