On Mon, Feb 27, 2017 at 01:15:28AM -0500, Patrick W. Gilmore wrote:
On Feb 26, 2017, at 21:16, Matt Palmer <mpalmer@hezmatt.org> wrote:
Even better: I want a CA cert. I convince a CA to issue me a regular, end-entity cert for `example.com` (which I control) in such a way that I can generate another cert with the same SHA1 hash, but which has `CA:TRUE` for the Basic Constraints extension.
Wham! I can now generate certs for *EVERYONE*. At least until someone notices and takes away my shiny new toy...
In the example above, the CA knows the SHA-1 hash of the cert it issued. (We are assuming there is a CA which still does SHA-1.) How do you get that CA to believe the two OTHER certs with DIFFERENT hashes you have to create so you can have two docs with the same hash?
This is doable because the data that goes into the cert is mostly predictable (or attacker controlled). The public key is provided by the attacker; the subject and sAN extension is attacker-provided, and a lot of the rest is predictable (issuer, policy OIDs, etc etc). Even the notBefore and notAfter fields are, to some degree, predictable; you can measure the average issuance delay to figure out when you need to submit your CSR(s) to get favourable timestamps, and many CAs "round" values, to make that easier. Thus, constructing a "dummy" TBSCertificate ("to-be-signed certificate") to play with isn't difficult. The mitigation to a chosen prefix attack (which is what this is) is to make the serial number a random number. The CA/Browser Forum Baseline Requirements (the agreed-upon rules between CAs and browsers) say that you need to put "at least 64 bits of randomness" into the serial number field, which supposedly mitigates this. Unfortunately, that isn't a property you can easily determine by observation, and I'll bet dollars to donuts it isn't audited, so whether that would stand up to a determined attacker is a Rumsfeldian question.. - Matt