It seems that part of the proposed solution is to get people to move from
MD5-signed to SHA1-signed. There will be a certain amount of resistance.
What I was suggesting was the use of the revocation mechanism as part of
the "stick" (think carrot-and-stick) in a campaign to replace MD5-based
certs. If there is a credible threat to MD5-signed certs, then forcing
their retirement would seem to be a reasonable reaction, but everyone here
knows how successful "voluntary" conversion strategies typically are.
Either we take the potential for transparent MitM attacks seriously, or
we do not. I'm sure the NSA would prefer "not."
As for the points raised in your message, yes, there are additional
problems with clients that have not taken this seriously. It is, however,
one thing to have locks on your door that you do not lock, and another
thing entirely not to have locks (and therefore completely lack the
ability to lock). I hope that there is some serious thought going on in
the browser groups about this sort of issue.
We cannot continue to justify security failure on the basis that a
significant percentage of the clients don't support it, or are broken in
their support. That's an argument for fixing the clients.
At a more basic level, though, isn't failure guaranteed for these kind of clients (web browsers) so long as users are conditioned to click OK/Continue for every SSL certificate failure that is reported to them?
If I was attempting a large-scale man-in-the-middle attack, perhaps I'd be happier to do no work and intercept 5% of sessions (those who click OK on a certificate that is clearly bogus) than I would to do an enormous amount of work and intercept 100% (those who would see no warnings). And surely 5% is a massive under-estimate.
Either we take the potential for transparent MitM attacks seriously, or
we do not. I'm sure the NSA would prefer "not."
As for the points raised in your message, yes, there are additional
problems with clients that have not taken this seriously. It is, however,
one thing to have locks on your door that you do not lock, and another
thing entirely not to have locks (and therefore completely lack the
ability to lock). I hope that there is some serious thought going on in
the browser groups about this sort of issue.
Something worth noting. I am not sure about Firefox, but with IE 7 (and IE
6 when CRL validation is enabled) when a the browser encounters a revoked
certificate, it does not present the usual "yes/no" box. Instead, one gets
a message basically saying "certificate is revoked, you can't continue,
period". Now, if the user is smart enough they can go into the advanced
settings and turn off CRL validation and get around the error. Though not
bullet-proof, that is better than just a "yes/no" box.
In a perfect world, all certificate checks should result in a
non-bypass-able error message. But the wide spread nature of self-signed
certs and the lack of knowledge of many tech staff would make this a very
hard position for any web browser vendor to swallow. In the near term, it
would be nice to see browsers start to implement mandatory CRL checking for
all non-self signed/root-level certificates. Ensuring that a each tier of
the PKI has a time/signature valid CRL published (note, many root
certificates do not publish CRL paths for themselves, hence the exception
for them and self-signed).
Speaking of this attack specifically. Publishing a CRL that would revoke
this certificate would be basically useless. Since the CRL path that is
used to valid a certificate is contained in the certificate, not the issuing
CA's certificate. And a potential attacker would have little reason to
point to a CRL that would incriminate themselves. (Note, there are a *few*
applications that actually do mandate strict CRL checking, and thereby
require the certificate to point to a valid CRL signed by the issuing CA,
though they are not very common).
It seems that part of the proposed solution is to get people to move from
MD5-signed to SHA1-signed. There will be a certain amount of resistance.
What I was suggesting was the use of the revocation mechanism as part of
the "stick" (think carrot-and-stick) in a campaign to replace MD5-based
certs. If there is a credible threat to MD5-signed certs, then forcing
their retirement would seem to be a reasonable reaction, but everyone here
knows how successful "voluntary" conversion strategies typically are.
A CA statement that they won't issue MD5-signed certificates in the
future should be sufficient. There's no need to reissue old
certificates, unless the CA thinks other customers have attacked it.
Either we take the potential for transparent MitM attacks seriously, or
we do not. I'm sure the NSA would prefer "not."
I doubt the NSA is interested in MITM attacks which can be spotted by
comparing key material.
Either we take the potential for transparent MitM attacks seriously, or
we do not. I'm sure the NSA would prefer "not."
As for the points raised in your message, yes, there are additional
problems with clients that have not taken this seriously. It is, however,
one thing to have locks on your door that you do not lock, and another
thing entirely not to have locks (and therefore completely lack the
ability to lock). I hope that there is some serious thought going on in
the browser groups about this sort of issue.
Would using the combination of both MD5 and SHA-1 raise the computational
bar enough for now, or are there other good prospects for a harder to crack
hash?
Would using the combination of both MD5 and SHA-1 raise the computational
bar enough for now,
I have never seen this recommended (and I do try and follow this).
or are there other good prospects for a harder to crack
hash?
The Federal Information Processing Standard 180-2, Secure Hash Standard, specifies algorithms for computing five cryptographic hash functions — SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.
(a) SHA-1 was not broken as badly. The best attack is, as I recall,
2^63, which is computationally infeasible without special-purpose
hardware.
(b) Per a paper Eric Rescorla and I wrote, there's no usable
alternative, since too many protocols (including TLS) don't negotiate
hash functions before presenting certificates. In particular, this
means that a web site can't use SHA-256 because (1) most clients won't
support it; and (2) it can't tell which ones do. (Note that this
argument applies just as much to combinations of hash functions --
anything that *the large majority of today's* browsers don't implement
isn't usable.)
These two points lead us to (c): security is a matter of economics, not
algorithms. Switching now to something else loses more in connectivity
or customers than you would lose from such an expensive attack.
Everyone seems to be stampeding to SHA-1..yet it was broken in 2005.
So we trade MD5 for SHA-1? This makes no sense.
(a) SHA-1 was not broken as badly. The best attack is, as I recall,
2^63, which is computationally infeasible without special-purpose
hardware.
special purpose? or lots of commodity? like the Amazon-EC2 example
used in the cert issue? (or PS3s or...)
(b) Per a paper Eric Rescorla and I wrote, there's no usable
alternative, since too many protocols (including TLS) don't negotiate
hash functions before presenting certificates. In particular, this
means that a web site can't use SHA-256 because (1) most clients won't
support it; and (2) it can't tell which ones do. (Note that this
argument applies just as much to combinations of hash functions --
anything that *the large majority of today's* browsers don't implement
isn't usable.)
This is a function of an upgrade (firefox3.5 coming 'soon!') for
browsers, and for OS's as well, yes? So, given a future flag-day (18
months from today no more MD5, only SHA-232323 will be used!!)
browsers for the majority of the market could be upgraded. Certainly
there are non-browsers out there (eudora, openssl, wget,
curl..bittorrent-clients, embedded things) which either will lag more
or break all together.
These two points lead us to (c): security is a matter of economics, not
algorithms. Switching now to something else loses more in connectivity
or customers than you would lose from such an expensive attack.
only if not staged out with enough time to roll updates in first, right?
>
>> Everyone seems to be stampeding to SHA-1..yet it was broken in
>> 2005. So we trade MD5 for SHA-1? This makes no sense.
>>
> (a) SHA-1 was not broken as badly. The best attack is, as I recall,
> 2^63, which is computationally infeasible without special-purpose
> hardware.
>
special purpose? or lots of commodity? like the Amazon-EC2 example
used in the cert issue? (or PS3s or...)
Let's do the arithmetic. 'openssl speed sha1' on my desktop -- a 3.4
Ghz Dell -- manages 1583237 16-byte blocks in 2.92 seconds, or
~542204/second. Let's assume that for an attack to be economical, the
calculations have to be completed within 30 days. My machine could do
1405B hashes in that time frame. But I need 2^63 of them, which means
I need 6.5 million machines cooperating. Not impossible for BOINC, but
I don't think that EC2 could handle it.
> (b) Per a paper Eric Rescorla and I wrote, there's no usable
> alternative, since too many protocols (including TLS) don't
> negotiate hash functions before presenting certificates. In
> particular, this means that a web site can't use SHA-256 because
> (1) most clients won't support it; and (2) it can't tell which ones
> do. (Note that this argument applies just as much to combinations
> of hash functions -- anything that *the large majority of today's*
> browsers don't implement isn't usable.)
This is a function of an upgrade (firefox3.5 coming 'soon!') for
browsers, and for OS's as well, yes? So, given a future flag-day (18
months from today no more MD5, only SHA-232323 will be used!!)
browsers for the majority of the market could be upgraded. Certainly
there are non-browsers out there (eudora, openssl, wget,
curl..bittorrent-clients, embedded things) which either will lag more
or break all together.
Have you looked at the statistics on upgrades lately? Not a pretty
picture... See, among others,
>
> These two points lead us to (c): security is a matter of economics,
> not algorithms. Switching now to something else loses more in
> connectivity or customers than you would lose from such an
> expensive attack.
>
only if not staged out with enough time to roll updates in first,
right?
From all the data I've seen, very many machines are *never* upgraded, so
the proper metric for "enough time" is "computer lifetime".
Firefox 3 does handle SHA-256/384/512; I don't think IE7 does.
This is a function of an upgrade (firefox3.5 coming 'soon!') for
browsers, and for OS's as well, yes? So, given a future flag-day (18
months from today no more MD5, only SHA-232323 will be used!!)
browsers for the majority of the market could be upgraded. Certainly
there are non-browsers out there (eudora, openssl, wget,
curl..bittorrent-clients, embedded things) which either will lag more
or break all together.
I think you might be downplaying the size of the problem here. X.509 and
TLS/SSL isn't just used for browsers, but for a wide variety of places
where there is a requirement for PKI based security. So when you talk
about a flag day for dealing with SHA-X (where X != 1), have you considered
the logistical problems of upgrading all those embedded devices around the
world? The credit card terminals? The tiny CPE vpn units? The old
machine in the corner which handles corporate sign-on, where the vendor has
now gone bust and no-one has the source code. And the large web portal
which had a whole bunch of local apache customisations based on apache
1.3.x and where the original developers left for greener pa$ture$, and
no-one in-house really understands what they did any longer. Etc, etc.
It's different if you have a protocol which allows parameter negotiation to
deal with issues like this, but not so good when you don't.
I think you might be downplaying the size of the problem here. X.509 and
TLS/SSL isn't just used for browsers, but for a wide variety of places
where there is a requirement for PKI based security. So when you talk
about a flag day for dealing with SHA-X (where X != 1), have you considered
the logistical problems of upgrading all those embedded devices around the
world?
They won't be affected by the flag day, because the flag day is set by
the relying party (that is, the browser), not the CA.
If you've got a real PKI deployment, by definition, you've got
procedures to deal with sudden advances in published cryptanalysis
(even if it involves posting guards at certain buildings, instead of
relying on smartcards for access control). The problematic areas are
those where cryptography is used to comply with some checklist (or for
PR purposes), and not for its security properties. In those
environments, algorithm changes can never justify the associated
costs.
This is a function of an upgrade (firefox3.5 coming 'soon!') for
browsers, and for OS's as well, yes? So, given a future flag-day (18
months from today no more MD5, only SHA-232323 will be used!!)
browsers for the majority of the market could be upgraded. Certainly
there are non-browsers out there (eudora, openssl, wget,
curl..bittorrent-clients, embedded things) which either will lag more
or break all together.
I think you might be downplaying the size of the problem here. X.509 and
I wasn't, not intentionally.. I was trying to address the problem
which the researchers harped on, and which seems like the hot-button
for many folks: "oh my, someone can intercept https silently!!"
I understand there are LOTS of things out there using certs for all
manner of not-http things. I also understand that by telling a browser
class that they shouldn't accept anything but sha-X seems workable. I
suppose having the CA's kick out ONLY SHA-X is a bad plan, but ...
maybe letting cert requestors select the hash funciton (not md5) is
better? (or a step in the right direction at least)
TLS/SSL isn't just used for browsers, but for a wide variety of places
where there is a requirement for PKI based security. So when you talk
about a flag day for dealing with SHA-X (where X != 1), have you considered
the logistical problems of upgrading all those embedded devices around the
world? The credit card terminals? The tiny CPE vpn units? The old
I had... yup.
machine in the corner which handles corporate sign-on, where the vendor has
now gone bust and no-one has the source code. And the large web portal
which had a whole bunch of local apache customisations based on apache
1.3.x and where the original developers left for greener pa$ture$, and
no-one in-house really understands what they did any longer. Etc, etc.
It's different if you have a protocol which allows parameter negotiation to
deal with issues like this, but not so good when you don't.
agreed, 100%. There are also lots of folks using certs internally for
all manner of oddball reasons... signed on their own CA (perhaps
chained to a 'real' CA, perhaps not). They'll have to be accomodated
as well, of course.
