It'll take a few days..
.. for officially tested patches to come through.
Just enough time to prep test platforms - it's not a patch I want to delay too long if I can help it.
Six security patches – two of them high severity – have been released today for OpenSSL 1.0.1 and 1.0.2. Last week, the open-source crypto-library project warned that a bunch of fixes were incoming, and true enough, Tuesday’s updates address serious flaws that should be installed as soon as possible. CVE-2016-2108 is a …
You mean a few days like this: http://www.ubuntu.com/usn/usn-2959-1/
I saw the alert from Ubuntu before I saw this article from El Reg.
The many recent security issues in Open SSL, Bash, etc and the many holes in common OSS web applications seem to be accelerating the move away from insecure *nix based hosting solutions.
According to Netcraft, Microsoft's IIS now has a just under a 41% share of all websites, versus Apache on 27% and Nginx on 13%...
The heart of problem is that all the SSL/TLS standards have a "compatibility mode" which is where most of the errors come from. What needs to happen is browsers need to start a connection to a server with only TLS 1.5 (assume a time traveler with from 2020), then when that fails, drop back to 1.4 and so on until it can talk rather than the current trend which was derived from starting the communications at SSL 1.0 and then having both sides agree to improve security after the connection.
What needs to happen is browsers need to start a connection to a server with only TLS 1.5 (assume a time traveler with from 2020), then when that fails, drop back to 1.4 and so on..
This is why sysadmins are encouraged to disable old protocols (SSL, TLS 1.0, etc) as a downgrade attack would force you to use a know broken channel. All you're replacing is TLS 1.4 for TLS 1.0 (for example)
> What needs to happen is browsers need to start a connection to a server with only TLS 1.5 (assume a time traveler with from 2020), then when that fails, drop back to 1.4 and so on until it can talk
Sorry Tim. That can't work. Or more specifically, it can't prevent a downgrade attack.
Alice sends Bob a TLS 1.5 handshake.
Trudy intercepts that handshake and responds to Alice with a wtf response. Alice can't yet verify that this isn't actually from Bob.
Alice then tries with 1.4. Trudy responds the same way.
And so on....
Eventually Alice tries the only-just-better-than-ROT13 version thinking Bob can't do anything better. Trudy lets it through and can then observe or fiddle with the stream.
Assuming you are running patches for existing vulnerabilities already, you should already be patched for one of the two high severity issues (CVE-2016-2108).
For the second high severity issue (CVE-2016-2107), you need to be running AES (you should be...) using crypto offload. On the plus side, it is likely to only effect newer installs that can be patched reasonably easily, on the bad side it was introduced by a previous patch (although it was in 2013 prior to the Heartbleed.... In addition, the vulnerability allows the decryption of data rather than a remote compromise - bad for you so patch it, but that abandoned website isn't going to become an easy target for script kiddies..
For the low severity vulnerabilities, existing mitigation steps around getting rid of older protocols should have you covered.
Patch as quickly as possible but this isn't too scary on the OpenSSL 1 to 12 scale...
And how often does Microsoft patch their version? Are you sure that the dozen or so MS lawye^wcoders are up to the same standard as the hundreds of eyeballs looking at OpenSSL? Or do we think that because the source is opaque there aren't any of these often very subtle bus?
You do realize the reason that every day is International Patch Your Scary OpenSSL Bugs day, is because no one was actually reading that opaque OpenSSL code for years, right?
The hundreds of eyeballs myth has been busted so many times, it's amazing anyone's still pushing it.
You do realize the reason that every day is International Patch Your Scary OpenSSL Bugs day, is because no one was actually reading that opaque OpenSSL code for years, right?
Eric Raymond himself has admitted that the multiple eyeballs statement was more marketing than reality, but given that the code was so leaky it's quite amazing it held so well for so long, and there IS now a fairly diverse group of people looking at it. I have not seen that ability appear with proprietary stacks. That doesn't make them more or less secure, it just makes a lot harder to prove that they are indeed safe - pardon me for not believing vendor claims..
"And how often does Microsoft patch their version?"
Not as often as OpenSSL!
"Are you sure that the dozen or so MS lawye^wcoders are up to the same standard as the hundreds of eyeballs looking at OpenSSL"
Microsoft source code is available to organisations for inspection / analysis too.
These "hundreds of eyeballs" looking at OSS don't seem to actually make much difference - if in fact more then the odd security researcher even bother looking. Some of the recent and very big OSS holes in Bash and Open SSL were 2 decades old...