8 ms·

Love Let's Encrypt, Like 1password, support/use them both. But I'm still unconvinced that every single one of those last remaining 15% of websites must be tran

Love Let's Encrypt, Like 1password, support/use them both. But I'm still unconvinced that every single one of those last remaining 15% of websites must be transitioned to HTTPS. I have personal websites that are open, public, non-controversial, simple. I like that you can curl or wget them without mucking about with certs and that you can view them using anything and everything vaguely browsery ever made. I feel moving to HTTPS subtracts value, at least to me, and I'm the owner. Not to get all grouchy old geezer, but I don't feel every single public open simple textual website must be encrypted. Where am I wrong / what am I missing? (While understanding there's a mathematical world of difference between statements "Most / 99% of websites should be encrypted!" and "All / 100% of websites should be encrypted!" :)

bo0tzz 5y ago
While your website might not contain anything interesting, leaving it on HTTP leaves the door open for an attacker to put something nefarious on there, which you wouldn't want even if the current content is low stakes.
- t0mbstone 5y ago
  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.
  - cpach 5y ago
    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://news.ycombinator.com/item?id=27507826
    - t0mbstone 5y ago
      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.
      - Spivak 5y ago
        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.
        gsich 5y ago
        Breached as in someone else has control over the server.
        cpach 5y ago
        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.
        gsich 5y ago
        True, but this would not satisfy "breached".
- anton96 5y ago
  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.
  - sofixa 5y ago
    > 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).
    - squiggleblaz 5y ago
      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.
- gsich 5y ago
  No it doesn't. Having HTTP does not magically open the server.
  - haswell 5y ago
    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.
    - gsich 5y ago
      Not against the site, against the client connecting.
deleted 5y ago
[deleted]
Klathmon 5y ago
Encryption isn't just about hiding information, it's also about ensuring that nobody tampered with it. Hacked routers can easily insert malware (and now days crypotminers) into html/javascript/css payloads, hell I remember playing with some stuff decades ago that would allow you to inject malware into exes that came across the network without encryption.
raspyberr 5y ago
From what I understand, one of the main issues with HTTP is that anyone in the middle can just change the content.
- Spivak 5y ago
  Which is exactly the problem DNSoTLS and DNSoHTTPS solve for DNS but there seems to be a lot more resistance on that front. I guess if a whole generation of ad-blockers has been based on Squid the tune would change I guess.
  - raspyberr 5y ago
    Doesn't DoH/DoT centralise a decentralised protocol though? DoH is great but then you just get Cloudflare knowing all the DNS calls.
    - Spivak 5y ago
      No, but also yes. I mean DNS and DoT have the same relationship as HTTP and HTTPS but unlike the HTTPS rollout large projects aren't waiting around for the world to upgrade all their software and are just connecting to public DNS servers that speak DoT/H. DNS the global database is still just as decentralized but DNS thing you connect to do the actual work is now a little less so.
    - gsich 5y ago
      No, as everyone (including your ISP) can setup a DoH/DoT server. What is a problem though is a lack of discoverability. Right now you need to manually configure DoT/DoH. Or you are Mozilla and force the decision.
      - tialaramex 5y ago
        IIRC If you have Chrome in some cases it will auto-detect an upgrade. So e.g. you've told Chrome you want 8.8.8.8 DNS, that can do DoH, so Chrome will use DoH from 8.8.8.8 From Google's point of view even if they auto-upgrade you from your ISP's DNS server to an ISP-controlled DoH server this is a win because the DoH server paperwork (to get that upgrade to happen) requires the ISP to have sane rules for the new shiny DoH server whereas their old DNS server was whatever Corporate said it should be. e.g. DoH has an explicit censorship mechanism. The server can say "Nah, I can't tell you that" rather than pretending the answer for your query is either NXDOMAIN when it isn't, or worse some custom ISP chosen IP that isn't even a sane answer to the question you asked. This means (if DoH servers implement it, which Google requires to get that auto-upgrade behaviour) software using DoH can do much less crazy acrobatics to cope with censorship than with DNS. For example that bogus IP trick obviously can't work with HTTPS. So users get a weird HTTPS error, and it's unclear why they can't look at Clown Porn. Whereas with DoH the browser can say "You are not allowed to look at Clown Porn". Much better. [This is independent of the question of whether censoring Clown Porn is a good idea, sometimes, or always, which is not a technical problem and so out of scope for DoH. People are doing it, and we want to make that cause less technical problems]
