Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Follows Mozilla In Considering Early Ban On SHA-1 Certificates (csoonline.com)

Posted by samzenpus on from the you're-outta-here dept.

itwbennett writes: Following the first successful collision attack on the SHA-1 hashing algorithm last month, Mozilla said that it was considering a cut-off of July 1, 2016 to start rejecting all SHA-1 SSL certificates, ahead of an earlier scheduled date of Jan. 1, 2017. And now Microsoft is considering blocking the hashing algorithm on Windows by June next year.

6 of 47 comments (clear)

  1. Overrides by sexconker · · Score: 4, Insightful

    At least let me fucking override shit for my devices (UPSes, copiers, etc.) that have absolutely no ability to use anything other than the self-signed shit they come with.

    I'm fine with warning or blocking by default, but when those idiots remove my ability to do what I need to do (whitelist) I end up having to keep an older version of the browser with more holes in it just to connect to this UPS, that switch, this copier, etc.

    1. Re:Overrides by Zuriel · · Score: 5, Informative

      You can join the ranks of people holding on to WinXP virtual machines because they need them to administer that one device that needs a certain version of Java 1.4 and Firefox 3.6.

  2. Forced to click through by Sits · · Score: 4, Informative

    My experience of these changes is that you'll be forced to click through a warning in your browser even if you installed the certificate (or the root CA signing the certificate). The Microsoft page about no longer trusting SHA1 certs is confusing in this respect because it includes information about signing Windows binaries but it does say

    Windows [...] will no longer trust any code that is signed with a SHA-1 code signing certificate and that contains a timestamp value greater than January 1, 2016

    That document also says it only applies to certs that are in the Microsoft Root Certificate Program so ones you've manually installed might not be affected.

    This is slightly different to the Mozilla's SHA-1 deprecation information:

    After January 1, 2017, we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox.

    Perhaps this isn't the override you were thinking of but it doesn't sound like a total block.

  3. Re:git by jonwil · · Score: 3, Insightful

    No, this only affects SSL certificates using the SHA-1 hash. Git isn't using the SHA-1 hash in a way where generating a collision would have security risks so there is no reason why anything has to change for Git.

  4. Try not to be misguided by GuB-42 · · Score: 5, Insightful

    It's fine rejecting insecure certificates but sometimes, I'd rather have browsers get their priorities in order.
    If you go on a SSL website that uses a self-signed certificate or use a slightly outdated one, you are presented with a scary warning page with multiple clicks needed to get to it. However, plain HTTP goes right through even though it is less secure than SSL with any bogus certificate.

    Instead of a ban, I'm all for a rating system, like :
    - Strong : everything OK, strong crypto
    - Medium : slightly outdated, weaker crypto (SHA-1 could be on this level)
    - Weak : self-signed, completely outdated
    - None : HTTP
    - Dangerous : revoked, mismatched certificate, suspect behavior (such as a decrease in security from last visit)
    Only the "dangerous" category should trigger a warning, for the other categories, a different "lock" icon should be sufficient. Like the crossed-out "https" in Google Chrome.

    1. Re:Try not to be misguided by GuB-42 · · Score: 3, Insightful

      Indeed but posting sensitive data unencrypted is even worse and the browser won't say anything about it.
      The problem is that the browser has no simple way of knowing if the site is sensitive or not. The best it can do is to tell you clearly about the level of security so that you can react accordingly.
      "Dangerous" would be "worse that unencrypted" and should be reserved for cases where an attack is strongly suspected, cases where the error is unlikely to be simply the result of poor maintenance (outdated) or not wanting to deal with certificate authorities (self-signed).
      Also note that the examples I gave are not necessarily the best. The true conditions should be determined by actual data. But, I sometimes see myself going to the http version of a (non sensitive) site to avoid the warning, that's retarded and browsers shouldn't encourage this behavior. Also, wanting to visit a broken https site once doesn't mean I want to add an exception forever.