OpenSSL SSL3_AL_WARNING undefined alert remote DoS
seclists.org> An attacker could repeat the undefined plaintext warning packets of "SSL3_AL_WARNING" during the handshake, which will easily make to consume 100% CPU on the server.
> It is an implementation problem in OpenSSL that OpenSSL would ignore undefined warning, and continue dealing with the remaining data(if exist). So the attacker could pack multiple alerts inside a single record and send a large number of there large records. Then the server will be fallen in a meaningless cycle, and not available to any others.
SSL3 is vulnerable and should be banned in the webserver's configuration. It stopped being supported by major browsers years ago.
The article doesn't say if webservers are vulnerable when they block SSL3 entirely. If so, it's the hell of a critical vulnerability! Otherwise, http://disablessl3.com/
There is a fair bit in common between the different versions of SSL/TLS, and functions and constants in OpenSSL tend to get get named with the version of the protocol they were introduced in.
So "SSL3_AL_WARNING" isn't necessarily exclusively used in SSLv3, if the format wasn't changed in TLS.
This is why I consider merging SSLv2 and SSLv3 into the term "SSL" a misnomer. The two are really completely different protocols.
"All versions (SSL3.0, TLS1.0, TLS1.1, TLS1.2) are affected." according to http://security.360.cn/cve/CVE-2016-8610/
It would be helpful if the researchers clarified how potent this DoS attack vector is. Is sending "a large number of these large records" more efficient at denying availability than a naive flood using e.g. SYNs or UDP?
That's a per-site/victim question, how big is your pipe, how big is your CPU, what kind of networking devices do you offload traffic on?
This seems like a pretty... weak vulnerability.
Sure -- you can send an SSL server a bunch of junk data, and it'll try to process that data. But from what I gather, it's not as though it takes an unusually long time for it to process these warnings either. Any attacker with the resources to perform this attack could probably just as easily saturate the host's network connection without involving SSL at all.
Not necessarily, DoS is all about asymmetry if it's 1:1 then yeah but if this only requires a handful of packets to cause the same resource exhaustion as 1000s or 10000s of normal SSL sessions then this is an issue.
You can't bring a site down from your phone normally if there is a CPU eating bug on the other hand you can.
Right, of course. I just don't see any reason that there would be an especially high "multiplier" on this vulnerability. A spurious SSL warning doesn't require the server to do anything particularly expensive; it just requires it to look at the ID, realize it's something weird that it doesn't recognize, and move on.
there's currently no post on openssl.org but i expect them to publish one soon. Also, now with all the OpenSSL sh*tstorm this year, I really wonder if LibreSSL is vulnerable to this security problem...
LibreSSL has removed SSL3, so I'd guess it doesn't do "SSL3_AL_WARNING"
And Firefox 52 is proposed to default to TLS 1.3 for safety and performance reasons: https://groups.google.com/forum/#!topic/mozilla.dev.platform...
I wish it was still possible to override these per profile. Last time I tried, the knobs were gone and had no effect whatsoever to enable safer defaults. I used to be able to force a minimum TLS version and enable only select few ciphers.
Still possible:
security.tls.version.min security.tls.version.max
security.ssl3.<cipher_suite>
Thanks, you're right, found and disabled all but two specs and tuned minimum to 3 which is TLS1.2. Will put those in the locked config file, so that they're read-only at runtime.
Since in OpenSSL TLS is affected as well, I wouldn't be so sure.
so far nginx is the only server which is affected by this issue, but the latest version wasnt affected.