MaxBarraclough 5y ago
A fair question deserving a real answer, rather than downvotes. 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities. 2. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad. 3. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though. 4. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [1]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [2]. 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons: * Reduced admin overhead not having to bother with certs * It enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3] * Better support for very old devices, such as old smartphones in the developing world [0] https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ [1] https://www.theguardian.com/us-news/2016/jan/13/us-library-records-purged-data-privacy https://www.theguardian.com/us-news/2016/jan/13/us-library-r... [2] https://arstechnica.com/information-technology/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/ https://arstechnica.com/information-technology/2015/04/it-wa... [3] https://web.archive.org/web/20200615045650/http://whydoesaptnotusehttps.com/ https://web.archive.org/web/20200615045650/http://whydoesapt... (Based on an old comment of mine at https://news.ycombinator.com/item?id=22147858 https://news.ycombinator.com/item?id=22147858 )
- eliaspro 5y ago
  I feel the notion of "I don't want to deal with HTTPS" is mostly to blame on the ridiculous UX of cert management in the past. The act of creating a CSR alone using openssl is reason enough to justify the emotional rejection of HTTPS. Since I switched all my setups to Caddy [1] using HTTPS by default has become an absolute no-brainer and nothing to care about, as it simply happens automatically due to its built-in ACME support. [1] https://caddyserver.com/ https://caddyserver.com/
- 5y ago
tialaramex 5y ago
The intuitive properties you expect from HTTP actually aren't delivered and can't be delivered, except over HTTPS. A lot of people focus on the confidentiality element of TLS. "Clearly I don't need for it to be secret that I looked at the Wikipedia entry for Napoleon (the 1995 movie, not the famous guy)". But TLS bundles together three things and if you need any of them you can't have them with plain HTTP. You get confidentiality, but you also get integrity and authentication. That means when you curl https://foo.example/something https://foo.example/something we can promise you that the result is the resource https://foo.example/something https://foo.example/something - maybe that's not what you actually wanted, maybe it's full of lies or worse, but it is what you asked for and it is what you get. With plain HTTP all bets are off, anybody can interpose and present anything else to you. If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? You could make up whatever you want, it's a black-and-white movie about a dog who ruled France and then went into space, and it was the #1 grossing movie in every country for six years.
- dvfjsdhgfv 5y ago
  > If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? This is probably the argument I hear most often. But it completely ignores the fact that for the last 20 years, when I wanted to grab a Wikipedia article, I got it in 100% cases, whereas the number of broken HTTPS websites (usually because of expired certs) is non-negligible. You can blame "incompetent admins" as much as you want, but with HTTP this particular problem simply doesn't exist.
  - rezonant 5y ago
    Sure, it is incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. But regular users want WiFi at their favorite coffee shop, and there are still plenty of unsecured wireless hotspots at those shops. The capability to intercept insecure WiFi has been heavily commoditized over the years since the techniques were created. Well within reach for a disgruntled lover, or a stalker, or perhaps for corporate espionage. Sure, more sophisticated organizations should have and more often do have protections for this (including, of course, strong TLS/HTTPS) but not everyone does, and we should protect them too. But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.
JoshTriplett 5y ago
The current Let's Encrypt tooling (certbot and company) is far from the simplest way to handle HTTPS / TLS. I think the simplest solution is a webserver with built-in ACME tls-alpn-01 support. That doesn't require listening on HTTP separately, and it works automatically without needing anything but the domain name. No "mucking about with certs" at all; just a single server listening on port 443 that's automatically secure. Apache supports this via mod_md; Caddy has this as a flagship feature; many other web servers support this as well. I do think there's high value in having 100% of Internet traffic encrypted, not just 99%. Consider something like the Great Cannon attack: someone could intercept traffic to your site and add in malicious JavaScript, or references to large resources on other sites for a DoS, or references to LAN resources, or other things that use your site to hurt others. Consider that we're moving to a more carefully sandboxed, permission-based web, and those permissions are tied to identity. If your site wants permission for location, or permission to autoplay video, or camera access, or any number of other things that we may want to limit access to, that permission needs to be tied to a site identity so that they're not available to anyone who MITMs your site. Consider that if your site has any kind of form, even the simplest of forms, users may use autofill with it, which puts them at risk if your site is plaintext. Consider that even if your site is 100% static, it could have ads or other JavaScript injected into it. Consider that what's "non-controversial" for you may not be non-controversial to everyone browsing your site; you're encrypting for their benefit, not just for yours. Consider that it's much easier to keep users secure when browsers mark http as explicitly insecure rather than just omitting security icons. We should absolutely make HTTPS even simpler and easier, so that security becomes the zero-effort default. And we should continue to deprecate HTTP. As a related aside, I do think there are some specific cases that haven't yet been well-handled by HTTPS. In particular, there isn't yet a great solution for routers and embedded devices, which need an identity but don't have a domain name for that identity.
tw04 5y ago
So let's say your site is popular. What exactly is preventing a bad actor from MITM your site and spreading malware at a coffee shop or insert open public wifi? HTTPS isn't just about securing the information, it ensures that when someone tries to get to your site, they ACTUALLY get to your site.
- dvfjsdhgfv 5y ago
  There are many assumptions here. Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so. In any case, using HTTPS is indeed helpful in a hostile network when combined with HSTS, but if you have already connected to a network controlled by an attacker, this means they can not only sniff all your traffic, but already control your DNS and can easily find multiple ways to deliver the payload to you.
  - kelnos 5y ago
    > Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so. If that's the case, you are absolutely not the average internet user. Plenty of people, most of them non-technical, will connect to the wifi of their local cafe, and spend many tens of minutes doing things on the internet while connected to it.
