Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Still Why No HTTPS?

troyhunt.com

Post reply on HN
Print view View original

331–340 of 345 posts

Re: Still Why No HTTPS?

#331

Post by tptacek »

jart wrote: post #330
xvector wrote: post #292

Earlier quoted context omitted.

> 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 on…

Who's knuckle-dragging on DNSSEC interop? The entire Internet community. It's been almost 25 years, and 3 major revisions of the protocol, and still it has almost no adoption --- virtually none of the most commonly queried zones are signed. Why is that? Because DNSSEC is awful.

Obviously, you can't replace "SSL with PKI" (you mean TLS, and/or the WebPKI) with DNSSEC, because DNSSEC doesn't encrypt anything. Whether or not you enact the ritual of adding signature records to your DNS zone, you will still need the TLS protocol to actually do anything securely, and the TLS protocol will still not need the DNS in order to authenticate connections.

Instead, what DNSSEC (DANE, really) hopes to do is replace LetsEncrypt, which is not "basically" but instead "actually" free, with CAs run by TLD owners. Who owns the most important TLDs on the Internet? The Five Eyes governments and China. Good plan!

Re: Still Why No HTTPS?

#332

Post by namibj »

zozbot234 wrote: post #323
namibj wrote: post #321

Earlier quoted context omitted.

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 hidd…

Then maybe fall back to DANE and thus restrict this to zones signed with more than 1024bit RSA?

Re: Still Why No HTTPS?

#333

Post by kuschku »

necovek wrote: post #327
kuschku wrote: post #317

Earlier quoted context omitted.

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 swit…

Because some websites serve something different on 443 and 80, and you won’t get the right result by visiting 443.

The preload list allows you to specifically say that for your own website clients should always use HTTPS, which is a good solution, as it means no one is ever going to visit kuschku.de on port 80, except for curl and dev tools, for which the redirect is useful.

Re: Still Why No HTTPS?

#334

Post by namibj »

necovek wrote: post #329
namibj wrote: post #322

Earlier quoted context omitted.

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 MI…

Don't worry.

I don't mean we should allow the fetch API to mess with the browsers trust configuration. It should only allow a temporary override of trust rules, similar to DANE TLSA-RRs, but provided by JavaScript instead of DNSSEC-verified DNS lookups.

Imagine e.g. combining this with an SPA bootloader contained in a data-url (like a bookmarklet), which the user scans via a QR-code or receives via text-based messaging.

CORS would still be in-play, and maybe the insecure nature of the caller is communicated to the API.

The benefit of this pinning would be e.g. allowing direct communication with IoT hardware, or even just prevention passive content analysis.

You could talk to IPs directly and still use TLS without weird wildcards like *.deviceid.servicedevices.com where the dns just has these zone entries:

  deviceid.servicedevices.com  DNAME  has-a.name
, but that's ugly and leaks the device's IP through a DNS lookup.

Re: Still Why No HTTPS?

#335

Post by jart »

tptacek wrote: post #331
jart wrote: post #330

Earlier quoted context omitted.

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 on…

Who's knuckle-dragging on DNSSEC interop? The entire Internet community. It's been almost 25 years, and 3 major revisions of the protocol, and still it has almost no adoption --- virtually none of the most commonly queried zones are signed. Why is that? Because DNSSEC is awful. Obviously, you can't replace "SSL with PKI" (you mean TLS, and/or the WebPKI) with DNSSEC, because DNSSEC doesn't encrypt anything. Whether o…

What we mean by DNS security is that when you visit your bank's website, you know it's actually your bank. We're less concerned about concealing DNS queries from routers and more concerned about preventing them from forging responses. Eavesdropping won't empty your bank account. Spoofing can, and encryption doesn't matter if the remote endpoint isn't authentic.

Right now you need to ping Google's servers each time you visit a website to ask if it's safe. We love Google but they're a private company that can do anything they want. If you feel comfortable with them being the source of truth for names on the Internet, then the problem is solved.

Most of us would prefer it be controlled by ICANN which is a non-profit, not controlled by any one government, that lets anyone from around the world who cares enough participate show up and take part in Internet governance. Controlling names was the purpose they were founded to serve. I say let them.

