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

81–90 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#81

Post by viraptor »

rogerbinns wrote: post #74
dorfsmay wrote: post #71

Earlier quoted context omitted.

I don't have any newish connected general purpose device (fridge printers, etc.... Do they give you an option to upload a cert?

My experience is that some may have self signed certs, or something similarly pointless, and that the vast majority have nothing so communications with them are in the clear. If someone like letsencrypt helped solve the issue (probably in a manner substantially similar to plex) then the devices will be able to get and renew their own certificates automatically, and clients talking to them would just work.

The self-signed cert is not entirely pointless in this case. On your LAN, you can be fairly sure (or even ensure) that the first connection is secure. This allows you to accept the specific self-signed cert as valid and trusted. From then on, that's what you keep on trusting.

There's no CA to tell you that it's a valid cert for this specific location. But you're the owner and you're the authority in this case.

Re: Progress Towards 100% HTTPS, June 2016

#82

Post by rogerbinns »

viraptor wrote: post #81
rogerbinns wrote: post #74

Earlier quoted context omitted.

My experience is that some may have self signed certs, or something similarly pointless, and that the vast majority have nothing so communications with them are in the clear. If someone like letsencrypt helped solve the issue (probably in a manner substantially similar to plex) then the devices will be able to get and renew their own certificates automatically, and clients talking to them would just work.

The self-signed cert is not entirely pointless in this case. On your LAN, you can be fairly sure (or even ensure) that the first connection is secure. This allows you to accept the specific self-signed cert as valid and trusted. From then on, that's what you keep on trusting. There's no CA to tell you that it's a valid cert for this specific location. But you're the owner and you're the authority in this case.

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, device controllers, your garage door and what have you).

If you were a device manufacturer what would you do? One approach is to make all communication happen with "the cloud" as an intermediary, but that means that local operation is dependent on the Internet and some backend running on it somewhere. Or you have to come up with some hack, confusing instructions for users, lots of documentation etc. We see the results in Matthew Garrett's most recent post, and it isn't pretty.

Re: Progress Towards 100% HTTPS, June 2016

#83

Post by viraptor »

rogerbinns wrote: post #82
viraptor wrote: post #81

Earlier quoted context omitted.

The self-signed cert is not entirely pointless in this case. On your LAN, you can be fairly sure (or even ensure) that the first connection is secure. This allows you to accept the specific self-signed cert as valid and trusted. From then on, that's what you keep on trusting. There's no CA to tell you that it's a valid cert for this specific location. But you're the owner and you're the authority in this case.

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.

Re: Progress Towards 100% HTTPS, June 2016

#84

Post by ssalazar »

chongli wrote: post #35
toomanythings2 wrote: post #19

Earlier quoted context omitted.

And when we visit your site for the first time, having never heard of you before, why should we trust you? That's the point. Having some authority who did at least some minimal checking, to extensive checking, and who will verify you really are who you purport to be. Trust but verify probably plays a part in this. But, remember, you don't have to go to HTTPS. There is no requirement for you to do so.

Why should I trust you even if you have an HTTPS cert? All you needed to get one was a domain name.

People seem to be misinterpreting the intent of HTTPS; it doesn't give you any reason to trust a given site. HTTPS only verifies that the site you are talking to is in fact the domain name in the URL, rather than a government agency, ISP snooper/intermediary, or other man-in-the-middle attacker. Its up to you whether you trust the operator of that domain.

Re: Progress Towards 100% HTTPS, June 2016

#85

Post by criddell »

agwa wrote: post #27
criddell wrote: post #14

Just at the entire world is going HTTPS, my faith in the system is seriously waning. When Symantec bought Blue Coat, it made me start to think about how fragile this is. How long before Symantec gets an NSL demanding an appliance that can mint bogus certs on the fly for dropbox.com, facebook.com, twitter.com, etc...? How effective is something like certificate pinning against fraudulent certs?

> How long before Symantec gets an NSL demanding an appliance that can mint bogus certs on the fly for dropbox.com, facebook.com, twitter.com, etc...? If the bogus certs are not logged in Certificate Transparency, they will be rejected by Chrome: https://security.googleblog.com/2015/10/sustaining-digital-c... If they are logged in Certificate Transparency, then the world will know, the offending certificates will be…

Now that I think about this more, I'm wondering how the certificate transparency program can be protected. The certificate information would have to be submitted out-of-band to be sure that it hasn't been tampered with, right? It wouldn't make sense to communicate about certificate security using infrastructure that depends on the same technology.

I was thinking about this because I was wondering if you could use secure dns to store certificate fingerprints. That doesn't make sense though because secure dns also depends on PKI.

Re: Progress Towards 100% HTTPS, June 2016

#86

Post by nisa »

arca_vorago wrote: post #61

Is there any alternative to ssl and tls out there? Sshttp anyone?

Tor Onions are technically an alternative. You access the hash of the public key? and you are only able to put up that URI if you have control over the private key. I guess something similar based on hashing and public key cryptography might be possible outside of Tor but it's not exactly user friendly to begin with.

Re: Progress Towards 100% HTTPS, June 2016

#87

Post by cdolan92 »

This is great, I use LetsEncrypt for my company. however, the graph is a little misleading. Lets look closer:

LetsEncrypt is almost built upon the idea of frequently (and automatically) re-issuing your certificate(s). The graph's line shows what appears to be an accumulated sum of certificates issued by day.

If every 90 days most certificate(s) expire, of course the graph will look like that!

Whats most interesting to me is the steps up in the graph. It appears that the steps in the graph roughly occur on 70-90 day intervals.

Impressive growth for a great mission/service, but I wanted to point out the mechanics behind the graph. Hopefully others can offer some alternative perspectives!

edit: Grammar, illogical sentence structure.

Re: Progress Towards 100% HTTPS, June 2016

#88

Post by brians »

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…

Presumably dhcp should tell you a CA for .local or similar?

Re: Progress Towards 100% HTTPS, June 2016

#89

Post by technion »

criddell wrote: post #38
agwa wrote: post #27

Earlier quoted context omitted.

> How long before Symantec gets an NSL demanding an appliance that can mint bogus certs on the fly for dropbox.com, facebook.com, twitter.com, etc...? If the bogus certs are not logged in Certificate Transparency, they will be rejected by Chrome: https://security.googleblog.com/2015/10/sustaining-digital-c... If they are logged in Certificate Transparency, then the world will know, the offending certificates will be…

From the link you posted: > However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research. So finding questionable certificates is trivially easy, but nobody ever bothers to look? What good is that?

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

Re: Progress Towards 100% HTTPS, June 2016

#90

Post by criddell »

technion wrote: post #89
criddell wrote: post #38

Earlier quoted context omitted.

From the link you posted: > However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research. So finding questionable certificates is trivially easy, but nobody ever bothers to look? What good is that?

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?

Post reply on HN