- merb 5y ago
  you can publish a sha256 hash for every site/resource. (just kidding of course)
  - randomhodler84 5y ago
    No kid, SRI : Sub Resource Integrity is exactly this and an important way to secure CDN hosted js you are using on your site, however if the channel itself has no integrity protection, like HTTP does not (but https does via TLS), an attacker can dynamically replace SRI values with their malicious equivalents. So, both?
jorl17 5y ago
Most people have already answered you. The problem is anyone in the middle can hijack the page and put whatever they want there. See what I mentioned here in the past: https://news.ycombinator.com/item?id=25123366 https://news.ycombinator.com/item?id=25123366 Now imagine you combine MITM-ing someone with social engineering. You send them a legitimate inocuous link like http://my-bank.my-tld http://my-bank.my-tld, but you are MITM-ing them and outright replace the content of the page with whatever you want. Yes, HSTS protects agains this example, but the problem still remains: whatever goes through HTTP can be manipulated and used for nefarious ends. It's kinda like walking around with a car door open waiting for someone to throw a bomb inside it.
gsich 5y ago
>But I'm still unconvinced that every single one of those last remaining 15% of websites must be transitioned to HTTPS. I use HTTPS. That said, if someone doesn't want to do it - also a valid choice. The arguments have been made (content manipulation, snooping ...) but if I as a site owner don't care about someone elses shitty ISP, then I can use HTTP only.
contrary3332 5y ago
Yes, that 15% includes my personal site. But let's be real, Apple, Google and Microsoft provide the money funding the browsers 95% of people use. So I think we can predict where this will end up.
greggman3 5y ago
first off, let me say, for me. I use Caddy (https://caddyserver.com/ https://caddyserver.com/) and it just works. You start it, it gets a cert from letsencrypt and starts serving https. So it was (almost) zero work to serve with https. As for reasons to encrypt 1. Prevents (I think) ISPs in the middle from injecting ads, spyware, phishing scams, etc on top of your site. 2. Prevents 3rd parties from seeing what pages the user is accessing. Some people would prefer that other's can not read over their shoulder and see what they're reading. I know for me, I'm sensitive to that particular issue to the point that I don't really want to use Netflix, Amazon Prime, Spotify, etc. I really don't like the idea that they're building a profile of me based on what I watch and thinking they know who I am based on that. It could be as simple as I don't want it known if I'm reading liberal or conservative blogs. I'm sure others might have other reasons they don't want a 3rd party to know what specific pages they're reading. --- ps: I get there are other ways to track me but I'm fairly confident that I'm avoiding most of them via HTTPS, VPNs, Private browser windows, multiple profiles, 3rd party cookies off, ad blockers, etc....
- EveYoung 5y ago
  If privacy is a concern, users should also consider switching to an independent DoS/DoT DNS provider.
riffic 5y ago
ISPs can inject content into HTTP pages. This alone is a reason to move to HTTPS across the board.

bo0tzz 5y ago

While your website might not contain anything interesting, leaving it on HTTP leaves the door open for an attacker to put something nefarious on there, which you wouldn't want even if the current content is low stakes.

t0mbstone 5y ago
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.
- cpach 5y ago
  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://news.ycombinator.com/item?id=27507826
  - t0mbstone 5y ago
    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.
    - Spivak 5y ago
      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.
      - gsich 5y ago
        Breached as in someone else has control over the server.
        cpach 5y ago
        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.
        gsich 5y ago
        True, but this would not satisfy "breached".
anton96 5y ago
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.
- sofixa 5y ago
  > 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).
  - squiggleblaz 5y ago
    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.
