Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

OpenSSL patch quashes rare HTTPS nasty, shores up crypto chops

Feet up for the many, head's down and patch for the rest.

OpenSSL maintainers have pushed a pair of patches, crushing a dangerous but uncommon bug that allows HTTPS to be unravelled while also hardening servers against downgrade attacks.

Affected servers are open to key recovery attacks only if it runs certain Digital Signature Algorithm and static Diffie-Hellman key exchange subgroups, while running OpenSSL version 1.0.2.

The high severity bug (CVE-2016-0701) revealed by Adobe engineer Antonio Sanso and which is fixed in version 1.0.2f.

Carnegie Mellon University CERT Garret Wassermann explains the crypto conundrum that will tickle many a neckbeard-owner.

OpenSSL 1.0.2 introduced the ability to generate X9.42 style parameter files as required by RFC 5114. The primes generated in this mode may be 'unsafe', enabling generation of groups containing small subgroups, which may allow for cryptographic attacks that may recover the key. OpenSSL prior to 1.0.2f did not properly check for this possibility.

Furthermore, OpenSSL prior to 1.0.2f will by default reuse this number for the life of the process. Such a number, particularly if re-used, severely weakens applications of the Diffie-Hellman protocol such as TLS, allowing an attacker in some scenarios to possibly determine the Diffie-Hellman private exponent and decrypt the underlying traffic.

It requires attackers complete multiple handshakes with OpenSSL targets that use the same private Diffie Hellman exponent.

The fix will also reject weak 768 bit Diffie-Hellman handshakes now requiring 1024 bits upping crypto chops.

The project's also addressed CVE-2015-3197, which means "A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2."

This one's an easy fix: if you run OpenSSL 1.0.2 upgrade to 1.0.2f. OpenSSL 1.0.1 users should upgrade to 1.0.1r. ®

 

Similar topics

TIP US OFF

Send us news


Other stories you might like