One-third of all HTTPS websites open to DROWN attack Security researchers have discovered a new technique for deciphering the contents of supposedly secure communications. The DROWN attack - it has already got a name, like recent high profile crypto attacks Lucky13, BEAST, and POODLE - is a “cross-protocol attack that can decrypt passively collected TLS sessions from up-to-date …
Beware that as OpenSSL itself warns, the SSLv2 server can be one "even with a different protocol such as SMTP, IMAP or POP", as long as it shares the RSA key with the TLS one.
Thereby if someone used the same cert to protect both an HTTP server and a mail server (or whatever else) connections with the same cert, all servers needs to be patched/configured to not use SSLv2, even under a downgrade attack.
"Servers" in this context is "server applications (daemon/services)" not instance, physical or virtual, of a server OS.
And because it is a protocol flaw, not an OpenSSL one, servers that doesn't use OpenSSL but another implementation of SSL, could be a vulnerability issue as well, if not properly configured.
"“A typical scenario requires the attacker to observe 1,000 TLS handshakes, then initiate 40,000 SSLv2 connections and perform 250 offline work to decrypt a 2048-bit RSA TLS cipher-text,”"
I'd assume that the TLS 1.2 attack mentioned still required the 40,000 SSLv2 requests?
"Beware that as OpenSSL itself warns, the SSLv2 server can be one "even with a different protocol such as SMTP, IMAP or POP", as long as it shares the RSA key with the TLS one."
What kind of crazy person would be using the same RSA key on all those things... Hmm the convenience of wildcard certificates.
This post has been deleted by its author
... I think around 1995 (when I first connected to the Internet), it seemed a great idea - and got better and better (how on earth did I pay my bills and stuff? I can't remember).
Now, 21 years later it seems to be going backwards, and becoming more of a liability than an asset.
What to do people?
Why is anyone still configured for SSLv2 anyway? Yes, the openssl bug (CVE-2015-3197) that allowed SSLv2 to be used even when disabled means there's still an issue to be patched, but that's not the question.
We know SSLv2 is insecure. It's been on the bad-boy list for many years. So why do people still have it configured?
> We know SSLv2 is insecure. It's been on the bad-boy list for many years. So why do people still have it configured?
I would reckon most of these aren't just web servers where even your local bobby tables web dev can disable SSLv2 in Apache. But appliances, admin interfaces, vCenter servers, iDRACs, NetScalers and who knows what else that have been left exposed by half-wits, never been patched, and never will be patched because support has elapsed and firmware can't be found and etc.
I found a few daemons in regular upkeep which do not, by normal configuration, allow you to disable protocols. You can disable the ciphers but not the protocols. So what happens is the SSLv2 handshake is permitted, thus trading certificate information, but then there are no ciphers which can be negotiated so the connection "fails." At this point the damage has been done.
If your SMTP server shares the RSA key with another using TLS only, the attack will work against the TLS one using the SMTP server SSLv2 flaw. It doesn't matter what protocol the SSLv2 server is using.
You need to ensure the SSLv2 server uses its own RSA key which is not shared with anything else - including IMAP and POP, if they are served by the same host.
This post has been deleted by its author
If it is only unenecrypted, SMTP, it wouldn't show up on the vulnerability page. It is quite likely also running SMTP/s on port 587 which negotiates the encrypting protocol and would be vulnerable.
The vulnerability scanner is trying to perform an SSLv2 handshake, so that fact that it was able to means that something on that server is vulnerable.
The vulnerability scanner is trying to perform an SSLv2 handshake, so that fact that it was able to means that something on that server is vulnerable.
Suspect it doesn't have to be "that server" but could include the load balancer et al used to front your site. Any one know if F5's Big-IP is vulnerable to DROWN?
It looks like the root cause of this situation lies in the obligatory inclusion of the export ciphers at the time SSLv2 was young in order to satisfy the "crypto is munitions" crowd. Something to ponder for those who still think there is such a thing as a "just for us" backdoor.
MacPorts contained updates this morning.
Inspecting the system more closely:
/usr/bin/openssl version
OpenSSL 0.9.8zg 14 July 2015
and
/usr/local/bin/openssl version
LibreSSL 2.2.0
Better, especially as /usr/local/bin gets precedence in the path bug 2.2.6 was released back in January.
C'mon Apple: release those upstream updates to your customers!
some silo protection ideas for debate?
i.e. do your browsing/banking on a refurb iPad Air set to "Private" - do not use this for email. Have Search_Engine_Suggestions, Safari_Suggestions, Quick_Web_Search, Preload_Top_Hit, Fraudulent_Website_Warning all OFF. Do dump the client-side cookies/LSO's every week Settings/Safari/Advanced/Website_Data/ Edit&Delete, repeat until they are gone.
If you have to use your old PC/Mac for browsing, consider using a clean Linux Mint liveCD from before the recent attack on their repos, or on OS X use Chrome(*) for everything except Goooogle products, use FF only for Gmail/google products, try using IXQUICK.nl for search (omnibox setting https://ixquick.nl/do/search?query=%s&cat=web&pl=chrome&language=english) but - do not use this PC for email. (*)On Chrome, do not sign-in, update Chrome every week (from About Chrome,) then ensure that chrome://settings/ Show_Advanced_Settings has ‘navigation errors,’’prediction,’’prefetch,’’report,’’protect,’’spelling,’’usage,’ OFF
Read/screen your POP email on a $/£ 35 Raspberry Pi 3, or an old smartphone, do not use this for web browsing. Emails that you wish to keep could be physically printed out for filing & storage. Re-instantiate the RaspberryPi regularly (possibly we could use a virtual machine here, but a hardware RPi3 is quite fun)
Update the OS/Firmware then switch off the WiFi/delete/reset the web connection to default on all your SmartTV's, Fridges etc
Abandon your telco Web router with its multiple unknown backdoors to the telco, turn off its WiFi, unscrew its antenna, have a single ethernet cable with fixed IPv4 to your real router, (Your Router with a spoofed MAC address so it's hard to guess which model) and set a hard to guess Administrator name & password - which you can write on the underneath of your router for those mislaid moments. Consider using OpenDNS family service on your router’s DNS = 208.67.222.123 and 208.67.220.123 (this will protect from most of the browser ’errors’ that we configured OFF earlier)
Invent & run several random traffic generators including DHS monitored keywords, use TOR for checking the cricket scores, the dark-web for reading the DailyMail & Telegraph
This approach at least leads to some level of phishing/crypto-locker immunity & restores a bit of 1990’s privacy. Lawful Interception can still profile you, but they’d need to do it with proportionality rather than vacuum-cleaning.
. . .there may be better ways to protect the civilian infrastructure from cyber-squirrels, what else to try?
This is one of the alleged military approach to sanitising messages, the email receiving/sending machine is destroyed each day. (Re-imaged from sd-card or similar for a VM state) Hence there's no terabyte of old emails in an inbox. Hence if you wish to keep a sent or received mail, either print it out or you could always forward it to your super-secret second email account that doesn't get phish/virus attacks.
Richard Stallman gets his emails delivered to a friend who prints the interesting ones out & posts-them, allegedly.
Why should a single obfuscated link in an email lead to all your data being cryptolocked? That's a spectacularly broken system, hence extraordinary measures are needed to defend users.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
