6 ms·

SSL Report: duckduckgo.com

122 points by cinquemb 13y ago

geal 13y ago
It's nice to see that they have a sane configuration (even though they should disable RC4 nowadays). They should implement HSTS, though. It is very easy to do (just a HTTP header to set).
- jaryd 13y ago
  Thanks for pointing this out -- we're implementing this now.
olympus 13y ago
Can someone provide commentary on what this means for those of us who aren't knowledgable about SSL/secure web traffic stuff? Is an A rating really good (I presume it is), or is it one of those things that you aren't really good unless you get an A+? What does 'RC4 yes PROBLEMATIC' mean and is that a vulnerability with any real world significance? edit: Or is this about the fact that it supports forward secrecy?
- Mithrandir 13y ago
  They just enabled forward secrecy today: https://twitter.com/duckduckgo/status/349948709418696706 https://twitter.com/duckduckgo/status/349948709418696706 This link has a nice rundown of why RC4 is no longer recommended for SSL/TLS: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... Basically: "According to AlFardan, Bernstein, Paterson, Poettering and Schuldt (a team from Royal Holloway, Eindhoven and UIC) the RC4 ciphersuite used in SSL/TLS is broken. If you choose to use it -- as do a ridiculous number of major sites, including Google -- then it may be possible for a dedicated attacker to recover your authentication cookies. The current attack is just on the edge of feasibility, and could probably be improved for specific applications."
  - jmillikin 13y ago
    A frustrating problem with ssllabs.com and RC4 is that it appears there is no way to achieve a 100% score. Sites are penalized for supporting RC4 if RC4 is placed above AES-CBC, and penalized as being vulnerable to BEAST if AES-CBC is placed above RC4. If CBC and RC4 are both disabled then no major browser can successfully negotiate a cipher. The BEAST penalty applies even if the preferred AES-CBC ciphers are defined by TLSv1.2 and thus shouldn't be vulnerable to BEAST. https://www.ssllabs.com/ssltest/analyze.html?d=john-millikin.com https://www.ssllabs.com/ssltest/analyze.html?d=john-millikin...
    - ivanr 13y ago
      It is actually possible to achieve 100%, but you have to run only TLS 1.2, IIRC. But that would also make your web site inaccessible to most users. But don't blame us, that's just the current situation with SSL/TLS. We're only reporting it. BTW, we used to show scores in the result, but too many people were trying to game the system (rather than be reasonable). As a result, we're showing only the grades now. In the future, the numerical scoring will be probably removed completely (switching to rule-based scoring). As for BEAST, our test tests SSL 3.0 and TLS 1.0 specifically, but not TLS 1.1+. So, the way to go with BEAST is to force RC4 with TLS 1.0 and earlier, some CBC suite with TLS 1.1, and GCM suites with TLS 1.2.
      - jmillikin 13y ago
        > So, the way to go with BEAST is to force RC4 with TLS > 1.0 and earlier, some CBC suite with TLS 1.1, and GCM > suites with TLS 1.2. Since most browsers now include mitigations for BEAST, don't you think that the proven insecurity of RC4 is more dangerous to users than BEAST?
        ivanr 13y ago
        Both (BEAST and RC4) are proven to be real. The only question is which is worse, and if the attacks are practical. In my view, both are equally unlikely to be a threat for an average web site. I'd love to get rid of the BEAST penalty, but there are no good (high-volume) stats on what percentage of "all" users is vulnerable to the BEAST attack. Because Apple is not yet deploying 1/n-1 in their browsers, the vulnerable BEAST percentage is still quite high. On SSL Labs, about 15%. Given that attacks against RC4 are not very practical (yet), one possible direction is to focus on supporting TLS 1.2 (without RC4, obviously), at which point both RC4 and BEAST attacks will become irrelevant.
- edwintorok 13y ago
  It'd be nice if they supported TLS 1.1, the CBC ciphers are not supposed to be vulnerable there and they could drop RC4. TBH I wouldn't use RC4 at all these days... Unfortunately Firefox doesn't yet have TLS 1.1 enabled (apparently you can manually enable it in about:config in recent versions), but Chromium does. TLS 1.2 would also give them GCM, but AFAICT the only browser that supports that on Linux is Konqueror.
  - claudius 13y ago
    Even Opera (12.15, the proper one) has TLS 1.2, and Firefox doesn’t even have 1.1? Why?
