MD5 broken, certs whose signatures use MD5 now vulnerable
Nelson B Bolyard
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.
Nelson B Bolyard
> 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/
Chris Hills
> 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?
Nils Maier
A recording of the talk is available from:
http://81.163.130.141/streamdump/saal1/
Tag4-Saal1-Slot15:15--ID3023-making_the_theoretical_possible*
vanbroup
> 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/
Nelson B Bolyard
It's in section 5.1 of that paper
Chris Hills
Thanks. For the convenience of readers here, it reads as follows:-
RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network,
OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data
Networks GmbH, OU=TC TrustCenter Class 3
CA/emailAddress=certi...@trustcenter.de
RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division, CN=Thawte Premium Server
CA/emailAddress=premium...@thawte.com
verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International
Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign
Ben Bucksch
> the world's browsers (and PKI software in general) stop supporting MD5
> for use in digital signatures.
>
What is MD2? Is that a weaker predecessor of MD5? According to Wikipedia
(en/de), MD2 was created 1988 for 8bit processors, and MD5 was created
1991 by the same guy, as replacement for MD4, which was back then
considered not secure. In 2004, MD2 was demonstrated to be vulnerable.
Yet, when I went through the cert store, I see not only MD5 certs, but
MD2 certs as well. Partially from VeriSign. How comes? Why were they not
removed? Surely there was plenty of time to renew any cert issued under
them in the meantime.
Ben
rseg...@googlemail.com
...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
Eddy Nigg
> 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: star...@startcom.org
Blog: https://blog.startcom.org
Ben Bucksch
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).
Michael Ströder
> 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.
Ben Bucksch
There's a patch from Nelson to stop accepting them outright.
Ian G
> On 30.12.2008 17:39, 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.
>
> What is MD2? Is that a weaker predecessor of MD5?
Yes, MD stands for Message Digest, and is generally the series that were
created by Ron Rivest. Also see RC4, RC6, where RC stands for Ron's Cipher.
> Yet, when I went through the cert store, I see not only MD5 certs, but
> MD2 certs as well. Partially from VeriSign. How comes? Why were they not
> removed? Surely there was plenty of time to renew any cert issued under
> them in the meantime.
I guess they should both be deprecated.
Really, we should be moving to SHA2 at the moment, but there are
problems with a lot of software not supporting it.
If I was Mozilla (!) I would do the following:
* select a date by which all MD5 certs is to be declared broken
Softare updated after that time blows up when seeing an MD5.
* select a date soon after by which all SHA1 certs be declared broken
Software updated after that time will wipe the hard drive when a
SHA1 is spotted within range...
* announce this widely!!!
Give SHA1 at least a year, I'd say. MD5 can go ... today?
Lucky I'm not Mozilla :)
iang
PS: this does not apply to top-level roots. The hash/sig on those is
cosmetic. But subroots will also have
Florian Weimer
> Yet, when I went through the cert store, I see not only MD5 certs, but
> MD2 certs as well. Partially from VeriSign. How comes?
These are self-signatures only. They should not be evaluated. (I
hope that NSS doesn't even contain an MD2 implementation. 8-/)
Paul Hoffman
>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
Nelson B Bolyard
> 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.
The patch that I wrote only affects signatures on digital certificates.
> 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.
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.
> 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.
> 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
Ian G
> 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
Paul Hoffman
>Paul Hoffman wrote, On 2008-12-30 12:43:
>>> 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.
Kyle Hamilton
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 <ia...@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-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Jan Schejbal
AFAIK it is NOT possible to create a fake cert from a signature, you
need to generate two specially crafted certs at the same time and get
one of them signed. So existing intermediate certs should not be much
of a problem. Any cert issued on a user-submitted (thus possibly
malicious) CSR is.
Sincerely
Jan
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
Daniel Veditz
> At 1:16 PM -0800 12/30/08, Nelson B Bolyard wrote:
>> I should have written: digital signatures on 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
Nelson B Bolyard
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.
Nelson B Bolyard
> [...] is there any difficulty with announcing today that NSS is
> 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
Frank Hecker
> 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.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Nelson B Bolyard
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.
Ian G
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 majo...@metzdowd.com
>
>
Paul Hoffman
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. :-)
Ben Bucksch
> 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.
Yes. However, we can't be sure, and surely it's just a matter of time
until there's an exploit for that, too.
I would suggest to keep verifying them, but (in case of positive result)
let the UI show a message "The message was verified to be signed by the
author, but the signature of the message uses an algorithm that has been
broken since 2004-2008, so the signature might have been forged. While
that is unlikely and it is very likely that the message is indeed from
the signified author, it is not 100% sure anymore."
The icon would need to differentiate, too, to prevent a scenario where I
always sign with SHA-1 and the attacker uses MD5, and my recipient
doesn't notice.
geoff....@gmail.com
> 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).
Paul Hoffman
For grins, I just now bought a RapidSSL cert. Sequential serial number, RSA-with-SHA-1.