So recently news broke about the attack dubbed ‘Sweet32’ that can potentially decrypt session cookies from an estimated 1% of of the Internets HTTPS traffic and potentially effects 600 of the most visited websites.
You can read more about it here.
Now of course even the news sources aren’t getting too hyperbolic over this because not only is it effecting an estimated 1% of the traffic (although that’s not negligible) it’s also not the easiest of attacks to carry out as it requires several conditional steps, and has never been tested outside of the lab.
Which is fine if the attacker is sniping particular target(s), but it’s also quite resource heavy, needing 38 hours to collect 785GB of data to get to the (sadly inedible) cookie.
Regardless of the efficacy of the attack in a live situation, the fact remains that this exploit is a great opportunity to learn more about vulnerabilities.
Now the main vulnerability here, or rather the source that enables this to work is old 64 bit block ciphers. Larger cipher blocks like AES (128 bit) are immune to this attack because it negates collisions.
Collisions, which we talked about earlier in the post titled ‘Security Fundamentals; Cryptography’ can be used to return plain text.
So if you are using protocols that can be vulnerable to collisions, then you have an insecure system. Even hash functions like SHA1 which don’t as-of-yet have any live collisions shouldn’t be used because we know computational power will eventually break that barrier – probably sooner rather than later.
The real takeaway however is that you should never be surprised at how many companies, both large and small will use insecure protocols. As with the recent impetus on rolling out HTTPS for example, companies really struggle to balance peoples conflicting needs with security, and often compromises are made.