- ivanr 13y ago
  [SSL Labs author here.] At this point, the A rating is the minimum you should expect. But, to have a really good configuration, you really ought to also implement 1) HTTP String Transport Security, 2) Forward Secrecy, and 3) Public Key Pinning (not yet quite feasible, but it's getting closer). The next step for SSL Labs is to start to reward sites when these additional features are deployed.
RyanMcGreal 13y ago
+1 for ssllabs.com. Nice resource.
signed0 13y ago
Is this trying to show that Duck Duck Go just enabled PFS (perfect forward secrecy)?
- shdon 13y ago
  Yes, pretty much.
  - lucb1e 13y ago
    Trying my own domain, it says the same. I never touched anything. Are they sure this is working?
    - nknighthb 13y ago
      It's working. "Perfect forward secrecy" is not a specific feature you turn on, it's actually an implicit consequence of certain ways key exchange can be implemented. Chrome says, for the blog mentioned in your profile: "The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism." "ECDHE" means elliptic curve Diffie-Hellman exchange. This means your server, whatever it is, is configured to support perfect forward secrecy. If you're running your own server, you're probably using some recent distribution or Apache release that defaults to enabling ECDHE. Otherwise, your host may have done such configuration themselves.
      - lucb1e 13y ago
        Okay, thanks for all the info! It's indeed about my blog, and I host it myself on a fairly recent version of Apache.
      - danbruc 13y ago
        The last E stands for ephemeral because ephemeral keys are used.
jsonau 13y ago
Cool tool. A bit ironic: https://www.ssllabs.com/ssltest/analyze.html?d=ssllabs.com https://www.ssllabs.com/ssltest/analyze.html?d=ssllabs.com
- makomk 13y ago
  Not particularly. If you read further down, they've marked themselves down because they intentionally disabled protection against the BEAST attack, in order to collect some kind of stats on vulnerable clients.
  - ivanr 13y ago
    That's right. Good stats on BEAST are difficult to come by, so we're running a passive handshake analyzer[1] on our site in order to determine what amount of our clients support the 1/n-1 split. The last time I looked, about 15% of the browsers we see are still vulnerable to this problem. [1] For the curious, have a look at https://github.com/ssllabs/sslhaf https://github.com/ssllabs/sslhaf The 0.1.x branch is the stable one; master is moving from an Apache module toward a portable library.
mikegioia 13y ago
The funny thing is that SSLLabs' own site throws an "Error code: ssl_error_no_cypher_overlap" when RC4 is disabled in the browser. Apparently they don't support browsers that only accept strong ciphers. This is especially odd because they advise against using RC4.
- ivanr 13y ago
  You are not going to get a failed connection if you only disable RC4. I suspect you've been too strict with the suites on your end.
skorgu 13y ago
For nginx 1.1.19-1ubuntu0.2 on Ubuntu 12.04 the following config line will get you that green 'yes' for perfect forward secrecy: ssl_ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!aNULL:!MD5:-LOW:-SSLv2:-EXP; You can test with a pair of terminals before you go bouncing your server (via [0]): openssl s_server -accept 8888 -cert mywebsite.com.pem -pass stdin -cipher ECDHE-RSA-RC4-SHA <hit enter a few times> openssl s_client -connect 127.0.0.1:8888 -cipher ECDHE-RSA-RC4-SHA I don't know what the proper way to get rid of RC4 is. [0] http://baudehlo.wordpress.com/2013/06/24/setting-up-perfect-forward-secrecy-for-nginx-or-stud/ http://baudehlo.wordpress.com/2013/06/24/setting-up-perfect-...
znowi 13y ago
Quick response. Request for PFS appeared on the duck forum only yesterday. https://duck.co/topic/duckduckgo-ssl-not-secure-enough https://duck.co/topic/duckduckgo-ssl-not-secure-enough
peterwwillis 13y ago
Sad: login.yahoo.com [1] gets a B grade due to Client-Initiated Renegotiation, BEAST, CRIME, RC4 and disabled session resumption. Even login.live.com [2] isn't that bad. [1] https://www.ssllabs.com/ssltest/analyze.html?d=login.yahoo.com&s=209.191.122.42&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=login.yahoo.c... [2] https://www.ssllabs.com/ssltest/analyze.html?d=login.live.com&s=131.253.61.82&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=login.live.co...
aray 13y ago
Why don't they support TLS 1.2?
hiroprot 13y ago
On a related note, running this against google.com shows that they support Forward Secrecy as well.
TallboyOne 13y ago
So.. I got an "A" rating but not 100% in all categories. Is there any way I can improve on this (nginx)? I have a lot of users with older browsers so that's really important, not sure if that matters. ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;
- ivanr 13y ago
  It's really impossible to give you a concise answer, because there are many details to take care of. My advice is to download the SSL/TLS Deployment Best Practices guide: https://www.ssllabs.com/projects/best-practices/ which covers virtually everything you need to know on this topic.
martindale 13y ago
Interestingly, Stanford's Applied Crypto Lab scores an "F" with this test: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.stanford.edu https://www.ssllabs.com/ssltest/analyze.html?d=crypto.stanfo...
avtar 13y ago
"Wildcard certificates are generally best avoided. Although they are not any less secure from a strict tech- nical point of view, the way in which they are typically handled (especially in larger organizations) makes them less secure in practice." https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.2.pdf https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Pr... I'm curious about this. Could someone please comment on "the way in which they are typically handled makes them less secure in practice" concern?
- ivanr 13y ago
  [I wrote that document.] With wildcard certificates, the main danger is that multiple groups with the organization will have access to the same private keys. The larger the group the worse the security gets: the chances of the private key leaking are higher, and the people from different groups effectively gain undetectable MITM capabilities against all other systems. The same goes for the intruder, who will gain access to everything after compromising a single system. From that perspective, it's much better to use separate certificates and keys, and compartmentalize everything. Then, you are supposed to rotate your keys when someone leaves, or if there is a compromise. Revoking a shared private key is nearly impossible if it is used in multiple systems. People get really afraid of breaking stuff, and if they do, it takes them ages to fix everything.

122 points by cinquemb 13y ago

geal 13y ago

It's nice to see that they have a sane configuration (even though they should disable RC4 nowadays). They should implement HSTS, though. It is very easy to do (just a HTTP header to set).

jaryd 13y ago
Thanks for pointing this out -- we're implementing this now.

olympus 13y ago

Can someone provide commentary on what this means for those of us who aren't knowledgable about SSL/secure web traffic stuff? Is an A rating really good (I presume it is), or is it one of those things that you aren't really good unless you get an A+? What does 'RC4 yes PROBLEMATIC' mean and is that a vulnerability with any real world significance? edit: Or is this about the fact that it supports forward secrecy?

Mithrandir 13y ago
They just enabled forward secrecy today: https://twitter.com/duckduckgo/status/349948709418696706 https://twitter.com/duckduckgo/status/349948709418696706 This link has a nice rundown of why RC4 is no longer recommended for SSL/TLS: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... Basically: "According to AlFardan, Bernstein, Paterson, Poettering and Schuldt (a team from Royal Holloway, Eindhoven and UIC) the RC4 ciphersuite used in SSL/TLS is broken. If you choose to use it -- as do a ridiculous number of major sites, including Google -- then it may be possible for a dedicated attacker to recover your authentication cookies. The current attack is just on the edge of feasibility, and could probably be improved for specific applications."
- jmillikin 13y ago
  A frustrating problem with ssllabs.com and RC4 is that it appears there is no way to achieve a 100% score. Sites are penalized for supporting RC4 if RC4 is placed above AES-CBC, and penalized as being vulnerable to BEAST if AES-CBC is placed above RC4. If CBC and RC4 are both disabled then no major browser can successfully negotiate a cipher. The BEAST penalty applies even if the preferred AES-CBC ciphers are defined by TLSv1.2 and thus shouldn't be vulnerable to BEAST. https://www.ssllabs.com/ssltest/analyze.html?d=john-millikin.com https://www.ssllabs.com/ssltest/analyze.html?d=john-millikin...
  - ivanr 13y ago
    It is actually possible to achieve 100%, but you have to run only TLS 1.2, IIRC. But that would also make your web site inaccessible to most users. But don't blame us, that's just the current situation with SSL/TLS. We're only reporting it. BTW, we used to show scores in the result, but too many people were trying to game the system (rather than be reasonable). As a result, we're showing only the grades now. In the future, the numerical scoring will be probably removed completely (switching to rule-based scoring). As for BEAST, our test tests SSL 3.0 and TLS 1.0 specifically, but not TLS 1.1+. So, the way to go with BEAST is to force RC4 with TLS 1.0 and earlier, some CBC suite with TLS 1.1, and GCM suites with TLS 1.2.
    - jmillikin 13y ago
      > So, the way to go with BEAST is to force RC4 with TLS > 1.0 and earlier, some CBC suite with TLS 1.1, and GCM > suites with TLS 1.2. Since most browsers now include mitigations for BEAST, don't you think that the proven insecurity of RC4 is more dangerous to users than BEAST?
      - ivanr 13y ago
        Both (BEAST and RC4) are proven to be real. The only question is which is worse, and if the attacks are practical. In my view, both are equally unlikely to be a threat for an average web site. I'd love to get rid of the BEAST penalty, but there are no good (high-volume) stats on what percentage of "all" users is vulnerable to the BEAST attack. Because Apple is not yet deploying 1/n-1 in their browsers, the vulnerable BEAST percentage is still quite high. On SSL Labs, about 15%. Given that attacks against RC4 are not very practical (yet), one possible direction is to focus on supporting TLS 1.2 (without RC4, obviously), at which point both RC4 and BEAST attacks will become irrelevant.
edwintorok 13y ago
It'd be nice if they supported TLS 1.1, the CBC ciphers are not supposed to be vulnerable there and they could drop RC4. TBH I wouldn't use RC4 at all these days... Unfortunately Firefox doesn't yet have TLS 1.1 enabled (apparently you can manually enable it in about:config in recent versions), but Chromium does. TLS 1.2 would also give them GCM, but AFAICT the only browser that supports that on Linux is Konqueror.
- claudius 13y ago
  Even Opera (12.15, the proper one) has TLS 1.2, and Firefox doesn’t even have 1.1? Why?
ivanr 13y ago
[SSL Labs author here.] At this point, the A rating is the minimum you should expect. But, to have a really good configuration, you really ought to also implement 1) HTTP String Transport Security, 2) Forward Secrecy, and 3) Public Key Pinning (not yet quite feasible, but it's getting closer). The next step for SSL Labs is to start to reward sites when these additional features are deployed.

RyanMcGreal 13y ago

+1 for ssllabs.com. Nice resource.

signed0 13y ago

Is this trying to show that Duck Duck Go just enabled PFS (perfect forward secrecy)?

shdon 13y ago
Yes, pretty much.
- lucb1e 13y ago
  Trying my own domain, it says the same. I never touched anything. Are they sure this is working?
  - nknighthb 13y ago
    It's working. "Perfect forward secrecy" is not a specific feature you turn on, it's actually an implicit consequence of certain ways key exchange can be implemented. Chrome says, for the blog mentioned in your profile: "The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism." "ECDHE" means elliptic curve Diffie-Hellman exchange. This means your server, whatever it is, is configured to support perfect forward secrecy. If you're running your own server, you're probably using some recent distribution or Apache release that defaults to enabling ECDHE. Otherwise, your host may have done such configuration themselves.
    - lucb1e 13y ago
      Okay, thanks for all the info! It's indeed about my blog, and I host it myself on a fairly recent version of Apache.
    - danbruc 13y ago
      The last E stands for ephemeral because ephemeral keys are used.

jsonau 13y ago

Cool tool. A bit ironic: https://www.ssllabs.com/ssltest/analyze.html?d=ssllabs.com https://www.ssllabs.com/ssltest/analyze.html?d=ssllabs.com

makomk 13y ago
Not particularly. If you read further down, they've marked themselves down because they intentionally disabled protection against the BEAST attack, in order to collect some kind of stats on vulnerable clients.
- ivanr 13y ago
  That's right. Good stats on BEAST are difficult to come by, so we're running a passive handshake analyzer[1] on our site in order to determine what amount of our clients support the 1/n-1 split. The last time I looked, about 15% of the browsers we see are still vulnerable to this problem. [1] For the curious, have a look at https://github.com/ssllabs/sslhaf https://github.com/ssllabs/sslhaf The 0.1.x branch is the stable one; master is moving from an Apache module toward a portable library.

mikegioia 13y ago

The funny thing is that SSLLabs' own site throws an "Error code: ssl_error_no_cypher_overlap" when RC4 is disabled in the browser. Apparently they don't support browsers that only accept strong ciphers. This is especially odd because they advise against using RC4.

ivanr 13y ago
You are not going to get a failed connection if you only disable RC4. I suspect you've been too strict with the suites on your end.

skorgu 13y ago

For nginx 1.1.19-1ubuntu0.2 on Ubuntu 12.04 the following config line will get you that green 'yes' for perfect forward secrecy: ssl_ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:RC4:HIGH:!aNULL:!MD5:-LOW:-SSLv2:-EXP; You can test with a pair of terminals before you go bouncing your server (via [0]): openssl s_server -accept 8888 -cert mywebsite.com.pem -pass stdin -cipher ECDHE-RSA-RC4-SHA <hit enter a few times> openssl s_client -connect 127.0.0.1:8888 -cipher ECDHE-RSA-RC4-SHA I don't know what the proper way to get rid of RC4 is. [0] http://baudehlo.wordpress.com/2013/06/24/setting-up-perfect-forward-secrecy-for-nginx-or-stud/ http://baudehlo.wordpress.com/2013/06/24/setting-up-perfect-...

znowi 13y ago

Quick response. Request for PFS appeared on the duck forum only yesterday. https://duck.co/topic/duckduckgo-ssl-not-secure-enough https://duck.co/topic/duckduckgo-ssl-not-secure-enough

peterwwillis 13y ago

Sad: login.yahoo.com [1] gets a B grade due to Client-Initiated Renegotiation, BEAST, CRIME, RC4 and disabled session resumption. Even login.live.com [2] isn't that bad. [1] https://www.ssllabs.com/ssltest/analyze.html?d=login.yahoo.com&s=209.191.122.42&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=login.yahoo.c... [2] https://www.ssllabs.com/ssltest/analyze.html?d=login.live.com&s=131.253.61.82&hideResults=on https://www.ssllabs.com/ssltest/analyze.html?d=login.live.co...

aray 13y ago

Why don't they support TLS 1.2?

hiroprot 13y ago

On a related note, running this against google.com shows that they support Forward Secrecy as well.

TallboyOne 13y ago

So.. I got an "A" rating but not 100% in all categories. Is there any way I can improve on this (nginx)? I have a lot of users with older browsers so that's really important, not sure if that matters. ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;

ivanr 13y ago
It's really impossible to give you a concise answer, because there are many details to take care of. My advice is to download the SSL/TLS Deployment Best Practices guide: https://www.ssllabs.com/projects/best-practices/ which covers virtually everything you need to know on this topic.

martindale 13y ago

Interestingly, Stanford's Applied Crypto Lab scores an "F" with this test: https://www.ssllabs.com/ssltest/analyze.html?d=crypto.stanford.edu https://www.ssllabs.com/ssltest/analyze.html?d=crypto.stanfo...

avtar 13y ago

"Wildcard certificates are generally best avoided. Although they are not any less secure from a strict tech- nical point of view, the way in which they are typically handled (especially in larger organizations) makes them less secure in practice." https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.2.pdf https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Pr... I'm curious about this. Could someone please comment on "the way in which they are typically handled makes them less secure in practice" concern?

ivanr 13y ago
[I wrote that document.] With wildcard certificates, the main danger is that multiple groups with the organization will have access to the same private keys. The larger the group the worse the security gets: the chances of the private key leaking are higher, and the people from different groups effectively gain undetectable MITM capabilities against all other systems. The same goes for the intruder, who will gain access to everything after compromising a single system. From that perspective, it's much better to use separate certificates and keys, and compartmentalize everything. Then, you are supposed to rotate your keys when someone leaves, or if there is a compromise. Revoking a shared private key is nearly impossible if it is used in multiple systems. People get really afraid of breaking stuff, and if they do, it takes them ages to fix everything.