Is there any alternative to ssl and tls out there? Sshttp anyone?
Progress Towards 100% HTTPS, June 2016
61–70 of 109 posts
Re: Progress Towards 100% HTTPS, June 2016
#62Is 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?
It sounds like you are doing something serious enough that Let's Encrypt might not meet your needs in other ways. Pay up for a wildcard cert or refactor subdomains out of your architecture.
Re: Progress Towards 100% HTTPS, June 2016
#63I 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.
Re: Progress Towards 100% HTTPS, June 2016
#64I 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…
Amen! While it's possible to get certs for things like firewalls and other embedded devices, it's a big PITA. Factor in the short expiration times, and buying a 2-5 year cert becomes a lot more attractive for those use cases.
Re: Progress Towards 100% HTTPS, June 2016
#65Earlier quoted context omitted.
This isn't about trusting you, it's about trusting that your domain belongs to the IP address it's supposed to.
IP addresses are not in certificates. Only hostnames. Not a rule, but I've set up hundreds and seen thousands, and never seen a single purchased cert that contained an IP.
That's because the certificate is used to determine if the IP address you're connecting to has control of the domain name you expected to visit.
Were the certificate to contain an IP address (or IP addresses), it would need to be updated every time the site started or stopped using a public-facing IP address.
Re: Progress Towards 100% HTTPS, June 2016
#66My 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.
Re: Progress Towards 100% HTTPS, June 2016
#67I 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 bigger problems than an SSL cert can solve.
> 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?
Re: Progress Towards 100% HTTPS, June 2016
#68I'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…
Aren't the root authorities in browsers/OSes just a means of short cutting the chain of trust validation by eliminating the need to validate the chain up to a single root?
I share your frustration and I understand that trying manage levels of trust a tough problem compounded by the fact that a user's expectations are fluid.
Re: Progress Towards 100% HTTPS, June 2016
#69I 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 runn…
An important point is that you need to own that public (sub)domain, even if it is only for use on a private LAN.
Re: Progress Towards 100% HTTPS, June 2016
#70Earlier quoted context omitted.
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 runn…
An important point is that you need to own that public (sub)domain, even if it is only for use on a private LAN.
Not necessarily. As an example, an IoT vendor could set up a domain for their devices and delegate a subdomain to each device (basically what Plex does). They could also provide an API that allows those devices to provision a TXT record to solve the domain validation challenge. The actual ACME client would still run on the device itself, and validate using that API.
You'd need a way to get past the rate limits (either via PSL or with a rate limit exception), but other than that this is doable.