[a012]

I worry about it too, my company use Fortinet with DPI enabled that it strips down target server's SSL cert and replaces by its self-signed cert. So, maybe with Comodo's CA, SonicWall DPI would be transparent to end users. Yes they assure in the press release but who knows.

[tialaramex]

An important thing about the way Public Key cryptography works is that if you try shenanigans like this you're obliged to supply the client with the smoking gun as part of your scheme. The signed certificates prove beyond doubt what happened, and they are automatically delivered to the client as a necessary part of the initial SSL/TLS connection.

Imagine if you had a fool-proof way to murder people, but it requires you leave their corpse in a public square with a copy of your photo driving license and a signed confession. Now, perhaps for some reason you are politically untouchable so you will never see justice. Still though, by this method absolutely everybody will know you did it, so it doesn't seem like a good idea anyway.

[schoen]

Next year Google Chrome will require people to publish all the certificates in Certificate Transparency, which will be a significantly better source of proof because then people who are in a better position to know that the attack is an attack will also have a straightforward way to see them.

[MichaelGG]

Is each cert chained to the previous somehow? Like a field from one hashed into the next, so that you can detect gaps in the issuance? That way they can't even issue a secret cert for a one time national security op without breaking the chain.

[castillar76]

Kind of. The way CT works is that everything submitted to a CT log is chained, so you can validate that the CT log's record of issuance is complete—that is, everything it has received has been digitally signed into its record, and you can verify that nothing has been removed from the record. So if you're presented a cert with a CT timestamp, you can validate that a CT log server saw and accepted that certificate (making it part of the public record). The signed timestamp (or timestamps--you're supposed to present stamps from a minimum of three different CT logs to make Chrome happy) has to be embedded in the cert or presented as part of the TLS handshake. (See https://www.certificate-transparency.org/how-ct-works for more info.)

All of that doesn't prevent someone from issuing a certificate from a public CA and /not/ submitting it to a CT server: there's no easy way to detect that. If someone did that, though, they would have to present the certificate to your browser without a CT stamp attached. Both Firefox and Chrome are working on implementing mandatory CT validation, at which point your browser will yell and scream if it is presented a cert from a public CA that doesn't have an associated CT stamp. (Right now, if you want to check CT timestamps on certs, you need a plugin (there's one for Firefox, e.g., at https://www.elevenpaths.com/labstools/certificate-transparen... although I can't vouch as to its completeness).) At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

[schoen]

> At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

An interesting problem in this design is how to persuade users that they've encountered something genuinely important that it would be helpful for them to tell someone else about. (Maybe browsers can store such questionable certificates offline and gossip about them to other TLS servers later.) It's not very common for people to be persuaded that errors on their computer matter and that other people will care about them... but this one does! :-)

I know HPKP has a report method which one could imagine generalizing somehow to CT inclusion failures, but, in many attack scenarios involving use of misissued certs, the victim's network connection is controlled by the attacker. In that case, the attacker will probably not want to allow the victim to report the attack to another server in real time.

[castillar76]

Interesting idea! I know the CT spec recommends that clients archive CT data received for later review, and it defines the concept of a CT 'auditor' that constantly reviews the logs from CT log servers looking for malfeasance. It would be interesting and very useful to amalgamate anonymized data from browsers into one of those auditors and crunch through it to compare to CT records.

[ChuckMcM]

Yes.

[pfg]

This would be a violation of root policies and would certainly cause the CA to be distrusted nowadays. It would also be detected with a high likelihood due to HPKP (and CT in the future). The economics of buying a CA for this purpose don't make sense.

[user5994461]

You might have missed yesterday's news from Chrome announcing that the HPKP feature is being considered for removal.

[pfg]

The deprecation timeline is being synced with the rollout of CT and CT enforcement headers (Expect-CT). This provides roughly the same detection (if not prevention) capabilities.

[criddell]

Would it be a violation if a company or person were only using it to crack open traffic into or out of their network? On my network, shouldn't I be able to do just about anything I want?

[pfg]

It would be a violation to do it with Comodo's publicly-trusted PKI, yes. You can do whatever you want with a private root that's manually deployed to the clients within your network.