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

Why Static Websites Need HTTPS

troyhunt.com

Post reply on HN
Print view View original

241–250 of 268 posts

Re: Why Static Websites Need HTTPS

#241

Post by 3pt14159 »

regecks wrote: post #240
3pt14159 wrote: post #218

Earlier quoted context omitted.

No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017. Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no…

Is your argument honestly that paying less than $10 is a sufficient deterrent for a serious attacker? To take advantage of a mis-issued certificate to begin with requires more resources than that. It's disingenuous to call this certificate forgery. If your gear is owned or somebody is in a position to perform active MITM on you, then WebPKI doesn't give a damn about your situation to begin with. It's not part of the…

The reality is that it isn't the $10 or the wildcard $120; it's the credit card that matters. When Let's Encrypt works in a scriptable context it means that something that used to be manual and a judgement call is now something that is routine.

I know this seems like splitting hairs, but it's actually mattered to some of my clients. Try to reverse the chessboard. This is exactly how things slip in and this is really being used in the wild.

Re: Why Static Websites Need HTTPS

#242

Post by 3pt14159 »

sleepychu wrote: post #238
3pt14159 wrote: post #218

Earlier quoted context omitted.

No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017. Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no…

This is really a drawback of the browser though, right? Let's Encrypt is about making traffic https not giving you strong verification of the other party. It's right there in the name! The browsers do show some things for better verified certificates e.g. "YOUR BANK LTD." on a banks cert, "Secure" on hacker news/My page secured with let's encrypt. So controlling traffic on the domain is really sufficient for the prom…

Unfortunately the "YOUR BANK LTD" certs have a major drawback: No obscure / arbitrary subdomains. It's why Google doesn't use them.

And I agree with your conclusion HTTPS is better than HTTP, but it doesn't mean we're talking with whom we think.

Re: Why Static Websites Need HTTPS

#243

Post by yboris »

derefr wrote: post #153
adwhit wrote: post #12

When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…

You know what's even easier than a simple Nginx server setup? A simple https://caddyserver.com server setup. Which will automatically provision a LetsEncrypt cert for you, no configuration required. Or, let's go even simpler: no server of your own at all. Anyone who uses GitHub Pages for their static site, gets an automatic LetsEncrypt cert provisioned for their custom domain if they set one. (I'm honestly surprised…

Thank you for sharing Caddy -- haven't heard of this until your comment. Cheers!

Re: Why Static Websites Need HTTPS

#244

Post by regecks »

3pt14159 wrote: post #241
regecks wrote: post #240

Earlier quoted context omitted.

Is your argument honestly that paying less than $10 is a sufficient deterrent for a serious attacker? To take advantage of a mis-issued certificate to begin with requires more resources than that. It's disingenuous to call this certificate forgery. If your gear is owned or somebody is in a position to perform active MITM on you, then WebPKI doesn't give a damn about your situation to begin with. It's not part of the…

The reality is that it isn't the $10 or the wildcard $120; it's the credit card that matters. When Let's Encrypt works in a scriptable context it means that something that used to be manual and a judgement call is now something that is routine. I know this seems like splitting hairs, but it's actually mattered to some of my clients. Try to reverse the chessboard. This is exactly how things slip in and this is really…

Forgive me for further splitting hairs, but you can buy SSL certificates without a credit card or proof of identity (Namecheap + Bitcoin since 2013 being one but not the only opportunity).

I think this $ thing is an arbitrary line in the sand based on an imperfect picture of how things used to be, and how things used to be did not protect domain owners. Getting certificates mis-issued used to be waaaay easier than it is now (even without demonstrable control of the domain/website). There were a tonne of insecure methods provided for in the BRs and there was no visibility into it until CT came along.

Re: Why Static Websites Need HTTPS

#245

Post by adrianratnapala »

3pt14159 wrote: post #242
sleepychu wrote: post #238

Earlier quoted context omitted.

This is really a drawback of the browser though, right? Let's Encrypt is about making traffic https not giving you strong verification of the other party. It's right there in the name! The browsers do show some things for better verified certificates e.g. "YOUR BANK LTD." on a banks cert, "Secure" on hacker news/My page secured with let's encrypt. So controlling traffic on the domain is really sufficient for the prom…

Unfortunately the "YOUR BANK LTD" certs have a major drawback: No obscure / arbitrary subdomains. It's why Google doesn't use them. And I agree with your conclusion HTTPS is better than HTTP, but it doesn't mean we're talking with whom we think.

> Unfortunately the "YOUR BANK LTD" certs have a major drawback: No obscure / arbitrary subdomains.

Why is that a drawback from a user POV? I wish sites would try hard to keep there stuff in one part of the DNS name-tree if only to make uMatrix easier to use. I'm glad of anything that encourages them to do so.

Re: Why Static Websites Need HTTPS

#246

Post by eldridgea »

schoen wrote: post #223
3pt14159 wrote: post #219

Earlier quoted context omitted.

It's fine now, following CAA records is now mandatory, but prior to 2017 we didn't and even now most websites don't use it. CAA should be mandatory in a Let's Encrypted world because it's now trivial to create a HTTPS cert. It no longer requires stolen credit card details.

Thanks. I'm also hoping that some day there will be a direct domain-registrar-to-CA authentication protocol of some sort!

More from the authoritative DNS servers than the registrar but with DNSSEC enabled, DANE[0] is a pretty good system.

Google deemed the failure rate of ~2% too high but I hold out hope that banks and other high value targets will use DANE in tandem with the traditional HTTPs CAs and use something like HSTS except instead of requiring HTTPS for a particular domain, will require DANE. Maybe something like viewing your account will accpet a CA signed cert, but an actual money transfer goes through a subdomain that required DANE.

[0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Re: Why Static Websites Need HTTPS

#247

Post by schoen »

eldridgea wrote: post #246
schoen wrote: post #223

Earlier quoted context omitted.

Thanks. I'm also hoping that some day there will be a direct domain-registrar-to-CA authentication protocol of some sort!

More from the authoritative DNS servers than the registrar but with DNSSEC enabled, DANE[0] is a pretty good system. Google deemed the failure rate of ~2% too high but I hold out hope that banks and other high value targets will use DANE in tandem with the traditional HTTPs CAs and use something like HSTS except instead of requiring HTTPS for a particular domain, will require DANE. Maybe something like viewing your a…

Sure, I was thinking about authentication for certificate issuance purposes (where Let's Encrypt already enforces DNSSEC validation for all issuance-related DNS lookups where DNSSEC is present on a zone—in fact, invalid DNSSEC signatures aren't an uncommon reason for issuance problems).

But DANE enforced by clients would also be quite valuable for preventing problems due to CA misissuance, or for the problem recently highlighted by security researchers that someone might deliberately allow a domain to expire while still possessing long-lived certificates for names under that domain.

Re: Why Static Websites Need HTTPS

#248

Post by jakelazaroff »

austincheney wrote: post #156
jakelazaroff wrote: post #88

Earlier quoted context omitted.

It doesn't matter. The browser can use the SSL certificate and the corresponding public key to verify that the contents of the connection originated from the server at the domain it expects. Unless the server's private key or browser's root certificates are compromised, the connection cannot be spoofed without being detected.

You really didn't read what I wrote. If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address. This is all handled by the DNS system. DNS lookups and caching are not a function of the browser. Perhaps you will take it more serio…

I did read what you wrote, but it's incorrect because you can't create a valid certificate for a domain you don't control.

> If the malicious site uses the valid domain and a spoofed cert for that domain it cannot tell the difference and will establish the very same trust. The browser has no way of knowing if the requested domain is hosted from the appropriate IP address.

In your scenario, the browser receives the spoofed certificate. The domain matches, but when it checks the certificate chain against its root certificates, it can't find a matching signature. Because of this, the browser knows the certificate hasn't been signed by a certificate authority it trusts, and it throws up that warning page about visiting an unsafe site.

Your Wikipedia article (and my earlier caveat about the server's private key being compromised) refers not to spoofing a cert, but to the CA being tricked into signing a certificate for a party who doesn't control the domain:

> In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation probes that CAs send.

In this case, requests to that specific domain would be vulnerable to man-in-the-middle attacks. However, it's outside the scope of TLS, which only ensures security in transport when neither the client nor the server have been compromised; it has nothing to do with securing private keys or verifying control of a domain in the first place.

Re: Why Static Websites Need HTTPS

#249

Post by Area12 »

adwhit wrote: post #12

When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…

I've had a quick look at the paper you reference, but my immediate question is ... this was written around 2009. If the costs and likelihood of getting hacked or phished have increased significantly, some of the conclusions of the paper may now be misleading, at least in detail. Has anyone done an update in the last year?

I still like the paper for one good reason ... it challenges IT people to ask the question: what risk am I mitigating with this rule on the users, and is it worth everyone's effort that will go into it? If yes, see if you can impose the rule. If no ... just be sure you didn't get the numbers wrong.

Re: Why Static Websites Need HTTPS

#250

Post by paulddraper »

ezekg wrote: post #184
peterwwillis wrote: post #180

If browsers supported a method to provide content securely without the need to encrypt everything, lots of uses of the web would not be hampered by the TLS-everything-that-moves movement. The limitations we have accepted in our browsers are what causes these conflicts. But we don't have to accept them. We could do with less propaganda and more compromise and innovation.

I'm unsure on how you could do what you've said without encryption. Any ideas?

Debian apt repos work this way. Everything has hashes or PGP signatures.

It doesn't have to be encrypted to be trusted. In fact, anyone can set up a separate mirror and clients can use it with no concern about safety.

It doesn't offer confidentiality, but it does offer integrity.

Post reply on HN