Re: Still Why No HTTPS?

#336

Post by AndrewStephens »

AnIdiotOnTheNet wrote: post #268
AndrewStephens wrote: post #185

Earlier quoted context omitted.

It is a sand castle on a private beach owned by you. Have you ever posted a link to your site anywhere? Imagine you sent me a post card saying "Come to my beach to look at my cool sandcastle" and then when I got there the sandcastle was actually a robot that stole my credit card. You could say that it wasn't your fault - somebody broke into your private beach and replaced the sandcastle. But I would probably still bl…

> and then when I got there the sandcastle was actually a robot that stole my credit card. What kind of moron shows up to see a sandcastle and doesn't think twice about handing over their credit card?

That's the thing with credit card stealing robots - they are nimble and you don't know if they are stealing from you.

Likewise, if I go to a website and serves up malware, you don't know it is stealing from you.

Re: Still Why No HTTPS?

#337

Post by tptacek »

jart wrote: post #335
tptacek wrote: post #331

Earlier quoted context omitted.

Who's knuckle-dragging on DNSSEC interop? The entire Internet community. It's been almost 25 years, and 3 major revisions of the protocol, and still it has almost no adoption --- virtually none of the most commonly queried zones are signed. Why is that? Because DNSSEC is awful. Obviously, you can't replace "SSL with PKI" (you mean TLS, and/or the WebPKI) with DNSSEC, because DNSSEC doesn't encrypt anything. Whether o…

What we mean by DNS security is that when you visit your bank's website, you know it's actually your bank. We're less concerned about concealing DNS queries from routers and more concerned about preventing them from forging responses. Eavesdropping won't empty your bank account. Spoofing can, and encryption doesn't matter if the remote endpoint isn't authentic. Right now you need to ping Google's servers each time yo…

DNSSEC doesn't protect your bank account. Your bank uses TLS to establish connections with you, and TLS is authenticated, and does not rely on the DNS when establishing connections.

DNSSEC is in fact controlled by world governments, who have de facto authority over the most important TLDs. When a CA misbehaves, Google and Mozilla can revoke them, as they've done with some of the largest and most popular CAs. You can't revoke .COM or .IO.

Re: Still Why No HTTPS?

#338

Post by romwell »

I consider myself young, but I've been around long enough to to rely on One True Service Provider for anything.

And "Let's Encrypt" is not an answer to "HTTPS is not free". It's not. We all are going to see our projects outlive Let's Encrypt (or their free tier).

In the end, nothing is secure. A dedicated attacker will find a way, given enough resources. Any security measure is just a deterrent.

My deterrent is that it's not worth MITM'ing my personal website with, like, 10 monthly visitors. (The reader might gasp that I lock my bicycle with a chain that can be snapped in a second, and that a strong enough human can probably bash my home door in).

Anyway. It's almost 2020, and if you are still advocating on moving the entirety of the Web to reliance on Big Centrally Good Guys, I really don't know what else to say to you.

Re: Still Why No HTTPS?

#339

Post by necovek »

kuschku wrote: post #333
necovek wrote: post #327

Earlier quoted context omitted.

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 swit…

Because some websites serve something different on 443 and 80, and you won’t get the right result by visiting 443. The preload list allows you to specifically say that for your own website clients should always use HTTPS, which is a good solution, as it means no one is ever going to visit kuschku.de on port 80, except for curl and dev tools, for which the redirect is useful.

I disagree with the claim that it's better for a web site to implement HSTS than to fix whatever they are serving on 443.

But to each their own.

Re: Still Why No HTTPS?

#340

Post by necovek »

namibj wrote: post #334
necovek wrote: post #329

Earlier quoted context omitted.

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 MI…

Don't worry. I don't mean we should allow the fetch API to mess with the browsers trust configuration. It should only allow a temporary override of trust rules, similar to DANE TLSA-RRs, but provided by JavaScript instead of DNSSEC-verified DNS lookups. Imagine e.g. combining this with an SPA bootloader contained in a data-url (like a bookmarklet), which the user scans via a QR-code or receives via text-based messagi…

Ah, enabling TLS for access using only an IP address is a great point, thanks.
Post reply on HN