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

91–100 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#91

Post by rogerbinns »

viraptor wrote: post #83
rogerbinns wrote: post #82

Earlier quoted context omitted.

You are right in theory and in older times, but these days trying to get a browser to accept a self signed certificate is difficult. Remember that it would need to be done on a multitude of different platforms (eg Safari on iOS, Chrome on Windows) and by regular users. And no one is going to repeat this for the combinatorial explosion of browsers in the home with the devices (fridges, printers, other computers, devic…

I'm not saying it's a great solution. Just that it's not pointless to put a self-signed cert on a device like that. What I'd do as a dev manufacturer? I'd try to change the game entirely. The current system simply did not have devices like that in mind. One idea would be "device certificates" - basically known CAs that can certify MAC addresses. This should be enough for local networks.

I think we can agree that self signed certs aren't useless in theory, they are close to impractical these days especially for folks who don't even know what one is, and are confronted by scary warning dialogs (if you are even lucky enough to see one!)

Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addresses for devices connected to it. For example if the real mac address is 11:22:33:44:55:66 when connected to the main access point, then when connected to the wifi range extender the rest of the network will see the mac address as aa:bb:cc:44:55:66. (The range extender also has ethernet ports - this affects wired and wireless connections to it.)

Re: Progress Towards 100% HTTPS, June 2016

#92

Post by technion »

criddell wrote: post #90
technion wrote: post #89

Earlier quoted context omitted.

On the subject of bothering to look, I built this service to answer that: https://ctadvisor.lolware.net

Very cool. Do you know if Lets Encrypt is monitoring on behalf of their users? It seems like that should be part of the job. Why are all these tamper detection tools targeted to domain owners rather than end users?

I don't really see how Lets Encrypt could monitor on behalf of their users. If a CT log shows created a certificate for my domain, I know it's unauthorised for the reason that I did not choose to authorise it. Lets Encrypt cannot assume they are the only company that I deal with.

Re: Progress Towards 100% HTTPS, June 2016

#93

Post by viraptor »

rogerbinns wrote: post #91
viraptor wrote: post #83

Earlier quoted context omitted.

I'm not saying it's a great solution. Just that it's not pointless to put a self-signed cert on a device like that. What I'd do as a dev manufacturer? I'd try to change the game entirely. The current system simply did not have devices like that in mind. One idea would be "device certificates" - basically known CAs that can certify MAC addresses. This should be enough for local networks.

I think we can agree that self signed certs aren't useless in theory, they are close to impractical these days especially for folks who don't even know what one is, and are confronted by scary warning dialogs (if you are even lucky enough to see one!) Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addres…

That's why I mentioned local network. Once we extend that with bridges, of course the verification fails. You can also assume any mac you want, so that's not a good security at all.

But that's all we've got. Unless we start integrating some kind of factory-sealed guaranteed-unique identity chips in all devices, there's simply no work around. Once something is on your network, you manage the identities. Either you have to manage some kind of CA, or trust whatever the factory provided you.

Re: Progress Towards 100% HTTPS, June 2016

#94

Post by rogerbinns »

viraptor wrote: post #93
rogerbinns wrote: post #91

Earlier quoted context omitted.

I think we can agree that self signed certs aren't useless in theory, they are close to impractical these days especially for folks who don't even know what one is, and are confronted by scary warning dialogs (if you are even lucky enough to see one!) Amusingly mac addresses aren't as constant as you'd think. On my home lan I use a netgear wifi range extender. The way it works is to give fake (transformed) mac addres…

That's why I mentioned local network. Once we extend that with bridges, of course the verification fails. You can also assume any mac you want, so that's not a good security at all. But that's all we've got. Unless we start integrating some kind of factory-sealed guaranteed-unique identity chips in all devices, there's simply no work around. Once something is on your network, you manage the identities. Either you hav…

My wifi extender is the local network. That is why I mentioned you can't even trust a mac address on the local network!

I think this can be solved the same way plex did, by combining separate DNS space with a certificate authority issuing certs programmatically like letsencrypt does.

Re: Progress Towards 100% HTTPS, June 2016

#95

Post by criddell »

technion wrote: post #92
criddell wrote: post #90

Earlier quoted context omitted.

Very cool. Do you know if Lets Encrypt is monitoring on behalf of their users? It seems like that should be part of the job. Why are all these tamper detection tools targeted to domain owners rather than end users?

I don't really see how Lets Encrypt could monitor on behalf of their users. If a CT log shows created a certificate for my domain, I know it's unauthorised for the reason that I did not choose to authorise it. Lets Encrypt cannot assume they are the only company that I deal with.

oh yeah, that's a good point. I didn't think that one through.

Re: Progress Towards 100% HTTPS, June 2016

#96

Post by userbinator »

chrisfosterelli wrote: post #63
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…

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 information they are actually communicating. Keep in mind that incidents like the smart TVs spying ( http://arstechnica.com/security/2013/11/smart-tv-from-lg-pho... ) were easily noticed because the data was in plaintext.

When pushing for more security, I think it is extremely important to be aware of all the consequences and pause to think deeply before we end up locking ourselves out of things we own, because by the time we realise, it will be too late.

Re: Progress Towards 100% HTTPS, June 2016

#97

Post by fulafel »

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 renewal system for this disconnected case, but that's just a "simple matter of programming".)

[1] assuming by "LAN" you meant "network disconnected from the Internet"

Re: Progress Towards 100% HTTPS, June 2016

#98

Post by rsync »

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 conveniences for that functionality.

But there are a lot of web resources that have existed, do exist, and potentially exist that are completely benign ... I think we're shackling ourselves by chasing after this perfection.

Or, put another way, we're chaining ourselves to a world where web resources are only accessed by web browsers, and only by those web browsers that are chaining themselves to a fairly dubious security scheme...

Re: Progress Towards 100% HTTPS, June 2016

#99

Post by rsync »

mholt wrote: post #59
Animats wrote: post #56

I see this as security theater. Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point. Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length. Encrypting everything increases the demand for low-rent SSL certs. Anything below OV (Organization Validated) is junk, and if mone…

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 interoperability ?

I guess if the only way you've every used the web is with a web browser, this doesn't make any sense to you.

Re: Progress Towards 100% HTTPS, June 2016

#100

Post by rsync »

pfg wrote: post #75
Animats wrote: post #72

Earlier quoted context omitted.

> Most web pages don't need to be encrypted. Anything with a form should be, but if you're just viewing static content, there's little point. Some really cool HTML and JS functionality will only work over HTTPS. 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. > Yes, it obscures what content you're viewing, slightly.…

> 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 nice to have the option to interact with a geolocation API (over http) with stdio and not include a giant truckload of dependencies and libraries and megabytes of packages ?

Post reply on HN