Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On Dec 31 2008, 3:10 pm, Paul Hoffman phoff...@proper.com wrote: I read that blog posting to mean that they were going to keep issuing certs using MD5 signatures, but would use unpredictable sequence numbers like other VeriSign CAs do. Someone can validate that by buying a new cert from them. :-) I had two certs from RapidSSL, and they offered free renewal with SHA-1 signatures instead. The serial numbers apparently remained sequential (very small difference between them, explicable by the short interval). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
At 11:05 AM -0800 1/2/09, geoff.tol...@gmail.com wrote: On Dec 31 2008, 3:10 pm, Paul Hoffman phoff...@proper.com wrote: I read that blog posting to mean that they were going to keep issuing certs using MD5 signatures, but would use unpredictable sequence numbers like other VeriSign CAs do. Someone can validate that by buying a new cert from them. :-) I had two certs from RapidSSL, and they offered free renewal with SHA-1 signatures instead. The serial numbers apparently remained sequential (very small difference between them, explicable by the short interval). For grins, I just now bought a RapidSSL cert. Sequential serial number, RSA-with-SHA-1. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Frank Hecker wrote, On 2008-12-31 10:48 PST: Nelson B Bolyard wrote: A representative of Verisign has posted a response to this issue at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php The VeriSign post is not 100% clear on exactly how VeriSign has removed this vulnerability (to quote the blog post). Is it simply that VeriSign has now discontinued using MD5 when issuing RapidSSL certificates and other end-entity certificates under the various VeriSign/thawte/GeoTrust brands? Material elsewhere in the post seems to imply that this was the only corrective action taken (or that needed to be taken), but I don't recall it being made explicit in the post. After reading the above-cited blog post, I conclude that RapidSSL was changed to stop using MD5, and that other Verisign-controlled CAs still plan to stop using MD5 before the end of January. It's not clear to me that the other CAs that still use MD5 have been made invulnerable, or how that was actually accomplished, if it was. There are a number of ways (besides replacing MD5) that could have been used to make the CAs less vulnerable, including (but not limited to) - switching to a large random serial number instead of a sequential (and hence predictable) serial number - issuing certs with less predictable notBefore and notAfter validity dates. (Just randomizing the number of seconds in each would go a long way.) - cease issuing certs from those CAs until they can be switched to SHA1. It would be nice to know which (if any) of those measures have been taken, because that would increase my confidence that the CAs actually have been made less vulnerable. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Personally, I cannot see that there is an imminent danger. The attack requires substantial resource, unpublished techniques, dramatic timing attempts and retrys and no doubt other caveats ... and will be stopped whenever MD5 is dropped, which is apparantly very soon or already. See the report of Hal Finney below (one of the half dozen most reliable people in security crypto work). (It would seem that the maximum Mozilla needs to do is simply stop accepting MD5. E.g., like Verisign, advance plans to drop it end Jan forward to end today.) Although the attack is widely puffed up as the end of the world as we know it, it looks quite narrow and harmless, as most of these are. Or? iang On 30/12/08 20:51, Hal Finney wrote: Re: http://www.win.tue.nl/hashclash/rogue-ca/ Key facts: - 6 CAs were found still using MD5 in 2008: RapidSSL, FreeSSL, TC TrustCenter AG, RSA Data Security, Thawte, verisign.co.jp. Out of the 30,000 certificates we collected, about 9,000 were signed using MD5, and 97% of those were issued by RapidSSL. RapidSSL was used for the attack. - The attack relies on cryptographic advances in the state of the art for finding MD5 collisions from inputs with different prefixes. These advances are not yet being published but will presumably appear in 2009. - The collision was found using Arjen Lenstra's PlayStation Lab and used 200 PS3s with collectively 30 GB of memory. The attack is in two parts, a new preliminary birthdaying step which is highly parallelizable and required 18 hours on the PS3s, and a second stage which constructs the actual collision using 3 MD5 blocks and runs on a single quad core PC, taking 3 to 10 hours. - The attack depends on guessing precisely the issuing time and serial number of the good certificate, so that a colliding rogue certificate can be constructed in advance. The time was managed by noting that the cert issuing time was reliably 6 seconds after the request was sent. The serial number was managed because RapidSSL uses serially incrementing serial numbers. They guessed what serial number would be in use 3 days hence, and bought enough dummy certs just before the real one that hopefully the guessed serial number would be hit. - The attacks were mounted on the weekend, when cert issuance rates are lower. It took 4 weekends before all the timing and guessing worked right. The cert was issued November 3, 2008, and the total cert-purchase cost was $657. - The rogue cert, which has the basicConstraints CA field set to TRUE, was intentionally back-dated to 2004 so even if the private key were stolen, it could not be misused. My take on this is that because the method required advances in cryptography and sophisticated hardware, it is unlikely that it could be exploited by attackers before the publication of the method, or the publication of equivalent improvements by other cryptographers. If these CAs stop issuing MD5 certs before this time, we will be OK. Once a CA stops issuing MD5 certs, it cannot be used for the attack. Its old MD5 certs are safe and there is no danger of future successful attacks along these lines. As the paper notes, changing to using random serial numbers may be an easier short-term fix. Therefore the highest priority should be for the six bad CAs to change their procedures, at least start using random serial numbers and move rapidly to SHA1. As long as this happens before Eurocrypt or whenever the results end up being published, the danger will have been averted. This, I think, is the main message that should be communicated from this important result. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
At 6:48 PM + 12/31/08, Frank Hecker wrote: Nelson B Bolyard wrote: A representative of Verisign has posted a response to this issue at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php The VeriSign post is not 100% clear on exactly how VeriSign has removed this vulnerability (to quote the blog post). Is it simply that VeriSign has now discontinued using MD5 when issuing RapidSSL certificates and other end-entity certificates under the various VeriSign/thawte/GeoTrust brands? Material elsewhere in the post seems to imply that this was the only corrective action taken (or that needed to be taken), but I don't recall it being made explicit in the post. I read that blog posting to mean that they were going to keep issuing certs using MD5 signatures, but would use unpredictable sequence numbers like other VeriSign CAs do. Someone can validate that by buying a new cert from them. :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Nelson B Bolyard wrote, On 2008-12-30 08:39: For years we've been reading stories of researchers making more and more progress on breaking MD5. Well, now they've made enough progress that it is possible to forge some certificates that use MD5 in their signatures. You're going to be seeing a lot of breathless stuff in the media about this, such as http://blogs.zdnet.com/security/?p=2339 I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30/12/08 17:47, Nelson B Bolyard wrote: I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from our own certificate stores? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30 dec, 17:49, Chris Hills c...@chaz6.com wrote: In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from our own certificate stores? Networking4all created a tool to check if a certificate in the chain has been signed with a insecure algorithm Example: https://www.networking4all.com/en/support/tools/site+check/?fqdn=www.verisign.com You can check all sites on: https://www.networking4all.com/en/support/tools/site+check/ ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30.12.2008 17:39, Nelson B Bolyard wrote: For years we've been reading stories of researchers making more and more progress on breaking MD5. Well, now they've made enough progress that it is possible to forge some certificates that use MD5 in their signatures. You're going to be seeing a lot of breathless stuff in the media about this, such as http://blogs.zdnet.com/security/?p=2339 The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. A recording of the talk is available from: http://81.163.130.141/streamdump/saal1/ Tag4-Saal1-Slot15:15--ID3023-making_the_theoretical_possible* ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Chris Hills wrote, On 2008-12-30 08:49: On 30/12/08 17:47, Nelson B Bolyard wrote: I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from our own certificate stores? It's in section 5.1 of that paper ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On Dec 30, 4:49 pm, Chris Hills c...@chaz6.com wrote: On 30/12/08 17:47, Nelson B Bolyard wrote: I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from our own certificate stores? ...also note that (at least some of) Eddy Nigg's StartCom certs/ intermediates (StartCom Class 3 Primary Intermediate Free CA I've checked) are affected. The Networking4All checker confirms this for at least the *.startcom.org cert: https://www.networking4all.com/en/support/tools/site+check/?fqdn=www.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 12/30/2008 08:17 PM, rseges...@googlemail.com: The Networking4All checker confirms this for at least the *.startcom.org cert: https://www.networking4all.com/en/support/tools/site+check/?fqdn=www.startcom.org This certificate expires in less than two days and will be replaced tonight anyway. Incidentally it's the last one we use ourselves signed from our old root. This root is scheduled to be removed during 2010. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30.12.2008 17:49, Chris Hills wrote: On 30/12/08 17:47, Nelson B Bolyard wrote: I meant to add: The paper with the real facts is seen at http://www.win.tue.nl/hashclash/rogue-ca/ In the meantime, could a list of the affected CA's be made available so that we may remove the trust bits from our own certificate stores? FWIW, you can check it yourself (it's a bit laborious, due to the many root certs, which is part of the problem): Firefox/Thunderbird Preferences | Advanced | Certificates | View Certificates | Authorities | select the cert | doubleclick or View... | Details | Certificate Signature Algorithm To remove one, you can either Edit... (back on cert list dialog) and uncheck all trust, or Delete... it (which has the same effect: it comes back when you re-enter the dialog, but then with all trust unchecked). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Nelson B Bolyard wrote: The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. It would be nice if the user could define in about:config to stop accepting certs with signatures made with MD5 like the config parameters for symmetric ciphers (parameters security.ssl3.*). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30.12.2008 19:50, Michael Ströder wrote: Nelson B Bolyard wrote: The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. It would be nice if the user could define in about:config to stop accepting certs with signatures made with MD5 like the config parameters for symmetric ciphers (parameters security.ssl3.*). There's a patch from Nelson to stop accepting them outright. https://bugzilla.mozilla.org/show_bug.cgi?id=471539 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote: The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. That is not what the paper advocates. It suggests stopping support for MD5 in the signature algorithm for *trust anchors*, not in other messages. It should probably have also made the same recommendation for the signature algorithm in intermediate certificates as well (I take partial blame for it not saying that...). The attack outlined is a collision attack, not a preimage attack. Signed messages that use MD5 in the signature algorithm, but where the content of the message is determined by the signer, are not affected by the attack. Thus, if we stop supporting MD5 for use in digital signatures we will needlessly affect probably tens of thousands of legitimate web sites for which there is absolutely no known attack. Of course, the trust anchor store for Firefox should be revised as soon as possible to include no trust anchors that use MD5 in their signature algorithm. Similarly, the trust anchor store for Firefox should be revised as soon as possible to include no trust anchors that use MD5 in their signature algorithm. Although the attack described in the paper does not directly affect MD2, it is very likely that the same math used by the researchers could be applied to MD2 as well. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
On 30/12/08 22:16, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-12-30 12:43: Well, of course, it's not the signature on the root CA cert itself that matters. It's the signature algorithm used on the certs issued by the root. And the issuer is always free to change that whenever they wish. (Maybe they would have to change their CP/CPS if they did that.) No change to the trust anchor itself is required. That is as I understood (and I was surprised at Paul's comment, it seems backwards?) Either way, is there any difficulty with announcing today that NSS is going to deprecate MD5 and earlier algorithms, totally, for all purposes, including Firefox and Thunderbird. (Leave off the date as to when the rejection will take effect.) The point is not when NSS does it, or when Firefox does it, but when all the CAs stop issuing them, and replace them. The more noise we make now, the earlier they are likely to act. (figure out a date later...) I propose it be announced today if not sooner ! Votes, disagreements? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-12-30 12:43: At 8:39 AM -0800 12/30/08, Nelson B Bolyard wrote: The upshot of this is probably going to be that, in a short time, all the world's browsers (and PKI software in general) stop supporting MD5 for use in digital signatures. I should have written: digital signatures on certificates. Actually, you were quoting someone else. The patch that I wrote only affects signatures on digital certificates. Good. I am quite concerned if we start affecting signatures in things like Thunderbird. Agreed. For that matter, we could permit MD5 signatures on certs whose serial numbers are known to be random rather than sequential. But that's not easy to determine by examining the cert itself. Correct. Let's not add a second layer of heuristics here. Of course, the trust anchor store for Firefox should be revised as soon as possible to include no trust anchors that use MD5 in their signature algorithm. Well, of course, it's not the signature on the root CA cert itself that matters. It's the signature algorithm used on the certs issued by the root. And the issuer is always free to change that whenever they wish. (Maybe they would have to change their CP/CPS if they did that.) No change to the trust anchor itself is required. Arrgh, I totally forgot that. alg-on-TA != alg-on-certs. One day I'll have that more firmly in my brain. Similarly, the trust anchor store for Firefox should be revised as soon as possible to include no trust anchors that use MD5 in their signature algorithm. The last two sentences are both about MD5. Did you mean MD2 Yes, sorry. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
My two cents: Trust anchors don't particularly need to have their hashes secure, because they're obtained through a process other than comparing their hash to an encrypted copy of the hash. It's certificates which are NOT trust anchors which are subject to the problem. -Kyle H On Tue, Dec 30, 2008 at 1:38 PM, Ian G i...@iang.org wrote: On 30/12/08 22:16, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2008-12-30 12:43: Well, of course, it's not the signature on the root CA cert itself that matters. It's the signature algorithm used on the certs issued by the root. And the issuer is always free to change that whenever they wish. (Maybe they would have to change their CP/CPS if they did that.) No change to the trust anchor itself is required. That is as I understood (and I was surprised at Paul's comment, it seems backwards?) Either way, is there any difficulty with announcing today that NSS is going to deprecate MD5 and earlier algorithms, totally, for all purposes, including Firefox and Thunderbird. (Leave off the date as to when the rejection will take effect.) The point is not when NSS does it, or when Firefox does it, but when all the CAs stop issuing them, and replace them. The more noise we make now, the earlier they are likely to act. (figure out a date later...) I propose it be announced today if not sooner ! Votes, disagreements? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Paul Hoffman wrote: At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote: I should have written: digital signatures on certificates. The patch that I wrote only affects signatures on digital certificates. Good. I am quite concerned if we start affecting signatures in things like Thunderbird. Why is that any different? The fake CA these guys produced could be used to issue forged S/MIME certs too. Or authenticode certs. This problem is NOT limited to SSL. Or am I completely misunderstanding you? -Dan Veditz ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Daniel Veditz wrote, On 2008-12-30 17:37: Paul Hoffman wrote: At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote: I should have written: digital signatures on certificates. The patch that I wrote only affects signatures on digital certificates. Good. I am quite concerned if we start affecting signatures in things like Thunderbird. Why is that any different? The fake CA these guys produced could be used to issue forged S/MIME certs too. Or authenticode certs. This problem is NOT limited to SSL. Or am I completely misunderstanding you? Dan, I believe Paul was suggesting that he did not want to see signatures on email messages themselves be invalidated just because they use MD5. The email messages themselves have different vulnerability characteristics than the signatures on the certificates, because the latter may be much more predictable. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 broken, certs whose signatures use MD5 now vulnerable
Ian G wrote, On 2008-12-30 13:38: [...] is there any difficulty with announcing today that NSS is going to deprecate MD5 and earlier algorithms, totally, for all purposes, including Firefox and Thunderbird. (Leave off the date as to when the rejection will take effect.) The NSS team is preparing for a possible move in that direction. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=471539 But there's presently no decision made about when it might happen. The point is not when NSS does it, or when Firefox does it, but when all the CAs stop issuing them, and replace them. The more noise we make now, the earlier they are likely to act. (figure out a date later...) A representative of Verisign has posted a response to this issue at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php I propose it be announced today if not sooner ! Votes, disagreements? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto