The DROWN Attack
drownattack.com
drownattack.com
There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack.
But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS and SSLv2, the anti- padding- oracle trick is that the server detects bad messages and then generates a fake message to continue running the protocol with, instead of aborting (which would reveal to the attacker that the message was corrupt, thus enabling the padding oracle). But when SSLv2 does that, the attacker can detect that it did, because the cipher key lengths in SSLv2 are so short that they can be brute forced. The attacker knows when the SSLv2 server replaced its message with a fake one, and thus has a working padding oracle.
The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them.
It's a great, great paper. The Bardou "trimmer" stuff was news to me too! :mind-blown-emoji:
The top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.
To me, the real problem here is RSA. Virtually every system on the Internet that does RSA uses PKCS1v15 padding (DNSSEC, which is only now being rolled out after nearly two decades of standards work, uses PKCS1v15 padding!). Moreover, RSA directly exposes an encryption primitive, unlike DH+signature forward-secure protocols, and RSA ciphertexts are surprisingly malleable.
To me, the real takeaway: RSA is obsolete. Stop using it.
† We walk you through this vulnerability in our challenges here: http://cryptopals.com/sets/6/ --- start with #46
1998: Bleichenbacher's padding oracle attack on RSA
2016: still vulnerable systems
http://framework.zend.com/security/advisory/ZF2015-10
The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?).
Neither Curve25519 nor Curve448 - which are said to be safe - are usable with X.509 and TLS, yet. Still waiting for that RFC to get past the draft status.
So, what should we do?
On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another.
High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist?
Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.)
Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity.
Long live TLS. May it forever waste my time and energy.
- Use RSA until 25519/448 land in TLS
- Switch to ECDSA in the interim
The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible.
You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy.
EDIT: I use secp384r1 for signing random_compat, so if anyone gets bit by this recommendation, I will too: https://github.com/paragonie/random_compat/blob/master/dist/...
Bruce Schneier recommends against using them.
If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone.
If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).
My threat model includes NSA dragnets but not being specifically targeted by the NSA.
That term likely means one of two things: guarding against a particularly capable attacker or paranoia for others
Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.
[1]: http://blog.cryptographyengineering.com/2015/10/a-riddle-wra...
I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually.
P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.
X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support.
X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while.
EDIT: NSS ticket for X25519 Key Exchange: https://bugzilla.mozilla.org/show_bug.cgi?id=957105
[1] http://web-in-security.blogspot.com/2015/09/practical-invali...
RSA: "I learned that as an undergrad. It's just multiplication, I'll use GMP!"
ECC: "Whoa what the hell is this? I better use a library."
Rainbow tables. Duh!
(Though I wonder if you can make a pedantic argument, that if the domain of your one-way function is suitably restricted (eg to passwords humans actually come up with) they do become bijective.)
But I don't know why I'm letting you off the hook on this. Can you be as specific as you can about the additional moving parts you're referring to? Is your comment about the difficulty of getting constant time key agreement or verification specific to legacy Weierstrass curves? And are you concerned about timing leaks in something other than scalar multiplication? If so, what are those other things?
When you say there are "more moving parts", are you referring to the fact that there's both a modular reduction and a scalar multiplication that need to be protected?
This thread and others like it make me think we need a security (and general) debate series.
I was a blog-arguer before HN, and a Usenet person before blogs, and a BBS person before that, and most of what I've learned in my whole career is traceable somehow to Internet arguments.
I really do think I'm right about RSA, though.
Maybe you're crypto's Bernie. Feel the Ptacek.
Moreover, if we can't get rid of export ciphersuites after twenty years, what is the probability that we'll manage to get rid of RSA in just a few? I'm not that optimistic.
There would be very little problem with RSA in TLS if people had moved to modern schemes like OAEP and RSA-PSS. The problem is that we didn't, and we're stuck with obsolete crap. Moving away from obsolete crap isn't the solution, it's the definition of the problem.
(There are attacks against OAEP, but they're less common and not intrinsic to the design the way PKCS1v15's are).
My impression is that RSA never really got the "djb treatment". The people designing OAEP and friends were mostly theorists concerned with security reductions, not implementation issues. I think an idiot-proof RSA scheme could be devised, but it is now way too late for that.
Obviously upgrading old clients is hard, but that's going to be a problem regardless. So in new standards that need RSA (e.g. something where the private key needs to be able to encrypt and sign), push for OEAP. If they don't need RSA, push for modern curves.
One could argue that the CA/Browser forum has achieved some success with moving away from SHA-1. As a spectator, I don't understand why this process is not repeated for similar obsolete primitives or standards.
Only solution I can think of is to create some sort of license where once the sunset deadline is established, the license to use it expires hard on the deadline.
If (as a random example that didn't annoy me at all for 2 years) a website also needs to support SmartTV devices which only accept obsolete certificates then your server has to either break them or not.
Yessss finally
> There's a padding oracle
hysterical sobbing sounds
It's setup so that you can only see the very last letter in what you think is a really long sentence someone has typed into a text editor.
With your bluetooth keyboard you move to the beginning of the line and repeatedly hit the spacebar, taking note each time what the new letter is that you can see through the keyhole.
Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error."
Think of error oracles this way: imagine a situation in which an adversary can hand you a ciphertext which, when decrypted, will trigger an error (in a padding oracle, that error is "the padding is wrong"). Now imagine that the error, revealed to the adversary, allows them to infer one bit of the plaintext. Not very useful by itself, but, as a final step, imagine that the attacker can permute the same ciphertext, generating (or not generating) an error and allowing them to reveal a different bit of the plaintext.
As long as they can keep doing that, they'll eventually recover the whole plaintext.
Here's a good starting point:
I think the point GP was making was that he got literally 4 words into the "simple to explain" explanation before realizing this explanation is going to be like tons of other things he reads here and elsewhere that require so much prior and specialized knowledge as to be nearly impossible for someone lacking a high level of experience in the area to understand.
I often feel this way when security topics come up on HN. I've been writing code a long time and I think I'm of moderate intelligence and I often have no idea what anyone is talking about. I try not to lose sleep over it because I understand that security can be really, really complicated (even if the issue is "easy to explain") and so I'm just not going to get it.
So it's not very important that you understand exactly how to go from "errors/exceptions generated by the target" to "recovery of plaintext". Even if you understand the specifics of those kinds of attacks, they're even more complicated (and fun) here.
The interesting nut of the attack is: there's a well-known error oracle in both TLS and SSLv2, but it's long since been mitigated in both protocols. However, details of the crappy crypto in SSLv2 conspire to make the mitigation for padding oracles in SSLv2 ineffective, and you can use the SSLv2 oracle to attack TLS ciphertexts if TLS and SSLv2 ever share keys.
I think everyone can understand why "Error: The fourth character of your password is wrong" is both more "usable" and insecure.
Had to deal with a program recently that gave "corrupted MAC" error on the server. All searching etc hinted at it being a network issue. Only after having fiddled with the network for ages and getting nowhere did i set up a loopback test and found the same error.
Turns out the program i was dealing with was using an old lib.
We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched.
Phone numbers were restricted information for some users, and we didn't display them in the search results. But you could search by those fields, if you already knew the value.
It turned out we left 'partial matching' available in the phone number field.
If you knew the name of a particular person, you could do the following:
Enter their name to confirm a single match shows up.
Then enter the same search, but put a single digit in the phone field, say "0". If no result came back, you knew that their phone number didn't start with that digit. So you try the next, 1, 2, 3... when you hit, say 5, you get a result. Now you know their phone number starts with a 5.
So you start on the next digit. 50-, 51-, 52-... and you get the next digit. Eventually you can reveal their entire phone number, and it was fast enough to do manually.
It wasn't super critical for the internal system, so we changed the phone numbers to exact match only and that was fine. but let's continue.
Let's say we had a REALLY slow system, and it checked each digit one at a time, taking one second per digit, and sent back a failure when it hit a non matching digit. We aren't leaking information DIRECTLY, you get no records back for partial matches. But we ARE leaking information indirectly. The attack now works roughly like this:
Do the same verification search to get a record.
Now do the same digit by digit search, start with 0. Carefully time the delay when you submit the question, and when the error shows up. If it's almost instant, you know the first digit failed. If it takes about a second to give you an error, you know the first digit worked.
You then continue to the second digit. One second fails, two seconds verifies.
Using only the timing you can determine each digit, and reveal the entire number. This is not the main information channel, the timings are what they call a side channel. The service that gives you this information by responding with an error and varying the time is an 'oracle' because it answers your questions.
This seems clear at a one-second time scale and obvious when it's explained, but it turns out that even over public networks with enough tries you can determine very small time differences, on the millisecond or less scale.
It turns out there are a lot of variations on this, some of them are very complex, and secure systems need to work very hard to run in the same amount of time ("constant time") for any query to avoid leaking information this way. The timing exploit described above is a very simplified form of the root of the described vulnerability.
This situation helped me understand 'timing attacks' and 'oracles' in a more mundane coding context, and hopefully it will help others.
"The big problem here is that people run old SSLv2 servers with the same RSA keypairs as their TLS servers. So you can take messages you captured from the TLS servers, and, with some very clever message manipulation owing to an older Bardou paper, make them intelligible to SSLv2, and use the SSLv2 padding oracle to decrypt them."
That is a lesson worth remembering: something acquired in one context might become valuable in an attack in another context. I've seen this concept show up repeatedly hacking and security analysis. Clever how this attack applied it.
I've occasionally wondered if that could be turned into some mental framework or heuristics for generically applying it to various security analyses. Some systematic way, maybe semi-automated, of saying we've collected all these pieces of information for protocols, configs, etc. Now what does that automatically infer in terms of attacks or even connections that might lead to them?
Not sure that it's feasible in general case. I used it in prototype security scanners before the commercial ones showed up. Might be something to be had researching the concept further. (shrugs)
So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right?
Two very important things come form that:
Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2.
> Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
IIRC XP supports TLS 1.0.
[1]: https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...
Ok, that makes it a lot less scary. Pretty bad still, but least the keys are not compromised.
You shouldn't have had SSLv2 enabled for many years now. If you need SSLv3 for WinXP support, this bug doesn't change anything in that regard.
I kept v2 running because we couldn't bring ourselves to prevent connections from clients of our clients, it's not our place to tell them what to do, especially if it only harms them and no one else. This time it harms everyone, including high-privilege users, so it's a lot easier to justify.
RSA also has the nice property of being deterministic.
ECDSA may not be, depending on how you implement it. EDDSA is.
This matters a great deal in a world where it's important to assume your hardware may have some adversarial properties. It's much easier for your ECDSA device to purposefully leak your private key than it is for RSA (both because there's an explicit covert channel available, and also because of how much smaller elliptic key-pairs are in practice).
Also, as we prepare for a post-quantum crypto world, this might be a bad time for shorter keylengths.
There are lots of great reasons to use curves, but I think describing RSA as obsolete is a little premature.
I don't think reasonable key lengths are going to make much of a difference if quantum computing becomes a practical threat. All the RSA cryptosystems and all the ECC cryptosystems will fall.
Meanwhile: the literature suggests that RSA and classical DH keys are threatened much more by conventional computing advances than curve keys; curve keys resist index calculus attacks.
The US government never misses a propaganda opportunity: "uncrackable crypto and impenetrable devices are evil". But technical people so easily miss the marketing value of sound bites.
This is a clear-cut case in which yet another major Internet security vulnerability is significantly caused by US government policy. Why shouldn't we run with this as a way to explain to the public why regulation of crypto is bad?
A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations.
At any rate, you should verify the configuration of your websites. There are many tools to do that, and we publish configuration sample to make it easy: https://mozilla.github.io/server-side-tls/ssl-config-generat...
[1] https://twitter.com/jvehent/status/704657734810148864
[edit] the page https://drownattack.com/top-sites shows that sites like yahoo.com are vulnerable, but there are no details as to why it is listed vulnerable. yahoo.com does not allows connections with SSLv2, but some of its subdomains do, so maybe the top-level domain is listed because some of its subdomains are vulnerable?
[edit 2] according to one of the researcher, the scanner "check if pubkey (not cert) runs on SSLv2. Then mark all others with that pubkey vuln" (src: https://twitter.com/seecurity/status/704665265712308224)
That seems to make sense, given that any SSLv2 service using a pubkey that's used on a non-SSLv2 service can be used in an attack against the latter.
The main takeaway from this is probably that it's a good idea to separate your SSL keys by service (or, more specifically, by DISTINCT($attack_surface), where $attack_surface is your software stack, OpSec, etc.). This would limit the impact of a number of vulnerabilities (think: Heartbleed) and should generally become a best-practice.
The bearing of this on the ongoing "backdoor" and "just one device" discussions is critical. This is direct evidence of real harm done by weakening encryption.
What I mean is that, today, many many years since the creation of the suite, the single-target cost has dropped to 'only' $440 per target for non-weakened ciphers. I love the money-to-execute-attack metric.
That's still high enough to slow down the viability of broad attacks for most attackers. What about in the past? How much was that back when the suite was created? Much higher. How much sooner did the weakened version make the attack efficient?
I don't mean that the government is the source of all crypto flaws, I mean that we have a specific example of a government mandated crypto 'back door' weakness causing a specific harm, making exploitation of a security flaw substantially easier. This is direct evidence of the harm caused by undermining security, which the government is currently adamant can be done "safely". The security and hacker communities know that this is not true, and this is a timely counter-factual example.
This is direct evidence that weakening cryptography, including back-doors, and special "one time" access fundamentally cause harm by undermining the security of cryptography for everyone.
Also, I'm not seeing any guides on fixes for Dovecot yet. If you built from source or the defaults aren't working, you can use the following:
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:!RC4:+HIGH:+MEDIUM
Also, you may need to update your Exim configs as well:
tls_require_ciphers = AES128+EECDH:AES128+EDH
openssl_options = +no_sslv2 +no_sslv3
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
ssl_protocols = !SSLv2 !SSLv3"In technical terms, DROWN is a new form of cross-protocol Bleichenbacher padding oracle attack. It allows an attacker to decrypt intercepted TLS connections by making specially crafted connections to an SSLv2 server that uses the same private key."
If users are accidentally enabling a feature that's been insecure for 20 years, the vulnerability is that your configuration mechanism is too complicated to understand.
To my eye, the way you've phrased it here could be read to imply "any server with SSLv2 disabled is safe". The linked report says this is incorrect, and its inaccuracy is responsible for roughly half of the vulnerabilities that they have observed.
It's still a good idea to not share keys to limit the exposure for future attacks.
Hopefully OpenSSL still honored a configuration setting to disable SSLv2?
With Perfect Forward Secrecy, any DROWN compromise is limited to the period where an attacker is actively running the attack against you. Previous PFS sessions cannot be decrypted. Without PFS, I'm not sure, but my gut feeling is that previous traffic could be decrypted if someone actively attacks you on an unpatched system now.
Do boring crypto: https://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf
Boring crypto means minimal state, minimal code (and therefore easy to audit), a minimal set of algorithms with new algorithms and encodings and such being added only when absolutely necessary, etc. Crypto "flexibility" means edge case bugs and lots of code where bugs can hide.
There is in general an exponential relationship between LOC and complexity and bugs. In crypto and security code this is really bad.
If you didn't, you had this one coming.
"Unfortunately, during our experiments we discovered that OpenSSL servers do not respect the cipher suites advertised in the ServerHello message. That is, the client can select an arbitrary cipher suite in the ClientMasterKey message and force the use of ex- port cipher suites even if they are explicitly disabled in the server configuration. The SSLv2 protocol itself was still enabled by default in the OpenSSL standalone server for the most recent OpenSSL versions prior to our disclosure."
From the OpenSSL 1.0.2f release notes:
SSLv2 doesn't block disabled ciphers
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.
Timemachine (debian) is a tool that constructs a Docker image of a Debian base system. You can choose a Debian distribution and a date in the past. Then install any (vulnerable) package of your choice for experiment. https://github.com/CSLDepend/timemachine
This tool is a part of a security testbed that we are developing. We have created container images of recent attacks in our repo, e.g., https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/...
If anyone is interested in developing such testbed for reproducible security experiments, let me know @pmcao
All nginx versions >= 0.8.19 (Oct 2009), and backported to >= 0.7.65 (Feb 2010), have SSLv2 disabled in default configuration[1][2]. Versions >= 1.9.1 (May 2015) also disable SSLv3 by default, which is not affected by this particular attack but suffers from the POODLE attack.
If you are on a version of nginx covered above, just ensure your nginx configuration does not have an "ssl_protocols" directive explicitly enabling SSLv2 (and SSLv3 for POODLE).
If you are on an older affected version of nginx, check your configuration to make sure you exclude SSLv2 (and typically SSLv3) with something like:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
It is not necessary to worry whether your nginx is built against openssl 1.0.2g, as this release simply disables SSLv2 support by default. If you've covered your bases with your nginx configuration, the openssl update is not strictly required.
[1] http://nginx.org/en/docs/http/configuring_https_servers.html (versions listed at very bottom of page)
In other words, while this compromises TLS when SSLv2 is enabled, it seems to be only maybe practical for targeted use by state actors, and even then easily detectable by network capture.
> To protect against DROWN, server operators need to ensure that their private keys are not used anywhere with server software that allows SSLv2 connections.
Also, I like this snippet:
> Disabling SSLv2 can be complicated and depends on the specific server software.
I just checked Debian versions.
Wheezy (oldstable): Much to old OpenSSL versions, according to the info site
Jessy (stable): Still to old OpenSSL version.
Stretch (testing): Still to old OpenSSL version.
Sid (unstable): The same version of OpenSSL as Stretch -- Still to old.
What to do?
According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found).
(I also updated my original post)
Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements.
So when you see "OpenSSL-1.0.c-stuffgoeshere" you are not looking at "OpenSSL" openssl anymore, but a version that Debian customized, probably to add security fixes. I say "Debian" here, but really most distros do it (RHEL, Ubuntu, CentOS, etc.) I'm just not familiar enough with their processes to comment specifically.
Debian has disabled SSLv2 in its OpenSSL packages since 2010 [0], and if you are running a Debian OpenSSL version later than 1.0.0c-2 your OpenSSL version is not vulnerable. The current version of OpenSSL in stable is 1.0.1k-3+deb8u2, so unless your server has been under a rock for 5 years you should be fine. And if it's been under a rock for 5 years you have a lot of security vulnerabilities to be worried about.
Of course you may have installed OpenSSL from somewhere else, or you may be using some other software for SSLv2 that doesn't involve OpenSSL at all. So merely upgrading your OpenSSL version is not a silver bullet, you need to think about every TLS deployment you have and how it might be used.
More broadly, use this vulnerability as a wakeup call to learn about "where your software comes from", because everybody has a role to play in staying secure, including users. Debian is maintained by volunteers; you might be happier with a commercial vendor who guarantees response times. Debian backports security fixes; you might be happier with a distribution that upgrades to new vendor versions which may have avoided the confusion here.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706
Might be a viable option.
I just don't know a commercial vendor, that also gives more transparency.
I knew, that there are also fixes from the Debian team, that add to the core functionality. But still my problem is the transparency. It is just very difficult in such a case, to find out the relevant changes, if you lack the time to observe all security changes in the distribution.
When such a thing pops up, like today, it is very tedious work for people like me, to find all the strings involved. So many packages, that can potentially involved, so many applications (eg. WebServer, SSH-Server, ...) and everywhere could be a hole. Here, I would appreciate, some more focused information, about the particular distribution.
I am using Debian because of its good reputation -- but of course if you could point out a commercial distribution with more transparency, it would be worthwhile!
http://anonscm.debian.org/viewvc/pkg-openssl/openssl/branche...
And similar for the other debian versions.
This is rather in-transparent to me. Would be nice, if somebody could give better advice on this soon.
None are fixed yet of course in debian. And not in ubuntu either: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
You won't see a fix appear in the changelog because there is nothing to fix in the Ubuntu packages.
The difference between older OpenSSL versions shipped by distributions and the latest version is not that newer protocols aren't supported, but that they haven't completely removed support for older, insecure protocols. For example, SSLv2 was only disabled by default in OpenSSL 1.0.2g, which was released today. Meanwhile, a lot of server software (e.g. nginx) had it disabled by default for quite some time now.
This is mostly relevant if you have code that uses OpenSSL directly - but then it's probably not a good idea to rely on OpenSSL defaults anyway.
tl;dr Older OpenSSL versions are probably fine as long as your server software has good defaults.
Nginx is not the only one, I guess. At least ssh should also be in the boat ... and the mail server .... and ....
As for other software, it depends on the defaults and how their code disables SSLv2 (i.e. whether they just disable all SSLv2 ciphers, or disable the actual protocol with SSL_OP_NO_SSLv2).
Anyway, it's likely that most distributions will backport the fix soon for all supported OS versions (either by disabling SSLv2 too or by including the fix from OpenSSL 1.0.2f that allows SSLv2 handshakes even if SSLv2 ciphers are disabled).
Not quite. If you disable the SSLv2 protocol, you're fine. If you have the SSLv2 protocol enabled but all the SSLv2 ciphersuites disabled, you're not fine. You can disable the SSLv2 protocol in versions of openssl previous to today's.
"Additionally the EXPORT and LOW ciphers were disabled since thay could be used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks, but note that the oldstable (wheezye)[sic!] and stable (jessie) distributions are not affected by those attacks since the SSLv2 protocol has already been dropped in the openssl package version 1.0.0c-2."
So it seems that neither Jessie nor Wheezy are affected by this.
https://www.ssllabs.com/ssltest/
DROWN is not yet marked there but you can look for "SSL 2" within the protocols section of the report.
Thanks again US government.
http://cloudformsblog.redhat.com/2016/03/01/drown-openssl-vu...
more technical detail
You should probably patch your origin servers anyway.
EDIT: Sorry, for consultancy read "peer-reviewed paper".
Rebels without a cause...
Edit: dear Ben, you let us down :(
Edit: Well, OP edited their comment and now mine makes no sense... time to take a break.
Instead of the nondescript
- Issue #2654: misplaced comma on page 3 of documentation
- Issue #2653: open() should accept relative file path
it should be
- Quetzalcoatl's Rage: misplaced comma on page 3 of documentation
- The Dying Curse of Buluc Chabtan: open() should accept relative file path
Instead of hating people marketing vulnerbilities, tackle why people-in-power don't care about vuln when communicated the old way.
Perhaps with a logo - I never really pay much attention to logos - but it wasn't the first to have an accessible name. Just off the top of my head I can name 3 SSL vulnerabilities that predated Heartbleed: BEAST, CRIME, BREACH.
Personally I can't see how having a logo changes much in terms of press coverage since radio and printed newspapers tend not to publish the logos, online publications have a large resource of stock images they can use (eg Getty) and the TV would likely want video footage anyway.
I think the nature of the bug with Heartbleed also played an important factor in it's coverage. It was quite a simple exploit to explain to the lay-person (albeit imprecisely) when compared to BEAST, CRIME, BREACH, POODLE, etc which require a much greater understanding of SSL/TLS. We do see other unbranded exploits are reported by the mainstream media, such as websites being hacked, DDoS attacks, etc, and in all of those instances the content is easily communicated in a 30 second soundbite.
- ILOVEYOU - Melissa - Slammer
We've been naming attacks for a long time. Perhaps one difference is that these days, a vulnerability is named if it's deemed high-risk/high-impact. In the past, vulnerabilities became well-known names once they'd been seen to do serious damage.
This is a blip. As soon as this escalates and everybody starts "Marketing" their latest security vulnerabilities they will once again be lost in the storm.
Whatever you might think of the name, this is bona fide important crypto work; it's one of the more interesting TLS attacks ever discovered. Please try to be careful about distracting from the important stuff with silly stuff like naming.
Is that because people don't pay attention when there's just a CVE number?
Government agencies lobby for what they want (restrictions on speech, limits on privacy, back doors into crypto), but we technical people should stick to technical discussion only?
A technical report should never discuss what government policy caused the bug, political decisions that could have avoided it, and their effect on society?
By the way (to save a click), the political stance is this (quoted from the article):
"Today, some policy makers are calling for new restrictions on the design of cryptography in order to prevent law enforcement from “going dark.” While we believe that advocates of such backdoors are acting out of a good faith desire to protect their countries, history’s technical lesson is clear: weakening cryptography carries enormous risk to all of our security."
Your machine can not support SSLv2 at all (so you couldn't be downgraded), but the existence of SSLv2 on the server (or a different server running SSLv2, say an e-mail server) allows the attack.