I cannot understand why rogued certificate is thought harmful though It can be used to impersonate some website. The attacker can craft a rogued certificate with different identities and public key but the same signature through hash collision, such as md5 collision. But the attacker cannot aquire the private key corresponding to the public key in the rouged certificate. So in the handshake stage of SSL, the attacker can't decrypt the PreMasterKey encrypted by the public key, then the negotiation will be fail. Can anyone tell me where I was wrong. Truly appreciated.

  • 3
    $\begingroup$ What makes you think that the attacker cannot acquire the private key? Depending on how to generates the collision, the public key can be either a value he selected (in which case he can know the private key), or a known random value (and a nontrivial fraction of random 2048 bit values can be factored, being a smooth number times a large prime). $\endgroup$ – poncho Apr 21 '15 at 3:12
  • 2
    $\begingroup$ Read this. It talks about exactly how security researchers actually created a faked CA certificate and legit certificate colliding pair, got the legit certificate signed by a real CA (who was not in on this), and then put that signature on the CA cert to get a real signed CA cert for which they had the private key and which, had they not intentionally made the CA cert long-expired, they could have used in actual attacks. $\endgroup$ – cpast Apr 21 '15 at 3:26

Very basically, the hash collision it can be used to fool CA's to sign a certificate that stores one set of information in the certificate's attributes, while there the requester uses it to create one or more certificates with different attributes.

The attributes in the certificate are as important as the public key that is being signed. They contain, for instance, the information of the holder. For web certificates the most important holder attribute is the domain name of the server. It is of course of vital importance that the name cannot be changed. Another part of the attributes is the key usage, which defines how the key should be used. One very important bit is the bit that defines if the certificate can be used as CA certificate. If it can be set then the user may simply start acting as an intermediate CA, issuing certificates himself, for any domain.

The public key stored in the certificate is only one part of information that is signed. That you can also sign another public key is not so much of a problem as the private key still needs to be controlled by the party sending the certificate request. This would only be a problem if the location of the private key is somehow part of the security properties covered by the certificate.

All in all, you seem to be focusing too much on the Public Key part and too little on the Infrastructure part of PKI. The attack isn't really a problem during the handshake of TLS, the attack is on the trusting of the certificate. The PKI method of establishing trust is used by TLS, it is not defined by it.

  • $\begingroup$ Follow the link @cpast gave me, I found the paper "MD5 considered harmful today". It's really useful. Now I know the attack scenario where rogued certificate is used. $\endgroup$ – chenxiang Apr 22 '15 at 0:32
  • $\begingroup$ Side node: it may be that the maximum path length is controlled by the CA certificates. In that case a well implemented client should not accept a leaf certificate for which the path length is out of range. $\endgroup$ – Maarten Bodewes Apr 23 '15 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.