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

71–80 of 109 posts

Re: Progress Towards 100% HTTPS, June 2016

#71

Post by dorfsmay »

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…

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

Re: Progress Towards 100% HTTPS, June 2016

#72

Post by Animats »

theandrewbailey wrote: post #67
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…

> 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. > Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length. If you have an attacker than can identify content solely from its length, you have bigge…

> 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. An observer often could figure that out from the file length.

If you have an attacker than can identify content solely from its length, you have bigger problems than an SSL cert can solve.

An eavesdropper knows the IP address and the length of the content, even if it's encrypted.

> Trying to encrypt everything leads to messes such as Cloudflare's MITM certs which name hundreds of unrelated domains. This is a step backwards.

I do not see the problem. All those domain owners consciously choose to have Cloudflare host their stuff. The cert might be a few KB bigger, but who cares?

When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.[1]

[1] http://john-nagle.github.io/certscan/whoamitalkingto04.pdf

Re: Progress Towards 100% HTTPS, June 2016

#73

Post by pfg »

yeukhon wrote: post #66

My understanding is for intranet, you could use Let's Encrypt. For example, if I own .foo.com, and i want my intranet to be .internal.foo.com I need to make *.internal.foo.com in the DNS in order to verify I own .internal.foo.com, correct? But then doesn't that expose my 'internal' network? Hope there is a different way to solve this problem.

You don't need to "open up" your internal network (the ownership validation can happen via DNS), but the hostname would be public through Certificate Transparency.

Generally, if you're relying on your internal hostnames being secret (which is a terrible idea anyway), you should consider using an internal CA, because there's a good chance all public CAs will start logging every single certificate they issue to public logs, and that would include all the domains the certificate is valid for¹. Better yet, don't treat your hostnames as secrets.

¹ I think there has been some discussions about allowing CAs to censor DNS labels after the TLD+1 level for Certificate Transparency. Not sure if that's going to happen, I'm not a fan. This would still require that your CA supports this mechanism, something I don't think Let's Encrypt would do.

Re: Progress Towards 100% HTTPS, June 2016

#74

Post by rogerbinns »

dorfsmay wrote: post #71
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…

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.

Re: Progress Towards 100% HTTPS, June 2016

#75

Post by pfg »

Animats wrote: post #72
theandrewbailey wrote: post #67

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. > Yes, it obscures what content you're viewing, slightly. An observer often could figure that out from the file length. If you have an attacker than can identify content solely from its length, you have bigge…

> 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). This is currently only enabled in the Developer Edition, but will eventually land in stable.

> When sites share an SSL cert, and you can break into one of the sharing sites, there's a way to impersonate others. Cloudflare customers for their lower tiers of "security" often don't realize this. The customer doesn't pick which sites share certs; that's up to Cloudflare.

This is a non-issue for services such as CloudFlare. Site owners do not have access to the private key, only CloudFlare does. Breaking into one of the other sites won't give you access to the private key, only breaking into CloudFlare would, and such a vulnerability would have nothing to do with the fact that you're sharing a SAN certificate with other sites. I'm not aware of any other cross-site vulnerabilities that stem from shared certificates in an environment where every site on that certificate is served by the same frontend.

[1]: https://www.chromium.org/Home/chromium-security/deprecating-...

Re: Progress Towards 100% HTTPS, June 2016

#76

Post by snowwrestler »

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…

> They trust me because of personal history, not because some banner says they should.

The chain of trust is not to tell your users to trust you. It's to tell your users not to trust me, even if I look just like you.

Re: Progress Towards 100% HTTPS, June 2016

#77

Post by mynewtb »

criddell wrote: post #57
agwa wrote: post #51

Earlier quoted context omitted.

"Nobody"? Google monitors for their domains. So does Facebook. I'll bet a lot of other high value sites are monitoring too but haven't said so publicly. As for everyone else, give it some time. The ecosystem is still very young and we're still developing tooling.

I'm happy that Google and Facebook are discovering fraudulent certs. When they pop up, hopefully those companies aren't prevented from going public with the information. Are there any end-user tools? When I open twitter.com, I would love for my browser (or my phone if I'm using an app) to tell me that the certificate fingerprint has changed unexpectedly since the last time I visited.

There is certificate patrol or something like that. It is very verbose and will annoy you.

Re: Progress Towards 100% HTTPS, June 2016

#78

Post by niftich »

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 browsers have a UX for certs that's designed around the common/high-risk case e.g. average users going to banking websites, and deliberately terrible UX for self-signed certs.

Compare with SSH, which prompts to save the fingerprint on first connect, and warns loudly if the fingerprint changes. This is a superior way to handle self-signed certificates.

Re: Progress Towards 100% HTTPS, June 2016

#79

Post by schoen »

criddell wrote: post #57
agwa wrote: post #51

Earlier quoted context omitted.

"Nobody"? Google monitors for their domains. So does Facebook. I'll bet a lot of other high value sites are monitoring too but haven't said so publicly. As for everyone else, give it some time. The ecosystem is still very young and we're still developing tooling.

I'm happy that Google and Facebook are discovering fraudulent certs. When they pop up, hopefully those companies aren't prevented from going public with the information. Are there any end-user tools? When I open twitter.com, I would love for my browser (or my phone if I'm using an app) to tell me that the certificate fingerprint has changed unexpectedly since the last time I visited.

If you don't mind the risk of false positives (detecting changes that are legitimate), you can get that information from

https://addons.mozilla.org/en-US/firefox/addon/certificate-p...

Re: Progress Towards 100% HTTPS, June 2016

#80

Post by rsyntax »

5ilv3r wrote: post #58
drzaiusapelord wrote: post #39

Earlier quoted context omitted.

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 t…

Nailed it, but my concerns about manipulation extend farther than criminal abuse. It's more about privacy to me.

Correct me if I'm wrong. So you argument is "Quis custodiet ipsos custodes"(Who will guard the guards themselves)?
Post reply on HN