This is a tiny bit odd. So they have issued their first certificate, but they don't have cross-signing in place yet? So between now and november 16th they'll be issuing a whole bunch of effectively broken certificates unless people manually install their root CA?
Why even push this today if you don't have cross-signing available? Without that Let's Encrypt is effectively broken out of the box.
PS - I actually like Let's Encrypt and the work they're doing. I will be all queued up when they go live to grab one (and, yes, will put my money where my mouth is and donate). But doing this today without cross-signing seems strange.
We need to demonstrate proper issuance under our root and gain confidence in our live systems before getting cross-signed. Issuing without a cross-signature for a bit is how we do this.
It's a bootstrapping process, I don't think they can be accepted as a root certificate until they have proved their automated issuing system it working.
One way to prove that their automated issuing system is working, is to turn it on.
Looks like they have set it up to only issue certificates for white-listed domains in the beta program, and they will switch to General availability in the Week of November 16th.
You should read back over their blog to see how much planning has gone into this so far. This isn't a single-file LAMP app running on a VPS, they're setting up a CA trustworthy enough to have its roots in all the major browsers
They aren't making it generally available to the public yet, only to certain beta folks who know what they are getting. It isn't broken out of the box since it isn't 'out of the box' yet.
> Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself. Specifics will depend on your browser. In Firefox, just click the link.
It's scary how easy it is to add new roots on all major platforms. You just click on the CA link and get a response with the appropriate MIME type back, then:
* Windows gives you a helpful little wizard wherein you click "next" a few times.
* Firefox gives you a dialog with 3 checkboxes; check them and click okay.
* iOS sends you to settings, and asks you if you want to trust the given CA.
* OS X hands it to Keychain Access, where you have to select 'trust' from a dropdown and maybe enter a keychain password; it's a bit less intuitive.
* Chrome uses the OS trust store, so it hands it off to the OS while claiming it's a dangerous filetype.
You're incorrect about Windows. If you just click next several times the cert will not be added to trusted. To do that you'll have to override default settings in a non trivial way (deselect "Choose cert store automatically" and select the correct cert store) on one of the steps
Ah, that is a bit misleading. When it says "just click the link," it's referring to the process for installing the root certificate.
It should read "specifics will depend on your browser. In Firefox, just click the link [to the .der file, and you will see a prompt allowing you to trust it.]" It looks like this: http://imgur.com/dzC89xI
Without importing the root, Firefox absolutely distrusts https://helloworld.letsencrypt.org/, and will do so until Bug 1204656 is marked RESOLVED FIXED. :)
> IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.
The cross-signature is expected to happen before the mainstream browsers finish processing our application to be a root CA. That will be the main initial mechanism by which browsers trust our certificates.
My understanding is that Mozilla is primarily just a sponsor of ISRG, the non-profit behind Let's Encrypt. Some of their sponsorship includes dedicated engineering time, but LetsEncrypt still has to pass all the same audits and requirements as any other CA, as defined in the Mozilla CA Certificate Policy at https://www.mozilla.org/en-US/about/governance/policies/secu....
Mozilla's not a nepotist with regard to its root store. :-)
I run https://certsimple.com: we only do EV certificates, we're the fastest place to get an EV cert, we check as much as we can before you pay us a cent, and our application process is 80 seconds.
Just removing the font-weight: 300 helps tremendously. Personally, I'm becoming less of a fan of external fonts. I've noticed lately that they're often the slowest thing to load on sites that use them (especially Google fonts).
The weight works great on a high DPI display, but on older displays, it just doesn't work. Open on a rMBP or iPad, and it's beautiful. I'm guessing the designers are working on a high DPI Mac.
I'm guessing OS X's font smoothing is more aggressive and makes it look better than Windows'. It also depends on how the font was hinted for Windows, whereas on OS X, the system "knows best" and has its own font smoothing technique.
I downloaded all of Google’s font library and installed it locally, means I can read the fonts without having to load them from Google. Still doesn’t help against fonts with 0.5px thin lines.
I’m on linux, and yes, it does. Opening the font selection menu can take for me, with 7000 installed fonts, about half an hour sometimes. I just don’t do that, instead select fonts by name (I know most of them now).
But you don’t notice it until you open a font selection menu.
That's insane! Guessing you don't use Photoshop. At least, the last version I used (I think CS5), the font selection was weird and, no matter what, required that you open the drop down. Bleh. Haha
I've made some changes to Typekit to thicken things up. Is it better? If not, can you provide details of your OS?
Original:
I'll investigate and fix that now. What OS are you on so I can reproduce it?
It looks this this here in Firefox (http://imgur.com/WRWYzBx) and this in Chrome (http://imgur.com/6dFeQhG) on OS X, testing across multiple Macs here. I'd really like to fix it though! Thanks for the heads up!
We moved from Google Fonts to TypeKit recently, so I suspect it may have happened then.
On the updated version, want to give some actionable feedback:
Not just the weight, the size combined with the weight: 12px in a thin font is too light for a screen, especially done in grey. Going to 16px could really make a difference.
Going with a bigger size gives the scope to use a different, contrasting (perhaps thicker, perhaps thicker and smaller for double-contrast?) font for the headings currently in green.
* Getting older happens to different people at different ages, one of the effects of this means eyes get more temperamental, and this doesn't happen 50+, it happens a lot earlier for a lot of people.
As I said above, the Firefox screenshot looks like a printer that ran out of ink, the Chrome version is slightly better, but look at the letter 'T', that's still wrong, a hairline that falls between pixels. That's only acceptable for text that is not actually intended to be read (thumbnails, mockups, zoomed out stuff, etc).
They offer EV certs, so there's some cost involved in doing the identity verification. I don't think it's $234 dollars a year, forever, but it costs something. And that's actually a pretty competitive price for an EV certificate.
Like the other comment says, the font is way too thin on your site and actually hurts to read on my monitor. Any interest I had in this service is effectively gone now.
Text needs to be legible, please try and stick to normal and bold weights.
These shameless plugs are getting really annoying. We know about you, we know CloudFlare and Let's Encrypt are kinda competitors with their free certificates, but you don't have to comment on each post about them. Really, stop annoying us - it doesn't do you any good, honestly!
These shameless plugs are getting really annoying. We know about you
I for one had never heard of these guys and appreciate the mention. Besides, as far as I can recall, it's never been considered problematic to promote your own service on HN as long as the mention is topical and done tastefully.
In this case, the previous commenter was explicitly asking for advice about how to get certificates more conveniently today, so the replies about existing services that can do so seem quite relevant.
Maybe so, but you know every regular guy driving a regular car would rather have a Ferrari and might even spend time looking at them even though he can't buy one.
You're wrong. EV is a scam. I can afford to buy EV for most of my sites, but I don't do it. Because consumers don't really care. Even HN doesn't have an EV! Ferrari is what everybody wants, EV is a different story! And stop downvoting all my comments - it shows your subpar human material. Downvote my main point and stop right there. No need to go aggressive and try to silence me and not comment further, because you will "punish" me further as well.
I am civil, but those who can't help the sick urge to downvote every single comment of mine although they all represent the same points are not civilized.
No, cpach is right. You can't post comments like "it shows your subpar human material" to Hacker News. Personal attacks are not allowed here, regardless of whether someone downvoted unfairly.
There's also the guideline specifically asking you not to go on about being downvoted.
Most are just suggestions, not law. I stand by what I said. Being vindictive is not civilized. I didn't make personal attacks - I have no idea who downvoted me.
Personal attacks can be anonymous, so that's a red herring. And HN's guidelines may not be laws, but neither are they optional—we ban accounts that violate them repeatedly.
It's not hard to see what kind of discourse we're going for here. What's hard is to stick to it when you're feeling that someone is subpar. On the internet, human biases yield a strong tendency to feel that way about others, and we all need to be disciplined about counteracting it. If you can't or won't take up the task, you're not welcome to comment here.
That doesn't mean you have to abide by it perfectly. I can't, and doubt anyone can. It means that when we slip we need to recognize our error and correct it, not defensively dismiss the information.
Then do the right thing and solve the problem by removing downvote on comments - you will do this community a huge favor and you will simplify the UX as well. It has no purpose outside of emotional buildups. Upvotes give you enough for sorting purposes - it's been working well for Facebook and Twitter. For everything else, there's reddit!
Downvotes are imperfect but HN would be worse without them. However, I don't think that has anything to do with your breaking the rule about incivility. Being downvoted, even being downvoted unfairly, is no excuse. Please only post civil comments from now on.
I am sure that you cannot back with any credible evidence the assumption than downvoting comments makes HN a better place. You can add flagging and that will do better, but downvoting is unhealthy. The fixed -4 threshold is random and wrong as well. The loyalty to Paul Graham's original decisions is misunderstood loyalty and there are a lot of missed opportunities here, because of these repeated mistakes.
Yes, I know who he is. Although I had a much older account, which password I couldn't recover, because it's from the days when no email was necessary here, I frequent HN for years and that's why I care about this community as I spend a significant portion of my life in here.
We can sometimes help people regain old accounts with no email address in them. If you still want it, you're welcome to email us (hn@ycombinator.com) with the username and we'll look into it.
I really would not care if any of your sites had EV. And I don't care that HN does not have EV. But I may care whether the place I am going to spend money does have one.
Oh, the commenter asked for the overly expensive EV type? Let's not be the devil's advocate. This is the wrong way to advertise. This is not the beginners corner. You advertise once, twice, three times, people remember, you can search HN - no need to annoy people till the end of the world. The company seems desperate for new business this way anyway.
The client has a checkpointing mechanism that does back up old configuration versions and can revert them. (This client feature is called the "reverter", in case you care to look at some of the code or issues related to it on our GitHub page.)
I still haven't figured out how that interacts with the automated renewal features (probably not well right now!) but the ability to revert configurations exists.
Also, please don't try the client with a live site right now, because we don't have general public availability (nobody outside of Let's Encrypt can get a cert issued from the Let's Encrypt intermediate -- you'll get one from "happy hacker fake CA" instead), and we don't have the cross-signature. We're not even quite at the beta-test stage yet, let alone the "please use our certificates on your popular public services" stage. :-)
The main exception would be if you currently don't have HTTPS enabled at all and you're in the mood to experiment to learn more about Let's Encrypt.
I'm so excited for this to take off, and it's good to see they've taken the first steps, but can I at least download the CA Cert over HTTPS? Not sure how comfortable I am installing a CA cert I downloaded via HTTP, since that's kind of the whole point of this whole thing.
Sorry for asking a potentially dumb question : but is it possible for me to set up a domain name thecitibank.com and ask letsencrypt to issue me a certificate ? I can then create a login page to steal IPINs. Isn't that why we have humans in the loop for issuing certificates ?
This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe, good or bad. HTTPS should be the default communication protocol for every website, and lets encrypt move us a major step towards that by making SSL certificates free and trivial to set up.
"This comment is the exact perception about HTTPS that we need to change. It's not the job of HTTPS to say whether a website is safe or unsafe."
Too late. The web industry has spent about 20 years training regular people to look for that green lock sign in the address bar and feel all warm and fuzzy about how safe the site is. You can post on hacker news all you want about what perceptions need to be changed. It's not going to change the ground reality. SSL, as practiced in the industry today with all it's historical baggage is fundamentally broken. There's no fixing it.
Actually what's really broken is the way we've approached implementations. Recently I was trying to get a self-signed certificate for myself trusted by Python urllib3...I still don't know how to do it. It uses a completely separate trust-store. As does half a dozen other things on my system.
Java is literally the worst as well. The Java truststore doesn't even have all the certs that every major browser supports. I'm looking at you StartSSL.
Green lock = EV cert. People are trained to look for the green, not for the lock - few people other than techies even look for a grey lock. EV certs generally have much more stringent requirements than "hey, give me a cert!".
I'm pretty sure "People are trained to look for the green, not for the lock" is newer and not nearly as widely known advice as "look for the lock". And it's pretty obvious just looking around non-tech-related sites that even the "look for the lock" advice isn't all that well received - so many sites use images of padlocks on the page to imply "banking grade security!!!", surely not _all_ of them are incompetent - I have a strong suspicion that at least some of those people are doing it as part of high statistical significance validated A?B tested funnel optimisations...
A valid certificate only allows you to have a secure connection without errors and warnings popping up all over. It does nothing to guarantee that the domain is "legit". You can already set up thecitibank.com and get an SSL certificate for it without any problem. What you can't do is get the EV (green bar) certificate where indeed you need to go through a human. But I'm pretty sure Let's Encrypt won't be giving away EV certificates.
On a slight side note he may not necessarily need to control the domain entirely, just have access to a privileged email address [1]
However, now it seems you won't even need access to an email address. What would stop someone creating a cert for the real citibank.com and using it for a MITM attack? How many people actually check the green bar?
In the live.fi example, it sounds like Microsoft may have failed to prevent a random user from registering administrator@live.fi as a personal account. Citibank probably won't allow a customer to get that e-mail address!
Yeah - there's many ssl vendors who've automated everything - so long as you can read email sent to webmaster@whatever-damned-phishing-domain-you-like.com, they'll sign a csr for that domain's ssl cert.
You can also do the same at every existing CA that provides domain verified certificates. From personal experience neither StartSSL nor Comodo have a human in the look – until you want more than domain verification (e.g., "green bar" EV certificates).
StartSSL at least have a human in the loop for your initial identity validation. They got in touch with me because I'd put a work address in instead of my home address, and they worked it out and sent me a very human-like email asking me to correct it.
I got also an email from a guy because my domain name had been registered that same day, telling me to wait, sure you can automate the check, but at least the email didn't look automated.
We don't have humans in the loop for issuing certificate; this can and has been exploited for fun and profit, with fun attacks like getting a cert for "citibank.com\0.mydomain.com" which used to trick the C strcmp in most browser certificate checking routines. Moxie has an entertaining talk: https://www.youtube.com/watch?v=MFol6IMbZ7Y
Your problem would be getting people to "thecitibank.com." Chrome, Firefox, and GMail would all eventually figure out it was a phishing site and warn users about clicking through to it.
As has been said, existing domain-validated (i.e. basic) certificates are automated anyway.
The type of certificate that banks etc use are EV - Extended Validation. This means the organisation details are verified as well, and as such the browser displays the verified organisation name in green in some cases, instead of any host/url at all).
Actually it's automated in most places, simply requiring you to confirm a request via an e-mail address associated with the domain you're getting an SSL for (typically admin@ hostmaster@ webmaster@, though it varies between certificate providers).
Most of the reputable CAs have some practices in place to check for keywords related to big brands and auto-reject certificate requests. (So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)
"(So you can't get a certificate for "login-facebook.com" or whatnot, for instance.)"
You mean not from one of those "reputable" CAs. But really, why would I go to a "reputable" CA for my deceptive certificate if my intent is not so reputable?
Er, from personal experience I can say that at least some well-known CAs absolutely do review keywords appearing in SSL certificate requests. For a (really stupid and disappointing) example, see:
What's the target audience of the beta program? I'd love to play around with this on a personal domain but I doubt that there will be more than 2 or 3 unique visitors between now and general availability. Do they want signups for the beta program irrespective of the traffic volume of the site or would toy site signups just be more of a hassle for someone to approve?
The verbiage on that page isn't very clear on if there's some manual process for approving beta participants or if it's just grab 100 entries a week out of a Google Sheets page.
Does anybody know if there is any protection built in against MITM or DNS poisoning attacks?
It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate.
For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which routes along a set path - say 2.3.4.5 and 3.4.5.6. To verify that I control amazon.com, letsencrypt is going to try and fetch http://1.2.3.4/something (through DNS resolving). If I can get MITM access on 2.3.4.5 and pass back /something to the request, letsencrypt is going to generate a certificate for me that I can use to say I am amazon.com for the entire world.
Is there any protection against this built into letsencrypt for this? Maybe checking if amazon.com already has https:// ? Although I'm not sure if there is any way to get around a DNS poisoning attack...
In essence, this seems to mean that you can take a single successful MITM and turn it into a globally authorized MITM. Right?
They may do domain validation by looking up WHOIS and emailing the contact address there.
You could MITM the DNS MX lookup and respond with an IP address of an SMTP server you control, and grab the validation code in the verification email as it is dutifully delivered to you just as easily.
Edit: In fact, come to think of it... For DNS you might not even need to MITM, just be able to spoof the IP source in an UDP package and correctly guess the remote source port + possibly a query ID, and race the real DNS server? I wonder how feasible that would be at for example 1 Gbps?
Boulder (the CA backend) has two solutions to this problem
a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate
b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuance (servers which would move over time)
Currently (a) is mostly implemented but (b) needs quite a bit more work before it can go live.
What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one?
Also, how can the new owner revoke all certificates delivered to previous owners?
Certificates expire. Presumably the answer to all of your questions would then be to wait for the old certificate to expire.
So if you want to mitigate the consequences at the outset, use certificates that expire quickly. Which should be easy when renewing a certificate is free and automatic.
Either wait for the certificate to expire, register a new certificate for the domain with another CA which LE will see and can then be used to prove ownership, or ask the originally issuing CA to revoke the certificate which will remove the need for the challenge completely.
I interpreted "you must prove control over both the server and the key used in the existing certificate" as meaning that if a Let's Encrypt certificate for the domain has been created in the past, you need to own its key (presumably proved by signing something with it) to get another one.
Is that wrong?
Waiting for certificates to expire could mean waiting for years, unless they have auto-renewing very short-lived certificates (but then you have the same problem for the authentication used to automatically get those certificates).
LetsEncrypt does use very short-lived certificates (90 days) for this reason. However, you have to remember than when you buy a domain you already have no idea if any CA has issued valid certificates for it.
Any CA performing domain ownership validation would be vulnerable to the same thing. If you can fake its WHOIS requests or make it appear as if the domain making the request does in fact have the "canary" file they told you to host to prove ownership, then you can get any CA to give you a cert for any site.
If the registrar held the job of being a CA, then at least there wouldn't be a spoofable link between the CA and the domain owner - the registrar already has your account information and proof of ownership, 100% verified, when your domain is held with them...
Sure, but registrars would need to start doing a lot better job of checking the identity of people applying for domains, otherwise we'd just end up with domain validated certificates all over again.
As the grandparent post notes, all CAs completely automate domian validation at present.
My point is that regular domain validated CA should be the sole job of registrars. It would even prevent parallel certs being fraudulently issued - a domain can only be registered at one registrar at one time.
Sure, you could have the other CAs still offer EV (real-world identity) validation as a value-add.
But it's pretty silly that, currently, you have to pay a third party (today's CAs) to validate something that the registrar already knows for sure.
The other side of that argument is that if your registrar is also your CA, they have the ability to give bogus SSL certs to an evil server and the ability to direct your domain to that evil server.
They can already do that, as they could temporarily hijack your NS records and buy a cert somewhere else. If you can't trust your registrar, you have bigger problems (I'd say "all is lost")
On the flipside, having a registar act as the only valid CA would mean that choosing a trustworthy registrar suddenly has real value. Power users could make an educated opinion on the trustworthyness of a given domain validated CA. Domain owners could be sure they're not at risk for how in the current system, an adversarity could get a valid parallel SSL certificate from a sloppy bargain-bin CA, even if the domain owner picked the most expensive and diligent CA and registrar for themselves.
A lot of folks might not have thought through the weakest-link aspect of the current system: they feel like they're safer because they chose to use a reputable or trustworthy CA. But misissuance events that I've heard of have never involved CAs that the victims had any business relationship with at all.
Agreed - but by making this a fully automated system you open up an easily testable and repeatable source of attack.
I don't think "You have to trust something" is really right in this case, as you're basically saying "You have to trust every single router between letsencrypt and every server on the internet".
I guess it's correct that with most current CAs now automating a lot of this with minimal manual checks, this is probably happening already? I wonder how many amazon.com valid certs are floating around the place? (Or more likely, smaller sites where people wouldn't be checking if the cert is really valid). The original point behind the costs charged by Thawte et al was that they would actually validate that you're who you say you are. I guess that ship has sailed though.
All mainstream CAs issue certs through a fully automated process, and have for at least a decade. Generally you are required to receive emails sent to the administrative contact in WHOIS, put something in a DNS TXT record, place or file they give you at a URL they give you, or some combination of the above.
There are Extended Validation (EV) certs where a human verifies your ownership of a legal entity. Chrome presents these as a big green bar with the name of the corporation in the URL bar. Most certs (including Amazon's) are not EV certs.
While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your apps is much more preferred.
This comes up when you are running a multi-tenant app with many tenants; github.com is a good example. You can sign up as "dude.github.com" or "me234.github.com" and so on. So, Github can either a) obtain wildcard SSL cert for "*.github.com" once, and then present it to tenants, and control access with the "domain" property of the cookie, and don't worry about SSL cert until next year's renewal time, or 2) apply to some authority for XXX.github.com every time the new tenant signs up. Well, 2) makes you reliant on "some authority" every time new customer signs up, (hopefully many times a day!) which is not so very good IMHO. Just my 5c.
Without wildcards you can't use the automated tool to pre-provision new servers, for example.
Say 1.example.com is in production and is to be swapped for new1.example.com which is in staging.
new1 can't obtain a useful cert from Let's Encrypt until it becomes 1 in Internet-facing DNS. So you have a service discontinuity whilst moving 1 -> old1 and new1 -> 1 and then applying for the cert.
I appreciate that the set of people managing such issues probably aren't the target market ( they also won't be running an as-root tool to make automated changes on their edge servers... ) but it's an example of why wildcards are so useful.
I can absolutely understand the need for this, but until then with a bit of code and the automated workflow you could make requests for new subdomains on-the-fly.
Not sure if they'll amend their certificate policy or not. My guess is because their process is automated, they want to confine their certificate issuance to specific domains/sub-domains and not wildcards. It mitigates some repercussions in the event of a compromised cert.
Pg. 24 of the Certificate Policy:
For DV-SSL The Issuer DN of a DV-SSL Certificate shall be its Issuer’s subject DN. CAs shall include FQDNs or IP Addresses of the Device in the subject Alternative Name extension. The Subject Alternative Name extension may contain more than one instance of the name form. CAs may include a FQDN or IP Address in the subject DN for backwards compatibility, but this name shall be also included in the Subject Alternative Name extension. Wildcard names are not permitted
The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.
To make the original comment more precise, should not proving ownership of:
<some domain>
be enough to imply ownership of anything under that? i.e., DNS is a hierarchy — right? At the top level (a bit closer to how the original comment phrased it, I'd say that proving ownership of,
<some domain>.<some public suffix>
should prove ownership of all domains under that. To address the specific case of "co.uk", anyone in control of a public suffix[1] should just fail the check (i.e., owning a public suffix does not imply ownership of all subdomains, which I think is correct). Someone with better knowledge of the innards of DNS would have to speak to if the Public Suffix List is good enough here.
Really, why can't I be a mini-CA for my own domain, with only the power to issue certs for the set of domains I actually have control over? (essentially, why can't I get a nameConstraint CA cert?)
[1]: The Public Suffix list is a list of what a human might call a "tld, essentially"; "com" is a public suffix, but so is "co.uk": https://publicsuffix.org
That's definitely what I was thinking of, but it's not entirely suitable as a list of domains not to issue certificates for, unless you're happy to accept you won't be issuing certificates for domains like blogspot.com or flynn.io.
StartSSL might also refuse you if you try to request a certificate on behalf of a friend or a client, as they sometimes checks if WHOIS lines up with your identity validation. Quite the hassle for domain-validated certs :-/
Unless things have changed drastically recently (it's been a little while since I've used them), StartSSL is not "open" for any meaningful definition of the word.
I've used StartSSL for my last three customer projects, only because they offer cheap wildcard certs. I for one cannot wait to never have to use them again:
* validation taking up to six weeks, with recurring ridiculous demands for documentation, such as energy provider bills etc
* very unpleasant interface
* nightmarish authentication scheme with client-side certs. Try signing on with Chrome on one box, then exporting the cert to Firefox on another for example
* the client-side cert expires. When it does, there is no way to get back into your account. Support says 'just make a new one'
* there doesn't seem to be a mechanism for designating a technical contact, and I've been admonished by them several times for having the gall of taking over the process for my customers
It might not always be enforced in practice, but StartCom's policy doesn't allow use of the free certs for a commercial purpose:
> Class 1 certificates are limited to client and server
certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc.
Works great. To install on Firefox, just click on the first certificate listed here, in der format (just be sure to 'view certificate' and compare with the SHA256 hash I list above):
https://letsencrypt.org/certificates/
For Chrome users, you have to download the cert, then go under "Manage Certificates" in "Advanced Settings". Then click the "Authorities" tab and import button. To check the cert hash, you'll have to run the following on OpenSSL:
You can check your own fingerprint using:
openssl x509 -fingerprint -sha256 -in isrgrootx1.pem
Command line users on Ubuntu and (I think) Debian can install it to all browsers at once using:
chmod 644 isgrootx1.pem
sudo mkdir /usr/share/ca-certificates/letsencrypt.org
sudo cp isrgrootx1.pem /usr/share/ca-certificates/letsencrypt.org/isrgrootx1.crt
sudo dpkg-reconfigure ca-certificates
And you can verify my GPG signature by fetching my PGP key here (note that the keybase profile is linked to this HN username):
https://keybase.io/esbullington
>Our cross signature is not yet in place, however this certificate is fully functional for clients with the ISRG root in their trust store. When we are cross signed, approximately a month from now, our certificates will work just about anywhere while our root propagates.
>Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself.
I checked the https demo using libcurl, and it failed unexpectedly with error code 35 (Unknown SSL connect error). I was expecting curl error 60 (untrusted certificate).
The test site requires SNI and only accepts TLS 1.1 and 1.2 with ECDHE/DHE+AES-GCM/AES-CBC ciphers[0]. I'm guessing whatever SSL library your libcurl is linked against only supports TLS 1.0, doesn't support SNI, or doesn't support any of those cipher suites (OpenSSL 0.9.x won't work with this site, for example).
They'll need to pass a webtrust audit, which covers how they handle their key material amongst others. Additionally the Microsoft, Apple and Android roots have their own extra requirements added.
It always seemed odd to me how strictly CACert is treated given that TrustWave got a pass when they deliberately sold a root CA certificate for man-in-the-middle purposes.
It's almost as if money is more important than key management practices.
Thanks for all the informed info.
I was just always weirded out when my browsers forced me to perform 2-4 clicks because of untrusted connections when visiting websites of say the CCC (who just switched to StartSSL apparently).
How a root CA goes into the trust store? I know Firefox embed them, so older versions of it will not include it. OS minor updates (Windows, OS X, ...) ever updates the trust store?
How much time actually takes it before I can safely use it and be sure that the majority of browsers accept it?
In the short term, Let's Encrypt will be primarily trusted through an IdenTrust cross-signature, which should be created in the near future (and before Let's Encrypt certs are available to the general public).
The cross-signature is a delegation of authority from an existing root CA to Let's Encrypt's intermediate CA, saying that Let's Encrypt should also be trusted to issue certificates. Browsers that accept IdenTrust's root, which is widely accepted today, will then also accept the Let's Encrypt certificates as long as the services that present them also present the certificate chain (which includes the cross-signature certificate).
This will happen in parallel to Let's Encrypt's efforts to be accepted as a root CA, and is not dependent on it. For example, if Mozilla decided not to allow Let's Encrypt to be trusted as a root yet, past, current, and future Mozilla browsers would still accept Let's Encrypt end-entity certificates (with the proper chain) because of the cross-signature.
I feel like these initiatives to make SSL available for everybody just lead to the same conclusion: EV will be the only viable alternative to show real trust, and EV is much, much more expensive than regular SSL ever was.
As far as I can tell EV certificates are completely worthless.
You know the TLS certificate you got from bankofamerica.com is legitimately from bankofamerica.com because of domain validation. What EV tells you on top of that is only that bankofamerica.com belongs to Bank of America Corporation. But you already have that information. Their website is written on the walls of all their bank branches and all the documents they've ever given you. You don't need a CA to verify that because you can trivially do it your own self. And the same is true for any person you actually know. You know their domain belongs to them because it's the domain they personally told you belongs to them.
So that leaves domains belonging to entities you've never otherwise encountered outside of their internet site. You may have never been to a Google office before. But if you've never encountered the entity outside of its internet site then the association is meaningless. What am I supposed to know of Google other than google.com?
There's also the fact that obtaining an EV certificate is so unbelievably painful. I swear it gets more difficult every year.
Last time I bought an EV cert, Comodo wanted a certification from a Chartered Accountant. Aside from the confusion associated with Comodo wanting a letter "your CA", we then had them Google for "accountants in Sydney" and complain they weren't listed on the front page.
"Kindly address the search page to show them on the page in order for us to process the order".
It took hours of complaints and escalations before they agreed to proceed, at which point they wanted to call the company's "public" phone number. Now they could have gone to the company's website, or the White Pages, but no, they found some .ru website with an "accountant review" and called the number listed there. Instead of asking what official phone listings Australians use, the only thing they would accept is "kindly update the website".
Yes, this is probably one of the more incredible examples, but the point is, who wants to risk even possibly dealing with this, when you can have a DV certificate in two minutes and it "just works"?
The benefit is that if I get BankOfAmericaa.com and try to get an EV cert, the CA is going to verify my actual company name, which will unlikely be Bank of America or anything similar. So now when I trick someone into visiting my site, if the EV area doesn't tell them "Bank of America [US]" then they should double check. Or flip it around - if a user is unsure they can go off the EV info instead of the domain name.
In practise, since EV certs aren't used all over (say, WellsFargo doesn't use them), then the value is fairly diminished since lack of EV doesn't mean much.
> The benefit is that if I get BankOfAmericaa.com and try to get an EV cert, the CA is going to verify my actual company name, which will unlikely be Bank of America or anything similar.
So the first question is, why not? Can't someone file papers for a shell corporation with whatever name they like? Of course "Bank of Americaa Corp" is likely to raise questions, but is it not possible to BS your way through an EV cert claiming to be "Bunk of America Corp", retailer of bunk beds, or "Bank on America Corp", domestic lobby group?
Going through the process is obviously a huge pain for the attacker, but it's a huge pain for a legitimate business too. If the purpose is to make the process expensive then you might as well dispense with the charade and just say "pay us $20,000 and we'll give you a shiny green bar".
And the attacker still has a problem. Everything you know about Bank of America says their website is bankofamerica.com, not bankofamericaa.com. The difference is right there on the user's screen if they're looking for it. And if they're not looking for it then what difference is a green bar? Especially if all we tell them is "make sure it's green" and not "make sure it doesn't say Back of America Corp".
If it says "bankofamericaa.com" your alarm bells should start ringing. Even assuming the attacker can't get a certificate for the right country, how is the user expected to notice (and understand) the wrong country code if they can't notice the wrong domain name?
Notice that by this point the claimed benefit of the EV cert has lost all connection to the validation process and is now solely an artifact of the impermissibility of spaces in host names.
There's one difference (I don't think it really matters though) - if you go to bankofarnerica.com and get a valid certificate for bankofarnerica.com, if would not be owned by "Bank of America Corporation". But I agree it's worthless because it relies on you remembering that bankofamerica.com has an EV cert normally. And people are terrible at noticing what's missing.
But that's nothing new. If you need real trust, you need EV. The win from LetsEncrypt and any other attempt to make SSL more mainstream is the encryption, not the trust. If you're using SSL you're protected from some government and ISP snooping, and from having the contents of your message or webpage altered in mid-stream by a nefarious third party like AT&T.
Of course it's new. It's new since there are free certificates. Before, you had to pay, always. The amount was irrelevant, but you had to show your credit card. You had to prove your identity. That's a whole new felony there: stolen ID, carding, etc.
You had to have a credit card, but there was never any matching of the credit card name to the cert. Nobody is going to stop you from buying a cert for my domain with a prepaid credit card.
Protected from criminals or from the ISP snooping, yes (with a certain confidence), protected from the government (any government really) snooping most likely no. If not through their own ca (just find the one controlled by your local government. High chances there is at least one in default ca stores) than always by obtaining a warrant and requiring the website in question to share information.
Well it's possible and reasonable that you don't want to have what products your browsing to be snooped on by some sort of MITM attack. While probably not from MITM snooping, Target found out a teenage girl was pregnant before her own parents, and sent her parent's address Diaper and Baby advertisements: http://www.forbes.com/sites/kashmirhill/2012/02/16/how-targe...
Who do you expect to care whether the certificate is EV or not? (serious question) Google is not EV, facebook isn't either, banks are 50/50, almost none of the big online shops are EV (amazon included). I've never heard anyone raise this as an issue - technical or not.
Does anyone familiar with the "paid-for certificate industry" know if anything major is going to happen? I'd guess they're going to be inundated with lawsuits or something.
Root CA status is conferred by the individual user-agent developers (for example, Mozilla, Microsoft, Google, Apple, among others). Some browser or OS developers may try to follow others' lead to avoid duplicating effort or creating big divergences in trusted status of a given cert.
Each entity that maintains its own root CA list has its own policy and process that people can apply through in order to propose to become a root CA. For example:
These programs have certain criteria, which became more formal and rigorous over time (it used to be quite informal when the CA system was first set up). One commonality is generally to get a WebTrust CA audit, and there are also rules and meta-rules for CAs from the CA/Browser Forum.
This will require creating and publishing a certification policy and certification practice statement that have certain elements, and the auditors will look at those.
There are also physical security issues. For example, CAs use hardware security modules (HSMs) to perform their signing.
The HSM will sign requested data, but won't export its private keys into a less-controlled environment like the CA's web server. It's akin to storing your crypto keys on a smartcard, only more expensive. :-)
You can also use key pinning with Let's Encrypt certificates. Hopefully a future version of the client will provide tools to make this more convenient.
And I don't think they will/should ever go for it. After the CAcert experience, I don't believe community based certificate signing will work in the current TLS ecosystem.
I don't understand what it is we should "beware" of? What's the perceived threat?
In theory, even if the NSA themselves were creating these site certificates, because of how they're created (i.e. you generate the keyset yourself locally, they sign the public part), it should be secure.
So as I said: What is the perceived threat condition here?
> because of how they're created (i.e. you generate the keyset yourself locally, they sign the public part), it should be secure.
Note that if the CA has the authority to sign certificates, they don't need your private key. They can just locally create a CSR for your domain, sign it, and have their own equivalently valid certificate for your domain.
Moreover, in the absence of HPKP, any CA can do this for any domain.
That's a great example, I'll have to keep it in mind. I'd never thought of such a great example that clarifies how strong the security is, and how it's orthogonal to the trust model.
I don't know about the threat, but this solves one use case. A local server connection from a browser pointed at an online web service. For example, Plex which gives you a web-based directory of movies you own, but the movies themselves are hosted on your private server).
To be honest I had not heard of them till now, and I am a bit confused even after reading some of their site...
So if the difficult part of being a CA (which I think is verifying that I, Paul Brian, own and control the rights to barlcaysbank.com and should have a certificate in that name) if that bit is either not done (!) or is reliant on donations to be able to afford it, is this going to work?
This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive.
The only thing that regular-style certificates verify (this is what current CAs do, you can also grab a free one with automatic validation at https://www.startssl.com/) is that the person who controls the domain name has requested the certificate. This is usually done by serving a specific file over HTTP once, setting a TXT DNS record or responding to mail to postmaster@yourdomain.tld
> This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive.
I'd like to see LetsEncrypt move into this territory though. What current private business providers are charging for this service is border-line extortion.
EV validation will have a marginal cost because of the offline interactions. DV can be done at almost no marginal cost. That's why Let's Encrypt can exist at all.
But the certificate is (supposed) to say we have verified that this person / organisation exists and is "allowed" this domain.
Now if we extend the idea of every business or even human having their own (sub)-domain (lots of good benefits there) then we are in the territory of ensuring the CA's track you from birth - that's what governments do, and boy are they expensive.
I think what I am saying is we either have CA we can trust or we dump the whole thing and go to web of trust
For the time being, it's DNS registrars who define who is allowed particular domain names, and DV CAs just try to draw the connection between what the registrars have said and the server you're visiting at a particular moment.
Well. I missed that memo. Or rather I kinda sorta knew it was getting devalued, but a Padlock in my browser is something I trust. If it's not trust worthy or verified should we not go the whole hog, dump trusted public keys from all browsers and move to the web-of-trust / certificate pinning.
From the blog:
just too much of a hassle. The application process can be
confusing. It usually costs money. It’s tricky to install
correctly. It’s a pain to update.
If the reason there is not enough SSL around is because it's too much hassle for webmasters, I doubt there is a solution. If you want to take payments you get SSL. if that's too much hassle PCI compliance is going to really stretch you.
Vanilla SSL verifies the the website is legit, EV verifies that the business is legit. More competition will lower the price, there's tons of room for cheaper & faster EV providers.
Yeah, verifying that "www.barclays.co.uk" is the correct URL for Barclays Bank PLC is what EV is for.
The other important role of a certificate is verifying that the server you're connected to is the correct one for the URL in the address bar. I may not know or care who "Hacker News" is supposed to belong to, but I do care that I'm connecting to the legit news.ycombinator.com, the same one I connected to yesterday, and that I'm not being Man-in-the-Middle'd.
The latter is what letsencrypt is for.
|browser|- letsencrypt verifies -|server|- EV verifies -|organization|
Why even push this today if you don't have cross-signing available? Without that Let's Encrypt is effectively broken out of the box.
PS - I actually like Let's Encrypt and the work they're doing. I will be all queued up when they go live to grab one (and, yes, will put my money where my mouth is and donate). But doing this today without cross-signing seems strange.