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

21–30 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#21

Post by pfg »

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.

Re: Progress Towards 100% HTTPS, June 2016

#22

Post by rogerbinns »

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 general approach could work for others if someone like letsencrypt led the effort. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Re: Progress Towards 100% HTTPS, June 2016

#23

Post by perlgeek »

zzzcpan wrote: post #7

Is it still problematic to issue lots of certs for lots of subdomains? I mean, still no wildcard certs and crazy rate limits, that disallow issuing 1000s of certs per day for user-generated subdomains?

Though if you are a hosting provider for example, I'm sure you could try to negotiate a deal with let's encrypt for more tolerant rate limits for a bit of sponsoring.

Re: Progress Towards 100% HTTPS, June 2016

#24

Post by Retr0spectrum »

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?

Re: Progress Towards 100% HTTPS, June 2016

#25

Post by 5ilv3r »

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

Re: Progress Towards 100% HTTPS, June 2016

#26

Post by pfg »

5ilv3r wrote: post #17
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?

I don't think they would be considered fraudulent at all, and in fact I'm pretty sure that's the "safety valve" built into the system and why public encryption is now being encouraged. I share your tinfoil hatted feelings wholeheartedly.

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 boils down to this: It's unsuitable for mass surveillance as it's easy to detect. It would work for targeted attacks, but in all likelihood your adversary will use other means to get in (zero-days, someone on the inside, physical compromise, etc.). Even for a targeted attack, my guess is that these other means would be less likely to be detected and would be significantly cheaper (if you take into account the cost of causing a root CA to get removed).

Re: Progress Towards 100% HTTPS, June 2016

#27

Post by agwa »

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 immediately blacklisted, and Symantec will be booted from root programs.

With the ongoing advancements in Certificate Transparency, your faith in the Internet PKI should be growing, not waning.

Re: Progress Towards 100% HTTPS, June 2016

#28

Post by 5ilv3r »

schoen wrote: post #20
5ilv3r wrote: post #17

Earlier quoted context omitted.

I don't think they would be considered fraudulent at all, and in fact I'm pretty sure that's the "safety valve" built into the system and why public encryption is now being encouraged. I share your tinfoil hatted feelings wholeheartedly.

> I don't think they would be considered fraudulent at all Er, by whom?

Well, they would be as technically valid as any other updated cert, and they would not violate any laws since a judge somewhere would have rubber stamped it, so I just don't think that word fraudulent could apply in any actionable sense.

Morally wrong, sure, but you know, politicians and law enforcement...

Re: Progress Towards 100% HTTPS, June 2016

#29

Post by maratd »

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 some devices and browsers have difficulty determining if they're talking to something on the local network or not. And they don't try to guess. So if your router requires you to connect via HTTPS, which is a good idea, have fun clicking past a nasty warning and then have nasty icons everywhere telling you that you're not secure.

And before you tell me to set up my own local authority and add it to the chain on every device ... common, really? Nobody wants to do that.

Re: Progress Towards 100% HTTPS, June 2016

#30

Post by 5ilv3r »

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

Earlier quoted context omitted.

I don't think they would be considered fraudulent at all, and in fact I'm pretty sure that's the "safety valve" built into the system and why public encryption is now being encouraged. I share your tinfoil hatted feelings wholeheartedly.

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 certificate could.
Post reply on HN