Hacker News Reader

Comment by zitterbewegung | Hacker News Reader

Step One: Google becomes a CA with a large fanfair and covered in every tech blog

Step Two: Google's entry makes the incumbents either decide to exit the space or change their bad behavior

Step Three: Google exits the space accomplishing their mission and screwing over whoever uses their services.

I really hope that it doesn't end like above but I think this will go the way of Google Fiber. Or maybe this is a play for their cloud services to also have be a CA like Amazon.

View on HN

> Step Two: Google's entry makes the incumbents either decide to exit the space or change their bad behavior

Yes, we wouldn't want the price of certificates to enter a race to the bottom. Let's Encrypt relies on that revenue!

Honestly these comments...

The comment you’re replying to thinks Step Two is good, but feels a bad Step Three is inevitable.

Why would existing CAs leave the market if they didn't before?

I think the argument is that existing CAs with mediocre practices are currently profitable, but in the presence of Google competition will stop being profitable and decide to exit, and may not decide to return if Google leaves.

(I don't think the scenario as a whole seems likely, but this specific argument is analogous to e.g. concerns about Uber and Lyft competing with taxies on VC-subsidized pricing that will run out one day, or the loss of SF laundromats thanks to laundry startups.)

Except, again, there are sponsored non-profits in this space. What further distortion do you expect?

LE is great for a lot of things. But it doesn't offer the wide range of SSL certs everyone requires, such as OV and EV certs.

Google did not request and were not granted EV treatment for this CA. So even if it mints certificates with an EV OID in them that will get ignored in Firefox.

Although the Google CA, Google's root trust programme, and the Chrome TLS implementation people are three distinct teams at Google, common sentiment among the technically savvy (which would include all three groups) is that EV is either entirely or largely pointless and nobody cares, so it would not make sense to request EV treatment.

Your general thrust is right, there are other things CAs issue that Let's Encrypt does not, but the numbers still tell a story of solid growth even in the Web PKI, Let's Encrypt grew the market considerably, seizing 75% of a market that is now five times bigger than before doesn't squeeze out other people.

Largely pointless to people @ Google is not a good measure. Customers still use it, and are willing to pay for it.

Who requires these certs? I've always gotten the impression they are useful for 1) checking a box on some form; and 2) making more money for CAs.

And, if its my job to check that box or to make money for a CA, well, that's fine. But, it terms of them actually having a real use, I'd love for someone to tell me what that real use actually is.

Everyone who operates a website with users that can be the phishing targets. Plain certs (DV) only tell you that you are talking to a server that that has been validated to belong to a domain (and the taking is done encrypted).

For example: https://twitter.com/musalbas/status/1038919152826757122

That assumes that a significant number of people a) know that Google has a EV certificate and b) actually check it. To the first point, I'm not sure that Google actually does have an EV cert - looking at Google.com, I think they just have a DV cert. And to the second point, I suspect that few people actually check if the cert is EV or DV (If they check that the connection is encrypted at all).

Having an EV cert for yourwebsite.com does nothing to prevent fishing if people are directed to someotherwebsite.com.someotherwebsite.com. So, whats the point if going through the extra pain / expense of getting one?

There's not a lot of point to EV. Google and eBay don't even EV their primary domains; given what high-profile targets those are for phishing, the fact that they're not EV should tell you something about its utility as an anti-phishing measure.

As per [1], twitter does use EV certs, but not everywhere. It depends on the geographical location. The author of this article (Troy Hunt) never noticed this inconsistency, whilst he works in security.

Given that he never noticed it, and the fact that I've never heard of anyone else noticing it. I'd say that even when high-profile targets deploy EV, it still does nothing.

A possible exception might be banks. I've heard (I think in the HN comment thread of [1]) of people actually calling up banks asking why the name isn't in the green part of the browser. I know I check that address most often. I guess people are just most security aware when it comes to mixing the internet and money.

[1] https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...

I recommend this presentation to help dispel a lot of misconceptions about phishing and how easy it is for even highly technically and security literate people to get phished:

https://www.youtube.com/watch?v=ZjW12K0IHgo

