2
$\begingroup$

Could you confirm whether my understanding of the SHA-1 collision issue is correct?

If for certificate $A$, the message digest equals to $X$ and a Root CA signs it with its private key everyone can verify its authenticity by decrypting the signature with the public key that is pre-loaded in to the browser in form of a X.509 certificate, correct?

So given the hash value of $X$ over the certificate and while not knowing the private key that signed the hash, I know that the final result (signature) = $Y$.

I compute another certificate (with the Issuer filed set to the Root CA that signed the real certificate) so that it’s hash value will as well = $X$. So with two different certificates (data input) we were able to get the same hash (collision occurred).

I still don't know the signers (Root CA that signed the original certificate) private key, but I know that the hash value of $X$ signed with his private certificate = $Y$.

I take my fake certificate and try to impersonate the legit website. I "steal" e.g. copy the signature (bytes) from the original certificate and send them along with the fake cert to the user/browser when the connection is set up.

Now, the browser will run few checks. It will, try to decrypt the signature with the public key that is wrapped in the X.509 certificate that is pre-loaded in to the browser.

Because we assume (we hope) that our hashing algorithm is collision resistant, the public key decrypts the signature and the browser is able to calculate the same hash value, hence proving the authenticity of the certificate and that it was not changed during transit.

Improve this question
$\endgroup$
2
  • $\begingroup$ It's somewhat better now, but I'm missing a real question. What part are you uncertain about? $\endgroup$
    – Maarten Bodewes ♦
    Mar 18, 2017 at 23:09
  • $\begingroup$ @MaartenBodewes The question is, whether what I describe is technically correct, and if it describes the issue behind moving away from SHA-1 to SHA-2. I know that it was proven recently that it's not collision resistant but I was looking for issues related to this. I've provided my understanding, why it might cause issues, the "why's" behind it . I would appreciate if someone could validate it, or otherwise correct me. $\endgroup$
    – cyzczy
    Mar 18, 2017 at 23:12

1 Answer 1

Reset to default
1
$\begingroup$

Correct. Essentially the issue is that you sign a hash of the document, so any other document with the same hash you have also signed.

However, you should not really mix terminology like "decrypts the signature". Signatures are "verified". Even in the case of RSA where the basic operation is similar to decryption, the verification involves other things like different padding that must be checked.

Improve this answer
$\endgroup$
8
  • $\begingroup$ Thank you for looking into this. One question though, how can I identify the signature algorithm used? Is it somehow in the ssl handshake? $\endgroup$
    – cyzczy
    Mar 19, 2017 at 9:44
  • $\begingroup$ @adam86, do you mean the signature algorithm that the certificate's public key will use in TLS or the signature algorithm used to sign the cert? In either case it is a part of the certificates in question. E.g. you can see the one for Stack Exchange in Chrome if you navigate to the HTTPS version of this page, open the Security tab of developer tools and click view certificate. (In Firefox you can get the same by clicking the lock symbol, and moving on from there.) $\endgroup$
    – otus
    Mar 19, 2017 at 11:07
  • $\begingroup$ Please apologize for my late reply. The more I learn the more conusing it gets :/ I was assuming that the CA signs the certificate with the public key inside and that's it. Or do you mean the part of a RSA key exchange SSL handshake where the client is using the public key to sign the pre-master secret? I appreciate your help in advance. $\endgroup$
    – cyzczy
    Mar 19, 2017 at 14:45
  • $\begingroup$ @adam86 the CA uses their cert's public key to sign the other certificate. That cert's public key is used to authenticate the key exchange. $\endgroup$
    – otus
    Mar 19, 2017 at 14:50
  • 1
    $\begingroup$ @adam86, yes, the CA signs the server cert which contains the public key. They sign with the private key corresponding to the public key in the root/intermediary cert (misspoke above). $\endgroup$
    – otus
    Mar 19, 2017 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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