Does my site need HTTPS?
doesmysiteneedhttps.com
doesmysiteneedhttps.com
It does include a lot of problems, including the reporting of browsing information through non-stapled OCSP, there's still major MITM-problems (yes, still; for example CloudFlare is huge-ass MITM), and no matter what this site claims, HTTPS is definitely still a lot slower than HTTP, even with HTTP/2; and it further makes it a lot easier to hide which data is extracted from a computer from the user. Encryption is great if you are using it, but it can also very much be used against you. The centralization it drives also creates unpleasant attack vectors for snooping governments.
I wish there was a way non-sensitive data could be transmitted plain-text, but signed with a server certificate. This solves many of the same problems, while avoiding many of the problems with HTTPS.
This is a client bug, IMO. And sensible servers like Caddy (and yes, before people complain about disclosure, I made it) staple OCSP automatically.
> here's still major MITM-problems (yes, still; for example CloudFlare is huge-ass MITM),
But optional (and often discouraged), not required! Separate issue.
> HTTPS is definitely still a lot slower than HTTP, even with HTTP/2
That's just plain false across most dimensions. https://css-tricks.com/http2-real-world-performance-test-ana...
> it further makes it a lot easier to hide which data is extracted from a computer from the user
That's a separate issue too; don't use clients you don't trust, period. And some big-name clients like Chrome let you dump keys to inspect data transfers locally.
> I wish there was a way non-sensitive data could be transmitted plain-text, but signed with a server certificate.
TLS supports a "NULL" cipher in certain cipher suites for signed-only transmissions, but mainstream server and client support are limited (for good reasons).
As a client I don't get to choose how the servers interact with are configured.
> But optional (and often discouraged), not required. Separate issue!
Not at all a separate issue. The issue is the absolute fantasy that HTTPS makes your connection secure.
> Don't use clients you don't trust, period. And some big-name clients like Chrome let you dump keys to inspect data transfers locally.
Are you really telling me I have to implement every piece of software I want to run myself from scratch, write custom firmware for my processor, for my router, then sit down and create a custom ROM with a custom operating system for my phone?
Clients are the ones that cause the privacy leak, not servers.
> The issue is the absolute fantasy that HTTPS makes your connection secure.
Oh, OK.
> Are you really telling me I have to implement every piece of software I want to run myself from scratch, write custom firmware for my processor, for my router, then sit down and create a custom ROM with a custom operating system for my phone?
If you don't trust them, then yes. Nothing new here though.
Regardless of where the leak is, this is not a problem that exists in HTTP. You could not just go to a central server and gather a log of some NN% of the HTTP connections being made. No, DNS is not analogous. You can choose your DNS server, you can even run your own.
> If you don't trust them, then yes. Nothing new here though.
What's new is that it's become a lot harder to examine the information my software is sending to servers on the Internet. If they all talked HTTP, it would be trivial for me to intercept and examine. You can do that with HTTPS, sometimes, but it's a lot harder and relies on the software obeying OS proxy settings.
Stuff that doesn't obey the system proxy (or a few of the other pitfalls e.g. HPKP) will break, but at least you'd be aware of what's not allowing itself to be intercepted.
HTTPS is reasonably secure if the person in control of the domain is making sure it is reasonably secure. Setting up your whole domain to be MITM is not that.
Your connection to whatever place the person in control of the domain has delegated your connection to is reasonably secure.
And how do you know how secure is a certificate issued by Google or Cloudfare or Microsoft ? Those certificates are just trusted. Good luck with security.
Well, this is a kind of compromise. It is similar with COVID-19 vaccines: even though they don't prevent transmission, hospitalization and death, they do reduce them (at least the last two).
Even though HTTPS can not offer a very high protection level, together with accompanying technologies they do make certain attacks more problematic - especially sniffing. So for most intents and purposes, HTTPS may make a connection more secure.
I always feel like any performance claims are nowhere near my real life experience, not even when talking about synthetic benchmarks.
For example I recently set up an Apache server that returned a 304 response, on an AWS t3.micro instance and with the Apache Benchmark tool I got around 3.5k[0] requests per second. Once I've enabled HTTPS that fell to around 500 requests per second.
From what I've read at the time (because I was aware of the general consensus that they should have comparable performance), there is some type of underlying hardware feature the TLS decryption/encryption routine can use to speed things up, but it's only available in AWS in m3 type instances and above. Read it from a Mozilla (I think) article, that I couldn't find again right now.
[0] that 3.5k/500 rps might be higher for you because I used maxminddb IP mapping on each requests which I'm sure adds some considerable factor to the rps.
... except that you don't, they're flagged behind https expressly to strongarm https implementation.
You can discuss "HTTPS performance" in a purist way that makes it look slower than plain HTTP, but in practice (the only way that matters) HTTPS is faster than HTTP.
So technically http/2 is faster, but it is only possible with https.
Because of arbitrary client restrictions. http/2 can be unencrypted, and would be faster unencrypted than encrypted. It's just that all servers/clients decided to not implement the optional unencrypted mode.
I'm not arguing either way, but technically it is possible to do it without https.
IIRC Windows Update used to do that in XP days, to guarantee responses were signed but to alleviate the pressure of encryption from the CDNs handling updates at the time. (When SSL/TLS was fairly heavy, and Windows Update traffic was 10s of % of internet traffic)
Isn't this, more-or-less, HTTPS? I think you'd end up with something very similar as you'd likely need to solve the same problems HTTPS attempts to solve:
1. How do you know the authenticity of a message? You need some out of band channel of communication or trusted intermediary to verify anything you receive (e.g. a certifying authority)
2. How do you know when somebody's signature has changed?
3. When does a message expire? Can somebody replay a previous valid response?
And stepping past a few of these implementation issues; how much overhead is HTTPS really? TLS is definitely a chatty protocol, but as I understand things that has more to do with TCP and the complexity of the CA system than the encryption itself.
I like your idea of a faster HTTP variant that only guarantee message integrity rather than secrecy, but I myself can't see how you'd get there without implementing a lot of the things that makes HTTPS slower than vanilla HTTP.
Centralization is the point where I agree with you, I would love to see browsers support a scheme where certs can be TOFU with a private CA.
I don't understand this argument. If the world was "HTTPS-optional" like it was 10 years ago, anything that wants to hide which data is extracted can still (optionally) implement HTTPS (or whatever encryption they please).
So the only way this argument makes sense to me is if 'pushback against HTTPS' means ban encryption, and it seems to me that's not what you're saying.
> The centralization it drives also creates unpleasant attack vectors for snooping governments.
The internet is already heavily centralized around a couple of large IXes. Not having HTTPS will only make snooping governments' jobs easier. It doesn't matter to them whether their wiretaps are in CloudFlare's datacenter or in the IX next door, and they'd probably get greater coverage with the latter.
No, no it does not.
(It's only a naive implementation of parsing the Accept-Language header. Sorry, was all I could do at the time.)
I'm not sure what the standard says, but i suspect you'd surprise users considerably less if you used the first language listed in that header rather than the last (assuming equal or missing q values).
A proper implementation would make for a good Caddy module.
Accept-Language: en-US;q=1.0, en;q=1.0, fr-FR;q=0.5, fr;q=0.5
> It just works if Caddy is your web server.
I wonder what percentage of people who thinks HTTPS is difficult to set up and maintain are able to run their own VPS and properly install and configure caddy.
You just purchase a domain. You decide to host on apache. You first have to setup http get the letsencrypt to perform the challenge. Once that's done you can install ssl.
The letsencrypt auto renewer is great until you run a version of linux unsupported.
The extra cost per request does add up as well.
The cost to support ssl isn't free but the certificate is and pretty seemless all things considered
Consider using an ACME client written in shell:
* https://github.com/dehydrated-io/dehydrated
* https://github.com/acmesh-official/acme.sh
There's a minor change for the pre/post-scripts to restart your web server, and telling the web server where "/.well-known/acme-challenge/" should be served from, e.g.,:
* https://salsa.debian.org/letsencrypt-team/dehydrated/-/blob/...
But otherwise I find there are a lot fewer moving parts (and dependencies) than ACME clients written in other languages.
The packages themselves are signed and checked locally before installing them, so MITM shouldn't be possible. If your local trust is broken, then you lost already.
And you can easily setup caching proxies for the repos, without requiring to setup your own CA.
One example of where this could lead to a wide spread attack is distros like whonix.org which update over Tor. They mitigate this with https/.onion package servers.
Theres also the smaller problem of package-set fingerprinting like you said.
AFAIR there are options to sign packages themselves, but there’s at least two competing incompatible signing schemes.
rpm packages carry a signature in the package itself.
I'd rather not ...
Google treat the HTTP and HTTPS pages as separate for link ranking purposes, so there is a chance that a move will destroy 10 years of link ranking. Even with redirects, there is a non-zero chance of the business being destroyed.
If Google would treat HTTP and HTTP pages as the "same page" then I would move tomorrow.
https://developers.google.com/search/docs/advanced/crawling/...
Also, good luck using LE in a web farm type environment "easily". Given the challenge limits there's usually a fair bit of plumbing required to get multiple servers on the same domain with the same certificates. It's anything but "just works".
[1] https://www.bleepingcomputer.com/news/security/lets-encrypt-...
> Head of Let’s Encrypt here. This is a compliance issue, there is no security or validation integrity risk.
For multiple servers running the same domain, you can configure them all the same and they will get certificates fine. If required, they will get a new certificate from LE; if this is not required then LE will provide the current certificate to the server. There maybe a short time where the actual certificate on two servers maybe different, but both would still be considered valid. So there really shouldn't be any plumbing required. (edit: This is dependent on you having a sensible way to load balance them. If you're just running IP round-robin then it's going to be difficult, but that is what scp and custom routes are for).
I use LE for multiple domains, on multiple systems. Internal and external with no issue. I've even had certificates revoked by LE and it's never had any operational impact.
True, but incomplete. It is not SOLELY the browser's job. Browsers can only keep the users safe if the server provides credentials through an HTTPS certificate. As a site owner, it's your responsibility to provide these credentials for your clients."
HTTPS, or even using the internet in general, is not the only way to provide credentials to clients (users). For example, public keys can be provided using other protocols or even out of band.
Not every website is engaged in commerce nor otherwise needs to "scale" in a way that only computers can enable.
And caddy is still not available in the Debian repos.
But you can add our source anyway: https://caddyserver.com/docs/install#debian-ubuntu-raspbian
I think it is fine to support both if you are not handling forms, etc. Obviously you prefer people to use HTTPS, but there may be cases where HTTP is preferred. One example might be a large download where you can verify the hash afterwards, or interacting with old hardware/software.
This wasn’t really a widespread problem before “https everywhere” became a thing, but it’s definitely possible. I distinctly remember projects that replaced images with cat pictures in-line, or made everything upside down; by exploiting the fact that can be modified in transit.
Sure, I've been there with "free WiFi" services injecting crap into a page. I believe some ISPs in the US would also put JS into HTTP pages. But this is why I argue for both HTTP and HTTPS.
I think it ultimately depends on your security model. Perhaps a workaround could be to disable forms in browsers whilst in HTTP mode, disable JS, parts of CSS, etc, by default. Require that the user explicitly ask for content in an insecure way.
I think it really depends on the scale of what you're working with. It's not just the network overhead but also the CPU overhead. It's the cost of a copy operation (and maybe not even that with io_uring) vs an entire encryption process.
/e: non-CDN site, hosted on EC2, safe ciphers+hash algos without crypto HW accelerators etc. Average business website. With WordPress it is even worse. The CDN lets us terminate TLS and fetch origin in plain text + optimisations on crypto etc.
Very strange way of thinking.
For Google this is fixed by hard coding the SSL hashes into chrome, for the rest of us we rely on http headers; which of course are much more fungible.
Maybe with DoH it’s better. But that’s more https to make https not suck.
Disclaimer, I didn't know about them either. TIL.
If you're using plain HTTP, someone can MITM in HTTP, and a rogue authority can issue a certificate to someone who isn't you. This is not an argument against you using HTTPS at all.
Self-signed HTTPS would be even better, but it seems to be frowned-upon by browsers these days.
Absolutely not. I am pointing out that even within your (incorrect) assumption, you using HTTPS does not hurt your security at all.
That you take it to mean "HTTPS is insecure" is your own assumption, that you take it to mean "equally as insecure as HTTP" is something you made up.
A parallel: A lot of companies make seatbelts, you're not sure you can trust all of them. Even though they would be caught by quality testing and instantly go under, it is possible that one of them would build them with cheap materials that wouldn't offer much protection. Therefore seatbelts are not completely safe. Therefore wearing a seatbelt is equally as safe as not wearing one.
They used to make SSL/TLS and more accelerators you could slot into servers to make it faster.
As a devil's advocate, I wonder how much energy the world would save by using HTTP, instead of HTTPS.
That is a hell of a lot of processing going on every single second globally.
The fatter and fatter and fatter websites get, the more compute is required to encrypt and decrypt everything.
Think of how much electrical power could be freed up and used for better things. </s>
https://news.ycombinator.com/from?site=https.dev
its last snapshot:
https://web.archive.org/web/20210126194059/https://docs.http...
source: https://github.com/https-dev/docs/blob/master/list-of-acme-s...
>They're free.
May be free but is it still applicable on hosting providers like Godaddy?
You mean ones that will try to exploit and defraud you on every opportunity? Probably not.
If you mean hosting providers in general, yes, they'll usually handle a Let's Encrypt certificate for you for free.
It may look like I'm being facetious, but I'm not. GoDaddy to me has always felt like the domain registrar for non-technical people that will overpay for things because they don't know any better. Like...GoDaddy's customers are the same people that continued to pay for AOL even after getting a DSL line or cable modem. The same people that have paid for a shady ad blocker despite uBlock Origin existing and being free. The same people that, in the early days of Android, paid $5/month to Verizon to get Verizon Maps and Navigation despite their phone having Google Maps on it for free.
Anything GoDaddy does can be done somewhere else for cheaper or even free. They are ripping you off.
There are several types of certificate. The most basic is DV where you only need to upload a file or modify DNS record to prove you own a domain.
EV certs used to be visually distinct in browsers but it was shown to not be that useful and in fact counterproductive. The browsers are going in opposite direction: show nothing special for HTTPS, and show red warnings on HTTP.
At this point EV certs are mostly only used by legacy SSL sellers to milk rich customers who can't tell the difference.
EV certs have long been known to be ineffective at preventing fraud. In fact, they can enhance fraudulent activity with a false sense of trust. And that's if users even notice it and know what it means (most don't).
Chrome has since adopted some ideas from my thesis which attempt to warn you if you're at risk based on suspicious characteristics of the site you're on, like unusual patterns in domain names.
some previous discussion: https://news.ycombinator.com/item?id=14753993
"Our site displays ads over HTTP."
Sorry, not sorry.
in terms of gains you get the benefit of easy to remember names, and you don't share everything in plaintext which is becoming more and more important as we get more and more devices on our LANs
Edit: certbot has plugins for a bunch of custom APIs too.
True, tls won't make a dramatic improvement, but it's still and improvement
> > If we encrypt only secret content, then we automatically paint a target on those transmissions.
> None of those things are my problem.
> > [HTTPS] guarantees content integrity and the ability to detect tampering.
> The legions of browser programmers employed by Mozilla, Google, Apple, and Microsoft should do something about that. It's not my flaw to fix, because it's a problem with the clients.
I re-ordered the quotes a bit, but I'm reasonably confident I didn't misrepresent what he was trying to say. The counter-arguments after this are good, but the first couple of things are, imo, already sufficient to make HTTPS a very very important thing.
Though… I find myself wondering whether he's really all that wrong, after all.
> Users must keep themselves safe. Software can't ever do that for you. Users are on their own to ensure they use a quality web client, on a computer they're reasonably sure is well-maintained, over an internet connection that is not run by people who hate them.
> It's just software. It can't fix your society.
And while "encrypting only sensitive content calls out that content as being sensitive" is certainly true theoretically, almost every site has HTTPS, sensitive or not, so in practice it's not a concern.
And not use insecure websites, I guess. I don't know how that person expects the browser to magically protect the user if their server transmits in plain text.
The arguments against Caddy are no longer true. Caddy runs on a ton of platforms, essentially any that Go can use as compile targets (except for plan9 for the moment because of a dependency of Caddy's that has a compatibility problem https://github.com/caddyserver/caddy/issues/3615#issuecommen...). Caddy also doesn't have to run as root, nor does it by default with our apt/yum packages.
Also a passing comment essentially calling Let's Encrypt... with their track record at this point, I don't think that can be said.
The rest is basically just vitriol.
It's nothing more than victim blaming and circular logic. Damn near every argument being made is "That attack doesn't matter to me because I don't use HTTPS because my site doesn't need HTTPS".