Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This area is a mess, there is now a difference between all major browsers and even between Firefox versions (With the Developer version complaining where regular FF does not).

For example firefox mentions SHA-1 insecurity when visting the google jquery CDN. [1] Chrome doesn't seem to care however and there are other sites where it is vice-versa.

[1] https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.mi...



It's frustrating that Chrome and Firefox don't give any details about why the connection to an insecure site fails. You just get a "connection reset" page in Chrome, and a generic SSL security error in Firefox.

I was deploying a virtual appliance and was baffled as to why I was unable to load the configuration web page from both Chrome and Firefox, until I visited the vendors web page and downloaded a hotfix that removed the SHA-1 certificate. This was an appliance released in 2015. It's a shame that the software vendor is releasing insecure virtual appliances, but it's also a shame that Google and Mozilla can't get their act together enough to display an informative error message.

How about "The site you are attempting to visit uses weak cryptographic algorithms, so the connection has been blocked."

And, please give advanced users a way to click through anyway. If this is a virtual appliance I'm deploying in an isolated network and I'm trying to access the administrative page, I should be allowed to get there, without some nanny state browser manufacturer determining that my crypto isn't safe enough.


> And, please give advanced users a way to click through anyway.

This already exists, and you can find it by reading through the source of Chromium.


Hmm, when Firefox errors for me it shows why. The usual reason is an expired certificate or a certificate for different domain.


It would have nothing to do with the cert being SHA1.


> With the Developer version complaining where regular FF does not

That's the right way to do it.

The Developer version should start complaining about outdated crypto years before the mainstream one. It should complain just after it's shown broken, and something better is available. Even if any attack is too expensive to perform.


Oh I agree, especially since the Dev version is usually a version ahead of release. (E.g. currently dev is 39.0a2).

It's just frustrating that there are so many different configurations to keep track of, it just feels like the whole hosting / cert industry has not handled this particularly well.


I've noticed the same thing re: Chrome not caring about subresources. Eg, we use Mixpanel, and mixpanel uses Akamai, and Akamai use CBC which is considered obsolete, but that doesn't trigger an 'outdated' warning.

I asked David Benjamin from Chrome and right now, sub resources aren't included in Chrome warnings (he thinks they should be though):

https://twitter.com/mikemaccana/status/597734101366476800


I may be mis-remembering here, but isn't Akamai on a special whitelist in firefox and chrome not to complain about CBC use?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: