LibreSSL not affected by DROWN attack

From what I read, it's only if you support SSLv2. But who does that? No one should be.

https://drownattack.com/
A server is vulnerable to DROWN if:

  • It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.
or:
  • Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.
Click to expand...
 
drhowarddrfine said:
From what I read, it's only if you support SSLv2. But who does that? No one should be.

https://drownattack.com/
Click to expand...
The same people who complain that the first move of LibreSSL guys was to nuke 50% of useless/obsolite code. I can't believe that OpenBSD put with this crap for such a long time. I can't wait to see GCC, and GNU binutils nuked on OpenBSD even if that means that OpenBSD will be running only on modern architectures: amd64, arm, and mips64. I have personally got rid of all other retro hardware which has also contributed to improvements in my marriage :).
 
Oko said:
I have personally got rid of all other retro hardware which has also contributed to improvements in my marriage :).
Click to expand...
It does wonders for your electricity bill too. Got rid of a lot of old stuff some time ago and replaced a couple of power supplies for modern, more efficient, versions. I think it cut my monthly electricity bill in half :D

In any case, as protocelt already noted the base has been patched. And I see the security/openssl port has been updated too. It's going to be a busy day today.
 
SirDice said:
It does wonders for your electricity bill too. Got rid of a lot of old stuff some time ago and replaced a couple of power supplies for modern, more efficient, versions. I think it cut my monthly electricity bill in half :D

In any case, as protocelt already noted the base has been patched. And I see the security/openssl port has been updated too. It's going to be a busy day today.
Click to expand...

Yeah I'm not buying any more vintage computers. Except for maintaining the three I have.

Oko said:
It is old news long time overdue IMHO. Fee should follow suit.
Click to expand...

I agree, it would motivate to make the software work natively.
 
Oko said:
It is old news long time overdue IMHO. Free should follow suit.
Click to expand...

Unfortunately I am one of the very few people who used OpenBSD's Linux compat. I needed it for perforce :/
https://www.ibm.com/developerworks/community/blogs/karsten/entry/perforce_on_openbsd_5_5

Perforce has actually bothered to put out a native FreeBSD binary but their OpenBSD one is for version 2.x and no longer works.
I ended up having to look into GitFusion to make a git compatibility layer over the Perforce server. Luckily all the other developers preferred to use Git in the end anyway so I managed to remove Perforce entirely from our work pipeline. So perhaps removing Linux compatibility layers is a great way to remove reliance on closed-source software :)
 
kpedersen said:
Unfortunately I am one of the very few people who used OpenBSD's Linux compat. I needed it for perforce :/
https://www.ibm.com/developerworks/community/blogs/karsten/entry/perforce_on_openbsd_5_5

Perforce has actually bothered to put out a native FreeBSD binary but their OpenBSD one is for version 2.x and no longer works.
I ended up having to look into GitFusion to make a git compatibility layer over the Perforce server. Luckily all the other developers preferred to use Git in the end anyway so I managed to remove Perforce entirely from our work pipeline. So perhaps removing Linux compatibility layers is a great way to remove reliance on closed-source software :)
Click to expand...
Unfortunately that is a tough one. Switching a version control system to accommodate OS usually is not an option as I learn to know all too well. There are still few Flash/Java based configuration tools for proprietary network devices which were working under Linux compatibility layer on OpenBSD. That was the last thing holding Linux comp on i386 for a very long time. It is just too much obsolete security ridden kernel code for what is worth.
 
I can't wait to see FreeBSD switch. OpenSSL makes me more and more concerned everyday.
As I understand it, there is a patch to make SSL in base private. Once that is done and applied, SSL is removed from the FreeBSD API/ABI and the switch can be made. The main concern was that LibreSSL developers have a support lifecycle of 2 years as opposed to the 5 years of a typical FreeBSD branch. Once SSL is removed from the API, however, I understand the support lifecycle should not be an issue.
 
You must log in or register to reply here.
Back
Top