Am I mistaken with understanding that were one to find a collision, they could impersonate the Verisign root CA, and use that to generate an intermediate and then server cert that would be trusted by a browser or OS.
You are mostly mistaken about being able to impersonate a root CA with just a hash collision as a successful attack on a root CA's certificate would require more steps, as explained in detail below.
You could however, as explained below, successfully impersonate an intermediate CA using just a hash collision.
In short client verifies that the RSA encrypted signature on a certificate matches the RSA encrypted signature that would be generated using the CA's public key to sign the hash of the bytes of the TBS certificate in said certificate. While the CA's public key can be used to verify the the RSA encrypted signature of the hash of the TBS certificate, one would need to know the CA's private key to generate the signature allowing you to impersonate the CA.
Supposing you were able to generate such a hash collision of the TBS portion of a CA root certificate by modifying it to contain a public key for which you know the private key the problem is that your modified CA certificate would contain a different public key than the CA's actual certificate and any clients verifying a certificate signed by the CA will have a locally installed copy of the CA's real certificate. When validating a signed certificate the client will retrieve the signer's thumbprint or signature from the signed certificate and will retrieve the public key of their local copy of that certificate when attempting to verify the signature of a certificate signed by that CA.
Therefore in order to impersonate a root CA and generate an RSA encrypted signature a client would trust you first need to find a collision of the TBS portion of the root CA's certificate from a TBS certificate you generate that contains a public for which you know the private key. You also need to find such a collision that passes RSA signature verification using the CA's public key. At this point you would have a forged certificate with both a SHA1 hash collision and an RSA signature collision. If somehow you accomplished all of this you would finally need to trick a client so they retrieve your forged certificate when looking for the root CA certificate instead of retrieving their locally copy of the root CA's certificate.
In nearly all imaginable scenarios in which you could accomplish all of these things would have much more efficient attack opportunities that didn't involve needing to first find a SHA1 hash collision of a certificate that contains a private key known to you which also generates an RSA encrypted signature collision which then need to trick the client into using for signature verification instead of using the real root CA's certificate that, given the fact the client trusts it, will be stored locally on the client.
Instead a more plausible attack would be to find a hash collision of an intermediary CA's certificate with which you can use to impersonate the intermediary CA to sign certificates. This attack is more plausible for two reasons, first being you can easily get a client to download an intermediary CA's certificate and the second being the hash collision will verify against a trusted CA's RSA encrypted signature so there is know need to try to trick the client into trusting the CA that signed the certificate.
If a client is presented with a certificate from a website signed by an intermediary CA for which it does not have a local copy it will in attempt to download the intermediary's CA from the website which presented said ticket from the website which presented the certificate in the first place. Recalling that a client will take the hash of the TBS portion of this intermediary's certificate and then verify the RSA encrypted signature on this certificate was indeed signed using the public key of a locally trusted CA, or chain of CA's that leads to a locally trusted CA, a successful attack is now simplified to generating a hash collision of the TBS portion of a valid intermediary's CA's certificate.
Once one can replace the public key of a verifiable intermediary CA's certificate with a public key for which the private key is known and then modify other bytes as needed to generate a hash collision with a the verifiable certificate. This this altered certificate can then beused to sign other certificates. Such signed certificate's can then, for example, be installed on a web server along side this modified intermediary certificate. When a client retrieves the certificate it will read the thumbprint of the CA that signed it. If the client does not have this intermediary's certificate installed locally it will download the certificate from the website from it retrieved the certificate it is verifying. The client will then generate the hash of the TBS website's certificate and verify it was digitally signed using the public key in the intermediary CA certificate it downloaded. This process is recursive in that it then creates a hash of the TBS portion of the intermediary certificate it downloaded and reads the thumbprint of the CA that signed the intermediary certificate. It will then lookup that CA's certificate and verify the RSA encrypted signature on the intermediary certificate was generated using the issuing CA's public key to sign the hash of the TBS certificate in the intermediary certificate. Since the intermediary hash of the TBS certificate in the intermediary certificate matches the hash of the original intermediary's certificate and the signature also matches the signature of the original intermediary's signature our modified intermediary CA's cerfitificate will validate. The client will complete the process recursively until it finds a certificate issued by a CA it trusts and which point verification succeeds and we have successfully impersonated the intermediary CA.
NIST and the NSA warned that
"SHA-1 shouldn't be trusted past January 2016 because of the
increasing practicality that a well-funded attacker or government
could find a SHA-1 hash collision, allowing them to impersonate any
SSL website" and Microsoft and Google began warning a year later of
connections that use SHA-1.
http://windowsitpro.com/security/your-organization-using-sha-1-ssl-certificates
It's important that the certificate chain be encrypted with SHA-2
certificates. (A certificate chain consists of all the certificates
needed to certify the end certificate.) This means that any
intermediate certificates must also use SHA-2 after January 1, 2017.
Typically, your CA will provide the intermediate and root CA
certificates when they provide the SHA-2 certificate. Sometimes they
provide a link for you to download the certificate chain. It's
important that you update this chain with SHA-2 certificates.
Otherwise, Windows might not trust your new SHA-2 certificate.
Root certificates are a different story. These can actually be SHA-1
certificates because Windows implicitly trusts these certificates
since the OS trusts the root certificate public key directly. A root
certificate is self-signed and isn't signed by another entity that has
been given authority.
For the same reason, any self-signed certificate can use the SHA-1
algorithm. For example, Microsoft Exchange Server generates
self-signed SHA-1 certificates during installation. These certificates
are exempt from the new SHA-2 policy since they aren't chained to a
CA. I expect, however, that future releases of Exchange will use SHA-2
in self-signed certificates.
