I would say that the main problem is not the encryption itself but the certificate that must be issued.

It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.

> It’s sad we can’t just encrypt the communication by setting up something in the server and that would be it.

You can? With any of Let's Encrypt's clients ( certbot, lego) of web servers that come with an ACME integration ( Caddy, Traefik).

I think the problem is if you use a self-signed certificate, the web browser tells you this is a grave concern. In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!

I'm not sure that this is an avoidable problem. If your web browser would accept an unsigned certificate, then it's not really encrypted content. The router could intercept the relevant HTTPS request, connect to the self-signed server on its own accord and pass the data back to the client. All we're achieving there is the use of a few more CPU cycles.

Lets Encrypt gives you proof that at some point in the last 90 days, Lets Encrypt's routes, which you trust to be more secure than your own routes, were able to access this server (modulo pedantry). If this information is interesting to you, you need to distinguish between the occasions when you have some alternative means of trust from the majority case. Browser warning pages are an in-your-face but reasonable approach.

As a person who has a vague understanding of how PKI works and a relative ability to distinguish "I want to access this site now" from "I have a means of proving that I trust this key", I would appreciate it if I could say I trust this signer or do something like trivially set up an acme signer for my home network.[*] The browser's "permanently stop caring about trust for this site" isn't really one that I enjoy using (even the old fashioned option to "add a temporary exception" was better!), and a lot of software is becoming harder to use without TLS.

[*] ed to add: I mean I can, but it's matter of time and energy. I think Windows makes it relatively easy to add a new root key, and on Linux I guess it's a matter of doing all the stuff you do whenever you configure stuff. On Android I have no idea if it's possible or if I just have to trust exactly whoever it is that OnePlus trusts. I've seen tutorials for how to deal with some of this stuff, and I always filed it into the box of things to deal with when I got a round tuit. It's not so much the ability to deal with it, as the fact that it's a fair amount of work, needs to be repeated for several devices, needs to be repeated for new devices, may not be doable for all devices, and it's done so rarely that it's completely impossible to memorise and even if you could something has probably changed in the interim. In short, it's possible, but using HTTP is way easier despite the fact that sometimes you have to override defaults.

>In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!

Only if you're using the HTTP challenge, the DNS challenge is (IMO at least) much simpler, easier, doesn't require any services open to the internet so can work in a LAN, and can issue wildcard certs too.

If you use a webserver like Caddy as well, then your SSL certs are done automatically without you needing to do much of anything at all.

That's true, and instead of verifying that Lets Encrypt can contact your server, they verify that you can control the DNS. It isn't compatible with least privilege though, is it?

Either every box that wants to use SSL has to be capable of changing DNS settings, or you need a central box that generates secrets and securely transmits them to the servers.

