
The foundation of a more secure web: Google Trust Services - noinsight
https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html
======
aduffy
You can now have a website secured by a certificate issued by a Google CA,
hosted on Google web infrastructure, with a domain registered using Google
Domains, resolved using Google Public DNS, going over Google Fiber, in Google
Chrome on a Google Chromebook. Google has officially vertically integrated the
Internet.

~~~
Cyph0n
What's remaining is: server written in Go, running on a Google server OS,
located on a Google designed server appliance, which is centrally controlled
by a Google designed microprocessor, which is finally manufactured in a Google
owned semiconductor foundry. Oh, and the sand used for silicon purification is
sourced from a Google-owned stretch of beach.

I haven't considered the internals of the datacenter though...

~~~
arkitaip
What I am waiting for is a good shopping experience hosted by Google. Can for
the life of my not understand why did still haven't done this because it would
solve so many of their problems wrt ads and purchasing.

~~~
dazc
Amazon have too far a head start on that one but it is ironic that google seem
to be able to crawl and index amazon better than amazon can do internally.

~~~
zabouti
It has seemed to me for quite some time that Amazon deliberately tries NOT to
return what you are searching for. Oh, they'll give you one or two items that
fit your search criteria, but they'll also return lots of stuff that they
think you'll be interested in and possibly buy.

------
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.

~~~
AdieuToLogic

      I don't think this is a bad thing. ... This ought
      not be surprising: presumably, who better to say
      that Google is indeed Google than Google itself?
    

The problem is that "connecting to a Google property" almost certainly
includes their WiFi access points as well as other networking offerings. Which
implies the ability to MiTM traffic encrypted from products not controlled by
Google (other browsers, VPN clients, etc.).

As stated in this Stackoverflow response[0]:

    
    
      Especially #2 is rather nasty, even if you
      pay for a highly trusted certificate, your site
      will not be in any way locked to that
      certificate, you have to trust all CAs in the
      client's browser since any of them can generate
      a fake cert for your site that is just as valid.
      It also does not require access to either the
      server or the client.
    

I wouldn't be surprised if AMP is also in play for this type of MiTM, but do
not know for certain. Android native apps, however, are definitely poised to
be compromised.

0 - [http://stackoverflow.com/a/14907718](http://stackoverflow.com/a/14907718)

~~~
castillar76
Google engineers have been very heavily involved in the CA/Browser Forum
([https://cabforum.org](https://cabforum.org)), which sets issuance and trust
rules for CAs. One of the things the CAB Forum is currently debating is a set
of requirements mandating certificate transparency (CT) and obeying
certificate authority authorization (CAA) records in DNS.

If implemented for all of these roots (and I don't see why they wouldn't,
given their push on it), CT would create an open, unalterable record of every
cert published from all of these roots and their subordinates. CAA, as a
complement, would create a method by which you as a domain owner could control
which CAs are allowed to issue certs for your domain, removing the ability to
man-in-the-middle your domain without your permission.

The first step for both of these is making them mandatory for CAs (which
Google is pushing hard on); once they're out there, it's possible to write
plugins that will check CAA and CT records and fail closed if something looks
wrong. _It 's a long way from perfect_, but it's definitely a step in the
right direction. Given Google's strong push for making those mandatory, I'm
far more worried about a lot of the CAs _already in my trust store_ than I am
about these.

~~~
AdieuToLogic
According to here[0], when you say:

    
    
      CT would create an open, unalterable record of
      every cert published from all of these roots
      and their subordinates.
    

That provides no substantiation for Google's push to be a Certificate
Authority (CA). It arguably makes a case for Google to be a "Log Server"
(which has its own troubling implications as that could then (now?) hook
Google into the verification process of _every certificate issued_ [1]). But
absolutely nothing about CT needs/implies/warrants Google to become a CA.

    
    
      Given Google's strong push for making those
      mandatory, I'm far more worried about a lot
      of the CAs already in my trust store than I
      am about these.
    

The very authority to which you are appealing is precisely the one which is
suspect.

0 - [https://www.certificate-transparency.org/how-ct-
works](https://www.certificate-transparency.org/how-ct-works)

1 - From [0]:

    
    
      During the TLS handshake, the TLS client receives
      the SSL certificate and the certificate’s SCT.
      As usual, the TLS client validates the certificate
      and its signature chain. In addition, the TLS
      client validates the log’s signature on the SCT ...

------
reddiric
"If you are building products that intends to connect to a Google property
moving forward you need to at a minimum include the above Root Certificates."

The foundation of a more secure web apparently requires you to trust Google
with the entire internet, using their properties as leverage to force it to be
so.

~~~
mastax
Is Google less trustworthy than Go Daddy? Or CNNIC? Or the Hong Kong Post
Office? Yes the CA system is broken but framing that as an anti-Google
argument seems silly.

~~~
ori_b
Google isn't less trustworthy, but it is far closer to being a monopoly. I
would like to bias towards a more decentralized infrastructure.

Especially since Google is US based.

~~~
lmm
I agree in principle, but currently every CA is a single point of failure for
the entire Internet, so adding more CAs makes things worse rather than better.
We need something like DNSSEC/DANE to enable actual decentralization (where
the Hong Kong post office could only sign Hong Kong domain names and so on).

~~~
joosters
Why should the Hong Kong post office only be able to sign HK domain names? Are
businesses in Hong Kong not allowed .com addresses?

~~~
lmm
I would like to see a single responsible CA for each domain (which are allowed
to hierarchically delegate). Country-specific agencies should only be able to
sign domains within their country, and .com addresses (which should be
reserved for genuinely international sites, though that's a separate argument)
should be handled by an international CA that can a) apply some consistent
international standard for how domain owners are identified etc. and b) be
specifically held accountable for dodgy .com certificates

~~~
joosters
So... one CA for each domain, leaving no competition? And which unwanted
domain will LetsEncrypt be left with, then?

Back in the real world, we have multiple CAs who have accountability for lots
of overlapping domains. You can wish for some other non-existent situation,
everyone else has to make the best of the situation as it stands.

~~~
lmm
> So... one CA for each domain, leaving no competition? And which unwanted
> domain will LetsEncrypt be left with, then?

Domains can compete with each other, particularly given the big opening up of
TLDs. We could have actual competition between CAs at the end-user-facing
level because it'd be visible to the user who the CA was (the CA and the
registry ought to be merged - at the moment they're two parallel sets of
infrastructure for doing the same thing), and if particular domains/CAs had
poor-quality identity checking users might actually start to notice. As
opposed to today, where the only one who knows which CA a domain might be
using is the domain owner, and so the incentive largely is for the CA to do as
little checking as possible.

> Back in the real world, we have multiple CAs who have accountability for
> lots of overlapping domains. You can wish for some other non-existent
> situation, everyone else has to make the best of the situation as it stands.

There's a migration path. Enable DNSSEC/DANE with all CAs authorized for all
domains initially, then allow countries / TLD owners to start restricting who
can sign certificates for their domains. If Hong Kong moved to requiring only
Hong Kong Post Office to sign their domains, we could see how well or badly
that model works - if it reduces phishing / spying then other countries will
follow the same, if it stifles innovative internet businesses then they'll
move away from that. But 150+ entities all having the power to own every site
on the internet can't possibly be the right model.

------
algesten
I have no love for most the major CAs I've interacted with, but this feels
wrong, though I can't quite pin point why.

Perhaps just a general feeling that all the internet eggs are being put, one
by one, in one single alphabet basket.

~~~
JoshTriplett
> 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 CA for
third-party sites as well, but right now it exists to certify first-party
sites.)

~~~
algesten
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?

~~~
infogulch
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).

