Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless.
Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletproof safe to guard a stick of gum. Think critically people.
Right, but for a static site that’s publicly accessible, even HTTPS leaks the requested URL, any listener can go fetch that page themselves to see the contents.
It does not. In the olden days the host name was leaked, but with SNI even that is gone. Anything past the first "/" is never and was never sent in plaintext in HTTPS
I respectfully disagree that verifying your domain is pointless. Without proper verification, you leave yourself vulnerable to a range of risks, such as man-in-the-middle attacks and DNS spoofing. These attacks can allow bad actors to intercept your web traffic and inject malware into content or modify it. Recent security breaches have highlighted the importance of domain verification, and I believe that all users should take steps to verify their domains, such as implementing SSL/TLS certificates or using a domain verification service.
That’s a valid concern too. For a lot of static sites I visit, I don’t particularly care if people know I visit them as I live a boring life. My primary concern is malware and verifying identity.
Agree, what I dislike most about https is the way it effectively has a forced expiry date. Have you ever stumbled across someones old abandoned university project page, a blast from the past with all sorts of interesting information. hopes and dreams from a bygone era. not gonna happen with https.
The https certificate “expiration” date is basically just a “fallback to treating this website as http” date. The site is still perfectly accessible and arguably still more secure than an http only site, you just have to click the scary button saying you know what you’re doing and proceed to the website treating it as though it was compromised which isn’t a big deal for the static pages you’re describing.
Besides the certifacte expiration date there are also expiration dates in the protocol itself as newer clients/servers will refuse to use older SSL/TLS versions or ciphers.
But even with "just" certificate expiration the user experience is not even close to "fall back to HTTP". Browsers won't even give you the choice to override certificate check at all with HSTS.
Then there is the fact that the move from HTTP to HTTPS changes all URLs. If only we would have had StartTLS for HTTP - and no, there is no security issue with StartTLS as you will need something like HSTS preloading anyway if you actually want to guarantee security.
Lack of backwards compatibility is absolutely a concern that the security community seems to care little about.
Not if you are using tools like letsencrypt, something most blogs and small university projects would readily use. Yes there may be a breaking change in the future but it's quite set and forget at this point.
If servers have an 80% survival chance, and a 95% certificate renewal chance, you'll only see the servers that are running with expired certs. You won't see the inverse.
Specifically? Firefox to stop bitching that I enter my passwords into unencrypted pages on my local network. Browsers halt or even reverse their plans of deprecating unencrypted transport. Browsers stop bitching about loading unencrypted static resources on an encrypted page.
Generally? Everyone I accused of being shills off the "everything encrypted" bandwagon. If you want to encrypt your websites go ahead. You don't have to believe my unhinged conspiracies from earlier.
> Browsers stop bitching about loading unencrypted static resources on an encrypted page.
I tend to agree with you on other points but that one is a weird take. If I deliberately visit an https page I want to be reasonably confident that it wasn't tampered with and that I'm not leaking information.
Allowing loading http resources in an https context breaks that trust. Scripts may be tampered with. The website URL is leaked via the referer. Cookies might be leaked.
Note: Mitigations for all those worries do exist. Cookies can be flagged secure-only. Referer can be stopped using CORS, etc. But they all need the developer to be proactive about it and, for the most part, they aren't.
What scaring? Chrome shows a gray "not secure" and firefox has a crossed out padlock. That seems understated to me.
If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.
And quote from it: "HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default."
Any browser that actively prevents viewing an HTTP site is not fit for purpose. Set secure defaults, absolutely. Show scary warning pages if you insist. But don't prevent legitimate activity entirely.
I don't want to pile on, but security vulnerabilities are often composed of a series of seemingly insignificant weaknesses that get chained together in highly clever ways. Anything that is accessed over http gives a potential attacker the ability to monitor activity, MitM, spread misinformation, and find potential other footholds that can be composed into a larger attack.
TLS doesn't add that much complexity unless you're actually writing your own handshake code.
> with it come additonal vulnerabilities that a HTTP-based site doesn't have
This strikes me as being a very strange point to make. HTTP includes no security whatsoever. HTTPS includes quite a lot of security. HTTPS may have vulnerabilities, but even so it's still certainly far more secure than HTTP.
The part where you require those for your ISP, a legal entity that you have a contract with and can enforce laws against, but not for Cloudflare, Netlify, Akamai, GitHub and all the cloud vendors have access and can modify this supposedly authentic and confidentional data.
Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletproof safe to guard a stick of gum. Think critically people.