search

mail-in-a-box / mailinabox

Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
https://mailinabox.email/
Creative Commons Zero v1.0 Universal
14.06k stars 1.44k forks source link

SSL/TLS Session Renegotiation (DoS vulnerability) #390

Open ikarus23 opened 9 years ago

ikarus23 commented 9 years ago

Multiple configurations allow client-initiated SSL/TLS session renegotiations. This leads to a denail of service vulnerability (CVE-2011-1473) that is really easy to exploit with tools like THC SSL DoS (and this patch).

Affected services:

This was validated using OpenSSL (and the TCH SSL DoS tool).

openssl s_client -starttls smtp -connect box.occams.info:587
[ press 'R' multiple times]

box.occams.info:587 tested with sslyze (example; the other ports work as well):

 ./sslyze.py --regular --starttls=smtp box.occams.info:587

[...]

   box.occams.info:587                 => 94.76.202.152:587

[...] 

  * Session Renegotiation:
      Client-initiated Renegotiations:   VULNERABLE - Server honors client-initiated renegotiations
      Secure Renegotiation:              OK - Supported

[...]

(The web server (nginx) is not affected by this issue.)

JoshData commented 9 years ago

Do you know if there's a way to fix this?

ikarus23 commented 9 years ago

Until now I only know of some iptables magic or fail2ban configs (see this post). I can look into this more this weekend.

ikarus23 commented 9 years ago

Sorry for not updating this earlier. I did some additional search on that weekend, but with no remarkable realizings. It seams that every application has to "fix" this on its own. The fix is to deactivate client-initiated SSL/TLS session renegotiations. Some software like Apache or NGINX have a setting to do this, others don't. Other argue that "it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment." Red Hat rated this issue with a low security risk (link). This blog has a nice article including prevention and mitigation measures. But they are all not really "satisfying"...

The way I see it there are only tow options:

  1. Live with it (there are a lot of systems out there with this issue).
  2. Create a fancy iptables rule to mitigate the risk.
ikarus23 commented 9 years ago

Ok, did some more real word testing to see how bad this is. By using the THC tool (patched to work with STARTTLS) I was able to increase the the CPU usage of my vServer. After some time however, it averaged out around 40%. All my services were still available during this test.

So maybe it's not so bad after all... It would be nice if other members of the mail in a box community could test this too. If they come to the same result, I would suggest to ignore this issue.