12 ms·
Phasing Out SHA-1 on the Public Web
- user5994461 10y agoSummary: > per recommendations by NIST, issuance of SHA-1 certificates halted for the web last January. > In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered.
- r1ch 10y ago> overridable “Untrusted Connection” error Allowing users to click past security warnings is a really bad idea. How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM?
- kkl 10y agoAs far as I know almost all browser security warnings are overridable. The only one that comes to mind that does not have a click-through option is when a HSTS-enabled site fails a validation check.
- r1ch 10y agoThis one in particular feels very strange, since there's actually nothing bad actively happening with the connection, it's more of a policy decision.
- coldpie 10y agoMy understanding is that you can't know that nothing bad is actively happening with the connection since SHA-1 is no longer a strong hash, so it's basically (hand-wave) no different from an HTTP connection.
- bandrami 10y agoSo why don't they present any warning on HTTP connections? It's not "basically no different" from an HTTP connection, it's strictly better than an HTTP connection, but not as good as a cert made with a more modern hash. (For that matter the same argument applies to self-signed certificates: you're still keeping a third party from snooping on the phishing attempt the MITM is giving you, which is itself a Good Thing.)
- coldpie 10y agoI agree, insecure HTTPS should be treated like HTTP. But this issue has been argued to death, especially over self-signed certs, and our side lost.
- kevincox 10y agoAll major browsers are moving towards this. Starting with the tiny icons changing colors they are beginning to make HTTP as insecure. Yes, it's very slow but at least they have started moving.
- MrRadar 10y agoIf you have explicitly dis-trusted a certificate you can't click-through either.
- rocqua 10y agoI think HPKP might also suffer the same issue.
- kkl 10y agoIt depends on who you ask, but I personally don't think hard certificate validation failures are a bad thing.
- rocqua 10y agoHKPK has the potential problem that losing / compromising 2 keys leaves your site unavailable until the pin expires.
- kkl 10y agoThis is a common theme in this thread but I'll re-state it here: Web browsers cannot reliably distinguish between a configuration mistake and an attack. For this reason, I think hard HPKP fails are a good thing. For those who opt-in to HPKP, this is a risk one takes in exchange for greater control over certificate validation.
- amiraliakbari 10y agoQuite a few are only overridable in about:config, like: (if I recall correctly) * DH short exchange keys * NTLM1 passwords
- smoyer 10y agoI just went digging through the about:config options and couldn't find a way to force SHA-1 off. Why are they gradually rolling this out to beta users if they've purposely downloaded the Developer Edition?
- sbierwagen 10y agoThere's a couple fatal errors, ERR_CERT_CONTAINS_ERRORS, ERR_CERT_REVOKED, ERR_CERT_INVALID, ERR_CERT_NOT_IN_DNS: https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239c2a3c2f2364da9967d7/content/browser/ssl/ssl_policy.cc#L78 https://github.com/adobe/chromium/blob/cfe5bf0b51b1f6b9fe239... Not sure which one of these catches HSTS failures.
- Karunamon 10y agoNot allowing users to visit sites they are directing their computers to visit is a worse idea. The computer's job is to do what I tell it to do, not what Mozilla thinks is best for me. Forgetting this leads to wonderful issues like the eight year old dupe certificate bug: https://bugzilla.mozilla.org/show_bug.cgi?id=435013 https://bugzilla.mozilla.org/show_bug.cgi?id=435013
- tptacek 10y agoThe problem is that when there's an adversary in the picture (when there isn't, you may as well not encrypt at all), your computer isn't doing what you tell it to. TLS doesn't work if you don't enforce authentication. When people visit TLS URLs, they're asking the browser to establish a TLS connection. When attackers make that impossible, it's the job of the browser to refuse, on the user's behalf, to downgrade to an insecure connection.
- Karunamon 10y agoSplitting hairs. The user is almost never directly controlling whether the connection is to be secured or not, they're clicking on a link, and even less so nowadays with the existence of things like HSTS. It should be the browser's job to inform the user if it can't meet Mozilla's definition of security, but if accessing the information is more important at the time, it needs to get out of the way with an override and honor the intention of retrieving the information.
- tptacek 10y agoIf the net effect of the override is that users routinely click through the warnings, then the security of the whole system depends on how well we can educate random end-users on the TLS security model. That's not going to work.
- Karunamon 10y agoAnd your alternative of not allowing the user to access what they have clearly stated the intention to access isn't acceptable either.
- geofft 10y agoWhy is there a difference? At this point we believe that SHA-1 is vulnerable to MITMs. There are of course plenty of SHA-1-using sites that aren't being MITMed, but there are also plenty of sites with invalid certificates that aren't being MITMed, either (or sites that are being MITMed in benign ways), and the browser doesn't distinguish between those and real MITMs.
- jrochkind1 10y ago> How is a user supposed to know the difference between untrusted because of SHA-1 deprecation and untrusted because of a MITM? The whole reason SHA-1 is being deprecated is because it's judged no longer strong enough to protect against MITM. So I'd say it's intentional and desirable to treat SHA-1 like MITM, rather than to try to get the user to distinguish. User's don't have the capacity to distinguish between, and shoudln't have to, any category of "someone may be viewing and/or altering the content in this connection." They are moving to judging SHA-1 such a category.
- makomk 10y agoExcept that SHA-1 is strong enough to protect against MITM and will be for the immediately foreseeable future. Well-financed attackers could probably achieve a collision but that doesn't get you very far these days.
- jrochkind1 10y agoThen you disagree with the browser vendors decision to gradually remove support/warn for SHA-1 entirely? They seem to disagree with you.
- user5994461 10y agoSHA1 is perfectly fine. Warning: The above sentence may not be right in 5-10 years so they are starting to shut it down now. I personally find the schedule rather aggressive. Stop issuing certs this year, block it next year. What's the average cert lifetime? 1-2-3 years? This is gonna give some warnings.
- spydum 10y agoSHA1 may not be defeated yet, but since it has been found weak, we would be foolish to continue using it. It does us little good to wait until it's actually broken. Especially since we have sha2 as a sufficient replacement.
- 10y ago
- bandrami 10y agoDoesn't matter when you have CAs known to have backdated certificates to avoid the SHA-1 deadline and all they get is a temporary suspension with none of their issued certs being revoked. The weak point of PKI is not the crypto, it's the CAs, of which there are too many and for whom there is little to no accountability.
- geofft 10y agoRevoking certs doesn't ascribe accountability to the CAs, it ascribes accountability to the end users. Which isn't a bad thing, per se - it's just not one we're set up for right now. (If, for instance, the CAs started spreading FUD about each other getting revoked and encouraged users to buy and configure two certs from two different CAs, they'd make more money and we'd be in a better place security-wise.) Preventing the CA from taking any new business ascribes accountability to the CA.
- snuxoll 10y agoHrm, this just made me think. Is it possible to provide two different root chains for a X509 certificate? I'm guessing not, but if so depending on the business it might not be a bad idea (especially with HSTS, pin both intermediate roots so if one is revoked you could rely on trust to your secondary to continue service without hoping users hit your site after you updated your rules but before the root was revoked or distrusted).
- geofft 10y agoYou can't do this with a certificate (a certificate is a digital signature, and signing with two different CA keys gives you two different signatures). I suspect it's possible to do this with two different certificates for the same server key, presenting the backup leaf certificate as one of the certificates in the "chain" - SSL clients tend to just take the entire list of certificates and find an order for them, because server operators / implementations don't reliably send them in the right order. I don't know what clients deal with this well. Usually you'll have enough lead time to configure your servers to send the other certificate, though. All you need to do is buy it in advance and have it ready to deploy. And yeah, with HSTS you can definitely pin multiple intermediate roots.
- 0x0 10y agoDisabling SHA1 for only a subset of Firefox 51 users after release sounds like it'll cause a lot of confusion. "Is my computer hacked?" "It works for me!" etc etc
- AstroJetson 10y agoAnother good reason to not do the nonstop upgrades that FF keeps coming up with. I'm hanging in the upper 40's until this shakes out. I understand SHA1 is an issue, but I'm also confused by some things. Happy to have web pages be encrypted to keep my personal information from being captured. Not really sure why we are encrypting video streams from Youtube. Is a cat video something that we need to make more secure? And I agree with the comment that the problems are now coming back to the plethora of CA's that have popped up in the last few years.
- apendleton 10y ago> Is a cat video something that we need to make more secure? If the video you're watching is political in nature and you live in under an oppressive regime, absolutely. Youtube's not just cat videos.
- AgentME 10y agoYouTube should sort all of its videos into two groups, one group worthy of being secured and one group not. /s
- epmatsw 10y agoProbably should be on v45 rather than the upper v4*s if you're not doing upgrades, since it's the extended support release and will receive security fixes. Although opting to not take updates because Firefox is taking a harder security stance going forward seems a bit self-destructive...
- Karunamon 10y agoVideo decoder bugs are not unheard of - unless you want to leave open the possibility for someone to inject content of their choosing into code running on your computer, you lock it down.
- niftich 10y agoChrome [1], Edge, and IE [2] are also in various stages along between the continuum of not marking SHA-1 secure, warning about SHA-1, or blocking it altogether. [1] https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html https://security.googleblog.com/2015/12/an-update-on-sha-1-c... [2] https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation-roadmap/ https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat... EDIT: My frustration is that it's a bit difficult to grok who's warning against what when, and who's blocking what when, and who's giving unskippable errors to what when but I'll try to collect and distill this down because right now I have to look it up every time on blog posts that haven't been updated in years (-cough- Google)
- niftich 10y agoMy progress on summarizing this can be found at https://gist.github.com/anonymous/63e5ecb1de2511985255a98bce7ce2fe https://gist.github.com/anonymous/63e5ecb1de2511985255a98bce...
- toast0 10y agoThe short version is, if you care about modern browsers, you should be using SHA-256 already. If you care about ancient clients, you should be using SHA-1 still. If you care about both, you need to serve both[1], but your SHA-1 cert most likely expires at the end of this year anyway, unless you've gone through the effort for extraordinary issuance. [1] you'll most likely need to write code for this, I don't think it's widely supported. If you send SHA-1 to TLS1.0 and SSLv3, that's probably easier than triggering off the signature algorithms extension.
- tinalumfoil 10y ago> If you care about ancient clients, you should be using SHA-1 still I want to point out here that the oldest OS the newest Firefox supports is Windows XP SP2 [0], released 8 years ago, and a free upgrade from the original XP release 14 years ago. Unless you need support for last millennium's hardware you have no excuse for not supporting SHA-256. [0] https://en.wikipedia.org/wiki/Firefox#System_requirements https://en.wikipedia.org/wiki/Firefox#System_requirements
- jlgaddis 10y agoRed Hat uses SHA1 certificates for their CDN [0] (that provides packages for RHEL7 and, I assume, other products). It is a "private PKI" but their (current) intermediate and root certificates do not expire for a long, long time. Hopefully they'll move to a SHA256 root in the near future. [0]: https://cdn.redhat.com/ https://cdn.redhat.com/
- iancarroll 10y agoThe hash algorithm of a root certificate does not matter, because you explicitly trust the root certificate, and it is only signed by itself. Their intermediates and end-entity certificates should be updated, but still, the attacks PKIs are concerned about on SHA1 (a preimage attack) can only happen during issuance. However, if a second preimage attack on SHA1 were viable, all of the above would be invalid, and SHA1 would be permanently weakened for all digital signature uses.
- jlgaddis 10y agoThey say that this won't affect any SHA1 certificates signed by a root that has imported and trusted, but there's a lot of devices that ship with their own self-signed certificates installed. I hope all the vendors have away from SHA1 or there might be a lot of "broken" devices.
- kevincox 10y agoRemember that if you are trusting the cert itself this is irrelevant because you aren't verifying the chain (which is the part using the SHA1 hash). I presume this is what most embedded devices do. But yes, if you imported a SHA1 root you should probably consider distrusting it.
- Cyph0n 10y agoHonest question: why does a SSL certificate need SHA-2? In other words, where does hashing factor into the asymmetric crypto process? So from my cursory understanding of SSL, it uses RSA to exchange a symmetric key which is then used for the remainder of the session. I'm interested in crypto systems but still getting my feet wet, so a simplified answer would be really appreciated! Also, pointers to any articles or papers would be great.
- AgentME 10y agoI might be wrong, but I'm pretty sure that in practice, whenever someone signs some content, they actually sign a hash instead of the entire content so that the signature is a sane size. If you can create a hash collision between two pieces of content and then get someone to sign one of the pieces of content, then effectively you've gotten them to sign the other piece of content too without them knowing it. This happened a few years ago when SSL certificates still allowed MD5: http://www.zdnet.com/article/ssl-broken-hackers-create-rogue-ca-certificate-using-md5-collisions/ http://www.zdnet.com/article/ssl-broken-hackers-create-rogue...
- Rafert 10y agoIt's the hash of the certificate that is signed by a CA. Create a certificate with the same hash and you can transplant the signature. http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/ http://web.archive.org/web/20071226014140/http://www.cits.ru... demonstrates this with the MD5 hashes of two different PDF files, a letter of recommendation and a security clearance. It's common to sign hashes instead of the data, reasons are explained here: http://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa http://crypto.stackexchange.com/questions/12768/why-hash-the...
- Cyph0n 10y agoSo basically it's used to verify a MAC? What I'm imagining: CA takes the hash of the certificate, encrypts that with its private key, and appends it to the cert. Client's browser then takes hash of locally stored certificate, and uses the CA's public key to check that the MAC attached to the incoming cert is valid. I'm guessing SSL uses RSA-PSS[1] or something similar. Guess I'll have to do some reading when I find the time. [1]: http://www.onefs.com/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm http://www.onefs.com/emc-plus/rsa-labs/historical/raising-st...
- jlgaddis 10y agoIf you want to test out this behavior before it rolls out, you can set security.pki.sha1_enforcement_level (per Gervase Markham). A value of 1 means "entirely forbidden", a value of 3 means "forbidden for public roots". I can't speak for the behavior when using any other value.
- deleted 10y ago[deleted]
- MichaelMoser123 10y agoThe funny thing is that data deduplication storage systems work on sha-1 hashes to identify identical data blocks (two blocks are considered equal if the hash is equal - most systems don't care to check for collisions); they kept telling that the likelyhood of collisions is so astronomically small [1] ; i wonder if this statement is still considered to be true. [1] https://pibytes.wordpress.com/2013/02/09/deduplication-internals-hash-based-part-2/ https://pibytes.wordpress.com/2013/02/09/deduplication-inter...
- tptacek 10y agoSecurity systems must retain collision-resistance even in the presence of adversaries. If your design doesn't have adversaries, you can use cheaper, less secure hashes. Nobody would still recommend SHA-1, though.
- johnmaguire2013 10y agoI think many systems use two hashing methods to verify this claim (e.g. SHA-1 and MD5.) Are there any known collisions that affect both algorithms?
- AgentME 10y agoUsing two algorithms together is basically just creating a new hash algorithm (with a longer hash), which could also have collisions. If you know a technique for making SHA-1 collisions and a technique for making MD5 collisions, it's probably possible to combine the techniques and make a collision for SHA-1-MD5.
- yoha 10y agoYou are talking about making a combined hash function from MD5 and SHA-1. Keep in mind that it is not trivial. For instance, if you just output both SHA-1 and MD5, you are actually only as strong as the weakest hash function (trivially for preimage, but also true for collisions, see [1]). If you are interested in hash function combiners, have a look at Robust Multi-Property Combiners for Hash Functions [2], a recent paper on the topic. It aims at getting several properties at the same time (preimage resistance, collision resistance). For simpler schemes with a single property, just explore the bibliography at the end of the paper. [1] https://cryptopals.com/sets/7/challenges/52 https://cryptopals.com/sets/7/challenges/52 [2] https://eprint.iacr.org/2016/723 https://eprint.iacr.org/2016/723
- ptaipale 10y agoDo I understand correctly, when Mozilla says: In early 2017, Firefox will show an overridable “Untrusted Connection” error whenever a SHA-1 certificate is encountered that chains up to a root certificate included in Mozilla’s CA Certificate Program. SHA-1 certificates that chain up to a manually-imported root certificate, as specified by the user, will continue to be supported by default; this will continue allowing certain enterprise root use cases, though we strongly encourage everyone to migrate away from SHA-1 as quickly as possible. This means that self-signed certificates, approved as an exception in browser, will continue to work because they are do not chain up to a root certificate included in Mozilla’s CA Certificate Program? I.e. if user has confirmed an exception for self-signed certificate, it is not impacted by this change in Mozilla?
- kevincox 10y agoThe signature on a self signed certificate doesn't matter as the certificate itself is trusted. However if you add your own CA then yes, I believe it will continue to work for the near future. (You should be moving away anyways though ;) )
- SiVal 10y agoShould SHA-1 be phased out of git, too? I understand that it's more of an issue for certs, but it's still a bit of an issue for anything that uses SHA-1. I'm just asking, not advocating, because the answer will depend on both benefits and costs, and I don't know enough about either in the case of git.
- kevincox 10y agoI don't think git's use was really intended for security. That being said it would be interesting to upgrade it and achieve security.
- petertodd 10y agoRegardless of whether or not it was intended for security, it is used for security now, via signed git commits and git tags. Lots of projects rely on them, and there aren't good alternatives yet; using third-party services like GitHub without signed git commits is very foolish. Fortunately it's only becoming possible for attackers to create pairs of messages that have the same SHA1 hash; an attacker still can't create a collision between a message of their choosing and an arbitrary SHA1 hash, and that type of attack is probably a long way off. But that's not much safety margin!
- ploxiln 10y agoA scheme to generate (and sign) a SHA512 hash that more directly incorporates the full state of the repo was invented, and is used by some projects incl. nodejs https://github.com/cgwalters/git-evtag https://github.com/cgwalters/git-evtag https://github.com/nodejs/node/issues/7579 https://github.com/nodejs/node/issues/7579 I personally think it's overkill
- petertodd 10y agoOh, interesting! I do something not unlike that with my OpenTimestamps git commit signing: https://petertodd.org/2016/opentimestamps-git-integration https://petertodd.org/2016/opentimestamps-git-integration I don't describe it in that post unfortunately, as I still consider the git tree "rehashing" support to be alpha-level, but I'll look into git-evtag.
- DyslexicAtheist 10y agowhat about retiring TLS 1.2 then? [banking industry gasps]
- toast0 10y agoDid you mean TLS 1.0? Retiring 1.2 seems a bit premature, since 1.3 isn't finalized.
- DyslexicAtheist 10y agono I was talking TLS 1.2 https://www.ietf.org/mail-archive/web/tls/current/msg21278.html https://www.ietf.org/mail-archive/web/tls/current/msg21278.h...
- d33 10y agoWhat about BitTorrent? It also heavily uses SHA1 - basically for everything from computing infohash to data integrity checks.
- TazeTSchnitzel 10y agoWell, a nation state attacker might be able to produce a fake block filled with garbage for a file and have your client accept it. Unless BitTorrent relies on digital signatures somewhere, that's probably the worst of it.
- d33 10y agoOr worse, use it to infect the victim if it's executable/exploitable.
- cheiVia0 10y agoWhat about git? It also heavily uses SHA1
- majewsky 10y agoSee this sibling thread about the same topic: https://news.ycombinator.com/item?id=12738567 https://news.ycombinator.com/item?id=12738567