7 ms·

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

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.
  - ZoFreX 13y ago
    That's very convincing. What then is the advantage of only selectively using SSL, and why are some people recommending it?
    - ivanr 13y ago
      Performance issues (I'd say most are imagined, but there is definitely an increase in latency) and higher cost of deployment with SSL (essentially more expensive CDNs). Some sites that rely on 3rd party services might struggle to deploy full SSL if not all services support it. In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.
  - espeed 13y ago
    Using encrypted tokens help mitigate stolen session IDs (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...). And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system. See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA http://www.youtube.com/watch?v=Z7Wl2FW2TcA)
    - ivanr 13y ago
      Encrypted tokens might help against CSRF, but if I have your session ID, it's game over. The best you can do is restrict the user agent used with the session, but that's an obstacle that can be overcome. You might try to restrict the IP address used with the session, too, but those change often even without attack that it's not practical, either. The robustness of the public CA system is a legitimate problem, but it's not a concern for most of us. People like to complain that the public CA security model is not perfect, but we have to remember that the CA ecosystem was not designed for perfection; it was designed to enable ecommerce. We now have different goals (well, some of us) and have to change our approach accordingly. MITM attacks using fraudulent certificates are very costly and make sense only against very high-value properties. If you're legitimately worried about them, you should consider using public key pinning, which effectively deals with the problem. (But, alas, only works in Chrome today.)
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.)

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.
- ZoFreX 13y ago
  That's very convincing. What then is the advantage of only selectively using SSL, and why are some people recommending it?
  - ivanr 13y ago
    Performance issues (I'd say most are imagined, but there is definitely an increase in latency) and higher cost of deployment with SSL (essentially more expensive CDNs). Some sites that rely on 3rd party services might struggle to deploy full SSL if not all services support it. In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.
- espeed 13y ago
  Using encrypted tokens help mitigate stolen session IDs (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...). And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system. See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA http://www.youtube.com/watch?v=Z7Wl2FW2TcA)
  - ivanr 13y ago
    Encrypted tokens might help against CSRF, but if I have your session ID, it's game over. The best you can do is restrict the user agent used with the session, but that's an obstacle that can be overcome. You might try to restrict the IP address used with the session, too, but those change often even without attack that it's not practical, either. The robustness of the public CA system is a legitimate problem, but it's not a concern for most of us. People like to complain that the public CA security model is not perfect, but we have to remember that the CA ecosystem was not designed for perfection; it was designed to enable ecommerce. We now have different goals (well, some of us) and have to change our approach accordingly. MITM attacks using fraudulent certificates are very costly and make sense only against very high-value properties. If you're legitimately worried about them, you should consider using public key pinning, which effectively deals with the problem. (But, alas, only works in Chrome today.)

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.)