gsich 5y ago
No it doesn't. Having HTTP does not magically open the server.
- haswell 5y ago
  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.
  - gsich 5y ago
    Not against the site, against the client connecting.

deleted 5y ago

[deleted]

Klathmon 5y ago

Encryption isn't just about hiding information, it's also about ensuring that nobody tampered with it. Hacked routers can easily insert malware (and now days crypotminers) into html/javascript/css payloads, hell I remember playing with some stuff decades ago that would allow you to inject malware into exes that came across the network without encryption.

raspyberr 5y ago

From what I understand, one of the main issues with HTTP is that anyone in the middle can just change the content.

Spivak 5y ago
Which is exactly the problem DNSoTLS and DNSoHTTPS solve for DNS but there seems to be a lot more resistance on that front. I guess if a whole generation of ad-blockers has been based on Squid the tune would change I guess.
- raspyberr 5y ago
  Doesn't DoH/DoT centralise a decentralised protocol though? DoH is great but then you just get Cloudflare knowing all the DNS calls.
  - Spivak 5y ago
    No, but also yes. I mean DNS and DoT have the same relationship as HTTP and HTTPS but unlike the HTTPS rollout large projects aren't waiting around for the world to upgrade all their software and are just connecting to public DNS servers that speak DoT/H. DNS the global database is still just as decentralized but DNS thing you connect to do the actual work is now a little less so.
  - gsich 5y ago
    No, as everyone (including your ISP) can setup a DoH/DoT server. What is a problem though is a lack of discoverability. Right now you need to manually configure DoT/DoH. Or you are Mozilla and force the decision.
    - tialaramex 5y ago
      IIRC If you have Chrome in some cases it will auto-detect an upgrade. So e.g. you've told Chrome you want 8.8.8.8 DNS, that can do DoH, so Chrome will use DoH from 8.8.8.8 From Google's point of view even if they auto-upgrade you from your ISP's DNS server to an ISP-controlled DoH server this is a win because the DoH server paperwork (to get that upgrade to happen) requires the ISP to have sane rules for the new shiny DoH server whereas their old DNS server was whatever Corporate said it should be. e.g. DoH has an explicit censorship mechanism. The server can say "Nah, I can't tell you that" rather than pretending the answer for your query is either NXDOMAIN when it isn't, or worse some custom ISP chosen IP that isn't even a sane answer to the question you asked. This means (if DoH servers implement it, which Google requires to get that auto-upgrade behaviour) software using DoH can do much less crazy acrobatics to cope with censorship than with DNS. For example that bogus IP trick obviously can't work with HTTPS. So users get a weird HTTPS error, and it's unclear why they can't look at Clown Porn. Whereas with DoH the browser can say "You are not allowed to look at Clown Porn". Much better. [This is independent of the question of whether censoring Clown Porn is a good idea, sometimes, or always, which is not a technical problem and so out of scope for DoH. People are doing it, and we want to make that cause less technical problems]

MaxBarraclough 5y ago

