> 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/
So "SSL3_AL_WARNING" isn't necessarily exclusively used in SSLv3, if the format wasn't changed in TLS.
Says the website with no TLS ;)
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?
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.
You can't bring a site down from your phone normally if there is a CPU eating bug on the other hand you can.
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.