~~~
JoshTriplett
You'd need a backup plan for sites that have transferred ownership, or for
sites that needed to revoke the old key due to compromise. And once you have
that backup plan, how would you decide whether to care if that additional
signature exists?

~~~
infogulch
But ownership change and compromise _should_ be communicated to the user.
Maybe an "Unverified Identity" shows up for a while and triggers stronger
checks in the browser for CT and revocation lists.

------
jhugg
I love that you can just buy a CA and devices will trust the new owner. That’s
not messed up or anything.

~~~
geofft
How could you design a system that works otherwise? Computer security is
always about "this key says", not "this legal entity says".

~~~
andy_ppp
Peer review and regular key rolling should be built into the system.

It should not be based on "root" certificates rather something more like
blockchain for generating security keys and each roll /session generates a new
key.

IANAEE but if building a currency is possible without it being possible to
create fake money then it should be possible to protect websites in a
similarly decentralised way.

~~~
zokier
We have peer review in current CA system in two forms; Certificate
transparency being the more visible one, CAB forum operating more in the
background.

------
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](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](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/](https://safecurves.cr.yp.to/).

~~~
tptacek
The P-curves are "unsafe" (according to that rubric) in the sense that there
are several ways to make mistakes writing curve libraries with them; you have
to be more careful using them than you do with Curve25519.

------
andmarios
No real problem with Google running their own CA, but can't help but to think
that the same people who provide the browser, the search engine and the OS,
now also provide the certificates on who and what to trust.

As much as we might trust Google, shouldn't there be something like separation
of powers as a safeguard?

~~~
niels_olson
There is: they are intertwined with other regimes:

    
    
      * The international banking regime
      * The US legal regime for corporate purposes
      * Many other national regimes for operating purposes

------
zokier
It feels like a new age of internet when we have stuff like Googles private
.goog gtld with domains signed by Googles private Root CA. It's not strictly
bad (and I'm not complaining), but it feels bit silly/weird/scary/... .

~~~
mixedCase
Most of us adjudicate too much value to TLDs. It's an artificially scarce
resource and most people here learned about the Internet when these TLDs were
even scarcer.

~~~
zokier
Well, personally I think that most of us adjudicate too little value to TLDs.
The point of DNS is to be hierarchical instead of one flat space, so imho all
legacy TLDs should have been immediately deprecated the day ccTLDs were
introduced, and countries should have been endorsed to maintain second level
hierarchy (somewhat like .uk had for some time).

But of course that train left the station 30 years ago... in the current
landscape I don't mind gTLDs any more than the general mess that is current
DNS "hierarchy".

~~~
TorKlingberg
Many websites are not country specific. They started somewhere and are
headquartered somewhere, but it is not something users should need to
remember.

~~~
lmm
Using the global TLDs for a global site is fine. But I wish there was a rule
against using .com/.org/... domains for sites that are restricted to a single
country (e.g. a shop that only ships to the USA should be under .us)

~~~
dx034
This is the case in nearly all countries except the US. In the UK, nearly all
shops will have a .co.uk domain. In Germany .de domains, etc. It's just that
.com is believed to be the US equivalent for that, not an international
domain.

That's also how large sites handle it. Amazon.com will lead you to the US
page, not to an international section (e.g. where you could choose where to
go).

------
gergles
I'm going to be 'that guy', but: Great, another page that requires JavaScript
to display text. Hey, Google, you know what's more secure? Browsing plaintext
sites without JavaScript.

------
andy_ppp
I mean people don't trust Google's motives but I trust the certificate
authorities less...

How do we (or Google) know that the CIA and FBI can't create certificates from
all the CAs because they have stolen/demanded the Root CA for them?

If I was a TLA I'd want the ability to perfectly MITM anyone.

I think these questions imply that there needs to be a better way to think
about security and trust for web endpoints in the days of the state as a bad
actor.

~~~
lima
> How do we (or Google) know that the CIA and FBI can't create certificates
> from all the CAs because they have stolen/demanded the Root CA for them?

Certificate Transparency.

~~~
zabuni
Which is why Google knew that someone issues a cert for their website:
[https://security.googleblog.com/2015/09/improved-digital-
cer...](https://security.googleblog.com/2015/09/improved-digital-certificate-
security.html)

Might be part of the reason they are becoming their own CA.

------
asdfasdfasdfa12
I think SSL certificates need to be replaced. Security can NOT be designed
with the 'good guy' in mind. if it can be broken at all we need an
alternative.

~~~
satai
The certificates are OK. The issue is the way they are signed and distributed.

Lots of issues with the current PK infrastructure is limited by the
certificate transparency.

~~~
amalag
The main issue I see is ease of MITM for corporate environments. In a
corporate environment a trusted root is installed, then an appliance can
intercept all SSL certs and re-create the trust chain to introduce their own
trusted root so they can read all SSL traffic and your browser says "SECURE".
That is broken IMO.

~~~
zokier
It is very difficult, if not impossible, to protect against attackers who are
in a position where they are able to install their root cert to your browser.
If they can do that, then they can do a lot more also. At least in the current
system such tampering is generally easily detectable.

------
ygjb-dupe
Hmm, I wonder if Alphabet will spin up a made at Google alternative to Let's
Encrypt?

~~~
rmhrisk
Disclosure: I am the author of that post and Product Manager for this project
as well as other related work like Certificate Transparency and Key
Transparency.

While I can not say what Google will do in the future, I can say we are very
supportive of Let's Encrypt. We have provided them funding and I personally
act as an advisor to Let's Encrypt.

In short, we love what Let's Encrypt is doing.

~~~
ygjb
I do too, and I also think that if one reasonably well funded, free CA that
has full transparency is great, then two would be awesome :D

------
Endy
All I can say is this - what if I don't trust Google one iota?

~~~
akjainaj
Remove the Google root certificates from your system once they deploy them.

~~~
richardwhiuk
and don't visit any Google sites, which are the only ones deploying Google
certificates.

------
vasco
You're google and you still take a print screen of a spreadsheet instead of
using an HTML table to display tabular information on a blog post.

------
pk22
What's next? Chrome marking certificates not signed by Google CA as "Maybe not
secure"?

------
jarcoal
Couple of notes:

* pki.goog does not enforce TLS

* Why use .goog instead of .google?

~~~
rmhrisk
Some PKI-related services can not, due to user agent behaviors and, do SSL,
for example, consider OCSP; if to fetch an OCSP request you need to do an SSL
connection and the library doing SSL does an OCSP check to verify the SSL cert
you can end up in an infinite loop.

While it would be ideal for that not to be the case, one has to build out
infrastructure that supports the way UAs behave today.

------
scottm84
Unless they launch a satellite far from earth with locked keys on it, I don't
see how this is anything more than a corporate NSL

------
bassman9000
Are we going to see preferences in Chrome regarding certificates that link to
a different root CA?

/cynical off

------
godmodus
i don't see how this is real security, considering trump's election and
google's track record of bending to government demands. even more
disappointing is their use of an NIST curve.

but then again, government players plague every security system we have.

------
arca_vorago
I have thought for a good while now that DNS is the primary weakness of the
current incantation of _the internet_ as the public knows it. I think perhaps
we should ponder the benifits of replacing it, and using raw IP's more often.

In the meantime, DNSCurve would be a great start, vs the major issues I have
found with DNSSec.

------
jfe
looks like the fox is guarding the hen-house.

------
forrestthewoods
I don't trust Google.

------
finid
The proverbial fox guarding the hen house.

