6 ms·

At CloudFlare, our solution to this problem for our customers is to automatically support SHA2 for modern browsers and fall back to SHA1 for legacy browsers tha

At CloudFlare, our solution to this problem for our customers is to automatically support SHA2 for modern browsers and fall back to SHA1 for legacy browsers that don't support SHA2. This is in place for most paying customers already. It will be complete for all paying customer by the end of the week. For free customers using our Universal SSL solution, only modern browsers are supported so it has only used SHA2 certificates since it launched over a year ago. The danger is that after December 31, 2015 we may no longer be able to get SHA1 certificates for new customers because CAs have been told by browser vendors to no longer issue them. While that won't cause a problem for modern browsers, for legacy browsers that can't be upgraded it will mean they will not be able to access the encrypted web. Unfortunately, that disproportionately affects regions of the world where censorship risk is high. In Iran, China, and parts of Africa with more restrictive governments, legacy browser traffic is as high as 30%. If providers like CloudFlare who can safely support SHA1 certificates only for legacy browsers, while supporting SHA2 for modern browsers, cannot continue to get SHA1 certificates then we risk cutting off a substantial portion of the most vulnerable Internet users from the encrypted web. That is a bad outcome. We will be talking more about this on our blog in the coming weeks and plan to open source the TLS handshake fingerprinting logic we're using to identify what browsers only support SHA1. I'm hopeful that the browser vendors and CAs will do the appropriate thing by requiring modern browsers to only support modern hashing algorithms but allow providers like us to continue to support the best available cryptography for those users who cannot upgrade to the latest browser tech.

