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

291–300 of 476 posts

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

#291

Post by IgorPartola »

byuu wrote: post #285

Here's my current issue with moving to TLS: library support. I do a lot of custom stuff and want to run my own server. I can set up and run the server in maybe 50-100 lines of code, and it works great. I know, I should conform and use Apache/nginx/OpenSSL like everyone else. Because they're so much more secure, right? By using professional code like the aforementioned, you won't get exposed to exploits like Heartblee…

Wow, of all the arguments I could think of against the current CA/TLS/HTTPS situation, a hobbyist deciding to write their own web server would not be one of them... Yes, you should just conform and stop doing this. Or at the very least you could let another process to TLS termination and just handle HTTP if you really want to create your own off-by-one remote code execution errors instead of using the ones supplied by apache et al.

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

#292

Post by userbinator »

kybernetikos wrote: post #257
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…

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 on them.

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

#293

Post by kaoD »

jsmthrowaway wrote: post #265
kaoD wrote: post #153

Earlier quoted context omitted.

Perhaps you should understand a system before slandering it? As others have said, encryption without authentication is useless. Running a CA has an associated cost, including maintenance, security, etc. That's what you pay for when you acquire a certificate. Whether current market prices' markup is too high would be a different question, but paying for a certificate is definitely not spending 200$ to look cool. CAs a…

That's the third comment of yours in which I've seen you taunt downvoters via edits in this thread alone. That's why I'm downvoting you. Knock it off, please.

I'm sorry it came across as a taunt, I didn't mean it like that.

Downvote sprees without an explanation detract from healthy discussion since they basically mean "I'm so mad about how wrong you are that I don't even care about why you think you are right".

I guess I'll just ignore them...

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

#294

Post by xorcist »

tomp wrote: post #106
iancarroll wrote: post #79

Earlier quoted context omitted.

The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.

NSA has NSL (national security letters with gag orders). There are CAs in the US. Mission accomplished.

That would be stupid. Google is a US company. NSA has NSLs. Mission accomplished. No certs involved.

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

#295

Post by cmdrfred »

icebraining wrote: post #277
danielweber wrote: post #176

Earlier quoted context omitted.

True, but on many small networks, you aren't addressing the embedded device by a FQDN. All these appliances should let you change the cert on them, but you still need that initial connection, and at smaller organizations (or households) the certs will never ever be changed. I used to work on embedded security projects so I care about this; I also realize that's a small portion of the market. I'm okay with making the…

True, but on many small networks, you aren't addressing the embedded device by a FQDN. Why not?

NAT traversal?

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

#297

Post by Xeoncross »

IgorPartola wrote: post #282
rufb wrote: post #247

Earlier quoted context omitted.

So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.

> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…

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.

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

#298

Post by anonbanker »

wnevets wrote: post #171
anonbanker wrote: post #151

Earlier quoted context omitted.

AOL bought Netscape, and incubated the Mozilla project while Netscape was still alive. they've spent a lot of money on doing things for free.

how long ago was that?

feel free to let me know why that matters.

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

#299

Post by drderidder »

higherpurpose wrote: post #276

> Let's Encrypt will be overseen by the Internet Security Research Group (ISRG), a California public benefit corporation. ISRG will work with Mozilla, Cisco Systems Inc., Akamai, EFF, and others to build the much-needed infrastructure for the project and the 2015 launch What's Cisco's role in this? I'm quite worried about that. It has been reported multiple times that Cisco's routers have NSA backdoors in them, from…

Yep. Read the product docs on some of their big network routers. You'd be surprised what's in there in terms of port mirroring and what they suggest carriers should use it for.

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

#300

Post by SilasX »

tptacek wrote: post #198
digitalsushi wrote: post #32

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and big…

Without some kind of authentication, the encryption TLS offers provides no meaningful security. It might as well be an elaborate compression scheme. The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session. But of course, real attackers trivially see all the the traffic for a session, because they snare attackers with routing, DNS, and layer 2 redirecti…

>The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session

Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption).

The threat model would be eavesdroppers who can't control the channel, only look. Using the SS cert would be better than an unencrypted connection, though still shouldn't be represented as being as secure as full TLS. As it stands, the server is either forced to wait to get the cert, or serve unencrypted such that all attackers can see.

Post reply on HN