Skip navigation

Category Archives: Certificates

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.

Slaying the BEAST in nginx

Just a quick post as I noticed that my nginx configuration was vulnerable to the BEAST attack thanks to the #spiffy SSL Certificate Tester from Qualys (I scored an “A”, btw :-).

The nginx docs show how to do this, now, and it’s pretty simple (very similar to the Apache configuration, in fact):

  1. ssl_ciphers RC4:HIGH:!aNULL:!MD5;
  2. ssl_prefer_server_ciphers on;

Set it to prefer RC4 ciphers and — BOOM! — you’re done.

Like many other system admins, I should have done this a long time ago. And, like many other system admins, I’ve got many other things going on. I let this slip (even though I’ve kept up on nginx patches) and I shouldn’t have. Thankfully, this was a low risk item as the site doesn’t perform truly critical transactions.

I definitely encourage folks to use the SSL Labs tool to help ensure you’ve got your site’s configuration up to snuff.

Also, make sure to follow @ivanristic on Twitter if you care at all about web app security.

DNSChanger Detector

The FBI made a tool to help you determine if you were a victim of the DNSChanger malware.

If you’re like many casual Internet users, you have no idea how to get the information to plug into the input box.

Unfortunately, the security model of most modern browsers makes it impossible to easily retrieve this information. However, it is possible to grab the DNS entries if the user is willing to trust the requesting source.

To help make it easier to determine if you’re infected, I wrote DNSChanger Detector. It’s a small Java applet that requires the user to allow it to have privileged access to the DNS entries via a call to sun.net.dns.ResolverConfiguration to get the nameservers. Once it has them, there is some jQuery glue in place to let Javascript access the results.

I understand why the FBI didn’t attempt to go this route, but it will hopefully be useful to folks who don’t wish to walk their friends and family through the process.

WEIS 2011 :: Session 2 :: Identity :: The Inconvenient Truth About Web Certificates

Nevena Vratonjic
Julien Freudiger
Vincent Bindschaedler
Jeane-Pierre Hubaux

Presentation [PDF]

Twitter transcript

#weis2011 Overview of basic ssl/tls/https concepts. Asking: how prevalent is https, what are problems with https?

#weis2011 Out of their large sample, only 1/3 (34.7%) have support for https, login is worse! only 22.6% < #data!

#weis2011 (me) just like Microsoft for patches/vulns, everyone uses Bank of America for https & identity examples. #sigh

#weis2011 More Certificates 101, but a good venn diagram explaining what authentication success looks like w/%ages. rly good visualization.

#weis2011 domain mismatch accounts for over 80% of certificate authentication failures. why? improper reuse. it has a simple solution (SNI)

#weis2011 the team did a very thorough analysis that puts data behind what most folks have probably assumed. #dataisspiffy

#weis2011 We've created a real mess for users with certs. EV certs help, but are expensive and not pervasive (***6%***!)

#weis2011 economics don't back good cert issuance practices; 0 liability on issuers; too many subcontractors; we trained users to click "OK"

#weis2011 great slide on CA success rates (hint: godaddy is #1) #sadtrombone

#weis2011 sample: 1 million web sites; less than 6% do SSL/TLS right. cheap certs == cheap "security"; policies need to change incentives

#weis2011 URL for the data is in the last slide. first question is challenging the approach for the analysis and went on for a while

“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.