
Blow up the Cert Business - smacktoward
https://www.tbray.org/ongoing/When/201x/2014/07/09/Disrupting-the-cert-business
======
michaelbuckbee
A real issue with the cert business is that phishers have really screwed up
the economics of it. They are desperate to get SSL certs for domains that are
almost that of legitimate companies and charities as much of the general
internet populace has absorbed that "the green lock" means "safe".

This has kicked off two responses by CA's and Browser makers.

Certificate issuers putting in place a mix of automated and manual approval
mechanism for what used to be "automatic" certs (from my own experience [1] -
around 10% of certificate requests fall into this category).

Browser makers have started to de-value the UI/UX of the "cheap and easy"
certs that Tim is advocating be issued. Case in point Tim's URL is just gray
(no green at all) in FF, but you can see a definite trend across the board in
making the SSL presence of non EV certs less prominent [2]

Taken together, I think this makes it really tough for Google to step in with
a 'cheap' solution.

1 - I run
[https://addons.heroku.com/expeditedssl](https://addons.heroku.com/expeditedssl)

2 - [https://www.expeditedssl.com/pages/visual-security-
browser-s...](https://www.expeditedssl.com/pages/visual-security-browser-ssl-
icons-and-design.html)

------
plorkyeran
While I suppose I trust Google to be a well-behaved CA more than many of the
current CAs, I still don't like the idea of a single company utterly
dominating the CA business no matter how well-intentioned they may be.

~~~
smacktoward
Yeah, this is my concern too. The closer we get to being able to have a
Google-only Internet experience (Google DNS, SPDY vs HTTP, Chrome as the
browser, etc.) the more nervous I get. It's just a lot of power to concentrate
in one place.

~~~
adestefan
Don't forget Google as the ISP (Fiber).

~~~
michaelt
Don't forget the search engine, the webmail provider, the ad network, the
analytics service, maps, sign in with google, youtube, docs, javascript
library CDN, fonts, Android, social network, translation system, and blogging
network.

~~~
smacktoward
"But other than THAT, how was the play, Mrs. Lincoln?"

------
cpeterso
What is the minimum (useful!) level of trust for a certificate? If someone
like Google handed out free (leaf) certs using the domain ownership
verification process they use for Google Apps [1], is that any less useful
than what other CAs do today?

[1]
[https://support.google.com/a/answer/60216](https://support.google.com/a/answer/60216)

~~~
Someone1234
The problem with that concept is: Bad guys steal your domain (e.g. break into
the DNS provider and change the A records). They go to Google, request a cert,
and Google checks the domain for the verification code (like Google Apps).

Google generates you a new certificate, you then install the certificate, and
now users are even less suspecting that the domain has been compromised. It
even defeats a Strict Transport Security policy.

~~~
nucleardog
As opposed to something like RapidSSL which would require an MX record change?

Point the MX record to an intermediary server which forwards all non-RapidSSL
e-mail (so no one notices an interruption) and captures the RapidSSL messages
for you. Generate certificate.

Once you have the certificate, you can swap the A record over to your own
machine and no one would be any wiser.

------
weddpros
Just an idea... should we consider the problem is not with the first visit,
but with subsequent visits?

If I sign-up on a website (bank, Google, etc), all I want to ensure after that
is that when I go back to that site, I will sign-in to the right website and
not a phishing one.

CAs don't provide this guarantee, when a simple self signed certificate would!

Certs signed by CAs provide some kind of identity, while a self signed ad-hoc
cert would provide strong identity! Let's imagine 3 factor auth: something I
know, something I have, something they GAVE me.

In the case of Google, I would gladly install a Google CA cert for all of
Google's services. Okay, I just checked and Google is already its own issuing
CA :)

When SSL was born, the "problem" was to send your credit card number to an
authenticated website (web store). Nowadays, we're loyal returning customers,
and we want to sign-in without _any_ ambiguity.

Maybe we should kill _generic_ CAs? and favor self signed certs after all. I
could trust any self-signed cert, if the only guarantee I need is that I'll
always return to the same website where I opened my account.

Remember, that was just an idea, please tell me _where_ I'm totally wrong!

~~~
michaelbuckbee
CA's don't provide this security, but there's a new security mechanism called
HTTP Strict Transport Security - [1] HSTS - which (along with some certificate
pinning [2]) would.

1 -
[http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

2 - [http://security.stackexchange.com/questions/29988/what-is-
ce...](http://security.stackexchange.com/questions/29988/what-is-certificate-
pinning)

~~~
weddpros
I wasn't aware of it. Cert pinning is definitely a good solution!

------
mey
I was recently pulling together the wide variance in SSL Cert providers. I
have an incomplete list available here
[https://docs.google.com/spreadsheets/d/1jzZqGzvtHe4egYNnp1L4...](https://docs.google.com/spreadsheets/d/1jzZqGzvtHe4egYNnp1L4-df_avGjEqMZiv0FWFP4d4E/edit?usp=sharing)

The real work is figuring out _which_ CA cert your cert will be issued on,
_then_ determining device/software package compatibility. (Chrome on Windows
uses Windows CA store, Firefox on Windows uses it's own, Java uses its own,
and all of those stores may or may not be routinely updated)

------
veesahni
It would be nice if we could store SSL certificates on DNS records, like how
email signing (domankeys/DKIM) works.

Looks like there's already some effort for this:
[http://tools.ietf.org/html/rfc4398](http://tools.ietf.org/html/rfc4398)
[https://bugzilla.mozilla.org/show_bug.cgi?id=672239](https://bugzilla.mozilla.org/show_bug.cgi?id=672239)

~~~
rakoo
That already exists and is called DANE [0].

The issue with DANE is that you must make sure the records you receive are the
good ones; unfortunately bare DNS as we know it doesn't provide any integrity
or security, so we need a way to make sure there is no spoofing... and this is
exactly what DNSSEC [1] aims to provide.

The problem here is that while DANE is straightforward, DNSSEC is a massive
pain to implement and, most crucially, _maintain_ , especially for domain
owners. Oh and the whole security relies on a hierarchy of key signatures that
takes its root in the ICANN. So, instead of having a "decentralized" world of
CAs, we go back to a hyper-centralized domain where everyone depends on the
good actions of the ICANN. That sucks.

[0] [http://tools.ietf.org/html/rfc6698](http://tools.ietf.org/html/rfc6698)

[1]
[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)

~~~
xorcist
I don't think people should be so hung up on the risk of ICANN misbehaving.
While the risk is obviously there, they have actually been very Internet-
friendly in their lifespan and so far managed to steer clear of both
government and private sector interference. (The big exception being all the
new top domains created, which is a disturbing trend but not really damaging
to existing ones.) When a certain naval themed torrent site hangs on to their
domain name you know things are really not that bad.

The good side about a central needle's eye for decisions is that all eyes are
on them. Any bad move will be caught immediately by the community and routed
around. One fuck up from their side and no one would trust them with the root
certificate for DNSSEC any more.

Until that happens, can't we at least agree that an authenticated DNS for
certificate storage is a whole lot better than the current CA system. That
does not mean development on alternatives should pause for even a second, but
please get those TLSA records of yours signed and published today! Only then
will we at least have something to compare other proposals against.

The fact that we have a central DNS root will be with us for the forseeable
future. And as long as we use domain names for identity that centralization
will be a thorn in the side. But that is what we use, for better or for worse.

~~~
rakoo
> Any bad move will be caught immediately by the community and routed around

And go where ? We don't even have an alternative when we have the time to
build it, do you think we will be able to build one when everything goes down
?

I agree with you that there are no viable alternative for the moment, and we
should at least put those TLSA records. You will notice that I was complaining
specifically about DNSSEC, not about DANE; as long as we have a secure way to
transmit those TLSA records, everything is fine.

A slightly better thing than what we have today would be:

\- Deploy those TLSA records, both in DNS servers and applications

\- Have _everyone_ use its own resolver, or at the very least a resolver they
_really_ trust (if we want to benefit from the cacheability of DNS)

\- Transmit DNS records through a secure channel such as DNSCurve

The advantage being that these are all available today with little
modifications.

~~~
xorcist
I don't think we need to go somewhere else if ICANN misbehaves. That's why I
wrote route around.

It all depends on what the particular bad move is. Suppose they transferred
control over a top domain to a US state actor. That's one of the few scenarios
I can imagine that are at least within the realm of the possible.

In that particular case I believe we should pressure root server operators to
temporarily hold the change and get ICANN to backpedal.

DNScurve is unnecesary when DNSSEC is implemented. It also has the unfortunate
design to give operators of authoritative name servers the possibility to
manipulate the zone. In that situation all domain name owners would be
expected to run their own DNS servers. I don't think that's realistic.

------
wtbob
Trusting Google to certify the world's systems hardly seems wise.

What _does_ seem wise would be for each certificate to certify multiple
independent chains of identity: each certificate should certify hostname, IP
address and national identity at a minimum, and possibly also things like BBB
status, trade association status &c.

How could this work? Imagine the case of HTTPS at 74.125.227.241 (of of the
IPs www.google.com resolves to). My browser would have public keys from the
IANA and from the US federal government (and possibly others); it would trust
IANA to vouch for IP addresses and DNS, and would trust the US to trust for
national identity.

The IANA would sign a certificate stating that ARIN are permitted to assign
their various blocks of addresses; ARIN would sign a certificate for the block
74.125.227.241 is in themselves, or a middleman if there is one. Google would
sign a certificate for the machines behind 74.125.227.241, stating that they
are permitted to use that IP address (wildcards could be used in the probably
case that one machine actually responds to more than one IP address).

My computer, talking to 74.125.227.241, would receive this certificate chain
and can see IANA->ARIN->(middleman)->Google->...->machine, and can verify that
there is no spoofing.

I think that some of this is theoretically possible with IPsec, but I don't
know if it's used anywhere.

Meanwhile, IANA would also have signed certificates stating that Verisign are
allowed to vouch for holders of .com names. Verisign could sign a certificate
stating that Google are allowed to vouch for holders of google.com names, and
Google could sign certificates stating that various subunits are permitted to
sign certificates for various subdomains of google.com. This is similar to the
current CA structure, only with the addition of delegation and subdomains,
which is really, really key.

Because of this, there would be no way for, e.g., INRegistry to vouch for
google.com, or any .com, because they only have the right for *.in.

Even more important, the holder of each certificate could further subdelegate
the authority he received, either in whole (in order hold a secure,
ultimately-trusted offline key), or to grant limited privileges to different
units. Thus apps.google.com might be delegated to one group and www.google.com
to another.

Some of this is done via DNSSEC currently.

The US federal government would sign a certificate granting the state of
Delaware the ability to vouch for corporations under its jurisdiction;
Delaware would sign a certificate stating that 'GOOGLE INC' is indeed a
Delaware corporation. The US federal government could _also_ sign a
certificate for Google, vouching for their tax identification and whatever.

The BBB could do the same thing, indicating that the Delaware corporation
'GOOGLE INC' holds a particular level of recognition.

MasterCard could issue a certificate indicating that Google is permitted to
charge credit cards for amounts up to whatever.

So, the browser trusts IANA to certify DNS names & IP address; it trusts the
US government (and possibly others) to certify corporate identities; it trusts
the BBB to say nice things about companies; it trusts MasterCard (and others)
to say that Google are permitted to receive my credit card info.

So the browser bar might show green, because DNS & IP addresses are good; it
might show the flags of the US & Delaware, because GOOGLE INC is a Delaware
corporation (a foreign subsidiary of Google might show its local nation's flag
as well); it might show a C- for Google's BBB rating; it might show a
MasterCard logo, or just a '$' or local currency sign.

The browser might outright refuse to display a page where IP & DNS
authorisations did not exist, and might display warnings on pages with IP &
DNS authorisations but lacking legal identities.

Of course, in reality each of these entities would probably have an offline
key which is what was vouched for; that offline key would then be used on,
say, an annual or monthly to certify online secure keys, which might then be
used on an hourly basis to certify endpoint keys.

You what's really cool? All of the work required to efficiently represent &
calculate on (e.g sign & verify not just a single certificate, but an entire
chain) the certificates need to do this has already been done, almost 15 years
ago.

It was a standard called SPKI, and it knocks the current X.509-based XPKI
dead. An efficient binary representation; easily-parsed human-readable
certificates; trust calculus; it was all there.

A lot of folks say that SPKI died because it eliminated the need for CAs, but
if you look at all the above there are more, not less authorities; there'd
clearly be a space to market certificate services, to offer insurance &c.
Granted, I don't see a lot of room for the current model where a company pays
someone to vouch for them, and I trust that voucher, despite there being no
relationship of trust between mee and the vouching entity.

