3 ms·

Certificate Transparency means SSL certs must have been logged to public CT log databases to be considered valid. This ensures that any monkey business MITMing

by 0x0 7y ago

Certificate Transparency means SSL certs must have been logged to public CT log databases to be considered valid. This ensures that any monkey business MITMing with rogue certificates will be detected quickly, either by site owners seeing unknown certs for their sites in the log, or browsers rejecting unlogged certs. http://www.certificate-transparency.org/home http://www.certificate-transparency.org/home

tialaramex 7y ago
Two related things are happening here, and a third thing isn't actually happening today but is an active subject of research. 1. All the trusted CAs log either all the certificates they issue or the vast majority of certificates intended for use on the public Internet. They do this because it's a good idea, and (as we'll see in #2) because it makes commercial sense. The effect is that if you have a way to trick a CA into issuing something that shouldn't exist, or if they just issue it through the usual human fallibility (e.g. an operator fat fingers something at a console) researchers can see it, the same way they'd see if your Senator doesn't bother attending Congress - it's a matter of public record. 2. Google's Chrome, and later Apple's Safari require SCTs (Signed Certificate Timestamps) from logs before they accept newer certificates. The cheap easy way to arrange this is to log "pre-certificates" which get you valid SCTs and then you bake those inside the real certificate given to a subscriber. If you use Let's Encrypt, this is how SCTs got inside all your certificates, no extra work for you. There are fancier options that let you get a certificate and then obtain SCTs later separately, but they're rather niche. This means if you can obtain an apparently valid certificate but only a new enough one (thus after enough time in the future, any certificate) but no SCTs for it, it won't be valid in those browsers. The logs aren't supposed to give out an SCT without logging the certificate. So now an attacker needs to either log their bogus certificate (if they can) and show it to the world, or corrupt the logs too, a big ask on top of whatever attack they've done to trick or corrupt the CA issuer or bypass them. 3. Eventually the intention is a Gossip protocol. The idea here is, when you browser sees an SCT we should like to verify that the associated certificate was really logged irrevocably for everybody to see. But we'd like not to undo your privacy in the process. You don't want to tell everybody "Hey I like Balloon Porn" but you'd ideally like to be sure the certificate on your Balloon Porn website is seen in the logs by everybody, not just a special version of the log shown only to you and six other people under investigation for liking Balloon Porn. Figuring out the best way to approach this is an active research topic.

by 0x0 7y ago

tialaramex 7y ago

Two related things are happening here, and a third thing isn't actually happening today but is an active subject of research. 1. All the trusted CAs log either all the certificates they issue or the vast majority of certificates intended for use on the public Internet. They do this because it's a good idea, and (as we'll see in #2) because it makes commercial sense. The effect is that if you have a way to trick a CA into issuing something that shouldn't exist, or if they just issue it through the usual human fallibility (e.g. an operator fat fingers something at a console) researchers can see it, the same way they'd see if your Senator doesn't bother attending Congress - it's a matter of public record. 2. Google's Chrome, and later Apple's Safari require SCTs (Signed Certificate Timestamps) from logs before they accept newer certificates. The cheap easy way to arrange this is to log "pre-certificates" which get you valid SCTs and then you bake those inside the real certificate given to a subscriber. If you use Let's Encrypt, this is how SCTs got inside all your certificates, no extra work for you. There are fancier options that let you get a certificate and then obtain SCTs later separately, but they're rather niche. This means if you can obtain an apparently valid certificate but only a new enough one (thus after enough time in the future, any certificate) but no SCTs for it, it won't be valid in those browsers. The logs aren't supposed to give out an SCT without logging the certificate. So now an attacker needs to either log their bogus certificate (if they can) and show it to the world, or corrupt the logs too, a big ask on top of whatever attack they've done to trick or corrupt the CA issuer or bypass them. 3. Eventually the intention is a Gossip protocol. The idea here is, when you browser sees an SCT we should like to verify that the associated certificate was really logged irrevocably for everybody to see. But we'd like not to undo your privacy in the process. You don't want to tell everybody "Hey I like Balloon Porn" but you'd ideally like to be sure the certificate on your Balloon Porn website is seen in the logs by everybody, not just a special version of the log shown only to you and six other people under investigation for liking Balloon Porn. Figuring out the best way to approach this is an active research topic.