251–260 of 318 posts
The headline is wrong and not very clever for such a project. The project was able to get a CA to sign their keys, this is what happened. Using the word "trust" is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure. Another, even bigger trust-breaking elephant in the room is the fact that this proj…
I really dislike the fact that a CA is able to bless a new CA completely independently. Does this cause anyone else the slightest amount of anxiety, or am I just being paranoid?
Second, would you prefer that browsers blessed a new CA completely independently? If not then who should have that power? Governments? Non-profit organizations like ISRG?
The big alternative is to maintain your own list of trusted CA's, going through each and every new CA that you encounter and associate a trust relationship. Not even famous security researchers do this, and I can't really blame them as it is like a lawyer reading every EULA that they encounter and fully investigate the scope of them. The scope and complexity just get beyond what a single person can manage.
See a Let's Encrypt cert in action: https://helloworld.letsencrypt.org/ Nice work team!
So, Let's Encrypt doesn't support Certificate Transparency?! If there's one place where CT should be adopted, it's probably here.
They are also planning on support CT.
Earlier quoted context omitted.
Not yet, because Let's Encrypt doesn't provide wildcard certificates as of now. This may change in the near future, though. Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.
What is the rationale for treating wildcard certificates differently? That is, why can't Let's Encrypt issue them?
This level of proof of control is standard for DV certs, although other providers haven't automated it to the extent Let's Encrypt has, at least not with as high-quality software. One hole in this verification of course, is that 'control' may not actually be 'ownership', it could be someone who's hacked the host or DNS. But that's not unique to Let's Encrypt, it's a side issue, proof of control is standard and accepted for verification for DV certs.
So anyway, that kind of automated proof of control is a lot harder to apply to all of *.example.com, not just an individual host a.example.com. There are likely ways to do it well, but it's harder to do and harder to get right. Is probably why Let's Encrypt, at least for now, is not doing it.
Earlier quoted context omitted.
An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.
An interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the domain of the app, he can't try to use XSRF against it[2]. [1] https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices...
So, it's still all about trust then? I thought Let's Encrypt would go beyond trust.
Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.
You would like to buy a knitted scarf from a yak herder in Ecuador. How do you propose that establish trust between you and the yak guy without an intermediary?
Earlier quoted context omitted.
... as could any other CA your browser trusts. What makes Let's Encrypt any worse?
It's not worse; it's just exactly the same broken model, now for no money and being pushed on everyone. All this because a couple of theorists in the 1990s decided that security requires authenticity, despite decades of research to the contrary. There are all kinds of ways to establish authenticity of counterparties. Entire books are written about that. There are much better ways than our current CA model. But we don…
The problem is having secured transport against active attacks as well, and without forcing the user to know anything about the site besides its domain.
Earlier quoted context omitted.
I would just like to point out the irony in using 'LE' as a short for Let's Encrypt, as 'LE' usually gets used for shortening Law Enforcement. (Also: Congratulations and well done, Team Let's Encrypt!)
"LE" is identified more with "Limited Edition," I think. At least in the US.
I really dislike the fact that a CA is able to bless a new CA completely independently. Does this cause anyone else the slightest amount of anxiety, or am I just being paranoid?
Whats the alternative to CA being able to delegate signing? Would you prefer having browsers constantly being updated with new lists of CA's, maybe one new per day. Second, would you prefer that browsers blessed a new CA completely independently? If not then who should have that power? Governments? Non-profit organizations like ISRG? The big alternative is to maintain your own list of trusted CA's, going through each…
I just think it's odd that any CA can turn around and make any other random CA fully blessed. It seems like it completely circumvents the browser manufacturers including root CAs at all.
Totally agreed re: maintaining your own list of CAs. I mostly do go through the system CA list and disabling any from foreign governments I don't ever plan on trusting, but that's mostly feel-good and not actual security.