I have domain names which I am authorised to serve content on, but not authorised to manipulate DNS for (but they're all exposed to the internet, so not relevant to the limitation - but probably the reason I overlooked the blindingly obvious solution)

Super agree with this comment. Been using Caddy with DNS and it's been amazing.

> I think the problem is if you use a self-signed certificate, the web browser tells you this is a grave concern. In order to avoid this issue, ACME requires your web server to communicate with an external service provider to sign the certificate. But now you're dependent on Lets Encrypt being able to access your server!

Not necessarily, you can use lego client with dns01 challenge. This is how I issue certificates for local services running with dnsmasq or hosts file.

No it doesn't. Having HTTP does not magically open the server.

It does not have to magically open the server to open an attack vector against the site by other means, e.g. MITM on an open WiFi access point. Other comments in this thread discuss this in more depth so I’m not elaborating here.

Not against the site, against the client connecting.

No, it doesn't.

SSL doesn't magically secure your servers, especially not if all you are doing is serving static HTML content and images.

All HTTPS really does is encrypt the HTTP traffic while it is in transit. The main reason this is important is because someone monitoring network traffic (for example, at the network switch) could theoretically see raw passwords and stuff being sent over the wire in plain text.

If your web site doesn't do anything with user names and passwords or form fields that accept some type of text that needs to be secured, then HTTPS isn't really doing jack shit for you (other than making visitors "feel" secure).

Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.

> Edit: I forgot about man in the middle attacks from internet providers and governments who might modify the HTML and image payloads being transmitted to the end user. I guess HTTPS would be useful for prevent those types of exploits on static sites. So that pretty much means HTTPS should be on every site, if for no other reason than that.

Not just governments. I can get in my car and go to the three main shopping malls in my relatively large Portuguese city. I will very easily MITM a bunch of people there, no problem, using a variety of attacks. They won't realize that I'm now sucking all their traffic in and modifying it as I please.

After I've done that, if they visit any HTTP link, I can inject whatever I want there: crypto mining, download links to a modified/hacked version of their browser, social engineering attacks (phishing), cookie hijacking, etc. Notice how I can modify whatever HTTP page you have to link to websites you think are secure (banks, social media, websites), but that are modified (e.g. via sslstrip, or just by being similar-but-not-quite-the-same-hosts, etc)

Many months ago I went through this here: https://news.ycombinator.com/item?id=25123366

It should be a duty for all sysadmins to make sure their sites are HTTPS. Sure, if they're only in an intranet, HTTPS is likely overkill. But any publicly hosted website should be forced to be HTTPS.

One single HTTP website leaves a person vulnerable to millions of attacks. Many of these are still present on the web with HTTPS -- but at least then they'll typically be done by the people running the HTTPS site, not by someone in the middle.

It seems firesheep[0] is fading from the internet's institutional memory. Seeing it action was startling for most of us at the time.

[0] https://en.wikipedia.org/wiki/Firesheep

Security is about the ”CIA triad“, i.e. confidentiality, integrity, and availability.

For those sites you mention, confidentiality and availability will not really be impacted by HTTPS.

But the integrity can be.

Case in point: See this comment https://news.ycombinator.com/item?id=27507826

HTTPS is definitely useful for preserving the integrity of data between the server and the end user.

To be clear, I'm very pro-SSL and have used LetsEncrypt for years on all my domains. I was just taking issue with the notion that someone's web server serving static content could be breached just because it didn't have an SSL cert.

I mean define breached? I don't think anyone ever would say that without TLS you can use HTTP to drop into a shell on the server. But you can, largely arbitrarily, mess with the content of the site if you're adjacent to either the sever or client, or in the path between them. Maybe this matters a lot for someone's security, maybe it doesn't at all.

Breached as in someone else has control over the server.

If you can hijack the connection (i.e. MITM) you don’t need to control the server in order to compromise the integrity of the information.

True, but this would not satisfy "breached".

I had the same feeling as you recently, until I read a site posted here a few weeks ago. I can't find it now, but it was a personal page where someone described in increasing levels of severity what can be done over an unsecured HTTP connection even if there is no private data transmitted over it. Can someone help?

Because unencrypted HTTP allows attackers to MITM the traffic, they can do things like put ads on your site, inject malware or bitcoin miners, or just replace your site completely. None of those affect you, the site owner, directly, but ìt subverts the purpose of your site and lowers the value and trustworthiness of your site to your visitors.

Most anyone who is in a position to reliably MITM an HTTP site would also be in a position to install a certificate source (either as part of a “install this to access the web” program or similar).

It’s a necessary level of defense but it is NOT sufficient- especially if you never check certificates.

I highly recommend you do a search for Firesheep - the tool that really started the push for HTTPS everywhere. You're right that a malicious network operator would be in a position to request users install root certs, but the problems with plaintext HTTP are deeper than just that.

Not really. In my experience it's always been an ISP that modified the HTTP in transit (to add their own advertising and analytics JavaScript inline), and the ISP didn't have the ability to install a certificate source.

Frankly, I feel it's very good, because at this point you notice your network has been hijacked and this is the first step to solve the problem. Patching it with HTTPS (especially without HSTS) won't solve the problem, it will just make it more difficult to discover by an unsuspecting user.