"In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@ virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them. In summary, https:// and two dollars will get you a bus ticket to nowhere. Also, SANTA CLAUS ISN’T REAL. When it rains, it pours."
(From "This World Of Ours" - http://research.microsoft.com/en-us/people/mickens/thisworld...)
The CA system is not great. But state actors using a CA is sorta far-down on the list of issues because it is so detectable and provable. CAs take a lot of work to get going and burning a CA isn't something anyone would do lightly. (Well except incompetent ones, like CNNIC.)
(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)
We have both an API and a highly scriptable open source command line client.
> DV certificates are $15.95/year per domain,
Not a bad price, very much one I'd be willing to pay in order to get certificates via a CLI.
> or $149.95/year for unlimited sub-domains.
Ouch, 10x for a wild card? Why do issuers do this? It really puts a crimp on the whole "hobbyist doing hobbyist things" since that's $150/year just to not have cert errors on a single domain.
(FWIW, I'm deliberately excluding StartSSL for a variety of reasons.)
Wildcard SSL
$149.95
/ year
- an admin-looking email address
- email mention in whois
- ability to upload a file
- ability to add a DNS TXT record.
Yes, that's a fairly low bar, that's why live.com gets taken over every few years with the same fake-DV-cert attack. This is also why EV certificates exist. Disclaimer: https://certsimple.com, where I work, sells EV certificates, we specifically don't sell DV certs.
I'd consider myself relatively security-savvy and I honestly couldn't tell you which of the sites I visit uses EV certs, and I'm fairly sure I wouldn't notice the browser bar change from green if a site got MITM'd with a valid DV cert after having an EV cert.
Pinning obviously helps in that case but AFAIK that works just as well for DV certs as EV.
The CA system is broken by design, but I don't think adding Amazon will make much of a difference either way.
edit: Downvoters--have you ever done measurements? Why do you think Amazon redirects HTTPS to HTTP for product pages? It actually matters and at their scale it's real money.
The answer isn't to attack Amazon, but to move to a model where basic certs (including wild card certs) are free or you don't get your root certificate in, only 3 companies get their cert in and none of the may be based anywhere but Germany or other countries that respect privacy.
But that is just the opinion of this random, angry, nerd.
Customers of the Amazon PKI are the general public. We do not require customers that customers have a domain registration with Amazon, use domain suffixes where Amazon is the registrant, or have other services from Amazon.
[0] https://bryce.fisher-fleig.org/blog/setting-up-ssl-on-aws-cl...
The problem is not the SSL certificate, the problem is the IP address. That will no longer be a problem as soon as IPv6 takes hold in a few years, I give it about 3. They currently have to deploy the SSL certificate to over 30 different IPs hence it costing the immense amount. The certificate can be had for $10.
RFC 5280, Section 8 (Security Considerations): "CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions."
(https://tools.ietf.org/html/rfc5280, page 103)
(It's page 104 though ;P )
"We do not require customers that customers have a domain registration (...)"
The writer was waffling between "We do not require customers to have a domain registration" and "We do not require that customers have a domain registration", and they forgot to remove the entirety of the old wording when replacing it with the new.
I've made this mistake myself several times, and it jumps out at me whenever I see it.
"We do not require that customers have a domain registration (...)"
or
"We do not require customers to have a domain registration (...)"
Did you mean " ... while restoring its credibility, which has long since been destroyed" ?
I mean, it could be years. Is there any other, speedier process? (cross-signing, for instance).