Add Amazon root certificates(bugzilla.mozilla.org)
bugzilla.mozilla.org
Add Amazon root certificates
https://bugzilla.mozilla.org/show_bug.cgi?id=1172401
79 comments
Does it bother anyone else that the links Amazon provided to their certificates and CRLs are not https?
The fingerprints are included in the bugzilla ticket and the CRLs are signed with the certificates, so TLS doesn't technically add anything as long as you confirm the fingerprints (though it doesn't hurt anything either).
Yeah, it just seems odd
I don't think CRLs usually are, under current infrastructure anyway.
How can you verify the certificate of the server when it's signed by the certificate you want to fetch; or check that it hasn't been revoked when what you're connecting to is its own CRL/OCSP? What about the risk of infinite loops?
Cross-signatures, or multi-signatures, perhaps; or going opportunistic and simply not minding on that occasion?
Nope, for now they just use HTTP, and pin what they need to, to the fingerprint.
They should, however, specify an SHA-256 fingerprint. SHA-1 doesn't really cut it anymore. But that's what Mozilla currently require, so that's what Amazon provided. https://wiki.mozilla.org/CA:Information_checklist
How can you verify the certificate of the server when it's signed by the certificate you want to fetch; or check that it hasn't been revoked when what you're connecting to is its own CRL/OCSP? What about the risk of infinite loops?
Cross-signatures, or multi-signatures, perhaps; or going opportunistic and simply not minding on that occasion?
Nope, for now they just use HTTP, and pin what they need to, to the fingerprint.
They should, however, specify an SHA-256 fingerprint. SHA-1 doesn't really cut it anymore. But that's what Mozilla currently require, so that's what Amazon provided. https://wiki.mozilla.org/CA:Information_checklist
No it's not. In order to establish a TLS connection, you'd have to do a revocation check. Can't perform that if you need a TLS connection to get the CRL.
As far as the certificate, I'm guessing there are many, many checks as to the authenticity of the key before it ships.
Plus, they'd have to use a cert from another CA, since theirs are not trusted yet. That's not elegant in a process that is used to start CAs.
As far as the certificate, I'm guessing there are many, many checks as to the authenticity of the key before it ships.
Plus, they'd have to use a cert from another CA, since theirs are not trusted yet. That's not elegant in a process that is used to start CAs.
It's normal, since their CA certificates aren't added to Firefox yet :-)
The CRL part is according to the standard
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)
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)
People having obscure knowledge never ceases to impress me.
(It's page 104 though ;P )
(It's page 104 though ;P )
I knew that as well because I was equally surprised that the revocation lists are over HTTP and looked this up, only I did this a few years ago. Not very obscure in my opinion.
An obvious move for Amazon. They'll be able to make SSL certificate management pretty painless for people using ELB.
I wonder if they have plans for CloudFront too. That'd be a killer feature to be able to use HTTPS on cloudfront on a custom domain without it costing a fortune.
You already can do that for pretty cheap (if you use SNI), but only from the CLI and the command isn't exactly simple. [0] Having it integrated so you just click 'yes, SSL' and it handles cert generation and config would be great.
[0] https://bryce.fisher-fleig.org/blog/setting-up-ssl-on-aws-cl...
[0] https://bryce.fisher-fleig.org/blog/setting-up-ssl-on-aws-cl...
Neat! I had missed the rollout of SNI certs.
> costing a fortune.
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.
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.
Why would anyone use non-SNI SSL/TLS anymore? Are there really that many Windows XP clients out there?
One of my clients still sees a surprising amount of Android 2.x traffic. Other than that, yeah, I can't see a reason.
Exactly. I default to SNI being acceptable now, unless somebody has convincing evidence that for their particular use case they can't use it.
I dunno where the line it, but Windows XP is in the ballpark of 2% of our traffic, depending on the site and how you measure it. The bummer is that HTTPS breaks kinda badly if you use an SNI cert and the OS/browser doesn't support it.
2% is IE on XP, or XP in general?
I wish people would be more clear when they bring up XP. The OS is not the problem.
I wish people would be more clear when they bring up XP. The OS is not the problem.
> 2% is IE on XP, or XP in general?
The latter sounds more likely to me. The sites I run get about 2.5% XP, but most of that population uses Chrome or Firefox. IE on XP accounts for only 0.3% overall.
The latter sounds more likely to me. The sites I run get about 2.5% XP, but most of that population uses Chrome or Firefox. IE on XP accounts for only 0.3% overall.
At this point my experience is that most people still on XP are using IE - it mostly appears to be institutions that are still(!) using a primitive corporate build.
python 2.7 doesn't support SNI which is used by a lot of consumers of APIs
Python 2.7.9 supports SNI:
https://www.python.org/downloads/release/python-279/
What's the benefit to serving your assets from a custom SSL-secured domain over https://whatever.cloudfront.net? The end-user doesn't really care what domain they're served from.
More than that, the Mozilla request also mentions code signing certs, makes it clear this is not just an internal AWS thing:
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.
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.
That would be nice, since managing SSL certs on ELB is currently the most painful way I've ever experienced. The documentation is vague, it's extremely finicky and doesn't give any useful feedback if you've done anything "wrong".
The community needs to figure out a way to demonopolize this business and make it ubiquitous without destroying its credibility.
I think the EFF has (and is making great progress towards launching it): https://www.eff.org/deeplinks/2014/11/certificate-authority-...
They're trying: https://letsencrypt.org/
"The community needs to figure out a way to demonopolize this business and make it ubiquitous without destroying its credibility."
Did you mean " ... while restoring its credibility, which has long since been destroyed" ?
Did you mean " ... while restoring its credibility, which has long since been destroyed" ?
A typo in the introduction:
"We do not require customers that customers have a domain registration (...)"
And I can see exactly how they got to that mistake...
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.
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.
Very fitting. 'Customer Obsession' is Amazon's first leadership principle [1].
[1] http://www.amazon.jobs/principles
[1] http://www.amazon.jobs/principles
How long will it take for the CA to be distributed to a large enough browser base?
I mean, it could be years. Is there any other, speedier process? (cross-signing, for instance).
I mean, it could be years. Is there any other, speedier process? (cross-signing, for instance).
8 to 12+ months for it to be in a release version of Firefox. https://wiki.mozilla.org/CA:How_to_apply#Timeline and https://wiki.mozilla.org/CA document the process in great detail.
Does that go for new root certificates as well?
I wonder how long it will take before it becomes practical to rely on Amazon-issued certs.
Since Amazon is an American company, would you trust their certificates? I mean are they going to give private keys to NSA or whoever is now spying in the US?
There isn't a single CA in existence that wouldn't be subject to nation-state pressure and/or infiltration. If NSA/GCHQ/FSB/etc. want to MITM you, they can probably MITM you.
I've always enjoyed James Mickens' perspective on this:
"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...)
"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...)
While entertaining, this is a bit like saying that there are only two kinds of vendors: beach stalls that sell you icecream; and giant multinational conglomerates that have huge department stores. In reality, there's plenty of folks in-between.
There are, however, degrees of pressure resistance. Given AWS dropped WikiLeaks the moment a few politicians started getting upset, they seem unlikely to be very concerned with customer protection.
If you're that concerned about centralised CAs, use self-signed certificates and distribute the keys to your users in-person. Once they get their browser to accept your certificate it will warn if it changes. Of course it doesn't scale very well, but for certain use-cases this "physical trust" system works.
Because other countries don't have spy organizations either? I mean, who can you really trust these days. Even non American companies could be compelled to hand over their private keys IF the NSA were doing such a thing.
It'd be FANTASTIC if the NSA used Amazon's private keys. It'd leak tons of information and cause a huge backlash. Amazon's CA would instantly be revoked. It'd cause a ton of damage to them. That might spur tech companies to spend even more on buying politicians, which is probably a good thing (or a lesser evil).
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 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.)
Why would I trust a company like Amazon with a root certificate when it doesn't even use HTTPS across its website?
Neither do Verisign, Entrust, TrendMicro, IdenTrust, StartCom which are root certificate authorities your browser trusts right now. All of their sites are accessible over HTTP. It doesn't really say anything about whether you should trust their CA businesses.
The GP wasn't pointing out that Amazon is "accessible over HTTP". He was making the much stronger point that Amazon doesn't even offer HTTPS on most of its site.
The latency increase for HTTPS actually causes a measurable conversion difference in the e-commerce space. It sucks but it's true.
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.
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.
Why would a redirect from https to http and then an http page load be faster than just returning the page over https? You're taking the SSL handshake latency hit either way.
You arguably shouldn't. We have way too many providers of certs as it is (including the Hong Kong post office, because reasons).
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.
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.
I don't think any of the big (or small) corporations should be trusted, but in the case of Amazon, the question of trust in connection to data is much bigger than trusting them not to abuse powers from having SSL certs in the browser. They already run a huge part of the infrastructure of the Internet, and have the possibility of reading the private SSL keys of a number of services by virtue of hosting them.
The CA system is broken by design, but I don't think adding Amazon will make much of a difference either way.
The CA system is broken by design, but I don't think adding Amazon will make much of a difference either way.
I'm not sure I agree with you but still I found it a bit funny how many of the URLs in the ticket were http instead of https.
[deleted](2)
This being Amazon AWS gives me hope that this will be a CA with an API that allows automatic certificate issuance for domains you control. I find the process of issuing and reissuing certificates for all sorts of services to be an increasing amount of work as more and more services move to https.
(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)
(The letsencrypt.org CA is build around automated certificate issuance through an API, but some competition wouldn't be a bad thing.)
Check out SSLMate, which has been automating certificate issuance since early last year: https://sslmate.com
We have both an API and a highly scriptable open source command line client.
We have both an API and a highly scriptable open source command line client.
Seems very clever, but I have to ask:
> 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.)
> 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.)
Could be it also discourages script kiddies from pulling antics.
Not sure why you've been downvoted - this is pretty much the reason for elevated pricing of wildcard certs. They are more open to abuse (have seen them used for phishing sites), so the issuer carries a higher risk of having to do additional management around the cert (i.e. revocations), so therefore charge more.
The cynic in me presumes that it's to make up for the lost cash in charging you individually for all those subdomains.
What do you mean about cert errors on a single domain [requiring a wildcard]? Because you use a lot of subdomains, or the bare domain/www. prefix?
If it's the latter, I think some (many?) registrars may let you add one or more SubjectAltName[1] values to a single cert for free or minimal cost, at least compared to a wildcard.
[1] Other values for which the certificate is considered valid: https://en.wikipedia.org/wiki/SubjectAltName
What do you mean about cert errors on a single domain [requiring a wildcard]? Because you use a lot of subdomains, or the bare domain/www. prefix?
If it's the latter, I think some (many?) registrars may let you add one or more SubjectAltName[1] values to a single cert for free or minimal cost, at least compared to a wildcard.
[1] Other values for which the certificate is considered valid: https://en.wikipedia.org/wiki/SubjectAltName
I wonder why you're excluding StartSSL. It's no matter if you trust them as long as all major OS/browsers trust them.
Wildcard SSL
$149.95
/ year
maybe sslmate can make a deal with GlobalSign/AlphaSSL for wildcard DV certificates. At least there are resellers out there that offer wildcards for 42$ https://www.ssl2buy.com/alphassl-wildcard.php but of course suck at API/automation. I've seen other resellers (usually lowendtalk-VPS) selling AlphaSSL wildcards for below 40$/y in the past.
Yep, I use AlphaSSL right now. It's been doing me well for the past year, so I just renewed a couple days ago. No regrets at all.
Nearly every CA already has an API to do cheap/free level (DV) SSL certificates for domains you control - all you need is one of:
- 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.
- 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.
Unfortunately I don't think that the level of differentiation provided in current browser implementations to EV certificates has users noticing when they get one.
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.
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.
Certly (which I founded) is working on an API for doing exactly this. You'll have to write your own tool to query our API (for now), but who knows what'll happen in the future.
Let's Encrypt is nice for your web server, but using that certificate at the ELB may not be so trivial. I hope that Amazon will offer free SSL certificates for ELB. Their custom SSL certificates for CloudFront currently cost the outrageous $600/month (well, $20/day), and recently they added free SNI certificates, so, for CloudFront, they still may charge us, but, hopefully, a lot less than the crazy $600!
please support S/MIME!