Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

151–160 of 345 posts

Re: Still Why No HTTPS?

#151

Earlier quoted context omitted.

That might be a step forward. Still a bit complex, but maybe worth considering. Would that work for mulitple domains? So I CNAME the _acme-challenge subdomain for all my domains to _acme-challenge.cheapthrowaway.com?

You can even just set NS records for _acme-challenge subdomain to your own DNS server. And then have your acme client auth against that one. No need for a new domain.

True, though running your own DNS server or paying for another DNS provider may be similar in effort or expense...as compared to a throwaway cheap TLD domain that comes with DNS.

Re: Still Why No HTTPS?

#152

One potentially good reason to not force SSL: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... TL;DR: Secure websites can make the web less accessible for those who rely on metered satellite internet (and I'm sure plenty of other cases).

Trading security for convenience is rarely a good idea. The rest of the world should not conform the to failures of certain areas to provide internet.

I see your point. But we trade security for convenience 24/7/365. We could all have bulletproof glass in our homes, personal security cameras everywhere, backup generators, panic rooms, etc, but we don't, because it's not convenient (and I know the expense is primarily what makes it not convenient, but I think it's still a valid argument).

Providing access to Wikipedia over http to people in third world countries may be worth the risk of someone MITMing the site with propaganda.

The suggestion is only to give some users the option.

Re: Still Why No HTTPS?

#153

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

You can't assume protection, whereas with http you assume no protection.

So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.

Re: Still Why No HTTPS?

#154

Why do browsers punish non-verified certs much harder than no-cert? If I want to quickly host my page and use encryption, then I have go through all that hustle to make it work. Perhaps allow use of self-signed certificates on same level as http instead of blocking my website.

Do they? IME, they just ask you if you want to trust the self-signed certificate and allow you to optionally store that "trust" indefinitely, ending up with something like Trust On First Use. The warnings have to be scary initially because the security model is so radically different from the usual case of CA's; specifically, getting that "first use" validation correct is critically important.

They show big red error and prompt to continue is hidden under spoiler. Also XHR requests just cut off, it's painful when developing and testing.

Re: Still Why No HTTPS?

#155

Earlier quoted context omitted.

The problem is that I also have domains which are completely internal, not known/resolvable outside

Could you run an internal CA server instead of self signing? At least then you reduce your attack surface if you’re compromised internally.

Yes, this is what is being done today.

My point was that HTTPS is (much) more complicated than bare HTTP and this is probably one of the reasons it is not taking over the web in a storm (though progress is undoubtedly there)

Re: Still Why No HTTPS?

#156

Earlier quoted context omitted.

One reason that comes to mind immediately: self-signed certificates offer no protection against MITM attacks. It's worse than without a cert, since it gives a false sense of security.

You can't assume protection, whereas with http you assume no protection. So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.

The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.

Re: Still Why No HTTPS?

#157
post #5

I don't get it. With Lets Encrypt, it's like one or two lines to get everything set up. I'm guessing people aren't as lucky as I am to be running on newer machines and such. I mean it even edits your nginx files to redirect http to https if you agree. It's not hard.

I set up Let's Encrypt for an older Exchange server a while ago. While I love the result, it was NOT a simple, one-line exercise.

Up to date documentation was near-impossible to find, and the scripts that came out of the box on the recommended client needed some fixing. The whole thing took about half a day, plus some hours a few weeks later once the unforgiving anti-abuse thresholds I accidentally triggered during end-to-end testing finally expired. Definitely wasn't a pleasant experience.

Re: Still Why No HTTPS?

#158
post #114

Earlier quoted context omitted.

If we migrate to HTTPS everywhere we can get rid of HTTP for general use and switch to a different UI, where HTTPS websites don't have any special icon but HTTP ones get a warning icon. It's already effectively how password form submissions work in many browsers.

You can't have HTTPS everywhere until we can get HTTPS for IoT devices. My router doesn't serve it's configuration screen via HTTPS. How could it? I have to connect to it to configure it before it's on the internet. Same with my IoT cameras and all the various local apps I run that can start a web server. Heck, my iPhone has tons of apps that start webservers for uploading data since iPhone's file sync sucks so bad.…

I agree that having an elegant and secure solution to enable HTTPS on non-internet-facing equipment would be nice. I work mainly on embedded devices and all my admin interfaces are over HTTP because there's simply no way to ship a certificate that would work anywhere. It would be nice if you could easily deploy self-signed certificates that would only work for local addresses and only for specific devices, although of course doing that securely and with good UI would be tricky.

In the meantime having big warnings when connecting to these ad-hoc web interfaces makes sense I think, since they can effectively easily be spoofed and MitM'd (LANs are not always secure in the first place so it makes sense to warn the user not to reuse a sensitive password for instance). It's annoying for us embedded devs but I think it's for the greater good.

Re: Still Why No HTTPS?

#159

Earlier quoted context omitted.

Do they? IME, they just ask you if you want to trust the self-signed certificate and allow you to optionally store that "trust" indefinitely, ending up with something like Trust On First Use. The warnings have to be scary initially because the security model is so radically different from the usual case of CA's; specifically, getting that "first use" validation correct is critically important.

They show big red error and prompt to continue is hidden under spoiler. Also XHR requests just cut off, it's painful when developing and testing.

Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.

Re: Still Why No HTTPS?

#160
post #73

Earlier quoted context omitted.

How do you use public Wi-Fi with captive portals?

Allowing http://captive.apple.com should make macOS’s captive portal auth window work.

If you block port 80, you'll never get to the part where you do URL filtering in the first place.

(And also the redirection thing.)

Post reply on HN