Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

171–180 of 345 posts

Re: Still Why No HTTPS?

#171
One annoyance with this system, from the linked webpage:

>an expectation that a site responds to an HTTP request over the insecure scheme with either a 301 or 302

Doing things this way is the final nail in the coffin for Internet Explorer 6, since IE6 does not use any version of SSL which is considered secure here in 2019. And, yes, I have seen in people the real world still using ancient Internet Explorer 6 as recently as 2015, and Windows XP as recently as 2017.

Which is why I instead do the http → https redirection with Javascript: I make sure the client isn’t using an ancient version of Internet Explorer, then use Javascript to move them to the https version of my website. This way, anyone using a modern secure browser gets redirected to the https site, while people using ancient IE can still use my site over http.

(No, I do not make any real attempt to have my HTML or CSS be compatible with IE6, except with https://samiam.org/resume/ and I am glad the nonsense about “pixel perfect” and Flash websites is a thing of the past with mobile everywhere)

Re: Still Why No HTTPS?

#172

One annoyance with this system, from the linked webpage: >an expectation that a site responds to an HTTP request over the insecure scheme with either a 301 or 302 Doing things this way is the final nail in the coffin for Internet Explorer 6, since IE6 does not use any version of SSL which is considered secure here in 2019. And, yes, I have seen in people the real world still using ancient Internet Explorer 6 as recen…

Be aware that blocking scripts from insecure connections is something you'd usually want to do...

Re: Still Why No HTTPS?

#173

Earlier quoted context omitted.

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.

The XHR api could allow specifying a trust root and/or cert-pinning though.

Re: Still Why No HTTPS?

#174

I mostly have port 80 egress traffic blocked on Little Snitch. The web is painful to use like that but gives you an idea of the sorry state of websites. A lot of websites just don't serve over HTTPS, or serve them with domains whose CN or SAN don't match the host. Many that do support https have links that downgrade you back to http on the same domain.

Same here. The browser extension HTTPS Everywhere can sometimes help, but I still have to turn off Little Snitch when some links are posted on HN

Re: Still Why No HTTPS?

#175
post #151

Earlier quoted context omitted.

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.

As it's a DNS server that only ever serves certificate validation requests, and doesn't need 100% uptime, a normal simple BIND or knot is good enough.

I'd expect it to be built in to certbot like serverauth.

Re: Still Why No HTTPS?

#176
post #9

Earlier quoted context omitted.

Instructions are here: https://certbot.eff.org/ I don't know how it could possibly be any simpler.

While I appreciate the efforts of certbot to make it as user-friendly as possible I still find this state of things unforgivable. I don't know where it went wrong so that today a developer must spend time learning and tweaking a low-level encryption tools. I'm just saying https will never be 100% unless it becomes a baked-in feature of any hosting.

What is the value in HTTPS being 100%? That seems silly to me. Many many things do not have any need for encryption.

Re: Still Why No HTTPS?

#177
post #160

Earlier quoted context omitted.

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

[deleted]

Re: Still Why No HTTPS?

#178
post #160

Earlier quoted context omitted.

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

I mean whitelist port 80 for captive.apple.com. Sorry if that wasn't clear.

macOS has a background daemon which automatically hits captive.apple.com on connection to a WiFi network, to detect if it's behind a captive portal (and opens up a browser window to let you complete the flow, if it gets a 302). So that much should work even if you block egress port 80 but whitelist captive.apple.com.

...that is, assuming the portal to which you get redirected would be served over https, but I guess that isn't a given either.

Re: Still Why No HTTPS?

#179
post #104

Earlier quoted context omitted.

If you can inject such content (as in an arp poisoning or other man in the middle scenario) why wouldn’t you go after the dns requests?

HTTPS will protect you against hijacked DNS requests as well.

Not by itself, if you have special HTTP headers it will. But some of those are deprecated (HPKP; for example)[0]

[0]: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#Browse...

Post reply on HN