4 ms·

Make sure you do not use compression with SSL. Using compression with SSL could make your site vulnerable to the CRIME and BREACH attacks. See... SSL Gone in

by espeed 13y ago

Make sure you do not use compression with SSL. Using compression with SSL could make your site vulnerable to the CRIME and BREACH attacks. See... SSL Gone in 30 Seconds - A BREACH Beyond CRIME [video]: http://www.youtube.com/watch?v=pIKIXQNFplY&hd=1 http://www.youtube.com/watch?v=pIKIXQNFplY&hd=1 BREACH Attack (HTTP Compression): http://breachattack.com http://breachattack.com, http://security.stackexchange.com/questions/39925/breach-a-new-attack-against-http-what-can-be-done http://security.stackexchange.com/questions/39925/breach-a-n... CRIME Attack (SSL/TLS/SPDY Compression): http://en.wikipedia.org/wiki/CRIME_(security_exploit) http://en.wikipedia.org/wiki/CRIME_(security_exploit), http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor http://security.stackexchange.com/questions/19911/crime-how-...

konklone 13y ago
SSL Labs does a great job of SSL testing domains and making recommendations: https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com I developed my nginx config based on their recommendations: https://gist.github.com/konklone/6532544 https://gist.github.com/konklone/6532544
- ivanr 13y ago
  Thanks. We also have a step-by-step configuration guide called SSL/TLS Deployment Best Practices. I've just submitted it here: https://news.ycombinator.com/item?id=6447518 In the nutshell, it's a continuously updated "everything you need to know" about SSL/TLS.
- espeed 13y ago
  Instead of using nginx or a Web server for SSL, you might consider using something like stunnel for SSL termination as recommended by 'cperciva: "...for security reasons, I prefer to keep SSL termination separate from HTTP serving" (http://colin.percival.usesthis.com http://colin.percival.usesthis.com, http://www.daemonology.net/blog/2009-09-28-securing-https.html http://www.daemonology.net/blog/2009-09-28-securing-https.ht...). In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryptography-in-1-hour-3646795 http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area. Amazon does this. For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed. See "Signing AWS API Requests" (http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html http://docs.aws.amazon.com/general/latest/gr/signing_aws_api...) To Colin and the other security professionals on HN: * Is limiting SSL still recommended in spite of the trend toward Always-On-SSL? * What are the current best practices and tradeoff considerations of this approach?
  - chc 13y ago
    > In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryp... http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area. Doesn't this leave you vulnerable to session theft?
    - espeed 13y ago
      The session ID is encoded into each URL or Form, and the request is signed using an HMAC-SHA-256 signature.
      - espeed 13y ago
        UPDATE: Looking again at Amazon.com's current HTML, it does not appear that Amazon.com is securing all requests so it may be vulnerable.
    - tedunangst 13y ago
      Yes and no. Depends on what you let open sessions do. For example, you can steal my Amazon cookies and dick with my wish list, or put a bunch of crap in my cart, or fill my recommendation list with weird stuff. But you can't buy anything because Amazon asks again for my password. (There does seem to be an option now to skip that, but I've never enabled it. Lets pretend I'm talking about the old Amazon.)
  - alinajaf 13y ago
    > For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed. My main concern about a scheme like this is the vulnerability to SSL stripping. I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.
  - ivanr 13y ago
    Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on). Someone else here mentioned SSL stripping, which is another problem, which you can't avoid [with partial SSL] no matter how much you try. If you're deploying SSL today and you're not using HTTP Strict Transport Security, you're doing it incorrectly.
- TomGullen 13y ago
  We just scored F: https://www.ssllabs.com/ssltest/analyze.html?d=scirra.com https://www.ssllabs.com/ssltest/analyze.html?d=scirra.com But I'm not quite sure what I need to do to make it better?
  - tacticus 13y ago
    What web server are you using. the big one is you need to remove the following cyphers: SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0x700c0) SSL_CK_RC4_128_WITH_MD5 (0x10080) and disable sslv2
  - ivanr 13y ago
    What tacticus said: disable SSL 2. But there's nothing wrong with the web server. (Also, given that you're using IIS, it's unusual that TLS 1.1 and 1.2 are not enabled.)
bitwizzle 13y ago
While it's true that you should disable compression, most browsers disable it client-side now so this isn't a huge issue. As for BREACH, HTTP compression has a huge performance benefit, so it's not really feasible to disable it. Unfortunately, it's pretty difficult to protect the attack using other methods.
barrydahlberg 13y ago
Can you please clarify exactly what you mean by compression? Is this referring to typical gzip compression in HTTP results or something else?
- cenhyperion 13y ago
  >Is this referring to typical gzip compression in HTTP Yes. It's a major vulnerability discovered in the past few months that significantly weakens the crypto. Website Describing the attack: http://breachattack.com/ http://breachattack.com/ Django Blog Post: https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ https://www.djangoproject.com/weblog/2013/aug/06/breach-and-...
  - barrydahlberg 13y ago
    That's not cool. The last thing we need is more things for people to use as reasons for not using HTTPS at all.
    - Trakzstarz 13y ago
      In other words, you think it's a dickish? LOL! Kids...
