Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

321–330 of 345 posts

Re: Still Why No HTTPS?

#321
post #242
post #193

Earlier quoted context omitted.

Rightly punishing the connection for having the trappings of security when it actually lacks it doesn't mean we need to punish openly insecure traffic. End users have been told time and again that http is insecure, and so it's fine to leave it. End users should also be able to trust that https means secure without having to distinguish between secure and secure unless I'm being mitm'd and needing to understand what a…

Most end users have no idea what HTTPS is. They've just been (incorrectly) taught that the padlock means it's secure. Disable the padlock for self-signed HTTPS, and disable the CA-signed HTTPS-only features, and it becomes strictly better than HTTP.

Especially because there is no way to MITM a connection with perfect-forward-secrecy only if it ends up serving a self-signed certificate, because the connection first negotiates an ephemeral key with which everything, including the certificate, will be encrypted.

This means that with eSNI and at least one CA-signed cert on the IP, any attacker runs the risk of having to spoof the CA-signed certificate.

Re: Still Why No HTTPS?

#322
post #173

Earlier quoted context omitted.

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

How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks. For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).

Well, the caller is already allowed to run code. Allowing it to use TLS with cert-pinning doesn't make that any less secure.

Re: Still Why No HTTPS?

#323
post #321
post #242

Earlier quoted context omitted.

Most end users have no idea what HTTPS is. They've just been (incorrectly) taught that the padlock means it's secure. Disable the padlock for self-signed HTTPS, and disable the CA-signed HTTPS-only features, and it becomes strictly better than HTTP.

Especially because there is no way to MITM a connection with perfect-forward-secrecy only if it ends up serving a self-signed certificate, because the connection first negotiates an ephemeral key with which everything, including the certificate, will be encrypted. This means that with eSNI and at least one CA-signed cert on the IP, any attacker runs the risk of having to spoof the CA-signed certificate.

A sophisticated attacker might know that you were going to connect to a self-signed site, though. Interestingly though, private DNS (DoH, etc.) might help further shroud this fact from the attacker.

All in all, I'd say that the browser should still throw up a full-page warning because of the implications of TOFU, but it can be one where the "continue to site" option is clearly shown even to a naïve user, and not hidden behind a spoiler.

Re: Still Why No HTTPS?

#324
post #295

Earlier quoted context omitted.

7. it breaks caching proxies

I remember a discussion here on HN about how it makes life very hard for organizations like a school in Africa where the Internet connection is slow and expensive. Although many requests go many times to same pages (e.g. Wikipedia), HTTPS makes it impossible to cache them with a local cheap proxy. HTTPS is cargo-cult'ish in this aspect. One obviously should not accept or serve personal data over HTTP, but why to encr…

One benefit of encrypting public information is that ISPs can't mess with it by inserting ads and such.

Re: Still Why No HTTPS?

#325
post #318

Earlier quoted context omitted.

What's with domains such as blubb.mysystem.local or foo.invalid? .invalid and .local are reserved domains and guaranteed to never be in use on the public internet - yet I can't get certificates for them

If you could get certificates for them, so could anyone else including your adversaries, since there is no system of ownership for them. It would be like issuing certs for https://192.168.1.1

Actually that's why browsers already treat http://127.0.0.1/ and certain other local IPs as if it was via https.

For all local IP and domain space - that is 192.168/16, 10/8 and so on - it should automatically treat them as if they were safe anyway.

Re: Still Why No HTTPS?

#326
post #130

Earlier quoted context omitted.

> Why does everything need to be TLS? It feels like a cargo cult. A requirement: “because!” Traditionally, people have only encrypted things that are deemed sensitive (logins, money, health). However, when the majority of traffic is non-encrypted, actually ciphered data is very noticeable to anyone monitoring the network, and it screams " look at me! I am important! ". However, when >90% of traffic of the Internet is…

"herd immunity" is a good argument; but herd immunity exists for outliers. The people who for some reason cannot get a vaccine, yet they are not exposed to the hypothetical disease because everyone they are surrounded by is immune. That's kinda my argument, not that https is bad. I agree with widespread adoption and taking it as a default even for a static page. But in my environment I have many dozens of nodes and i…

> I also serve many domains with this project so I don't have the nice DNS-01 ACME verification features because not all DNS providers have an API.

Are you aware of using ACME DNS aliasing with CNAMEs?

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

* https://github.com/Neilpang/acme.sh/wiki/DNS-alias-mode

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

My work's DNS provider does not have a handy API, so if we want a cert for the internal-only foo.example.com, we point _acme-challenge.foo to _acme-challenge.foo.dnstest.example.com. And the NS server for the dnstest.example.com lives in our DMZ and is only there to answer ACME queries from Let's Encrypt. We set up some scripting to allow updates to the NS server via nsupdate.

And there are ACME clients written specifically around the idea of having the client run on a different system than the web server:

* https://github.com/srvrco/getssl

Re: Still Why No HTTPS?

#327

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…

