Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launching in 2015: A Certificate Authority to Encrypt the Entire Web

eff.org

Post reply on HN
Print view View original

381–390 of 476 posts

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#381

Post by eric_bullington »

handsomeransoms wrote: post #350
eric_bullington wrote: post #208

Earlier quoted context omitted.

>A browser extension could automate this. Unfortunately, it couldn't on Chrome, because you can't even access a page's certificate from an extension in Chrome: http://stackoverflow.com/questions/18689724/get-fingerprint-... And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert.

> And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert. Nope. Firefox's Addon API lets you do pretty much whatever you want. It might be kind of hard and annoying, but you can certainly block connections that are signed by an untrusted CA. How do you think Convergence [0] worked? [0] http://convergence.io/

Fair enough, that's what I get for believing a Stackoverflow answer (even a highly upvoted one) without verifying for myself:

https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensio...

So with Firefox, you could build the kind of add-on described by Mike.

But I have confirmed for myself Chrome extension API's lack of ability to even read the certificate of a current page[1]. Chrome may be able to read block page loads (don't know, haven't checked) but without being able to even view a cert, it doesn't do much good.

1. https://code.google.com/p/chromium/issues/detail?id=93636

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#382

Post by iancarroll »

teamhappy wrote: post #286
schoen wrote: post #237

Earlier quoted context omitted.

The thing that's causing the delay is not the client software development, it's the need to create the CA infrastructure and then perform a WebTrust audit. If we were ready on the CA side to begin issuing certificates today, we would be issuing them today.

I think I may have misunderstood all of you. Is the audit process itself really that time consuming? I can imagine the amounts of bureaucracy involved, but I can't image this takes much longer than, say, a month or so. Most of the time is probably spent waiting for someone or something, right? I mean we're talking about very capable people here who have done this kind of thing before.

The CA is audited for six months. During this time frame, auditors collect info about the CA, and mainly what happens with it during the six months. Sometimes an auditor will issue a "readiness" statement to help the root get included before the audit closes, but it doesn't seem like they'll need that here.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#383

Post by h4xar »

jameshart wrote: post #333
pzb wrote: post #331

Earlier quoted context omitted.

There is such a thing -- name constraints. It allows exactly what you describe, limiting the valid names for certificates signed by the certificate.

Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...

You mention that the revocation-check problem is old, which is certainly true, but I think you allude to the possibility that a domain-registry-based hierarchy will exacerbate that problem in the form of an increase in revocation checks. I'm not sure that would be the case; it should be about the same. What difference does it make if I owned a domain, got a cert from a CA, and stopped owning the domain -- vs -- got that cert from my registrar? If anything this helps the process, because my registrar knows when I stop owning the domain whereas a CA has no clue and relies on the cert's expiration date exclusively.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#384

Post by [deleted] »

nnnnni wrote: post #371
moe wrote: post #332

Earlier quoted context omitted.

The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…

...and then if the fingerprint changes, you get something like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

[deleted]

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#385

Post by schoen »

paulchen wrote: post #375
tmmm wrote: post #50

Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.

I just installed it including all its Python dependencies, and tried it on my Apache server, but it throws me tons of Python errors.

It would be super-awesome of you if you could let us know about those errors at

https://github.com/letsencrypt/lets-encrypt-preview/issues

or e-mail me about them. So far this has only been tested on a handful of configurations and will clearly need to be tested on many more over the next few months.

Please be careful when running it on your live server: if it does manage to get a cert right now, that cert won't be accepted by clients and will produce cert warnings (and if you use the "Secure" option at the end, you'll also be generating redirects from the HTTP site to the cert-warning-generating HTTPS version).

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#386

Post by caf »

moe wrote: post #332
pilif wrote: post #60

Earlier quoted context omitted.

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating…

The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…

Certificate Patrol can give you something like this for Firefox.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#389

Post by zobzu »

psykovsky wrote: post #118
zobzu wrote: post #68

Whos auditing the ca?

Who's auditing the CA's currently trusted by your browser?

various 3rd parties. this is required by the cab forum which my browser requires as well.

inform yourself if you want to write stuff like that. even more, its sad that people think CAs have zero checking and just give what, money to browsers to be included? Thanksfully its not like that yet.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#390

Post by userbinator »

SXX wrote: post #310
lazyjones wrote: post #92

Earlier quoted context omitted.

They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate. PS. nice (presumably political) downvote further up ...

Fake certificate for Google wouldn't work in Chrome at least. There is certificate pinning already.

That is completely ineffective if they get Google to cooperate and issue an update that pins the new cert - and due to how automatic updates work, the majority of users will be completely oblivious, and those who do notice the new certificate won't find it any more suspicious than any other certificate update.
Post reply on HN