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

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.

Comments

Overrides

[sexconker]

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.

Re:git

[jonwil]

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.

Try not to be misguided

[GuB-42]

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.

Re:Try not to be misguided

[GuB-42]

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.

Re:Try not to be misguided

[Erik Hensema]

Then the first visit is always unsafe since no data is known. Now you can get valid data by checking the certificate, but since that's not what the OP wants, what's left?