That's what HSTS is for - you set a HSTS policy, and the browser will remember this site for a certain time you can set (usually 1-2 years). And going further, you can enable HSTS preloading, meaning the next release of browsers is going to hardcode your website as always and only ever going to be used with HTTPS. See for example my domain https://hstspreload.org/?domain=kuschku.de , which is currently in the preload…

Right, so HSTS will protect a visitor who has visited your web site at most max-age ago using that particular browser and device.

Or, as I stated, for preload, you have to either not have HTTP at all, or have a redirect to HTTPS: it should be clear from my above post why I think a redirect is a bad idea. I also dislike turning off HTTP for those that don't have any other option.

To me it seems that browsers just switching to https-by-default and http-as-fallback is a much simpler, better, backwards-compatible change that should just work. What am I missing and why do you feel HSTS is a good idea compared to that?

Re: Still Why No HTTPS?

#328
post #311

Earlier quoted context omitted.

But "common pre-shared secret" (well, public key allowing verification that there is a trusted secret being used) is at the root of https security today (a preset list of root certificates distributed with OSes/browsers). If someone presents as your web site to a first time visitor (or a previous visitor but on a new device), there is no way for them to really trust your web site. Basically, it's the equivalent of yo…

Can you explain how root certificates makes anything secure? Why can't you just hack the root cert store on the local computer f.ex.? There must be a million attack vectors to that system too, with a lot of attackers working on them since the payout is good when everyone uses the same system? Even if it makes sense, since all governmental offices and some corporations have their own; doesn't that make you skeptic of…

You are conflating multiple things.

If you are on an untrusted device (eg. someone else could have hacked the root cert store in the OS/browser), all bets are off: they could have also just hacked the browser to drop any and all warnings and to always display a green padlock icon.

If you are talking about someone else hacking your machine, well, then it's pretty much the same: they can get most stuff by adding keyloggers, screen recorders and just scraping your disk for useful data.

If you are on a trusted device, you can "hack" the root cert store all you want to add root certificates you trust. As long as you trust them, no trust has been lost.

Root certificates are not really "centralized": they are issued by different CAs, and different browsers trust different root CAs too, and it was even more prominent in the past where you had some certs "work" in only some browsers. Still, there are multiple recognised attack vectors there as well (each individual CA, their certificate issuing servers which have access to the root or intermediate signing cert, browsers and OSes and their trusted-CA components...), and the big difference is that the attack vectors are known and heavily monitored.

PGP/GPG keyrings were basically the same approach without the root certificates, and the (in)famous signing parties did not bring a trust level that is ultimately needed on the internet today. I would love to see a development in that direction (one could say it was an early consensus-building approach on who to trust), but we are not there yet.

It certainly is your choice to how you want to protect yourself and your web site visitors, and it's your web site visitors' choice whether they want to trust you with their data (for instance, I personally would recommend you to set up a self-signed cert and add that root cert to your keyring for services that you plan to only access yourself through untrusted networks).

Except that most people won't understand where the risks are in either approach, and that's half the battle.

Re: Still Why No HTTPS?

#329
post #322

Earlier quoted context omitted.

How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks. For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).

Well, the caller is already allowed to run code. Allowing it to use TLS with cert-pinning doesn't make that any less secure.

I apologise, I still don't understand your claims.

Without previous proof that the calling code was not eg. modified in-flight (eg. over HTTP or over HTTPS without a valid certificate), allowing it to use TLS and to either modify the trust root or pin a new certificate would severely reduce the security of the communication, and would be completely against what HTTPS is designed to solve in the first place (mainly MITM snooping and attacks).

And if there is a "previous proof" of genuinity (eg. by serving through properly encrypted HTTPS), what the benefit is to allowing those clients to pin certs? I.e. they'll still need the existing "proper" HTTPS for all the other first time visitors (and return visitors using new browsers/OSes/devices)?

Re: Still Why No HTTPS?

#330

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. Giving in ends the hope that it will ever get changed. Genuinely curious - what alternatives do you have in mind? Are there any WoT models that interest you more? > There is currently only one free cert provider, if there are ever issues with it, your users will see a scary error message Isn't this the point? > Downloading and ru…

DNSSEC is superior to both PKI and WOT. It's basically free. It makes chains of accountability transparent (hint: it's the dots in the URL). It provides the benefits of hierarchical trust except with democratic control, and is operated on film in public ceremonies.

We don't have a robust understanding of who exactly operates PKI, but we do know that it's de facto governed by a company on Charleston Road, since CAs only have their root keys listed in things like web browsers at their pleasure. We also know that Charleston Road rewards CAs for their loyalty by red-zoning and down-ranking the folks who don't buy their products. Products which should ideally be deprecated, since SSL with PKI is much less secure.

Can anyone guess who's stymied progress in Internet security, by knuckle-dragging on DNSSEC interoperation? It reminds me of the days of Microsoft refusing to implement W3C standards. Shame on you, folks who work on Charleston Road and don't speak up. You can dominate the Internet all you like, but at least let it be free at its foundation.

Post reply on HN