Extended validation and organization validation (EV and OV) certificates do not solve any technical cause of phishing. They're also poor instruments for attacking the social efficacy of phishing attacks. The phishing demo you linked in that Twitter page is not mitigated by EV or OV certificates.

These "extra" certificates are sold at a premium 1) so CAs can earn more, despite the race to the bottom; and 2) so potential victim companies of data breaches can point to all the "extra" effort (read: money) they invested in security. But they fundamentally do not improve security, because they're predicated on the idea that non-technical end users will use increasingly more sophisticated methods of identity assurance. The software security industry has decades of case studies which demonstrate this is not the case.

Simply put: you can't solve phishing by stuffing more and more authentication signals into a URL bar and a padlock icon. Approximately all users won't even bother to check and most will simply click through warnings. Trying to design better, more "verified" certificates is a clear example of a local maximum. It seizes upon a weak proxy for security against phishing, then tries to optimize further with the bureaucratic scar tissue of identity verification. In so doing it completely loses focus on the core issue.

Yes, and yes, and yes. They seem to fall strongly into the category of things I wish I sold but I can't figure out why anyone buys.

I'm going to start brewing vats of neurons, as an anti-phishing measure. Anyone have any good ideas for a distribution mechanism ?

Tinder?

That sounds like a problem of needing better identity indicators rather than verifying identity via EV.

