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

31–40 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#31

Post by pfg »

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…

It's certainly possible to get a trusted certificate for a LAN-only device. DNS-based validation is your best option here. The only requirement is that you use an ICANN ("public") domain. This is not a requirement made up by Let's Encrypt, but rather by the CA/B Forum and applies to all CAs (for good reasons[1]!)

The Plex approach would be possible with Let's Encrypt, though you would have to find a way to avoid running into rate limits (via PSL or by making users use their own domains, which is admittedly only an argument if you're catering to a technical audience).

[1]: https://cabforum.org/wp-content/uploads/Guidance-Deprecated-...

Re: Progress Towards 100% HTTPS, June 2016

#32

Post by IgorPartola »

Retr0spectrum wrote: post #24
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…

For local traffic, why do you need a public certificate authority?

Because every device and program uses more or less the same list of trusted root certs. Yes, you can install your own root cert and run your own CA for stuff like this, but it's a huge pain in the ass to actually install the cert on all your devices. Sure, you can put that cert in your Chrome trust store. But what about Firefox, Safari, IE/Edge? What about your iPhone with Safari and Chrome? What about curl/telnet? What about your daughter's tablet, your son's gaming rig, your wife's e-reader? It's all just so much work. Businesses that have in-house IT departments can get away with it because they provision hundreds/thousands of identical installs of the same software. You don't have that in your house or small office.

Re: Progress Towards 100% HTTPS, June 2016

#33

Post by 5ilv3r »

pfg wrote: post #21
5ilv3r wrote: post #16

I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…

> Those should be distributed by the service providers, who are the actual trustworthy entities in the user's minds. That's what HPKP does, basically, unless I'm misinterpreting what you mean with service providers. HPKP is Trust on First Use, so it's not perfect, but the alternative - some kind of Web of Trust - is not really practical for non-technical, not-security-conscious users, IMO.

This looks like it still uses https. Currently I am giving openkeychain on android a try. It's trust establishment process is very interesting.

Sadly I understand https much better than alternatives, due to web hosting experience. I am trying to catch up.

Re: Progress Towards 100% HTTPS, June 2016

#34

Post by mdiazcl »

toomanythings2 wrote: post #19
5ilv3r wrote: post #16

I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…

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.

> They trust me because of personal history

That does not mean that you know something about Security.

> ... why should we trust you?

That's exactly the point. This is INTERNET, we don't trust anyone, it's a dangerous place to do such action... but we have to, otherwise it's better to go a live up in the mountain.

So, I prefer to trust Symantec/Google/DigiCert/etc... instead of some small business that does not even know the meaning of updating software or change default passwords.

The chain of trust it's a burden, I know, why we should trust anyone? But there has to be some level of trust between two parties, and, if we can have a third one (Like an escrow) that can ensure that trust I think it's great. Even using asymmetric encryption you need to trust the other party's public key...

A quick example of an unencrypted, cert-less network, an unsecure one with tons of vulnerabilities is the SS7 and the GPS systems... Since they cannot add Certificates to their BTS (base transceiver station) or their satellites, because of roaming technology, it's quite easy to set up an antenna an spoof them[1] and have full control over you phone and GPS[2]

[1] https://julianoliver.com/output/log_2014-02-13_17-17

[2] http://permalink.lanl.gov/object/tr?what=info:lanl-repo/lare...

Re: Progress Towards 100% HTTPS, June 2016

#35

Post by chongli »

toomanythings2 wrote: post #19
5ilv3r wrote: post #16

I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…

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.

Re: Progress Towards 100% HTTPS, June 2016

#36

Post by schoen »

5ilv3r wrote: post #30
pfg wrote: post #26

Earlier quoted context omitted.

It would certainly be considered fraudulent by all major browser vendors, possibly leading to a death sentence for the CA (i.e. root removal) in cases of deliberate misissuance or massive negligence. Key pinning mechanisms and Certificate Transparency would make it quite likely that this kind of misissuance would be detected as well. My personal opinion on the "nation-state adversary forces CA to misissue" topic boil…

How would it be identified as anything other than a routine cert rotation? You would have to have proof that you were being served different certs for the same endpoint from different devices or locations, AND find someone who cares and is not under some influence. That sounds difficult for you, but easy for a central entity to detect. Ads follow me around between devices and locations, so I am quite sure a certifica…

The certificate is presented when fairly little information has been sent by your browser, so it's tough to target it more specifically than source IP address and OS/browser.

There are a lot of ideas for catching this and some of them are starting to work, like HPKP pinning and preloads, and in the long run Certificate Transparency (including not accepting certs that haven't been publicly disclosed).

If you use HTTPS Everywhere, you have an option to submit certs that you see to the EFF SSL Observatory.

I don't mean to minimize the threat; I think there are lots of sites and browsers against which misissued certs can still be successfully used today without detection, and it's important to keep working on making that no longer true.

Re: Progress Towards 100% HTTPS, June 2016

#37

Post by 5ilv3r »

mdiazcl wrote: post #34
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.

> They trust me because of personal history That does not mean that you know something about Security. > ... why should we trust you? That's exactly the point. This is INTERNET, we don't trust anyone, it's a dangerous place to do such action... but we have to, otherwise it's better to go a live up in the mountain. So, I prefer to trust Symantec/Google/DigiCert/etc... instead of some small business that does not even…

I take cash, and always let folks try before they buy. :) I do have solid means of establishing trust. None of it has anything to do with technology security. Old school, baby!

That said, I am actually trying to move to a rather isolated place, and that is a perfectly valid option, so don't knock it.

Re: Progress Towards 100% HTTPS, June 2016

#38

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…

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?

Re: Progress Towards 100% HTTPS, June 2016

#39

Post by drzaiusapelord »

5ilv3r wrote: post #16

I'm still bitter about this chain of trust model. The fact that I have to get some other party to tell my users that they can trust me just seems wrong. They trust me because of personal history, not because some banner says they should. Browsers and OS vendors shipping CAs seems to be the root of the problem, in my mind. Those should be distributed by the service providers, who are the actual trustworthy entities in…

Its a bit like gun control laws; ultimately the criminals won't follow them. I was reading about some recent attacks and how hackers just steal certs or fool CA's into making certs for them. My understanding is that this is trivial for them to do in most cases. Turns out most CA's are run like security shitshows.

Meanwhile at work we're juggling dozens of certs left and right each with their own expiry as a handout to CAs. There's no reason why CAs cant sell me a cert that has a decade expiry. If the cryptography it uses goes bad, we'll just replace it. Why am I constantly buying these things?

Everything about CAs and browsers are wrong. Especially when many browsers ship with root certs from entities controlled by autocratic governments with zero accountability and involved in cybercrime and cyberspying. I'm giving incredible access to these nation states by downloading Firefox, Chrome, or IE. How is this "secure" again?

Re: Progress Towards 100% HTTPS, June 2016

#40

Post by ademarre »

5ilv3r wrote: post #25
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 you trust me if you have never met me? If you like what I do, trust me, and please give me money. :) Cert companies only do a phone call check for the very expensive EV certs. There is no minimal to extensive checking. That is a scam. Web tech is all https now. I can't even browse a lot of https sites with some of my older devices. There is a requirement and I dislike it.

> Why should you trust me if you have never met me? If you like what I do, trust me, and please give me money.

What if a customer who trusts you returns to your site, but ends up on an impostor's site instead? He was no way to discern the difference.

Post reply on HN