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

311–320 of 476 posts

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

#311

Post by Tepix »

schoen wrote: post #69
mangeletti wrote: post #45

So, one CA to rule then all? There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised. 1) browser requests site via SSL 2) MITM says, "let's chat - here'…

We will look for ways to mitigate the risk of misissuing for any reason, including because someone tries to coerce us to misissue. One approach to this that's interesting is Certificate Transparency. http://www.certificate-transparency.org/ There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on th…

DANE is the way to go forward. Have your TLD CA sign your domain key and sign your web certificates with your own key.

Only one "root CA" to trust per TLD, and it's free if you own a TLD that supports DNSSEC (most do these days).

Now we just need the DANE check built into the browser without any plugins that require installation.

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

#312

Post by IgorPartola »

dragonwriter wrote: post #301
IgorPartola wrote: post #282

Earlier quoted context omitted.

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

> This case should be eliminated. We need to stop publishing stuff over HTTP. Period. HTTP is perfectly fine for information originating on and never leaving controlled, trusted, internal networks, and there is no reason to pay the overhead for HTTPS for those cases. There's other use cases where its probably not worth the (small) overhead for HTTPS.

No it is not. I have talked about this on here before, but I don't mind repeating myself:

- Your small blog you publish over HTTP is now opening the door for me, the attacker to mess with any traffic originating from your site. Say you host your resume on your site. I can substitute it with a much less flattering version. Say you host a code snippet. I can add a little obfuscated fork bomb or root kit at the end. Say you have a referral link to Amazon. I send your users to amazom.com, a site that's MitM'ing amazon.com but captures credit card details on the payment form.

- Your internal corporate system is great an all, until you have an unrelated breach and the HTTP site becomes a vector for me to attack your systems. Or worse yet, I learn how to trick your users into believing they are accessing your genuine document store when in fact they are uploading their secret company plans to my very own rogue site. Trust inside the electrified fence is different than on the Internet, but a self-signed cert that your IT sends to every employee is also pretty easy. Conversely, if your organization is so large that it's impractical, just buy a $10 domain and a $8 TLS cert. The "overhead" you speak of does not exist when your server side stops supporting HTTP. FFS, configuring nginx to use TLS/HTTPS takes exactly 3 additional lines of configuration code as compared to an HTTP-only site.

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

#313

Post by Tepix »

iancarroll wrote: post #306
SilasX wrote: post #289

Earlier quoted context omitted.

Encryption without verification is not useless; it protects against snooping.

If you don't verify what is sent, I could easily send you a malicious web form. If you don't verify the key or cert behind the connection, anyone can claim to be x site.

Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance.

Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).

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

#314

Post by nandhp »

SilasX wrote: post #289
iancarroll wrote: post #59

Earlier quoted context omitted.

I'm not entirely sure I understand your point, so if I misunderstood you please correct me. First, TLS has three principles that, if you lose one, it becomes essentially uselsss: 1) Authentication - you're talking to the right server 2) Encryption - nobody saw what was sent 3) Verification - nothing was modified in transit Without authentication, you essentially are not protected against anything. Any router, any gov…

Encryption without verification is not useless; it protects against snooping.

It doesn't prevent snooping -- you can still be MITM'd. It does however, make snooping much harder because it has to be done actively.

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

#315

Post by byuu »

IgorPartola wrote: post #291
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 b…

> a hobbyist deciding to write their own web server would not be one of them

nginx started out as a hobby project by Igor Sysoev. Maybe he should have just used Apache too?

> Or at the very least you could let another process to TLS termination and just handle HTTP

A well-designed HTTPS->HTTP proxy package could work. Install proxy, and requests to it on 443 fetch localhost:80 (which you could firewall off externally if you wanted) and feed it back as HTTPS. Definitely not optimal, especially if it ends up eating a lot of RAM or limiting active connections, but it would be a quick-and-dirty method that would work for smaller sites.

But it won't handle other uses of TLS, such as if you wanted to use smtp.gmail.com, which requires STARTTLS. Or maybe you want to write an application that uses a new custom protocol, and want to encrypt that.

If you put this stuff into libc, and get it ISO standardized and simplified, and have it present out of the box with your compilers on each OS, then you'll open the door for developers to more easily take advantage of TLS encryption everywhere.

Look at the core API for GnuTLS: http://www.gnutls.org/manual/html_node/Core-TLS-API.html

This is just insane. It would take an average developer months to fully understand that API.

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

#317

Post by xorcist »

justcommenting wrote: post #210
schoen wrote: post #195

Earlier quoted context omitted.

Four things: (1) You can do the attack you describe today with existing CAs that are issuing DV certs because posting a file on the web server is an existing DV validation method that's in routine use. (2) There is another validation method we've developed called dvsni which is stronger in some respects (but yes, it still trusts DNS). (3) We're expecting to do multipath testing of the proof of site ownership to make…

agree completely and it's worth noting that i don't have a solution to the issues i mentioned, either. leveraging other (potentially-insecure) paths to establish trust might help further enhance confidence in authenticity; e.g. verification using something like the broad-based strategy of moxie's perspectives (except via plaintext) or maybe through additional verification of plaintext on the site as fetched via tor o…

That problem does have a straightforward solution.

Publish your TLSA records. Sign your zone. Done.

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

#318

Post by iancarroll »

Tepix wrote: post #313
iancarroll wrote: post #306

Earlier quoted context omitted.

If you don't verify what is sent, I could easily send you a malicious web form. If you don't verify the key or cert behind the connection, anyone can claim to be x site.

Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance. Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).

That would make dragnet surveillance easier. Just MITM everything and you'll be the Trusted Source™ for all traffic.

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

#319

Post by icebraining »

JetSpiegel wrote: post #309
icebraining wrote: post #277

Earlier quoted context omitted.

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

Why should my fridge have a FQD name? What purpose does that serve? Why install a firewall in each device if you can install one on the router that works for everything?

Why should my fridge have a FQD name? What purpose does that serve?

To allow you to create a signed certificate to authenticate it?

Why install a firewall in each device if you can install one on the router that works for everything?

Having an FQDN doesn't mean you need to install a firewall on your device. You can still use the router's, and even prevent any inbound connections from the WAN to the device.

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

#320

Post by icebraining »

cmdrfred wrote: post #295
icebraining wrote: post #277

Earlier quoted context omitted.

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

NAT traversal?

FQDN doesn't have to mean publicly accessible. I have a personal subdomain that points to an internal IP. It's kinda weird to do with IPv4, but it works fine, and with IPv6 it'll be natural, since each device will probably have a globally unique address anyway, even if it can't be accessed outside of your LAN.
Post reply on HN