If you think EV has magical phishing-prevention sauce, you probably want to do more research on the topic. Especially since browsers are starting to tone down or even remove special visual signifiers for EV certs (since, if EV had incredible anti-phishing power, they wouldn't be doing that).

EV doesn't solve that problem though https://stripe.ian.sh

Literally all SSL was done this way prior to 2003 when DV was invented. The use case for verification on the web is the as it it anywhere else.

Yeah I doubt this. I don't know what exactly Google's PKI will be for but to me this seems like a close relative of Google Cloud (esp. DNS) and Google Domains. Also, similar infrastructure services from Google, like Google's public DNS resolver, show no signs of being turned down.

(Disclaimer: I am a Google employee, but I don't work on any of this.)

Are Cloud and Domains special-case product protected from closure? How do I as an outsider know which Google products have this protection?

Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox. There's no guarantee that Cloud and Domains will never be closed, but that's on the level of RIM no longer making Blackberries. Google's a modern Internet company and has bet, and bet big, on being a leading cloud services provider, and Domains are a key component to having a vertically integrated offering.

Google is a public company and as such they are required to release certain information in annual report, so their investment in the cloud is verifiable.

> Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox.

Not an insider, but TBH, I was always pretty much sure that one of Gmail or Inbox will go away soon. With Gmail having more user base, it was natural for Inbox to be subsumed by gmail.

Inbox was not really fundamentally different from Gmail. It offered some new features, but I can't imagine that it would be too hard to implement them in Gmail too (e.g., snooze feature).

> Inbox was not really fundamentally different from Gmail.

I disagree, and suspect that anyone else that used custom bundles would too.

This guy sums it up well: https://www.androidpolice.com/2018/09/12/google-may-push-peo...

That article mentions that bundles are supposed to arrive in Gmail soon. My point still stands that Inbox features would be not-so-difficult to add to Gmail.

It's much easier than developing and maintaining 2 apps, and testing them on variety of platforms (Web, ios, android etc.) and device/browser combinations.

It was already getting confusing with smart compose (https://www.blog.google/products/gmail/subject-write-emails-...) coming to Gmail, but not to Inbox.

I suspect Inbox was never meant to survive. It had small details that prevented mass adoption. For instance, it took them months after launch to implement an automatic signature, and then they added the artificial restriction to only allow them in your gmail.com account, not other accounts like in gmail. This prevented a lot of people whose workplace policy requires a specific signature, me included, from completely ditching gmail.

What does "protection" and "guarantee" really mean? If a dozen meteors simultaneously strike every Google datacenter and office location, would the products continue to live on, even in the face of every conceivable guarantee their leadership makes before the event?

Point being; the only guarantees that any consumers should hold companies accountable to is: Does the product make money, and is it parallel to their conceivable long-term vision? That's literally all that matters. That's the only data consumers can use to decide whether a product will still exist in 10 years.

Google Cloud is this. Its absolutely profitable. And cloud tech is so deep in their DNA, they're literally decades ahead of anyone else. They were running containers and clusterized homogeneous server resource pools 8 years before anyone else knew to call them that, its just taking them time to productize everything they use internally.

Trust money. Trust vision. Don't trust words. G-Suite, Cloud, and Domains are very safe products.

DannyBee, in a sibling reply to yours, points out that Google has made some legally binding commitments about the longevity of the Cloud products:

https://news.ycombinator.com/item?id=17997494

No, it wouldn't require them to keep it operating if all of Google was simultaneously destroyed by meteors. But it would probably allow lawsuits against Google if they didn't give the required advance notice merely due to a change in business strategy, without a sufficient reason.

Interestingly, AWS doesn't have that kind of guarantee, though they do have a long public cloud track record of not turning stuff down.

You make a lot of additional good points about why these Google products are safe.

I'm not convinced I'd put Domains in that list, and for G Suite and GCP I'd only put the core services (G Suite jargon) and GA offerings (GCP jargon). Plus some other services under those umbrellas if Google has told you something about their plans under NDA, which they do for many customers.

But Google reliably provides transition plans and data exports if they do turn anything down, and I expect that will continue.

(Disclosure: I formerly worked for Google and GCP in particular, but no more recently than early 2015 and I have no current insider info.)

AWS likely doesn't have because they don't have the same trust problem Google does. Google likely were loosing from GCP deals because of this, so they put it in there to appease customers.

One year is way too short as well. Enterprise application development does not happen at that speed . Teams and budgets are not readily available to start migration to something equivalent just coz Google felt like it.

Even if that's not a problem migration may not even possible with proprietary APIs. You may have to deprecate entire fearures. If your SLA is longer and reasonable time to your customers, you are screwed.

Actually, they have explicit guarantees, yes.

As an outsider, you would know from the terms of service: https://cloud.google.com/terms/

7.2 Deprecation Policy. Google will announce if it intends to discontinue or make backwards incompatible changes to the Services specified at the URL in the next sentence. Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):

(i) required by law or third party relationship (including if there is a change in applicable law or relationship), or

(ii) doing so could create a security risk or substantial economic or material technical burden.

The above policy is the "Deprecation Policy."

If you click through to https://cloud.google.com/terms/deprecation you will see the covered services. (Reasonable good faith is a legal term of art, so no, Google would not get away with whatever silly edge case people come up with)

Summarising: they have no guarantee against closure; Google promises to give one year's notice if/when they decide to close them.

... unless they decide that giving one year of notice would be too expensive or hard.

As mentioned, no, the legal standard is not that simple

Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running. I don't see how this would be any different. I know that "reasonable good faith" is a legal term of art, and I'm saying that I don't think Google would struggle to meet that standard if they needed to shut one of these services down.

Those products Google shut down didn't have terms of services requiring Google to keep them up. You've ignored half the argument here.

"Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running."

That isn't the standard listed. It's "substantial economic burden".

None of those services were a substantial economic burden for a many-billion dollar company, so sorry, but i completely disagree.

This is the best guarantee any company ever gives.

For smaller companies if something becomes too expensive or hard, they just go out of business. For larger companies, they have to draw the line somewhere. You won't get stronger guarantees from anyone, that would be insane.

Google definitely has a history of turning down free services when they're proving unprofitable, but that's only free services. There's no history of Google turning down paid services without good notice that I know of.

Remember also this is the guarantee made to all users. I expect larger users get a lot more than that.

Wouldn't be surprised if it was related to their new Titan Security Keys. They are advertised as 2-factor authentication devices but they almost certainly have the ability to act as a certificate store. If you have a CA you can start issuing certs to people and drop the password / user name login altogether.

Google has been behind the effort to kill client certificates on the web, though, and as as someone who has run a web host for a large client-cert-using population I think this is a reasonable move: in particular, the protocol doesn't provide confidentiality for client cert data any more than it provides for server cert data, so if your name is in the subject it is sent in the clear which is a huge privacy violation, and there's no obvious way to implement a "logout" button, because auth is tied to SSL. You can work around these things, but at that point it's not obviously better than just doing some auth with WebCrypto (or your own WASM) and localStorage, and the tradeoff of using SSL client certs is that the complexity is inside your SSL layer and not sandboxed to the individual websites.

I happen to like, and have used, mutual authentication (and thus client certs) for B2B HTTPS APIs where the systems at both ends are servers not people or user agents. I agree it's not so great for people.

FWIW TLS 1.3 encryption kicks in before the certificates get sent, in either direction, so if you like/ need client certs but worry about confidentiality you should go to 1.3

Oh TLS 1.3 also has nicer filters so you can tell a client "Hi, please send me a client cert, but, I want one that has the following properties based on ASN.1 OIDs" whereas with earlier TLS versions you could only say "Here is the list of Certificate Authorities which I trust to issue client certs, give me any cert you have from one of those CAs".

A logout button could work the same way as with usernames and passwords. Sure you could use the cert to reauth the user with every page load but you could also use a traditional login page you just replace the user / password entry with the certificates and then operate as usual from there. Same with privacy it is all in the implementation details.

A logout button doesn't give extra security if anyone with access to the PC can hit the 'login' button. So unless access to the cert is behind a password there is no useful way to logout using client certs.

The user usually has the option to require a pin be supplied to unlock the hardware token. The advantage to certificates on a hardware token is that they can't be stolen remotely unlike a user name and password which can be compromised on either the user end or service provider end.

i.e., put a cookie on the site, and trust the cookie instead of the cert for all pages except the login one? That leaves you with all the usual problems of cookie-based logins that certs are supposed to solve (revocation, risk of being stolen, etc.), and also if you want to do that you can just put a private key in localStorage and use WebCrypto on the login page. Or with username + no password + FIDO security key as your only factor, if you want a hardware token, or whatever. There's no advantage in using SSL for this.

The point of the hardware token is that the credential never touches the PC. Putting a private key in local storage is no better than a user name and password because it leaves it open to theft. The most common problem that an everyday user faces is either a data breach on the service provider end or a virus / keylogger on their PC. Hardware tokens with certs solve both those problems in terms of account access.

The power play in the CA world has already happened, with the major browser and operating-system vendors -- using their position as gatekeepers of the root certificate stores for the overwhelming majority of devices as leverage -- working to clean up a lot of the historical bad behavior.

Also, any unilateral move by Google would have to get past the rest of the CAB, which includes Apple, Microsoft and Mozilla, who all control significant root certificate stores.

An EFF member has tried to convince me that Google is subject to the whims of the CAB, but failed to explain to me how. Google's Root CA policy doesn't mention the CAB, and specifically provides Google's own authority to remove CAs as it sees fit.

Whether or not Mozilla, Microsoft, or Apple follow suit, if Google were to chose to distrust a CA, such as they did with Symantec, due to Chrome's 60%+ market share, that CA is out of business, regardless of what any other browser vendor says on the matter. Whether or not the other vendors choose to follow suit doesn't change the fact that the CAB has no legal authority over Google, and Google is a significant majority of the browser market.

You just shifted the goalpost.

Google's going to maintain a root store either way. The parent I replied to was worried that Google becoming a CA would be a power play to eliminate all other CAs and then Google would get out of the business. Apple, Microsoft and Mozilla have the power to drop Google's CA from their root stores and make Google-issued certs worthless on a huge number of devices worldwide, which is how they act as a balance against unilateral moves by Google-the-CA.

Would Mozilla be able to risk being the browser that can't access Google services? I am not sure that's a realistic scenario for any of the major browser vendors. But arguably if Google's Root CA were never to gain multi-browser support in the first place, they'd never be able to launch their service to begin with.

I don't think Google would "embrace, extend, extinguish" the CA market though as the parent suggested, the CA system gives Google a massive amount of control of the Internet at large, and I can't fathom them giving it up.

I don't understand why step 2 would happen, but burning off 90% of the existing roots would be a good thing.

Now that SSL is effectively mandatory for every HTTP application, cloud providers will all either have to become CAs, or integrate with an external CA like Let's Encrypt.

The existence of LE provides an alternative to commercial and potentially hosting-specific CAs, so a Google CA isn't going to wreck the market. Except for the existing commercial providers who change large fees for not much.

Reply on news.ycombinator.com