DanielDent 11y ago
(A) A significant percentage of users with legacy browsers could upgrade (by installing Chrome or Firefox, instead of relying on a woefully out of date bundled browser). If much of the internet stops working for them, I imagine knowledge of how to get it working again will spread pretty quickly. (B) It seems incredibly difficult (impossible?) to support graceful downgrade to older insecure approaches to TLS without also introducing the opportunity for a downgrade attack. Many of the TLS attacks we've witnessed over the last few years seem to be the direct result of bending over backwards to maintain backwards compatibility. I'm unconvinced it can be done safely.
- eastdakota 11y ago
  (A) If you've ever traveled across rural Africa or rural China or rural India and seen how many people access the Internet over original Android (if they're lucky) or Candy Bar Phones (if they're not) you'd realize the folly of your argument. (B) If someone can find a vulnerability to our implementation that we cannot fix then we'll drop support for SHA1 fallback. We'll also allow customers to turn off SHA1 fallback if they'd prefer. But that should be the choice of a site on a site-by-site basis, not imposed by the browser vendors.
  - qb45 11y ago
    You may not even need to travel to the third world. Just wait until all those "smart" cars, refrigerators, etc. with "secure" (i.e. not user tamperable) update mechanisms come out of warranty.
    - eliaspro 11y ago
      As if they shipped updates to these devices within the warranty period in the first place.
- ploxiln 11y ago
  Amusingly, these users may not be able to download modern browsers from the official websites, which will of course be only available over TLS for obvious security reasons ...
  - biot 11y ago
    You mean as the article explicitly points out with "Mozilla's one million downloads mistake"? I'm not sure how that could be considered amusing.
    - ploxiln 11y ago
      Unintended consequences. Unfortunate. But after you've seen enough of them, funny as well.
fulafel 11y ago
> automatically support SHA2 for modern browsers and fall back to SHA1 for legacy browsers that don't support SHA2 Doesn't this expose users to downgrade attack?
- eastdakota 11y ago
  Not in any way we've been able to think of — and we've spent a lot of time thinking about this and running it by the crypto community. But, if someone can demonstrate such an attack and we can't fix it technically, then we will drop support for the SHA1 fallback. And, on a customer-by-customer basis, we'll allow customer to turn off fallback if they're worried about a theoretical, if undemonstrated, attack.
  - yaps8 11y ago
    Could you elaborate or do you have a source on the technique you use to mitigate downgrade attacks ?
    - ryan-c 11y ago
      No mitigation is required. Part of the data signed by the server certificate in the handshake is the entire ClientHello message. If a MitM attacker did a downgrade, they would have to change the ClientHello, and then the client would notice that what the server signed does not match what they sent.
ryan-c 11y ago
Are you looking at anything beyond the SignatureAlgorithms TLS extension? That is the obvious solution, but I know there are a few browsers that support sha256 certificates that don't send that extension.
- eastdakota 11y ago
  Yes. It's above my pay grade to walk through what we're doing to fingerprint TLS connections. However, we will provide a thorough blog on what we're doing and open source the algorithm we're using.
  - ryan-c 11y ago
    "above my pay grade" is an odd phrase to use considering that your profile says you're the CEO, but I'm guessing you mainly mean you're not familiar with the details? I'm pretty sure I know exactly what you're doing, but I'm very interested to see how much of the secret sauce you'll share.
    - eastdakota 11y ago
      Yes, I was being a bit flip. But only a bit. We strive to be a company where engineering drives our priorities. While, a long, long time ago, I wrote a tiny bit of the code that became CloudFlare, there's no way I'd be trusted to do that today. There are engineers on our team whose salaries are far higher than mine. And, in this case, while I've been briefed on what we're doing, I don't feel comfortable enough with the details to comment on them. Thankfully, the people who are should be getting to work in London soon and I've asked that they watch this thread. PS - I have no problem sharing the complete "secret sauce" as the biggest risk here to us is not competition but that CAs after December 31, 2015 won't be allowed to issue SHA1 certificates anymore. The more organizations that can responsibly support SHA1 fallback, regardless of whether they're CloudFlare customers, the more likely it is we can convince the CA/B forum to allow the extension of the issuance of SHA1 certs to responsible parties.
      - 11y ago
hsivonen 11y ago
Since you already have the capability to do something different for SHA-256-intolerant browsers, I suggest you inject (this year with permission from your customers) banners informing the users of these browsers to switch to SHA-256-compatible browsers (Firefox on XP and Opera Mini on mobile) while they still can. It's not like the users "cannot" upgrade. They don't know how. Also, if you successfully lobbied an exception for you to keep using SHA-1, less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers or to non-browser clients--weakening security for everyone. (See https://cabforum.org/pipermail/public/2015-October/006100.html https://cabforum.org/pipermail/public/2015-October/006100.ht... )
- viraptor 11y ago
  This is wrong for so many reasons... 1. They're providing different valid signature, not changing the content of the communication itself. 2. Injecting anything into a valid response is a terrible idea. Broken cache, potentially breaking scripts relying on dom layout, messing up file fingerprints, etc. etc. 3. "It's not like the users "cannot" upgrade. They don't know how." No, lots of people cannot upgrade. Corporate policies, hardware requirements, weird device backwards compatibility, and many other reasons may prevent you from upgrading a system. 4. "less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers" They'll be marked as insecure very soon - this is a pretty good reason not to serve sha1 cert to a modern browser.
  - hsivonen 11y ago
    1. Right. I suggested they probably should (with permission) to change the content. 2. The cache is a red herring. It wouldn't matter on the Cloudflare side if done on the edge. It wouldn't matter on the client, because the client would only see either the SHA-1 view or the SHA-2 view. Again with permission of their customers. If you have a SHA-2-intolerant browser, it's not checking for fingerprints. Chances are that scripts already break in legacy browsers. 3. The concern here isn't about corporate policies. A policy that says you have to stay on IE on an obsolete service pack of an obsolete system gets no sympathy. The concern here people in Africa/China etc. who can't affort to pay for an upgrade. Firefox, Xubuntu, Opera Mini, etc. are free. 4. Did you read the CA/B Forum email I linked to?

DanielDent 11y ago

(A) A significant percentage of users with legacy browsers could upgrade (by installing Chrome or Firefox, instead of relying on a woefully out of date bundled browser). If much of the internet stops working for them, I imagine knowledge of how to get it working again will spread pretty quickly. (B) It seems incredibly difficult (impossible?) to support graceful downgrade to older insecure approaches to TLS without also introducing the opportunity for a downgrade attack. Many of the TLS attacks we've witnessed over the last few years seem to be the direct result of bending over backwards to maintain backwards compatibility. I'm unconvinced it can be done safely.

eastdakota 11y ago
(A) If you've ever traveled across rural Africa or rural China or rural India and seen how many people access the Internet over original Android (if they're lucky) or Candy Bar Phones (if they're not) you'd realize the folly of your argument. (B) If someone can find a vulnerability to our implementation that we cannot fix then we'll drop support for SHA1 fallback. We'll also allow customers to turn off SHA1 fallback if they'd prefer. But that should be the choice of a site on a site-by-site basis, not imposed by the browser vendors.
- qb45 11y ago
  You may not even need to travel to the third world. Just wait until all those "smart" cars, refrigerators, etc. with "secure" (i.e. not user tamperable) update mechanisms come out of warranty.
  - eliaspro 11y ago
    As if they shipped updates to these devices within the warranty period in the first place.
ploxiln 11y ago
Amusingly, these users may not be able to download modern browsers from the official websites, which will of course be only available over TLS for obvious security reasons ...
- biot 11y ago
  You mean as the article explicitly points out with "Mozilla's one million downloads mistake"? I'm not sure how that could be considered amusing.
  - ploxiln 11y ago
    Unintended consequences. Unfortunate. But after you've seen enough of them, funny as well.

fulafel 11y ago

> automatically support SHA2 for modern browsers and fall back to SHA1 for legacy browsers that don't support SHA2 Doesn't this expose users to downgrade attack?

eastdakota 11y ago
Not in any way we've been able to think of — and we've spent a lot of time thinking about this and running it by the crypto community. But, if someone can demonstrate such an attack and we can't fix it technically, then we will drop support for the SHA1 fallback. And, on a customer-by-customer basis, we'll allow customer to turn off fallback if they're worried about a theoretical, if undemonstrated, attack.
- yaps8 11y ago
  Could you elaborate or do you have a source on the technique you use to mitigate downgrade attacks ?
  - ryan-c 11y ago
    No mitigation is required. Part of the data signed by the server certificate in the handshake is the entire ClientHello message. If a MitM attacker did a downgrade, they would have to change the ClientHello, and then the client would notice that what the server signed does not match what they sent.

ryan-c 11y ago

Are you looking at anything beyond the SignatureAlgorithms TLS extension? That is the obvious solution, but I know there are a few browsers that support sha256 certificates that don't send that extension.

eastdakota 11y ago
Yes. It's above my pay grade to walk through what we're doing to fingerprint TLS connections. However, we will provide a thorough blog on what we're doing and open source the algorithm we're using.
- ryan-c 11y ago
  "above my pay grade" is an odd phrase to use considering that your profile says you're the CEO, but I'm guessing you mainly mean you're not familiar with the details? I'm pretty sure I know exactly what you're doing, but I'm very interested to see how much of the secret sauce you'll share.
  - eastdakota 11y ago
    Yes, I was being a bit flip. But only a bit. We strive to be a company where engineering drives our priorities. While, a long, long time ago, I wrote a tiny bit of the code that became CloudFlare, there's no way I'd be trusted to do that today. There are engineers on our team whose salaries are far higher than mine. And, in this case, while I've been briefed on what we're doing, I don't feel comfortable enough with the details to comment on them. Thankfully, the people who are should be getting to work in London soon and I've asked that they watch this thread. PS - I have no problem sharing the complete "secret sauce" as the biggest risk here to us is not competition but that CAs after December 31, 2015 won't be allowed to issue SHA1 certificates anymore. The more organizations that can responsibly support SHA1 fallback, regardless of whether they're CloudFlare customers, the more likely it is we can convince the CA/B forum to allow the extension of the issuance of SHA1 certs to responsible parties.
    - 11y ago

hsivonen 11y ago

Since you already have the capability to do something different for SHA-256-intolerant browsers, I suggest you inject (this year with permission from your customers) banners informing the users of these browsers to switch to SHA-256-compatible browsers (Firefox on XP and Opera Mini on mobile) while they still can. It's not like the users "cannot" upgrade. They don't know how. Also, if you successfully lobbied an exception for you to keep using SHA-1, less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers or to non-browser clients--weakening security for everyone. (See https://cabforum.org/pipermail/public/2015-October/006100.html https://cabforum.org/pipermail/public/2015-October/006100.ht... )

viraptor 11y ago
This is wrong for so many reasons... 1. They're providing different valid signature, not changing the content of the communication itself. 2. Injecting anything into a valid response is a terrible idea. Broken cache, potentially breaking scripts relying on dom layout, messing up file fingerprints, etc. etc. 3. "It's not like the users "cannot" upgrade. They don't know how." No, lots of people cannot upgrade. Corporate policies, hardware requirements, weird device backwards compatibility, and many other reasons may prevent you from upgrading a system. 4. "less savvy deployers of TLS would get an opportunity to mix SHA-1 with modern browsers" They'll be marked as insecure very soon - this is a pretty good reason not to serve sha1 cert to a modern browser.
- hsivonen 11y ago
  1. Right. I suggested they probably should (with permission) to change the content. 2. The cache is a red herring. It wouldn't matter on the Cloudflare side if done on the edge. It wouldn't matter on the client, because the client would only see either the SHA-1 view or the SHA-2 view. Again with permission of their customers. If you have a SHA-2-intolerant browser, it's not checking for fingerprints. Chances are that scripts already break in legacy browsers. 3. The concern here isn't about corporate policies. A policy that says you have to stay on IE on an obsolete service pack of an obsolete system gets no sympathy. The concern here people in Africa/China etc. who can't affort to pay for an upgrade. Firefox, Xubuntu, Opera Mini, etc. are free. 4. Did you read the CA/B Forum email I linked to?