Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The foundation of a more secure web: Google Trust Services

security.googleblog.com

Post reply on HN
Print view View original

41–50 of 178 posts

Re: The foundation of a more secure web: Google Trust Services

#41

Post by wbond »

It is interesting to see that Google decided to opt for NIST P-384 curve for the root certs it is going to have valid until 2036.

Brian Smith has argued for supporting only P-256, P-384 and Curve25519: https://briansmith.org/GFp-0. That said, Mozilla decided to continue to advertize support for P-521 for NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=1128792).

P-256 and P-384 are widely supported in various TLS libraries (SChannel, SecureTransport, OpenSSL, NSS), whereas Curve25519 doesn’t yet seem present in Microsoft or Apple’s libraries. I suppose with TLS 1.3 support perhaps we may see it implemented?

Unfortunately it seems none of the NIST curves (P-*) are considered “safe” by DJB and Tanja Lange: https://safecurves.cr.yp.to/.

Re: The foundation of a more secure web: Google Trust Services

#43

Post by niftich »

I don't think this is a bad thing. Instead of a third-party you trust (or rather, your user-agent trusts) vouching that Google's indeed Google, it's now Google vouching for itself, and you trust them by the virtue that they're Google.

This ought not be surprising: presumably, who better to say that Google is indeed Google than Google itself?

The reason everyone doesn't run a root CA is because it's difficult to coordinate trust between parties that may not know about each other ahead of time, and each and every root CA adds more maintenance burden on part of trust-stores. When I self-sign my cert, I am effectively my own root CA, but I lack a compelling value proposition for everyone to add it into their trust-stores, and of course there's the initial difficulty of me propagating my key fingerprint over a tamper-proof "out-of-band" channel ahead of time where you have assurance that it's coming from me.

Google, on the other hand, is fairly easy to verify that they're indeed Google, considering they just published their public keys on their own website. By having a prior web property that's already trusted, they have bootstrapped the trust necessary for fingerprint distribution, and the rest should follow.

When Google's CAs start issuing certs to non-Google parties, we can revisit the 'eggs-in-basket' question.

Re: The foundation of a more secure web: Google Trust Services

#46

Post by buzer »

algesten wrote: post #40
JoshTriplett wrote: post #30

Earlier quoted context omitted.

> this feels wrong, though I can't quite pin point why. It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this. (The announcement mentions that they might use this to operate as a…

I guess if NSA/FBI forces google to hand over the CA keys, they kan orchestrate undetectable MITM-attacks. I wonder why browser won't automatically store the fingerprint for every HTTPS-certificate it encounters and throw up a fuzz to the user if a certificate changes without any good reason?

It's risky for browsers to do it automatically since it's not something that sites are excepting. Some might be using different certificates on different servers for same domain for example.

It's possible for sites to instruct browsers to do it though, but that's opt-in. https://en.wikipedia.org/w/index.php?title=HTTP_Public_Key_P...

Re: The foundation of a more secure web: Google Trust Services

#47

Post by satai »

asdfasdfasdfa12 wrote: post #23
satai wrote: post #20

Earlier quoted context omitted.

Not any transparency. Certificate transparency. https://en.m.wikipedia.org/wiki/Certificate_Transparency

I think we are talking on different lines of thought. I am not concerned with certificate transparency... as the article you point out says it can take a long time [years] before it is found to be compromised. the fact of the matter is, if ssl decryption is possible on the fly, we need a different solution for encryption, this include the use of credit card chip. an encryption scheme cannot be designed to be broken a…

You can pretty much trust all the root CAs that provide Certificate Transparency. If such a CA went evil such an event would be detected.

Re: The foundation of a more secure web: Google Trust Services

#48

Post by tlrobinson »

algesten wrote: post #40
JoshTriplett wrote: post #30

Earlier quoted context omitted.

> this feels wrong, though I can't quite pin point why. It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this. (The announcement mentions that they might use this to operate as a…

I guess if NSA/FBI forces google to hand over the CA keys, they kan orchestrate undetectable MITM-attacks. I wonder why browser won't automatically store the fingerprint for every HTTPS-certificate it encounters and throw up a fuzz to the user if a certificate changes without any good reason?

It's opt-in by the site, but that's what public key pinning is: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

Re: The foundation of a more secure web: Google Trust Services

#50

Post by infogulch »

algesten wrote: post #40
JoshTriplett wrote: post #30

Earlier quoted context omitted.

> this feels wrong, though I can't quite pin point why. It's unusual for a root CA to be run by a service that otherwise has nothing to do with CA issuance, for the primary purpose of issuing certificates for that service's first-party sites, and not for third-party sites. I can't think of a single other example of a single-purpose root CA like this. (The announcement mentions that they might use this to operate as a…

I guess if NSA/FBI forces google to hand over the CA keys, they kan orchestrate undetectable MITM-attacks. I wonder why browser won't automatically store the fingerprint for every HTTPS-certificate it encounters and throw up a fuzz to the user if a certificate changes without any good reason?

Why aren't new certificates for the same domain signed by the old (perhaps expired) certificate (recursively) in addition to the whole CA model?

This proves that whoever has the new cert used to have the old cert. A browser would save a copy of a certificate the first time it visits a site, then when it visits again later it could request the chain of certs back to the first one it ever encountered. Past certs verify new certs; this check wouldn't even involve a CA.

This basically overlays trust-on-first-use security model on top of the CA security model and would make it much more difficult to perform a MITM on sites that the user regularly visits (which are probably the most valuable targets).

Post reply on HN