Let me first thank you for your efforts. Yesod is awesome, and Conduits is the data processing model I've always wanted.
I am now running Warp on ports 80 & 443, and some SSL analysis site says it's prone to the BEAST attack.
Removing the MD5/RC4 ciphers from warp-tls did not help. Sorry that I cannot come up with a patch as I don't have much understanding about the issue, but other users may be bothered about this as well.
Thanks for the report. I found this test script, and it seems that removing the AES ciphers fixes the problem. Can you confirm?
@vincenthz I was wondering if you had any thoughts on this, giving that you know exponentially more about this stuff than I do ;).
I believe it's now fixed in tls-0.9.7
I'm not sure how much to trust that beast.pl script I found, but it still says that warp-tls is vulnerable after compiling against tls-0.9.7.
I don't think the script is actually doing something useful (if i can still trust my fading perl skills).
It's basically just reporting "not vulnerable" if the cipher used is RC4 (which is true), but report "prone to attack" for anything else. It's more likely that the SSL analysis site would give a more trustworthy answer.
OK, I just got a dummy HTTPS server running at https://www.yesodweb.com/ . I'm running the sslabs.com test, I'll let you know the results.
Nope, still failing: https://www.ssllabs.com/ssltest/analyze.html?d=www%2eyesodweb%2ecom&s=23%2e21%2e150%2e239&ignoreMismatch=on
Ignore the F grade, it's just that I didn't bother generating a new certificate with the correct domain name.
ah well ok, quite confusing test. The BEAST attack is on the client side: if the client is not sending empty packet with TLS1.0 while using block cipher, then the server can't do anything about it. Hence basically the test is slightly bogus like this.
more information on their own link https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
Basically, the only thing that could be done is you could prevent block ciphers to be selected on the server side when using TLS1.0, which would impact every good TLS clients that use the empty fragments workaround (and practically dumping down the encryption from AES to RC4, which IMHO far less secure).
I'll defer to your judgement here: do you think we should just leave warp-tls as-is, and unpatched clients will be vulnerable, or remove the AES encryption and make everyone's experience less secure?
What do other servers do about BEAST?
i've added (on branch next) a callback on the server to tweak the cipher list according to the version chosen; it could be use to choose a stream cipher (RC4) when <= TLS10 is used. I could backport to tls-0.9.x if that is deemed useful.
For the default behavior in warp-tls, I think it should be left as is; I don't have strong preferences, but i hope (or i'm wishfully thinking) that by now the number of patched clients strongly out-weight the number of unpatched clients.
I'm OK leaving it as-is. @astro If you think this is truly problematic, I'd be OK added a compile-time flag to disable the AES ciphers.
It was brought to my attention because I run this service on https. I vote for disabling AES by default, because defaults should be secure.
@vincenthz's point is that AES is more secure. The security hole here is really on the client side. So we end up with the following two choices:
@vincenthz Is that an accurate summary?
@snoyberg: spot on !
@astro: I don't think the default is about security in this case. This is about letting careless clients (using old versions or unpatched tls stack) burn themselves. While you may have a reason to do that for your particular case, setting it as a default for everyone using warp-tls would have consequences to every clients, even if they are careful clients that are up-to-date security wise. I also think that by now, most SSL/TLS stack would have been updated to solve this problems, and the remaining unpatched clients are a very small minority.
If clients really have caught up in the meanwhile, I'm happy with that decision.
BTW: Cheers for warp-tls 1.3, it seems to run more stable than 1.2. (I would have opened a bug otherwise.)