OpenSSL Patches Critical Certificate Forgery Bug 45
msm1267 writes: The mystery OpenSSL patch released today addresses a critical certificate validation issue where anyone with an untrusted TLS certificate can become a Certificate Authority. While serious, the good news according to the OpenSSL Project is that few downstream organizations have deployed the June update where the bug was introduced.
From the linked piece: The vulnerability allows an attacker with an untrusted TLS certificate to be treated as a certificate authority and spoof another website. Attackers can use this scenario to redirect traffic, set up man-in-the-middle attacks, phishing schemes and anything else that compromises supposedly encrypted traffic. [Rich Salz, one of the developers] said there are no reports of public exploits.
Trusted certificate owners (Score:2)
So i understand from this that o don't need to rush & patch my web servers who all have Trusted certs.
Right ?
Re: (Score:2)
Did you install the version of OpenSSL that introduced the bug?
Re: (Score:2)
Does 1.0.1e-2+deb7u16 qualify?
Re: (Score:1)
No, that was released 19th of March.
The June update is 1.0.1e-2+deb7u17
Re:Trusted certificate owners (Score:4, Informative)
Debian claims that their patched versions of openssl for squeeze/wheezy/jessie are not affected by this issue.
Re: (Score:1)
Re: (Score:2)
Unless you're running on sid you're fine: https://security-tracker.debia... [debian.org]
According to that page testing (stretch) is also vulnerable, and a few people might actually use that.
Re: (Score:2)
If true, that explains why the lack of updated OpenSSL packages on my oldstable Debian.
Re: (Score:2)
Latest one i have in production is 1.0.1m - the release before the LogJam fix in 1.0.1n that introduced this bug.
Re: (Score:2)
It sounds like if you are not verifying certificates then it's not critical, but if you've got client certificates to identify/authenticate users you need to update.
If you're running any kind of client connection (for instance, consuming a https webservice) then you'll need to update (unless they're using gnutls or nss instead of openssl)
LibreSSL and BoringSSL? (Score:4, Interesting)
If you're running any kind of client connection (for instance, consuming a https webservice) then you'll need to update (unless they're using gnutls or nss instead of openssl)
Are LibreSSL and BoringSSL also affected? The article mentions that a BoringSSL contributor found the problem, but it doesn't say one way or the other whether this misbehavior made it into any releases of BoringSSL or any other OpenSSL fork.
Re: (Score:3)
.
http://marc.info/?l=openbsd-te... [marc.info]
We have received several emails asking if we are impacted by the latest CVE-2015-1793. We are not impacted. The code related to that CVE was added after we forked 1.0.1g and we did not merge these changes from upstream. This CVE only concerns newer OpenSSL releases.
Re: (Score:3)
So i understand from this that o don't need to rush & patch my web servers who all have Trusted certs. Right ?
You may want to rush if your web server validates client certificates? That is, does any of your users have to present a certificate to the web server instead of just the opposite way around?
Re: (Score:2)
AIUI this is mostly a client issue, servers do not normally validate certs presented to them (client certs do exist but they are rarely used and even where they are used afaict it'susually with a "known cert for each user" model rather than a CA based model).
Compromise Window (Score:2, Funny)
Apparently the NSA/FBI needed collect someone's encrypted data in the last year. Now that they have what they want, they are sewing it back up again.
Though with the NSA's purported computing capability and back doors it doesn't seem like they would need this -- unless some lesser player on the intelligence field got this in -- but then I'm positing corroboration with the OpenSSL folks, so it seems like only a government would be capable of coercing this kind of flaw. But with the underhanded C contest, ma
Re: (Score:1)
There are too many secrets in the system to trust anyone. Wipe the word from your memories. It's over, Johnny.
Re:Too Many Secrets (Score:2)
That's why I get my crypto from SETEC Astronomy
Re: (Score:2)
too many secrets
ill have some of that world peace about now.
Bugs are like cockroaches (Score:1)
For every one you see, there are tens of thousands more under the cabinet. Outside single user mode this whole certificate thing is not trustworthy in any sense...
SubjectsInCommentsAreStupid (Score:1)
Background checks and all...
Re: (Score:2)
Yes well why don't you start checking then?
Re: (Score:2)
Re: (Score:2)
mr. smartass
Where did that come from?
turns out the reviewer is the same guy who reviewed the heardbleed 'patch' too.
And who introduced the problems (rather than reviewing the fixes)?
Re: (Score:2)
Re: (Score:2)
Okay, so you're an idiot. Thanks for clearing that up beyond doubt.
WTF is a "TLS certificate"? (Score:2)
Hey editors - did you mean an "X.509 certificate?"
X.509 cert with hostname as common name (Score:5, Informative)
A TLS certificate is an X.509 certificate whose common name identifies a hostname in the manner specified by TLS. All TLS certificates are X.509 certificates, but not all X.509 certificates are TLS certificates because not every X.509 certificate's common name identifies a hostname.
Re: (Score:2)
Also, SSL/TLS certificates are X.509 certificates with the proper key usage / extended key usage.
How the bug was introduced (Score:2)
Re: (Score:2)
Thats one way of looking at it (Score:2)
Good news everybody, people aren't installing our broken and insecure updates!
Re: (Score:2)
OpenSSL problems are due to proprietary company controlling the project for certain proprietary interests.
Why don't we call you a CorporateSlaveTard?
Re: (Score:2)
No, anyone can submit a contribution which may or may not get accepted by those controlling the project. Your understanding is so flawed
Fund LibreSSL, not OpenSSL (Score:2)
Understatement.
RHEL/CentOS/etc not vulnerable (Score:2)
There was an announcement by RH in response to this, noting that the vulnerabilities were included in a recent release by openSSL, and that they had not gone into RHEL updates, so RHEL is not vulnerable, nor are it's children, like CentOS.
mark