the author writes: > At Black Hat ‘08 there was a great demonstration of how valid “internal > testing only” FQDN certificates for URLs that you don’t control can be > obtained by anyone asking. The one obtained by the researcher at Black Hat > was for MSFT’s https://login.live.com site, he didn’t disclose the CA that > issued it to him but it was one that was trusted in IE by default.
This is, of course, very serious, as it casts doubts on the value of SSL and PKI for all products that use SSL.
If we can determine what CA is doing this, I propose we pull them from the trusted CA list immediately.
>> At Black Hat '08 there was a great demonstration of how valid "internal >> testing only" FQDN certificates for URLs that you don't control can be >> obtained by anyone asking.
This means that CA doesn't even do "domain validation", right?
Wan-Teh Chang wrote: > On Tue, Aug 19, 2008 at 5:40 PM, Nelson Bolyard > <NOnelsonS...@nobolyardspam.com> wrote: >> In a Network World column, >> http://www.networkworld.com/community/node/31124 >> the author writes:
>>> At Black Hat '08 there was a great demonstration of how valid "internal >>> testing only" FQDN certificates for URLs that you don't control can be >>> obtained by anyone asking.
> This means that CA doesn't even do "domain validation", right?
I believe so. I seriously doubt that the presenter of this demo (whoever it was) really controlled the domain for live.com.
On the other hand, it is possible that the domain validation was performed but that it was deceived through the use of DNS attacks. In his slides on the subject of DNS attacks, Dan Kaminsky did say that it was possible to deceive domain validation through DNS attacks.
Nelson Bolyard wrote: > On the other hand, it is possible that the domain validation was performed > but that it was deceived through the use of DNS attacks. In his slides > on the subject of DNS attacks, Dan Kaminsky did say that it was possible > to deceive domain validation through DNS attacks.
I think domain validation could be deceived using DNS attacks, but in this case this was apparently not necessary:
"Michael started his talk by detailing how he was able to purchase a certificate from a major CA with a FQDN of an existing fortune 500 company’s website! How you ask is this possible, well when filling out the request form he simply checked the box that stated that the certificate was not going to be used on the internet and was for internal testing only."
Thorsten Becker wrote: > Nelson Bolyard wrote: >> On the other hand, it is possible that the domain validation was performed >> but that it was deceived through the use of DNS attacks. In his slides >> on the subject of DNS attacks, Dan Kaminsky did say that it was possible >> to deceive domain validation through DNS attacks.
> I think domain validation could be deceived using DNS attacks, but in this > case this was apparently not necessary:
> "Michael started his talk by detailing how he was able to purchase a > certificate from a major CA with a FQDN of an existing fortune 500 > company’s website! How you ask is this possible, well when filling out the > request form he simply checked the box that stated that the certificate was > not going to be used on the internet and was for internal testing only."
I'll be convinced when I see the cert and/or see the web site's enrollment page with that feature. There's one CA that can kiss it's place in the root list good-bye.
> I'll be convinced when I see the cert and/or see the web site's enrollment > page with that feature. There's one CA that can kiss it's place in the root > list good-bye.
Quoting from the article:
"The one obtained by the researcher at Black Hat was for MSFT’s https://login.live.com site, he didn't disclose the CA that issued it to him but it was one that was trusted in IE by default."
First of all, this CA doesn't have to be in NSS, but is in IE. Luckily not every CA which is trusted by MSIE is also in Mozilla. Some of you might be surprised about which aren't in NSS and most likely rightly so. MS doesn't have the same requirements as Mozilla. Not sure now if they require domain validation, but maybe not...
Second, Mozilla and/or Microsoft might be able to force the disclosure of that CA. Most likely they removed the evidence at the web site and revoked the certificate by now, but the certificate itself might be prove enough.
> Luckily, Michael also stated that most CA's rejected his requests. But it > only takes one CA to spoil the party.
It only takes one CA to spoil the party, because there's no presentation to the user of who's responsible for the muckup.
Of course, if he doesn't provide the certificate and proof that he has the private key to it, I'm going to believe this as an unfounded attack against the credibility of the PKI system in general.
It's called "put up or shut up". Unfortunately, since there's no single "owner" of the PKI, there's no place/person who can directly claim slander or libel and thus damages, which essentially makes these types of attacks damaging without recourse.
Kyle Hamilton wrote: > 2008/8/20 Robert Relyea <rrel...@redhat.com>: >> Luckily, Michael also stated that most CA's rejected his requests. But it >> only takes one CA to spoil the party. > Of course, if he doesn't provide the certificate and proof that he has > the private key to it, I'm going to believe this as an unfounded > attack against the credibility of the PKI system in general.
> It's called "put up or shut up". Unfortunately, since there's no > single "owner" of the PKI, there's no place/person who can directly > claim slander or libel and thus damages, which essentially makes these > types of attacks damaging without recourse.
I agree with you completely on the above quoted points.
Someone from Mozilla is trying to get info about the CA from the presenter.
|