- espeed 13y ago
  Yes, BREACH exploits HTTP body compression so this means typical gzip compression in HTTP results (see http://breachattack.com http://breachattack.com, http://en.wikipedia.org/wiki/HTTP_compression#Security_implications http://en.wikipedia.org/wiki/HTTP_compression#Security_impli...). Full Paper: "BREACH: Reviving the CRIME Attack" (http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%2...)
elchief 13y ago
Don't use HTTP compression on private responses when using TLS. It's okay to HTTP compress publicly available images/scripts/stylesheets
- wglb 13y ago
  Well, be careful that it is just the body that gets compressed. The vulnerability occurs when the cookie is part of the compression payload. Although that does depend on the attacker being able to control what gets sent.
  - elchief 13y ago
    Probably best to serve your public/static content on a cookie-less domain, so your session cookie is not sent on those requests.

by espeed 13y ago

konklone 13y ago

SSL Labs does a great job of SSL testing domains and making recommendations: https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com I developed my nginx config based on their recommendations: https://gist.github.com/konklone/6532544 https://gist.github.com/konklone/6532544

ivanr 13y ago
Thanks. We also have a step-by-step configuration guide called SSL/TLS Deployment Best Practices. I've just submitted it here: https://news.ycombinator.com/item?id=6447518 In the nutshell, it's a continuously updated "everything you need to know" about SSL/TLS.
espeed 13y ago
Instead of using nginx or a Web server for SSL, you might consider using something like stunnel for SSL termination as recommended by 'cperciva: "...for security reasons, I prefer to keep SSL termination separate from HTTP serving" (http://colin.percival.usesthis.com http://colin.percival.usesthis.com, http://www.daemonology.net/blog/2009-09-28-securing-https.html http://www.daemonology.net/blog/2009-09-28-securing-https.ht...). In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryptography-in-1-hour-3646795 http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area. Amazon does this. For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed. See "Signing AWS API Requests" (http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html http://docs.aws.amazon.com/general/latest/gr/signing_aws_api...) To Colin and the other security professionals on HN: * Is limiting SSL still recommended in spite of the trend toward Always-On-SSL? * What are the current best practices and tradeoff considerations of this approach?
- chc 13y ago
  > In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryp... http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area. Doesn't this leave you vulnerable to session theft?
  - espeed 13y ago
    The session ID is encoded into each URL or Form, and the request is signed using an HMAC-SHA-256 signature.
    - espeed 13y ago
      UPDATE: Looking again at Amazon.com's current HTML, it does not appear that Amazon.com is securing all requests so it may be vulnerable.
  - tedunangst 13y ago
    Yes and no. Depends on what you let open sessions do. For example, you can steal my Amazon cookies and dick with my wish list, or put a bunch of crap in my cart, or fill my recommendation list with weird stuff. But you can't buy anything because Amazon asks again for my password. (There does seem to be an option now to skip that, but I've never enabled it. Lets pretend I'm talking about the old Amazon.)
- alinajaf 13y ago
  > For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed. My main concern about a scheme like this is the vulnerability to SSL stripping. I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.
- ivanr 13y ago
  Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on). Someone else here mentioned SSL stripping, which is another problem, which you can't avoid [with partial SSL] no matter how much you try. If you're deploying SSL today and you're not using HTTP Strict Transport Security, you're doing it incorrectly.
TomGullen 13y ago
We just scored F: https://www.ssllabs.com/ssltest/analyze.html?d=scirra.com https://www.ssllabs.com/ssltest/analyze.html?d=scirra.com But I'm not quite sure what I need to do to make it better?
- tacticus 13y ago
  What web server are you using. the big one is you need to remove the following cyphers: SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0x700c0) SSL_CK_RC4_128_WITH_MD5 (0x10080) and disable sslv2
- ivanr 13y ago
  What tacticus said: disable SSL 2. But there's nothing wrong with the web server. (Also, given that you're using IIS, it's unusual that TLS 1.1 and 1.2 are not enabled.)

bitwizzle 13y ago

While it's true that you should disable compression, most browsers disable it client-side now so this isn't a huge issue. As for BREACH, HTTP compression has a huge performance benefit, so it's not really feasible to disable it. Unfortunately, it's pretty difficult to protect the attack using other methods.

barrydahlberg 13y ago

Can you please clarify exactly what you mean by compression? Is this referring to typical gzip compression in HTTP results or something else?

cenhyperion 13y ago
>Is this referring to typical gzip compression in HTTP Yes. It's a major vulnerability discovered in the past few months that significantly weakens the crypto. Website Describing the attack: http://breachattack.com/ http://breachattack.com/ Django Blog Post: https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ https://www.djangoproject.com/weblog/2013/aug/06/breach-and-...
- barrydahlberg 13y ago
  That's not cool. The last thing we need is more things for people to use as reasons for not using HTTPS at all.
  - Trakzstarz 13y ago
    In other words, you think it's a dickish? LOL! Kids...
espeed 13y ago
Yes, BREACH exploits HTTP body compression so this means typical gzip compression in HTTP results (see http://breachattack.com http://breachattack.com, http://en.wikipedia.org/wiki/HTTP_compression#Security_implications http://en.wikipedia.org/wiki/HTTP_compression#Security_impli...). Full Paper: "BREACH: Reviving the CRIME Attack" (http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%2...)

elchief 13y ago

Don't use HTTP compression on private responses when using TLS. It's okay to HTTP compress publicly available images/scripts/stylesheets

wglb 13y ago
Well, be careful that it is just the body that gets compressed. The vulnerability occurs when the cookie is part of the compression payload. Although that does depend on the attacker being able to control what gets sent.
- elchief 13y ago
  Probably best to serve your public/static content on a cookie-less domain, so your session cookie is not sent on those requests.