Our First Certificate Is Now Live(letsencrypt.org) |
Our First Certificate Is Now Live(letsencrypt.org) |
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.
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?
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
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.
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.
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|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
EV validation and whatnot is essentially a nice way to burn a ton of money on borderline extortion.
On the padlock note, Microsoft Edge shows a hollowed out, grey padlock for DV certificates.
Only EV certs get a full green one (as well as the legal name as other browsers show for EV). See https://certsimple.com/blog/dv-ssl-in-microsoft-edge
Firefox does the same. Luckily, Chrome is unlikely to do the same, since google.com itself is "only" domain validated.
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.
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.
EDIT: Kudos everyone working on Let's Encrypt. You're doing awesome work.
https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...
Firefox trusts the cert on TFA because letsencrypt.org itself is using a certificate signed by IdenTrust.
https://letsencrypt.org/howitworks/
I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
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.
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?
(just hoping they will appear next year)
One more nail in the coffin of the ssl cert mafia.
* 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
For the record, the cert I've downloaded (using SSL over the Let's Encrypt site) from the Let's Encrypt site has the following SHA256 fingerprint:
SHA256 Fingerprint=96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
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
For the extra paranoid, this is the same cert that another user posted to a Github gist earlier this summer: https://gist.github.com/rmoriz/1211745a21bc6114e770
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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIcBAEBCgAGBQJV95CmAAoJELGyxBAnWFiCpF4P/0sxqdrobdKm02V2cadHWQX3 AqXEENlPoReoVazf6Xhr3xfcyLw7g798q7YG4Bd0XtZLwofTr8Hq2On4q9w6dufu 6yGv+PyBTqL2EiSvuyY1p29ieYJV3tqOLUTaYjlvf7YGS90wLphRsEF1RVOaKfLK J1HSfx5Gctl1IRqa3Lt4zK6pot8xOzvV2d6V+fW1V/Svx5ZrfEUgJ7hgcyrgCSzB wqKJNhpoZCK50iqzrBlwjByRA+yi4LJckzSZ97l2p86QfvSg8xeVuMWVT+Qw6Pll Lw+rlrh4sLtcVGTcc6qUfBa5FXfoNOfT0vL009uBz5UkCs0vTjmbOwfZTGAMxKgC fD9dfOY3f9lA87nxTCP7nKR/USbDJANztNdQ/14qJwKFVmdusAjvf8LR8MzaIi5Q aBiC6otSuAMDGOTPXJ3aex/v+pt1412K5CgLEq83zeTGK04OoEWV/MMzggT+UxH6 eUpChtwKtFQIjqagzhkWWgc6ti2Qy0PnvZZa36PfFa01iK4jOhRPH9aCkg5UQtbl MjMPF2gAbHwTGP8cSs+PIrFUYyEK8FgWW4HhXBVCbNgedIEjRJwuorr/Ug8D7mJk kx+nFENVIsjEHUa5k64fYYc4eRX244jKORvYxH/iwCvvpCaineBkVmXPIFGIBXqp EYdDJBWF/PWfMvjFYHL3 =es48 -----END PGP SIGNATURE-----
>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.
[0]: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...
It's almost as if money is more important than key management practices.
How much time actually takes it before I can safely use it and be sure that the majority of browsers accept it?
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.
This is discussed in
https://community.letsencrypt.org/t/frequently-asked-questio...
and is also described in more detail at
Great work, by the way.
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:
https://technet.microsoft.com/en-us/library/cc751157.aspx
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.
https://en.wikipedia.org/wiki/Hardware_security_module
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. :-)
https://community.letsencrypt.org/t/if-when-will-le-support-...
And this is in Firefox, which renders fonts more bold than other browsers.
I can't wait until letsencrypt is done.
Text needs to be legible, please try and stick to normal and bold weights.
(No affiliation, I just saw their HN post some time before)
Does anyone know if there's an undo command for `$ letsencrypt run`?
I would love to try this, but too scared to do it and mess up with my nginx configs.
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.
A recently released Ruby gem also looks promising, in that it's a much better codebase with a tonne of tests.[1].
[0] https://github.com/diafygi/letsencrypt-nosudo [1] https://github.com/unixcharles/acme-client
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.
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).
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.
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).
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?
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?
You have to trust something.
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.
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.
Altough because of SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) the need for wildcard certificates has greatly diminished.
SNI and SubjectAltName [https://en.wikipedia.org/wiki/SubjectAltName] mixed with the simplicity of issuing a new certificate using LetsEncrypt [https://letsencrypt.org/howitworks/] all but eliminate the need for wildcards.
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
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?
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"?
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.
Or the CACert website itself.
Always seemed to me like some kind of joke.
> 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.
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.
As the grandparent post notes, all CAs completely automate domian validation at present.
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.
> I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
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?
http://forums.comodo.com/ssl-certificate-b14.0/-t106480.0.ht...
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?
[1] http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
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.
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).
> 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.
But adding a new root? Little popup, check a box and OK-you-go!
* 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.
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.
Mozilla's not a nepotist with regard to its root store. :-)
Firefox uses a grey lock for domain validated certs.
Edge uses a hollowed-out grey lock for domain validated certs.
<some domain>
<some domain>.<some public suffix>
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
See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.
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.
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.
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".
I'm sure that's intentional design
Either way, trusting a root CA generally looks far less threatening than the self-signed certificate warnings.
Original: working on a standard DPI Mac, but it still looks fine - see http://imgur.com/WRWYzBx. Trying to figure it out now...
It's painfully thin, and the eyestrain factor is pretty high.
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.
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.
I'll be changing the base font to 14px and darkening the grey to #222 quite soon.
I'll also look at 16px but this needs some additional design work.
Cause that looks like a printer that ran out of ink.
But you don’t notice it until you open a font selection menu.
But seriously, I had to use Gtk3's font selection menu today, and it was impossible to work with it.
There's also the guideline specifically asking you not to go on about being downvoted.
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.
When people can't or won't be civil on HN, we ban their accounts. There's no exception for getting downvoted—on the contrary.
I'm asking because I'm wondering if it should be made more obvious that he is when he is posting in his moderation role.