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

Progress Towards 100% HTTPS, June 2016

letsencrypt.org

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#101

Post by profmonocle »

vtlynch wrote: post #10
projectramo wrote: post #2

Is there any work being done on being able to easily switch out standards? That way when https is found to lack some feature, we can easily upgrade to httpz almost immediately?

This will likely never be the case due to how HTTPS actually works. As someone else stated, HTTPs is HTTP + TLS. The "s" in HTTPS is for "secure", and TLS provides that security. TLS is a evolving standard which is updated over time to add new features when necessary. When HTTPS is negotiated, it can seamlessly choose which version of TLS to use, based off what the client and server want to use. So, HTTPS will never…

Plus, even if we did decide to fully replace TLS, nothing would necessarily need to happen with certificates. We call them "SSL certificates", but the certificate standard - X.509 - actually predates SSLv1 by several years. A TLS alternative/replacement could adopt the X.509 standard as its certificate format and automatically work with the existing CA system.

Re: Progress Towards 100% HTTPS, June 2016

#102

Post by icebraining »

rsync wrote: post #98

Am I the only person that is wary of 100% https ? Remember, once you encrypt a web resource in SSL, you add a ton of baggage on top of any methods that might be used to access it. I like a world in which I can 'nc' a web resource and manipulate it with unix primitives without a truckload of software dependencies. If sensitive information is involved, then certainly - use SSL. I understand that we must give up conveni…

Just as you can use "nc" for an HTTP resource, you can use "openssl s_client" or "ncat --ssl" (from the nmap project) or "socat" to manipulate an HTTPS resource using the same unix primitives. Which truckload of dependencies does this require? The Debian package for OpenSSL only depends on libc.

I do fully agree that the web is getting more tied to browsers, and to me that's worrying, but TLS is mostly a transparent tunnel over which you can use the same protocols; it's not part of that trend, in my opinion.

Re: Progress Towards 100% HTTPS, June 2016

#103

Post by pfg »

rsync wrote: post #100
pfg wrote: post #75

Earlier quoted context omitted.

> What "really cool" HTML feature requires HTTPS? There can be problems with mixed secure/insecure content, but that's more of an offsite content issue. One example would be the the Geolocation API, with more to come[1]. Another example (specifically for HTML) would be Mozilla showing a user-visible warning when it encounters a type="password" field in a form served via HTTP (or with a HTTP target - I'm not certain).…

"One example would be the the Geolocation API, with more to come[1]." Ugh. Why would they do that ? I can understand that geolocation could be tremendously sensitive and you absolutely would want to offer the option of SSL ... but why limit it to SSL ? geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory. Wouldn't it be nic…

> I can understand that geolocation could be tremendously sensitive and you absolutely would want to offer the option of SSL ... but why limit it to SSL ?

I think you answered your own question. ;-)

> geolocation is also something that you'd want to hack into and build into things ... and maybe even things with limited processing power and memory.

Presumably, once your device is capable of running a modern browser such as Chrome or Firefox (which is what we're talking about here), TLS is a drop in the bucket in terms of resource usage. Or were you talking about the server?

Re: Progress Towards 100% HTTPS, June 2016

#104

Post by pfg »

rsync wrote: post #99
mholt wrote: post #59

Earlier quoted context omitted.

Sorry, but your comment is literally all wrong.

Have you ever built toolchains on top of parsing web resources with unix primitives ? Adding SSL makes it a lot more complex and limits your toolset dramatically. If your source is sensitive, by all means - use SSL. I don't think anyone would argue with that. But if you provide a useful resource that isn't sensitive or controversial (say, for instance, the weather) why would you want to chop off so much interoperabil…

mholt is the lead developer of Caddy[1], so it's probably safe to assume that he knows a bit about this.

The goal behind the HTTPS everywhere effort isn't just to encrypt private data, but also to provide authentication for your content. ISPs are known to interfere with HTTP requests, injecting ads, malware and what not. That's something that affects anyone, even static sites.

[1]: https://caddyserver.com/

Re: Progress Towards 100% HTTPS, June 2016

#105

Post by thinkMOAR »

djrogers wrote: post #64
rogerbinns wrote: post #22

I keep hoping they will help address non-Internet TLS. For example if you run a HTPC, fridge, printer, device controller or anything similar on your LAN and want to talk to it over the same LAN using TLS. Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique. Plex did solve this in conjunction with a certificate authority, but that solution only works for them. The gen…

Amen! While it's possible to get certs for things like firewalls and other embedded devices, it's a big PITA. Factor in the short expiration times, and buying a 2-5 year cert becomes a lot more attractive for those use cases.

small note, since a while they are limited to maximum 3 years

Re: Progress Towards 100% HTTPS, June 2016

#106

Post by mholt »

rsync wrote: post #99
mholt wrote: post #59

Earlier quoted context omitted.

Sorry, but your comment is literally all wrong.

Have you ever built toolchains on top of parsing web resources with unix primitives ? Adding SSL makes it a lot more complex and limits your toolset dramatically. If your source is sensitive, by all means - use SSL. I don't think anyone would argue with that. But if you provide a useful resource that isn't sensitive or controversial (say, for instance, the weather) why would you want to chop off so much interoperabil…

This has nothing to do with complexity or tooling.

Many people, including you, forget that TLS protects content from tampering. ISPs, captive portals, and other network entities are known for injecting ads or intercepting transmissions. Imagine your liability if a bad actor is injecting child porn on your site to a large portion of your audience. This isn't unheard of, by the way. Arguably less criminal, even Comcast is known for injecting content into pages.[1]

[1]: https://gist.github.com/ryankearney/4146814

Re: Progress Towards 100% HTTPS, June 2016

#107

Post by chrisfosterelli »

userbinator wrote: post #96
chrisfosterelli wrote: post #63

Earlier quoted context omitted.

The fact that it would not be unique would fundamentally undermine the security of the CA system. Nothing would stop someone from getting a certificate for the hostname "myfridge" on their LAN, then going to your LAN and using the same one to perform MitM for your "myfridge". The plex approach is very interesting though! There would be a lot to think out, but LetsEncrypt could do it if anyone could.

Nothing would stop someone from getting a certificate for the hostname "myfridge" on their LAN, then going to your LAN and using the same one to perform MitM for your "myfridge". Which brings up an important point that is often lost amongst the "encrypt everything!" "hype" prevalent today: you should be able to MITM the traffic of every device you own, or else you do not really own them and cannot tell what informati…

You can still MiTM your own devices which use SSL, just add a custom certificate to them (all major MiTM tools support this).

The problem is not encryption... the problem is buying black box devices which are not transparent to their users. Bad manufacturers will always be able to do this whether we advocate for encryption everywhere or not.

Re: Progress Towards 100% HTTPS, June 2016

#108

Post by rogerbinns »

fulafel wrote: post #97
rogerbinns wrote: post #22

I keep hoping they will help address non-Internet TLS. For example if you run a HTPC, fridge, printer, device controller or anything similar on your LAN and want to talk to it over the same LAN using TLS. Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique. Plex did solve this in conjunction with a certificate authority, but that solution only works for them. The gen…

> Getting a workable cert is currently not possible: for example the LAN names aren't going to be unique Connectivity [1] and using a global namespace are orthogonal things: you can use global DNS namespace just fine independent of connectivity. So from the naming perspective it Just Works if you get certs for printer.yourhouse.you.tld and fridge.yourhouse.you.tld. (Of course you'd still like an automated cert renewa…

By "you" I also meant people in general, rather than an individual tech person. Every connected printer, fridge, light switch etc user should have better security, and approximately none of them are going to set up global DNS space for their house!
Post reply on HN