3 ms·
I kind of wish they wouldn't just hand out an A+ that easily. There are clear areas of improvement that the sub-scores call out (90 in both Key Exchange and Ci
by samch 12y ago
I kind of wish they wouldn't just hand out an A+ that easily. There are clear areas of improvement that the sub-scores call out (90 in both Key Exchange and Cipher Suite). They see the HSTS and grant the A+ when there is clearly improvement that can be made. In my mind, an A+ should be reserved for an SSL/TLS implementation that cannot reasonably be improved upon given the current state of the industry.
To improve your Key Exchange score you can bump your certificate from a 2048-bit key up to 4096-bit (giving you a score of 100). That's probably a good idea anyway as 2048 has been the minimum safe key size since 2010 [1], and I'd imagine that 4096 will become the new minimum over the next few years.
To improve your Cipher Suite score you can easily drop support for payload encryption with keys less than 256 bits in length. You will risk not supporting IE 6 users, but that's a fringe case these days (and there are many more issues with supporting IE 6 on top of that).
Making those adjustments, you should be able to get your scores to 100,95,100,100 which, in my opinion, is much more worthy of an A+.
There may be a few other tweaks you can make to improve items in the Protocol Details section, but I don't know enough about the node.js/io.js system to be able to recommend a clear path for improvement there.
The only score that you really would have difficulty bumping to 100 is the Protocol Support which is limited by the fact that all versions of IE prior to 11 had TLS 1.1 and 1.2 disabled by default. Unfortunately, there are still many IE 9 and 10 users out there
1. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13...
- nailer 12y agoThanks & agreed completely. I'm working on a followup improving the cipher suite score (with a couple of options depending on browser compromises). I'll do some research around 4096 bit key support. I'm also checking out OCSP stapling. Edit: precursory investigations show 4096 bit keys generally good to go with a few exceptions, eg AWS CloudFront:http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html#cnames-and-https-size-of-public-key http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...
- agwa 12y ago> I'd imagine that 4096 will become the new minimum over the next few years. That's unlikely to happen. 2048-bit RSA provides a security level of ~112 bits, which would physically require a massive amount of energy to break, and it's unlikely that so much energy would ever be expended on a single task. So 2048-bit RSA is only likely to be broken if there's a mathematical breakthrough against RSA. The thing is, such a breakthrough is likely to break 4096-bit RSA as well, so using 4096-bit RSA is only a protection against a minor breakthrough. Meanwhile, 4096-bit RSA carries a massive performance cost. It's just not worth slowing down your TLS handshake with 4096-bit RSA to protect against a mathematical breakthrough, but not too much of a breakthrough. So stick with 2048-bit RSA for now, and in a few years when elliptic curve crypto is better supported, switch to that.
- nuxi7 12y agoTotally This ^ This is a key you get re-signed every 1-3 years. You don't need it to last 10 years, you need it to last maybe a year longer than your SSL cert is actually good for. (Assuming your site is setup to have all the browsers do PFS)