Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

301–310 of 345 posts

Re: Still Why No HTTPS?

#301

1. The requirement to involve a 3rd party certificate authority is a needless power grab. Giving in ends the hope that it will ever get changed. 2. There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message which will make them think there are security issued with your website. 3. Downloading and running code from a 4th, or 5th party and giving it acces…

> The requirement to involve a 3rd party certificate authority is a needless power grab.

TLS is public key encryption... a 3rd party attesting to the provenance of public keys is inherent to its design.

Re: Still Why No HTTPS?

#302

Earlier quoted context omitted.

You misinterpreted the above commenter. The suggestion is to disallow self-signed contexts access cookies set in authoritative contexts.

I don't see that as the biggest problem. If we repeat what was said in the above comment: > ...disable secure cookies ... for self-signed certs. ... the user ... enable[s] them. So you make a self-signed cert for your website which needs secure login, and you tell your users to turn on secure cookies so that you can safely store their credentials in the browser. Then your website gets MITM'ed with another self-signed…

The convoluted and unlikely scenario you describe is currently possible with HTTP and non-secure cookies (the website admin is setting the cookies and can choose to define them as secure or not).

Using a self-signed cert. isn't secure. What's being discussed is whether it's worse than HTTP. It isn't.

Re: Still Why No HTTPS?

#303

Earlier quoted context omitted.

I don't see that as the biggest problem. If we repeat what was said in the above comment: > ...disable secure cookies ... for self-signed certs. ... the user ... enable[s] them. So you make a self-signed cert for your website which needs secure login, and you tell your users to turn on secure cookies so that you can safely store their credentials in the browser. Then your website gets MITM'ed with another self-signed…

The convoluted and unlikely scenario you describe is currently possible with HTTP and non-secure cookies (the website admin is setting the cookies and can choose to define them as secure or not). Using a self-signed cert. isn't secure. What's being discussed is whether it's worse than HTTP. It isn't.

Browsers now try to detect and warn about credential forms which are submitted over HTTP. Any website admin who tries to convince users to ignore security warnings about HTTP is somewhere between seriously negligent and evil.

>What's being discussed is whether it's worse than HTTP. It isn't.

I disagree. The self-signed cert approach tries to carry with it the trappings of proper HTTPS, but it results in a bigger attack surface. Every additional bit of complexity that can be added to describing the "safe browsing experience" to the end user is an additional chink in the public armour. This is why I originally called it "open users up to social engineering attacks to make my web-dev life easier".

Since the self-signed cert is not secure, admins should have no reason not to simply use HTTP. In fact, this is where the discussion has gotten to now: self-signed certs can't even do safe login. What makes the self-signed cert worse is that for some reason people are insisting on using it anyways.

Re: Still Why No HTTPS?

#304

Earlier quoted context omitted.

4. The culture of fear around HTTPS, meaning only the "most secure" or "newest" protocols and cipher suites are to be used. This prevents older clients from working, where HTTP works just fine. This is important. I have several devices at home that cannot display many web sites because they don't have the ability to use latest ciphers.

Don't buy computing devices that don't give you root.

Rooting won't help most of these devices. They just don't have the horsepower. Moreover, they don't run Linux.

Re: Still Why No HTTPS?

#305
post #239
post #235

Maybe I’m wrong, but I feel SSL has a downside of relying on more centralization. If a visitor to my totally-static webpage wants to bypass that layer and request the http version directly, I’m going to let them. (Obviously not excited about the idea of being mitm’d but it’s not a security risk, so leave that tradeoff up to the visitor).

https://doesmysiteneedhttps.com/ MITM can do anything to your site, so your totally-static site may not be static any more at the victim's end. It may be a site collecting private details, attacking the browser, or using the victim to attack other sites. Your static HTTP site is a network vulnerability and a blank slate for the attacker.

Thanks for the reply. I've seen that site but it seems to be aimed at people who don't offer any https at all. At this point I'm still more comfortable offering visitors the decision. (Not many people visit my site by the way.)

Re: Still Why No HTTPS?

#306

Earlier quoted context omitted.

Don't buy computing devices that don't give you root.

Rooting won't help most of these devices. They just don't have the horsepower. Moreover, they don't run Linux.

> Rooting won't help most of these devices. They just don't have the horsepower.

If a device can "display" webpages then it's extremely likely that it can handle tls.

> Moreover, they don't run Linux

That has never stopped people before.

Re: Still Why No HTTPS?

#307

My biggest gripe with the current de facto recommended approach (even mandated in HSTS) is that you need to redirect to https from untrusted http. So you are being forced to either not serve http, or to condition users to trust MITM-able redirect. How many people will notice a typoed redirect to an https page with a good certificate? The solution is simple: browsers should default to https, and fall back to http if u…

Annoyingly, if you want to get a let's encrypt cert you have to serve http. Back when I was manually purchasing & installing certs I didn't even listen on 80 for several services. (Exception being if you use the dns challenge)

>(Exception being if you use the dns challenge)

Exactly. DNS challenges don't suffer from this issue.

Re: Still Why No HTTPS?

#308
post #239

Earlier quoted context omitted.

https://doesmysiteneedhttps.com/ MITM can do anything to your site, so your totally-static site may not be static any more at the victim's end. It may be a site collecting private details, attacking the browser, or using the victim to attack other sites. Your static HTTP site is a network vulnerability and a blank slate for the attacker.

So then disable javascript for http sites

Ok, cool, I found a new numerical overflow image rendering in your browser library. Now I can shove an tag in the insecure stream and exploit you.

Re: Still Why No HTTPS?

#309

Earlier quoted context omitted.

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…

Mitm with propaganda is the least of the worries. Full on exploit code is.

The fact is as an ecosystem develops completely increases. Lifeforms in that ecosystem have to spend more time and effort protecting themselves from outside attacks as time progresses.

Re: Still Why No HTTPS?

#310
post #12
post #9

Earlier quoted context omitted.

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

It is simple for a one-server website. When you're on Alexa 1M, you certainly have a load balancer, multiple servers for redundancy, etc. It makes things not straightforward, and you certainly don't want to use the default certbot which overwrites your config.

I mean the next more complicated case isn't that bad either. You set up a sidecar VM/container/machine/whatever-you-want that either instruments your DNS or gets the traffic from .well-known/acme-challenge and just renews your certs every day.

Then your load balancers pull the current cert from the sidecar every day with NFS/Gluster/Ceph/HTTP/whatver-you-want and reload the web server if it changed.

Assuming that you can catch a failure of your sidecar server in 89 days or so you don't need much more redundancy.

Post reply on HN