4 ms·

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 custo

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?
  - viraptor 11y ago
    > A policy [...] gets no sympathy. That's a completely different argument then. There's a lot of users in both categories. I just disagree with blanket "It's not like users "cannot" upgrade". I did read the CA/B post which mostly deals with... enterprise internal policies and security relaxation. So what are we talking about here now? Poor 3rd world countries that can't afford upgrades, or enterprises? Non-enterprise users don't have an intranet zone. Re. cloudflare. No, I still disagree. There's a number of reasons why it's important to get exactly what the server sends. Even with permission from the user MITM-ing traffic to inject banners is a terrible idea that's likely to break things.
    - hsivonen 11y ago
      The Cloudflare ancestor comment raised the concern about certain countries--not enterprise. The CA/B forum post is relevant regarding the downsides of exceptions even if the thread there focuses on enterprise issues.

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?
- viraptor 11y ago
  > A policy [...] gets no sympathy. That's a completely different argument then. There's a lot of users in both categories. I just disagree with blanket "It's not like users "cannot" upgrade". I did read the CA/B post which mostly deals with... enterprise internal policies and security relaxation. So what are we talking about here now? Poor 3rd world countries that can't afford upgrades, or enterprises? Non-enterprise users don't have an intranet zone. Re. cloudflare. No, I still disagree. There's a number of reasons why it's important to get exactly what the server sends. Even with permission from the user MITM-ing traffic to inject banners is a terrible idea that's likely to break things.
  - hsivonen 11y ago
    The Cloudflare ancestor comment raised the concern about certain countries--not enterprise. The CA/B forum post is relevant regarding the downsides of exceptions even if the thread there focuses on enterprise issues.