7 ms·

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-i

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/
upofadown 5y ago
>HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. If you are in a legal/political environment that allows active attacks by an ISP on their customers then you have a much bigger problem than just this sort of thing.
- xahrepap 5y ago
  Comcast in the US has injected content into non-secured pages to notify customers of things. That is a horrible business practice that should not be allowed. What can I, an individual with nearly zero political clout (I can vote... but I live in a gerrymandered district... another layer to the problem!) do to get this problem fixed? Best case scenario, I say something, it goes viral, people march in protest against bad ISPs, the monopolies get broken up, etc. But how long does that all take? Meanwhile, I'll only use HTTPS websites as a first-line of defense. The "much bigger problem" can be solved in parallel.
- gsich 5y ago
  "you" and clients connecting to your server might be different entities.
- joshuajill 5y ago
  "It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser." https://www.internetsociety.org/resources/deploy360/dane/ https://www.internetsociety.org/resources/deploy360/dane/ Isn't it then possible, albeit harder to do a MITM attack at this point with HTTPS?
  - tialaramex 5y ago
    If you've decided that you trust the "firewall or other device", perhaps because you purchased it, or because doing so is a condition of employment, then you get to keep both halves. If the "firewall or other device" tries to interpose when you don't trust it, that won't work, for the same reason it doesn't work for bad guys. We do not distinguish the apparent reason for attempts to destroy the confidentiality, integrity or authenticity promises in TLS, whatever the apparent motive your HTTP transaction will either work, delivering those promises or you get an error and no progress is made.
schoen 5y ago
> 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. 1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.) > 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: I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all. I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)
yjftsjthsd-h 5y ago
A fair question deserving a real answer, rather than downvotes. It gets downvoted because this idea ("my site isn't sensitive so I don't want https") gets brought up and refuted every time LE or HTTPS comes up and it's getting old.
Koenvh 5y ago
This is a good comment. There are I believe a couple more cases where HTTPS is difficult: - You use a dynamic subsubdomain scheme. E.g. abc.xyz.example.org. A wildcard certificate for *.example.org only covers xyz.example.org, not abc.xyz.example.org. Requesting a certificate as the page is requested is possible, but will cause a lot of latency, and you will probably hit the Let's Encrypt rate limit; - You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons; - You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network. These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.
- MaxBarraclough 5y ago
  I see HackerNews chewed up your formatting. An extra newline between bullet-points is necessary. > You use a dynamic subsubdomain scheme Good point. If you run a site that creates a new subdomain per customer, and uses subsubdomains, you might end up making a high volume of cert requests. I don't know a lot about this stuff but presumably there are paid CAs that offer a more generous rate limit than Let's Encrypt? > You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons When is this a problem? > You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network I don't follow here. If for some reason you need to present that data as a local HTTP service, that service could just act as a proxy to GitLab Pages over HTTPS, no?
NikolaNovak 5y ago
Thanks; #1 is the most persuasive argument for the type of site I'm envisioning (and likely massive part of "remaining 15%"). While a lot of other arguments in comments are not persuasive because they don't seem a feasible or relevant threat vector, a non-specific, generic injection of ads/malware makes more sense as a legitimate threat vector such a site could get caught in.

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/

upofadown 5y ago

>HTTPS prevents ads/trackers/malware being injected into the page by unscrupulous ISPs. If you are in a legal/political environment that allows active attacks by an ISP on their customers then you have a much bigger problem than just this sort of thing.

xahrepap 5y ago
Comcast in the US has injected content into non-secured pages to notify customers of things. That is a horrible business practice that should not be allowed. What can I, an individual with nearly zero political clout (I can vote... but I live in a gerrymandered district... another layer to the problem!) do to get this problem fixed? Best case scenario, I say something, it goes viral, people march in protest against bad ISPs, the monopolies get broken up, etc. But how long does that all take? Meanwhile, I'll only use HTTPS websites as a first-line of defense. The "much bigger problem" can be solved in parallel.
gsich 5y ago
"you" and clients connecting to your server might be different entities.
joshuajill 5y ago
"It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser." https://www.internetsociety.org/resources/deploy360/dane/ https://www.internetsociety.org/resources/deploy360/dane/ Isn't it then possible, albeit harder to do a MITM attack at this point with HTTPS?
- tialaramex 5y ago
  If you've decided that you trust the "firewall or other device", perhaps because you purchased it, or because doing so is a condition of employment, then you get to keep both halves. If the "firewall or other device" tries to interpose when you don't trust it, that won't work, for the same reason it doesn't work for bad guys. We do not distinguish the apparent reason for attempts to destroy the confidentiality, integrity or authenticity promises in TLS, whatever the apparent motive your HTTP transaction will either work, delivering those promises or you get an error and no progress is made.

schoen 5y ago

> 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. 1a. Spy agencies or botnets that have compromised routers and want to attack Internet users. (The spy agencies are probably more of a concern for backbone routers, while the botnets are probably more of a concern for CPE routers.) > 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: I've encountered, I guess, five others: you want to use the server in a mostly or totally offline environment (so it can't count on getting Internet access to perform renewals), you want to use a totally air-gapped environment, you don't possess a domain name or can't be sure of renewing it for some reason, you want to use web protocols for a very lightweight (but not necessarily very old) embedded system in a LAN, or you are subject to sanctions that prevent CAs from charging you for a certificate and/or issuing one to you at all. I guess also "for some reason you want to use TCP/IP on a point-to-point link to collect telemetry where very low latency is your absolute highest priority, and integrity and/or confidentiality are handled sufficiently by some other layer somehow". (Although in that case the client probably isn't a web browser, so this probably isn't an issue.)

yjftsjthsd-h 5y ago

A fair question deserving a real answer, rather than downvotes. It gets downvoted because this idea ("my site isn't sensitive so I don't want https") gets brought up and refuted every time LE or HTTPS comes up and it's getting old.

Koenvh 5y ago

This is a good comment. There are I believe a couple more cases where HTTPS is difficult: - You use a dynamic subsubdomain scheme. E.g. abc.xyz.example.org. A wildcard certificate for *.example.org only covers xyz.example.org, not abc.xyz.example.org. Requesting a certificate as the page is requested is possible, but will cause a lot of latency, and you will probably hit the Let's Encrypt rate limit; - You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons; - You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network. These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.

MaxBarraclough 5y ago
I see HackerNews chewed up your formatting. An extra newline between bullet-points is necessary. > You use a dynamic subsubdomain scheme Good point. If you run a site that creates a new subdomain per customer, and uses subsubdomains, you might end up making a high volume of cert requests. I don't know a lot about this stuff but presumably there are paid CAs that offer a more generous rate limit than Let's Encrypt? > You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons When is this a problem? > You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network I don't follow here. If for some reason you need to present that data as a local HTTP service, that service could just act as a proxy to GitLab Pages over HTTPS, no?

NikolaNovak 5y ago

Thanks; #1 is the most persuasive argument for the type of site I'm envisioning (and likely massive part of "remaining 15%"). While a lot of other arguments in comments are not persuasive because they don't seem a feasible or relevant threat vector, a non-specific, generic injection of ads/malware makes more sense as a legitimate threat vector such a site could get caught in.