Live data from Hacker News

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

eff.org

431–440 of 476 posts

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

#431

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/

How does converge work? Is it any good?

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

#432
post #354

Earlier quoted context omitted.

It wasn't done a long time ago because running a CA costs money (which is why they charge for certificates), so whoever signs up to run one is signing up for a money sink with no prospect of direct ROI, potentially for a loooooong time. This new CA is to be run by a non-profit that uses corporate sponsorship rather than being supported by the market; whether that's actually a better model in the long run is I suppose…

I'm curious. Whats the biggest cost in running a CA? As in, what makes those certs so expensive?

.... also, you need multiple people in the organisation, you typically need to write your own infrastructure for vending certs, billing, you need to run OSCP responders and perhaps CRLs so clients can check if the cert was revoked, that can take a lot of bandwidth, then you need support staff because when people are paying, they expect support, etc.

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

#433

Earlier quoted context omitted.

> Tell me how the logic works here (for an average user). "Neutral Chrome" is the default state of the web -- the site doesn't assert that it should be trusted, and it shouldn't be, and that's the default state people should have in approaching the web. "Cool Green" is "the site asserts that it has a particular identity and that communication with that identified site is private, and it passes the tests built into th…

Plaintext is zero security. Self-signed is a low probability of security. Signed is a high probability of security. This continuum makes more sense than the current state of affairs.

Self-signed is a significant probability of man-in-the-middle attack.

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

#434

Earlier quoted context omitted.

> If it's public static content, what is SSL protecting? https:// helps protect the act of participation and deters the building of dossiers. Its the difference between the books in the library and the list of books in the library you have read.

Since SSL doesn't hide the length of the encrypted document, an attacker can make a good guess as to what public static content is being read.

Out of curiosity, does keeping connections alive help at all with this? Would an effective defense be embedding variable-length chunks of nonce in each header?

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

#435

Earlier quoted context omitted.

> Nothing can be man-in-the-middled passively, that makes no sense. That isn't what a MitM is. It requires active involvement by its very nature. By this I mean record all form submissions done through HTTP. >> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what publ…

>man-in-the-middled passively "eavesdropped" is the word you're looking for.

I think NSA was calling it Man On The Side? Or was that something different?

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

#436
post #389

Earlier quoted context omitted.

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.

So,if you knew the answer to your own question, why did you ask?

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

#437

Earlier quoted context omitted.

I'm not sure you should completely cut off anyone else but your registrar from holding the power to grant you certs. As long as you can transfer the domain out I guess it's not too bad.

What does it matter who issues your cert if your registrar controls your domain name? They can transfer your domain name to the FBI, your competitor, your ex-husband, whoever. They can keep it for themselves, and they can publish their own DNS servers as authoritative, making all traffic flow through them anyways. They already are in 100% control of your domain and you are at their mercy. You already trust them enoug…

This article[0] is largely about DNSSEC and DANE but it might give you some insights why making registrars the sole authorities isn't such a good idea.

[0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

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

#438

Earlier quoted context omitted.

There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc). There are certainly other options too: here's my suggestion- The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice fri…

The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to. I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed…

With SSH you usually own both endpoints (or at least trusting your cloud provider).

The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.

I'm putting my eggs on certificate pinning.

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

#439
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…

There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc). There are certainly other options too: here's my suggestion- The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice fri…

You're (almost) describing certificate pinning. Have a look at http://tack.io although it appears down for the moment. Here is the HN thread: https://news.ycombinator.com/item?id=4010711

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

#440
post #427
post #160

Earlier quoted context omitted.

No. Self-signed certificates are much worse because they bring a false sense of security. A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766 ). EDIT: Y…

> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. Trivial? Yes. As trivial as intercepting plain HTTP? No. The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect),…

https://news.ycombinator.com/item?id=8625420
Post reply on HN