A fair question deserving a real answer, rather than downvotes. 1. HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. Man-in-the-middle attacks of this sort really have happened, [0] and remember that the browser itself may have exploitable security vulnerabilities. 2. Modern browsers will (rightly) warn users not to trust the site. This makes the site look bad. 3. Some fancy browser features are disabled if you use unencrypted HTTP. Likely irrelevant for a static site though. 4. Privacy matters. A medical website, or indeed Wikipedia, should prevent a snooping ISP from finding out you have been reading about an embarrassing condition. This is similar to the way librarians are extremely protective of their loan records [1]. Netflix use HTTPS for their streams, for the same reason (it does nothing to aid their DRM, it's purely about privacy) [2]. 5. Let's turn the tables and ask why you wouldn't use HTTPS for a public-facing web server. There are just 3 reasons: * Reduced admin overhead not having to bother with certs * It enables caching web proxies, which is only relevant if you're running a serious distribution platform like Steam, or a Linux package-management repo [3] * Better support for very old devices, such as old smartphones in the developing world [0] https://doesmysiteneedhttps.com/ https://doesmysiteneedhttps.com/ [1] https://www.theguardian.com/us-news/2016/jan/13/us-library-records-purged-data-privacy https://www.theguardian.com/us-news/2016/jan/13/us-library-r... [2] https://arstechnica.com/information-technology/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/ https://arstechnica.com/information-technology/2015/04/it-wa... [3] https://web.archive.org/web/20200615045650/http://whydoesaptnotusehttps.com/ https://web.archive.org/web/20200615045650/http://whydoesapt... (Based on an old comment of mine at https://news.ycombinator.com/item?id=22147858 https://news.ycombinator.com/item?id=22147858 )

eliaspro 5y ago
I feel the notion of "I don't want to deal with HTTPS" is mostly to blame on the ridiculous UX of cert management in the past. The act of creating a CSR alone using openssl is reason enough to justify the emotional rejection of HTTPS. Since I switched all my setups to Caddy [1] using HTTPS by default has become an absolute no-brainer and nothing to care about, as it simply happens automatically due to its built-in ACME support. [1] https://caddyserver.com/ https://caddyserver.com/
5y ago

tialaramex 5y ago

The intuitive properties you expect from HTTP actually aren't delivered and can't be delivered, except over HTTPS. A lot of people focus on the confidentiality element of TLS. "Clearly I don't need for it to be secret that I looked at the Wikipedia entry for Napoleon (the 1995 movie, not the famous guy)". But TLS bundles together three things and if you need any of them you can't have them with plain HTTP. You get confidentiality, but you also get integrity and authentication. That means when you curl https://foo.example/something https://foo.example/something we can promise you that the result is the resource https://foo.example/something https://foo.example/something - maybe that's not what you actually wanted, maybe it's full of lies or worse, but it is what you asked for and it is what you get. With plain HTTP all bets are off, anybody can interpose and present anything else to you. If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? You could make up whatever you want, it's a black-and-white movie about a dog who ruled France and then went into space, and it was the #1 grossing movie in every country for six years.

dvfjsdhgfv 5y ago
> If it's OK if you just get anything and not the article from Wikipedia, why even look at Wikipedia at all? This is probably the argument I hear most often. But it completely ignores the fact that for the last 20 years, when I wanted to grab a Wikipedia article, I got it in 100% cases, whereas the number of broken HTTPS websites (usually because of expired certs) is non-negligible. You can blame "incompetent admins" as much as you want, but with HTTP this particular problem simply doesn't exist.
- rezonant 5y ago
  Sure, it is incredibly rare for a man-in-the-middle attack to take place at the ISP level in the US. But regular users want WiFi at their favorite coffee shop, and there are still plenty of unsecured wireless hotspots at those shops. The capability to intercept insecure WiFi has been heavily commoditized over the years since the techniques were created. Well within reach for a disgruntled lover, or a stalker, or perhaps for corporate espionage. Sure, more sophisticated organizations should have and more often do have protections for this (including, of course, strong TLS/HTTPS) but not everyone does, and we should protect them too. But that's just in the US, what about in countries where the ISP is far less than trustworthy. It's feasible that a state actor or other malicious actor could replace your web page with a phishing page. A non-sophisticated user (or even a somewhat sophisticated one, if the phishing attack is done well enough) might make that critical mistake that grants access to what is normally highly secured, but because a webmaster who doesn't understand the risks decided not to enable HTTPS, the user's personal information (or worse, their life) could be at risk.

JoshTriplett 5y ago

The current Let's Encrypt tooling (certbot and company) is far from the simplest way to handle HTTPS / TLS. I think the simplest solution is a webserver with built-in ACME tls-alpn-01 support. That doesn't require listening on HTTP separately, and it works automatically without needing anything but the domain name. No "mucking about with certs" at all; just a single server listening on port 443 that's automatically secure. Apache supports this via mod_md; Caddy has this as a flagship feature; many other web servers support this as well. I do think there's high value in having 100% of Internet traffic encrypted, not just 99%. Consider something like the Great Cannon attack: someone could intercept traffic to your site and add in malicious JavaScript, or references to large resources on other sites for a DoS, or references to LAN resources, or other things that use your site to hurt others. Consider that we're moving to a more carefully sandboxed, permission-based web, and those permissions are tied to identity. If your site wants permission for location, or permission to autoplay video, or camera access, or any number of other things that we may want to limit access to, that permission needs to be tied to a site identity so that they're not available to anyone who MITMs your site. Consider that if your site has any kind of form, even the simplest of forms, users may use autofill with it, which puts them at risk if your site is plaintext. Consider that even if your site is 100% static, it could have ads or other JavaScript injected into it. Consider that what's "non-controversial" for you may not be non-controversial to everyone browsing your site; you're encrypting for their benefit, not just for yours. Consider that it's much easier to keep users secure when browsers mark http as explicitly insecure rather than just omitting security icons. We should absolutely make HTTPS even simpler and easier, so that security becomes the zero-effort default. And we should continue to deprecate HTTP. As a related aside, I do think there are some specific cases that haven't yet been well-handled by HTTPS. In particular, there isn't yet a great solution for routers and embedded devices, which need an identity but don't have a domain name for that identity.

tw04 5y ago

So let's say your site is popular. What exactly is preventing a bad actor from MITM your site and spreading malware at a coffee shop or insert open public wifi? HTTPS isn't just about securing the information, it ensures that when someone tries to get to your site, they ACTUALLY get to your site.

dvfjsdhgfv 5y ago
There are many assumptions here. Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so. In any case, using HTTPS is indeed helpful in a hostile network when combined with HSTS, but if you have already connected to a network controlled by an attacker, this means they can not only sniff all your traffic, but already control your DNS and can easily find multiple ways to deliver the payload to you.
- kelnos 5y ago
  > Personally I don't even remember when I connected to an open wifi, I believe some systems will prevent you from doing so. If that's the case, you are absolutely not the average internet user. Plenty of people, most of them non-technical, will connect to the wifi of their local cafe, and spend many tens of minutes doing things on the internet while connected to it.
merb 5y ago
you can publish a sha256 hash for every site/resource. (just kidding of course)
- randomhodler84 5y ago
  No kid, SRI : Sub Resource Integrity is exactly this and an important way to secure CDN hosted js you are using on your site, however if the channel itself has no integrity protection, like HTTP does not (but https does via TLS), an attacker can dynamically replace SRI values with their malicious equivalents. So, both?

jorl17 5y ago

Most people have already answered you. The problem is anyone in the middle can hijack the page and put whatever they want there. See what I mentioned here in the past: https://news.ycombinator.com/item?id=25123366 https://news.ycombinator.com/item?id=25123366 Now imagine you combine MITM-ing someone with social engineering. You send them a legitimate inocuous link like http://my-bank.my-tld http://my-bank.my-tld, but you are MITM-ing them and outright replace the content of the page with whatever you want. Yes, HSTS protects agains this example, but the problem still remains: whatever goes through HTTP can be manipulated and used for nefarious ends. It's kinda like walking around with a car door open waiting for someone to throw a bomb inside it.

gsich 5y ago

>But I'm still unconvinced that every single one of those last remaining 15% of websites must be transitioned to HTTPS. I use HTTPS. That said, if someone doesn't want to do it - also a valid choice. The arguments have been made (content manipulation, snooping ...) but if I as a site owner don't care about someone elses shitty ISP, then I can use HTTP only.

contrary3332 5y ago

Yes, that 15% includes my personal site. But let's be real, Apple, Google and Microsoft provide the money funding the browsers 95% of people use. So I think we can predict where this will end up.

greggman3 5y ago

first off, let me say, for me. I use Caddy (https://caddyserver.com/ https://caddyserver.com/) and it just works. You start it, it gets a cert from letsencrypt and starts serving https. So it was (almost) zero work to serve with https. As for reasons to encrypt 1. Prevents (I think) ISPs in the middle from injecting ads, spyware, phishing scams, etc on top of your site. 2. Prevents 3rd parties from seeing what pages the user is accessing. Some people would prefer that other's can not read over their shoulder and see what they're reading. I know for me, I'm sensitive to that particular issue to the point that I don't really want to use Netflix, Amazon Prime, Spotify, etc. I really don't like the idea that they're building a profile of me based on what I watch and thinking they know who I am based on that. It could be as simple as I don't want it known if I'm reading liberal or conservative blogs. I'm sure others might have other reasons they don't want a 3rd party to know what specific pages they're reading. --- ps: I get there are other ways to track me but I'm fairly confident that I'm avoiding most of them via HTTPS, VPNs, Private browser windows, multiple profiles, 3rd party cookies off, ad blockers, etc....

EveYoung 5y ago
If privacy is a concern, users should also consider switching to an independent DoS/DoT DNS provider.

riffic 5y ago

ISPs can inject content into HTTP pages. This alone is a reason to move to HTTPS across the board.