9 ms·

Consider disabling HTTPS auto redirects

26 points by bradley_taunt 4y ago

batch12 4y ago
So the argument is https has too much overhead and excludes those who cant use updated browsers? Unless I missed it, the article doesn't discuss mitm, nonrepudiation or censorship/privacy concerns.
- w-j-w 4y ago
  I also do not understand which users anywhere using the internet wouldn't have access to an https capable browser?
- nix23 4y ago
  If you want to update/browse with Windows2000 i don't think privacy/security are a concern.
  - josephcsible 4y ago
    If you want to update/browse with Windows 2000, then you should set up a local TLS terminating proxy for it, rather than asking the rest of the world to decrease their security for you.
    - nix23 4y ago
      >rather than asking the rest of the world to decrease their security for you. Or just let your browser decide that for you? All modern browser go directly https, until forced to http, why take away what i decided (server-side)?
- dizhn 4y ago
  It gives a few examples of use cases where protection against these are not necessary. This is one of my pet peeves too and I agree with the author. Though if you want google to list and rank you, you have to have it. (This might have changed. Google doesn't do anything for long.) As a side effect of the push for https, local web log analysis is basically worthless nowadays. This might be why google pushed it so heavily.
davewritescode 4y ago
One thing that these types of articles always miss is that HTTPs isn't just there to protect user data being submitted to your website. It's also there to make sure that the data you're looking at wasn't modified by a 3rd party without your consent. The fact that someone technical has missed it this is a really good argument for redirecting users from HTTP to HTTPS.
- deleted 4y ago
  [deleted]
jenny91 4y ago
Confidentiality should be on by default: not just when you enter your credit card details.
josephcsible 4y ago
This is really misleading and potentially dangerous. Details: * Even on static sites, HTTPS prevents a MITM from telling what pages you're reading, or introducing falsehoods into the content. It's not "overuse" to use HTTPS there. * I don't know how the author's server is set up, but a 1-second increase in page load time isn't consistent with load times I've ever measured anywhere else. In fact, there's a lot of HTTPS pages where the total load time is less than what's claimed as the difference here. * If you care about sustainable technology, you should be demanding that Apple provide updates for hardware longer, or open-source everything so that the community can. Whether or not the sites you want to visit use HTTPS, using the Internet from a system years behind on security patches is a really bad idea, and not something you should optimize for. * The specific suggestion of disabling the redirect is exactly equivalent to a MITM attacker running sslstrip, so you're doing a big piece of the bad guy's job for him.
- nix23 4y ago
  I don't know why your browser cannot redirect to https and the web-server has to do it.
  - JoshTriplett 4y ago
    Your browser can redirect to HTTPS, if you use HSTS preloading. Also, at this point I think we have sufficiently pervasive availability of HTTPS that it'd be reasonable for browsers to expand typed domains (if the user types `example.org`) to use https:// https:// rather than http:// http:// , unless they're an IP address or localhost.
    - remram 4y ago
      HSTS preloading requires that you have the redirection on your site though, as per "Submission Requirements" on https://hstspreload.org/ https://hstspreload.org/
      - JoshTriplett 4y ago
        Which is one of many good reasons why you should have that redirection enabled. Or disable HTTP entirely (the HSTS requirements say "if you are listening on port 80").
SquareWheel 4y ago
Not a compelling argument in the least. MITM still means ISPs can track and inject ads, regardless of how static the content is on your website. And the performance argument is completely invalid because it's only measuring total bytes, and doesn't consider HTTP/2 multiplexing. > It should be mentioned that my personal website is also plain text based and tiny. Imagine the impact of a blog article or research paper with significantly more content. The larger the website, the greater the improvement from using HTTP/2 (which requires TLS). And it doesn't take much data at all to offset that TLS lookup. This post is justifying bad behavior. The only sites that can afford to remain http are neverssl.com and local development.
- soruly 4y ago
  even for local development, I tend to serve the HTTP server with nginx for adding HTTPS. Because many of the web APIs, like service worker, clipboard APIs, are only available in HTTPS context.
  - JamesSwift 4y ago
    Unfortunately mobile apps complain a ton about 'insecure' https, and make it a real chore to do local certs. So its usually easier to just run over http locally when doing mobile dev.
babypuncher 4y ago
That is a pretty weak argument for why we should sacrifice privacy. We should continue moving in the opposite direction. Ideally, within 5 years, browsers should send up warning flags whenever the user hits a website that doesn't use HTTPS. They had to go back 20 years to find a browser that does not support TLS. Software that old is going to have other fundamental problems accessing the modern web. The amount of work necessary to make every website actually work on a browser that old is far, far greater than just supporting HTTP.
tarasglek 4y ago
There are a lot of ISPs, even consumer wifi gateways that mess with unencrypted traffic. HTTPS is the only way to ensure that the data served is what the user received.
- orphea 4y ago
  This. This is so mind-blowing that in 2022 people, I presume knowledgeable engineers, don't care about their privacy and security, and willingly suggest to let ISPs and whatnot inject ads and even miners sometimes [0]. [0]: https://medium.com/@mxschmitt/crypto-miner-injection-on-internet-routing-hops-of-my-isp-b8f9ad54ed21 https://medium.com/@mxschmitt/crypto-miner-injection-on-inte...
JoshTriplett 4y ago
> Let’s take an example of the Powerbook G4, which was released in 2002. > So why force users to toss away perfectly viable devices If it can't do secure connections, it's not a perfectly viable device.
theandrewbailey 4y ago
> By using HTTPS my website increases it’s overhead by almost 100%. It should be mentioned that my personal website is also plain text based and tiny. Imagine the impact of a blog article or research paper with significantly more content. An extra kilobyte. Wow. Such data transfer. What a dealbreaker. No HTTPS means worse performance, because HTTP 2.0 requires it. HTTP 1.x doesn't have connection multiplexing. When I moved my blog to HTTP 2.0, I noticed that it loaded faster, even when on the same LAN as the server. > Helpful Tips: > If users are nervous of links set in standard http:// http:// format, they can add s themselves or better yet, use a browser extension like HTTPS Everywhere (highly recommend) HTTPS Everywhere won't be supported beyond 2022: https://www.eff.org/deeplinks/2021/09/https-actually-everywhere https://www.eff.org/deeplinks/2021/09/https-actually-everywh...
- SahAssar 4y ago
  A bit nitpicky but: > No HTTPS means worse performance, because HTTP 2.0 requires it HTTP 2.0 actually does not require it, the spec allows for it over unencrypted connections. All browsers have decided to only enable it over TLS connections though.
elverado 4y ago
Most modern browsers display a danger warning icon on classic HTTP addresses? Or am I mistaken?
- josephcsible 4y ago
  You're not mistaken. Try http://http-login.badssl.com/ http://http-login.badssl.com/ to see it for yourself.
  - noodlesUK 4y ago
    Wow! Safari on iOS doesn’t throw any warning. That’s deeply surprising and kinda terrible…
strogonoff 4y ago
Plain HTTP is synonymous with trust. In an ideal world where no one would snoop or mangle responses, it should be enough. In our still-imperfect world with potential MITM attacks, sometimes that trust is not warranted. However, one still should be able to choose to trust own connection. I don’t want this choice to be made for me with no way to appeal.
- Sohcahtoa82 4y ago
  It's not just your own connection, it's every device your packets flow through. And if you use Comcast/Xfinity, then your own connection can't be trusted. They've been caught injecting messages in plaintext HTTP web pages.
  - strogonoff 4y ago
    I may use a self-provisioned VPN, but actually this doesn’t matter. The point is that the user has no choice, regardless of circumstances. As an example (although it’s whataboutism), the option of using insecure SMS 2FA is routinely offered in much more sensitive contexts compared to the option of using plain HTTP to read static text content—yet the former is considered acceptable but the latter isn’t.
remram 4y ago
Using HTTPS by default has obvious security benefits, but it's not clear we need a redirect to implement it. We could have leveraged the Alt-Svc header for this instead, which is meant specifically for this. This would allow modern browsers to use HTTPS without preventing older browsers which want to use HTTP from doing so (at their own risks).
- jaywalk 4y ago
  There is plenty more than HTTPS that prevents older browsers from using many websites.
- Ajedi32 4y ago
  You can already implement this using the Upgrade-Insecure-Requests header[1]. Servers just need to check for that header and only send an HTTPS redirect if it's included. All major browsers already send that header except Internet Explorer so the security impact of such a check would be pretty minimal. The only argument I can see against it is that it's insecure-by-default, but you could theoretically fix that by allowing clients to send `Upgrade-Insecure-Requests: 0` to explicitly indicate that they don't want to be redirected. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Up...
  - remram 4y ago
    Ah, even better! Thanks for this, I might add it to my web services.
toast0 4y ago
One way to manage this is to use HSTS to send modern browsers to https and leave older browsers to whatever they want. a) put your content on www.example.com because it's important b) redirect http://example.com http://example.com to https://example.com https://example.com because this is required for HSTS preloading. And from there to https://www.example.com https://www.example.com because it's important that your contentful urls be at a domain that isn't going to redirect. c) serve hsts preload headers at least for https://example.com https://example.com; serve hsts headers for at least https://example.com/favicon.ico https://example.com/favicon.ico d) set your favicon on all pages to https://example.com/favicon.ico https://example.com/favicon.ico e) submit to the hsts preloading site f) remove redirects from http to https on www Modern browsers with preload built after your site is added would always use https. Modern browsers without the preload will load whatever the first page they hit as http, but pickup the preload from the favicon and future page loads will be https. Resources from the first load will likely be http, depending on favicon loading timing. There's no additional MITM risk for modern browsers, because a MITM could avoid your redirect if an http load is attempted just as well as they could mess with your HTML. Older browsers can still go to the http version, although inbound links are likely to be https, because people like to cut and paste from the URL bar, and most people are going to have a modern browser with your site preloaded. Users of older browsers would need to edit the url in the URL bar, a skill they'd likely rapidly develop.
bugmen0t 4y ago
Pervasive traffic monitoring is an attack and it is an attack being carried out in massive scale. I believe HTTPS is the most meaningful and available method out there to stop this attack. If your website does not support using HTTPS you are an accomplice in pervasive monitoring.
noodlesUK 4y ago
I pretty much wholeheartedly disagree with this. HTTPS provides confidentiality, but it also provides integrity, which is arguably much more important for many cases. If you’re browsing around on an older (perhaps unpatched) machine, a plaintext HTTP website can easily have malware embedded in it by another person on the wifi network (with ARP spoofing or whatever). It can also have incorrect links (see sslstrip) that impersonate other websites. It used to be that a major UK bank didn’t use HTTPS for their homepage, only for their online banking application. You would probably think this is fine, but it’s trivially easy to replace the link to said online banking application with one that MITMs you. Requiring HTTPS also provides another benefit, which is that it stops downgrade attacks. If your site is available in plaintext, I can just block access to the secure version in order to do my nefarious business. The internet is a nasty place these days.
jillesvangurp 4y ago
I think there are few excuses left for not having https on your website. Having the option of having an http only variant of your website should likewise not be a thing. A redirect is better than a not found error. IMHO those are the two valid responses for a public http website (go away, or go here instead). As for "updated browsers", anything that doesn't support https (or redirects) in 2022 is not fit for use on the modern internet. Most of the web would in any case be unusable with such a browser already. And essentially everything that shipped in the last 20 years or so would be able to deal with this (with the exception of handling newer TLS versions perhaps). You'd be well advised to not use a browser that hasn't been updated for that long. If somehow you are using such a browser (why?!), you might want to fix that ASAP. Meanwhile, I'll blindly assume the intersection of those users and this audience (hacker news) is extremely small to non existent. If that intersection exists at all, it's probably for some esoteric reasons that have nothing to do with an inability to fix the actual problem (like fixing your browser setup) and is by choice rather than by circumstances. Either way, your problem to solve and not something to waste energy on for website maintainers looking to do the right thing.
maerF0x0 4y ago
IMO it's better to close port 80 entirely because many clients will end up sending unencrypted headers and rely on the redirect, not realizing they've exposed themselves. ===> HTTP GET /your_api Host: passwordleaker.com Authorization: Bearer 12312312321 <=== HTTP/1.0 302 Found Location: https://passwordleaker.com/your_api (but note it's too late)
- SahAssar 4y ago
  What client are you using that sends Authorization on domains that are not configured (since then you would configure them to use https)? Also, if you are MITM:ed the MITM could still have port 80 open, so you don't actually protect against anything, right?
  - maerF0x0 4y ago
    Closing 80 protects against a Mallory that has readonly access to the network between Alice and Bob. Also afaik most http request libraries in many languages would not have such a guard? eg: this code sample in go produces the raw header when I listen with nc https://go.dev/play/p/s1CaOVcGcxS https://go.dev/play/p/s1CaOVcGcxS nc -l 8080 GET / HTTP/1.1 Host: localhost:8080 User-Agent: Go-http-client/1.1 Authorization: Bearer 123123 Accept-Encoding: gzip
    - SahAssar 4y ago
      Yes, because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right?
      - maerF0x0 4y ago
        That's my whole point though. If you build an API but then its up to customers to integrate with you, you can help them avoid one of many pitfalls by not allowing them to do a dumb thing like send private headers over unencrypted channel >because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right? The "you"s in your sentence are actually 2 different actors the one doing configuring is often a not technically excellent client, the "you" who has a domain is the API creator, who can also help out the client by closing 80 or refusing non-TLS traffic on 80.
dingosity 4y ago
meh. the reason i like HTTPS is it makes it difficult for unscrupulous ISPs to insert ads and code into my pages. and yeah. bad guys inserting nefarious cookies as well. it's great the poster hasn't had to deal with such problems, and they're certainly not universal. but they're common enough to just do HTTPS and not worry about it. also... https is adding half a second to load times? pretty sure this is what QUIC and HTTP/3 were designed for. or move your content to akamai or cloudfront or cloudflare or whatever CDN you're comfortable with.
sebazzz 4y ago
Say what you will, but HTTPS did kill http compression.
- theandrewbailey 4y ago
  What are you talking about? Every web server will both compress and encrypt responses when using HTTPS.
  - sebazzz 4y ago
    For static content perhaps, otherwise look up CRIME.
freitasm 4y ago
Article suggests to use Httpseverywhere but it is being deprecated https://www.eff.org/deeplinks/2021/09/https-actually-everywhere https://www.eff.org/deeplinks/2021/09/https-actually-everywh...
sshine 4y ago
> increases it’s overhead by almost 100%. 3.8/2.9 kB is a 31% increase. 1.16/0.62 s is an 87% increase. But okay, let's round up to 100%. The article is citing a page that counter-argues this: > Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2. > https://istlsfastyet.com/ https://istlsfastyet.com/ --- > But what about sites like https://doesmysiteneedhttps.com https://doesmysiteneedhttps.com? While this website makes a few valid points, it still relies heavily on “fear tactics” that honestly don’t apply for the vast majority of users. It’s overkill. Sorry, but not good enough. 1. "a few valid points": you avoid making your visitors liable in oppressive environments (employers, regimes), you avoid very real content injection (commercial or malicious), and you give the visitor a way to know that content wasn't tampered. That's a few valid points. (The rest are counter-arguments.) 2. "fear tactics": not true. Protecting the integrity of your visitors and your content is nurture, not fear. 3. "don’t apply for the vast majority of users": by making HTTPS standard at practically no cost, you make it work for those for whom it matters. Just because I feel safe on Hacker News doesn't mean that any visitor who goes here will be treated fairly by reading my message.

26 points by bradley_taunt 4y ago

So the argument is https has too much overhead and excludes those who cant use updated browsers? Unless I missed it, the article doesn't discuss mitm, nonrepudiation or censorship/privacy concerns.

w-j-w 4y ago
I also do not understand which users anywhere using the internet wouldn't have access to an https capable browser?
nix23 4y ago
If you want to update/browse with Windows2000 i don't think privacy/security are a concern.
- josephcsible 4y ago
  If you want to update/browse with Windows 2000, then you should set up a local TLS terminating proxy for it, rather than asking the rest of the world to decrease their security for you.
  - nix23 4y ago
    >rather than asking the rest of the world to decrease their security for you. Or just let your browser decide that for you? All modern browser go directly https, until forced to http, why take away what i decided (server-side)?
dizhn 4y ago
It gives a few examples of use cases where protection against these are not necessary. This is one of my pet peeves too and I agree with the author. Though if you want google to list and rank you, you have to have it. (This might have changed. Google doesn't do anything for long.) As a side effect of the push for https, local web log analysis is basically worthless nowadays. This might be why google pushed it so heavily.

davewritescode 4y ago

One thing that these types of articles always miss is that HTTPs isn't just there to protect user data being submitted to your website. It's also there to make sure that the data you're looking at wasn't modified by a 3rd party without your consent. The fact that someone technical has missed it this is a really good argument for redirecting users from HTTP to HTTPS.

deleted 4y ago
[deleted]

jenny91 4y ago

Confidentiality should be on by default: not just when you enter your credit card details.

josephcsible 4y ago

This is really misleading and potentially dangerous. Details: * Even on static sites, HTTPS prevents a MITM from telling what pages you're reading, or introducing falsehoods into the content. It's not "overuse" to use HTTPS there. * I don't know how the author's server is set up, but a 1-second increase in page load time isn't consistent with load times I've ever measured anywhere else. In fact, there's a lot of HTTPS pages where the total load time is less than what's claimed as the difference here. * If you care about sustainable technology, you should be demanding that Apple provide updates for hardware longer, or open-source everything so that the community can. Whether or not the sites you want to visit use HTTPS, using the Internet from a system years behind on security patches is a really bad idea, and not something you should optimize for. * The specific suggestion of disabling the redirect is exactly equivalent to a MITM attacker running sslstrip, so you're doing a big piece of the bad guy's job for him.

nix23 4y ago
I don't know why your browser cannot redirect to https and the web-server has to do it.
- JoshTriplett 4y ago
  Your browser can redirect to HTTPS, if you use HSTS preloading. Also, at this point I think we have sufficiently pervasive availability of HTTPS that it'd be reasonable for browsers to expand typed domains (if the user types `example.org`) to use https:// https:// rather than http:// http:// , unless they're an IP address or localhost.
  - remram 4y ago
    HSTS preloading requires that you have the redirection on your site though, as per "Submission Requirements" on https://hstspreload.org/ https://hstspreload.org/
    - JoshTriplett 4y ago
      Which is one of many good reasons why you should have that redirection enabled. Or disable HTTP entirely (the HSTS requirements say "if you are listening on port 80").

SquareWheel 4y ago

Not a compelling argument in the least. MITM still means ISPs can track and inject ads, regardless of how static the content is on your website. And the performance argument is completely invalid because it's only measuring total bytes, and doesn't consider HTTP/2 multiplexing. > It should be mentioned that my personal website is also plain text based and tiny. Imagine the impact of a blog article or research paper with significantly more content. The larger the website, the greater the improvement from using HTTP/2 (which requires TLS). And it doesn't take much data at all to offset that TLS lookup. This post is justifying bad behavior. The only sites that can afford to remain http are neverssl.com and local development.

soruly 4y ago
even for local development, I tend to serve the HTTP server with nginx for adding HTTPS. Because many of the web APIs, like service worker, clipboard APIs, are only available in HTTPS context.
- JamesSwift 4y ago
  Unfortunately mobile apps complain a ton about 'insecure' https, and make it a real chore to do local certs. So its usually easier to just run over http locally when doing mobile dev.

babypuncher 4y ago

That is a pretty weak argument for why we should sacrifice privacy. We should continue moving in the opposite direction. Ideally, within 5 years, browsers should send up warning flags whenever the user hits a website that doesn't use HTTPS. They had to go back 20 years to find a browser that does not support TLS. Software that old is going to have other fundamental problems accessing the modern web. The amount of work necessary to make every website actually work on a browser that old is far, far greater than just supporting HTTP.

tarasglek 4y ago

There are a lot of ISPs, even consumer wifi gateways that mess with unencrypted traffic. HTTPS is the only way to ensure that the data served is what the user received.

orphea 4y ago
This. This is so mind-blowing that in 2022 people, I presume knowledgeable engineers, don't care about their privacy and security, and willingly suggest to let ISPs and whatnot inject ads and even miners sometimes [0]. [0]: https://medium.com/@mxschmitt/crypto-miner-injection-on-internet-routing-hops-of-my-isp-b8f9ad54ed21 https://medium.com/@mxschmitt/crypto-miner-injection-on-inte...

JoshTriplett 4y ago

> Let’s take an example of the Powerbook G4, which was released in 2002. > So why force users to toss away perfectly viable devices If it can't do secure connections, it's not a perfectly viable device.

theandrewbailey 4y ago

> By using HTTPS my website increases it’s overhead by almost 100%. It should be mentioned that my personal website is also plain text based and tiny. Imagine the impact of a blog article or research paper with significantly more content. An extra kilobyte. Wow. Such data transfer. What a dealbreaker. No HTTPS means worse performance, because HTTP 2.0 requires it. HTTP 1.x doesn't have connection multiplexing. When I moved my blog to HTTP 2.0, I noticed that it loaded faster, even when on the same LAN as the server. > Helpful Tips: > If users are nervous of links set in standard http:// http:// format, they can add s themselves or better yet, use a browser extension like HTTPS Everywhere (highly recommend) HTTPS Everywhere won't be supported beyond 2022: https://www.eff.org/deeplinks/2021/09/https-actually-everywhere https://www.eff.org/deeplinks/2021/09/https-actually-everywh...

SahAssar 4y ago
A bit nitpicky but: > No HTTPS means worse performance, because HTTP 2.0 requires it HTTP 2.0 actually does not require it, the spec allows for it over unencrypted connections. All browsers have decided to only enable it over TLS connections though.

elverado 4y ago

Most modern browsers display a danger warning icon on classic HTTP addresses? Or am I mistaken?

josephcsible 4y ago
You're not mistaken. Try http://http-login.badssl.com/ http://http-login.badssl.com/ to see it for yourself.
- noodlesUK 4y ago
  Wow! Safari on iOS doesn’t throw any warning. That’s deeply surprising and kinda terrible…

strogonoff 4y ago

Plain HTTP is synonymous with trust. In an ideal world where no one would snoop or mangle responses, it should be enough. In our still-imperfect world with potential MITM attacks, sometimes that trust is not warranted. However, one still should be able to choose to trust own connection. I don’t want this choice to be made for me with no way to appeal.

Sohcahtoa82 4y ago
It's not just your own connection, it's every device your packets flow through. And if you use Comcast/Xfinity, then your own connection can't be trusted. They've been caught injecting messages in plaintext HTTP web pages.
- strogonoff 4y ago
  I may use a self-provisioned VPN, but actually this doesn’t matter. The point is that the user has no choice, regardless of circumstances. As an example (although it’s whataboutism), the option of using insecure SMS 2FA is routinely offered in much more sensitive contexts compared to the option of using plain HTTP to read static text content—yet the former is considered acceptable but the latter isn’t.

remram 4y ago

Using HTTPS by default has obvious security benefits, but it's not clear we need a redirect to implement it. We could have leveraged the Alt-Svc header for this instead, which is meant specifically for this. This would allow modern browsers to use HTTPS without preventing older browsers which want to use HTTP from doing so (at their own risks).

jaywalk 4y ago
There is plenty more than HTTPS that prevents older browsers from using many websites.
Ajedi32 4y ago
You can already implement this using the Upgrade-Insecure-Requests header[1]. Servers just need to check for that header and only send an HTTPS redirect if it's included. All major browsers already send that header except Internet Explorer so the security impact of such a check would be pretty minimal. The only argument I can see against it is that it's insecure-by-default, but you could theoretically fix that by allowing clients to send `Upgrade-Insecure-Requests: 0` to explicitly indicate that they don't want to be redirected. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Up...
- remram 4y ago
  Ah, even better! Thanks for this, I might add it to my web services.

toast0 4y ago

One way to manage this is to use HSTS to send modern browsers to https and leave older browsers to whatever they want. a) put your content on www.example.com because it's important b) redirect http://example.com http://example.com to https://example.com https://example.com because this is required for HSTS preloading. And from there to https://www.example.com https://www.example.com because it's important that your contentful urls be at a domain that isn't going to redirect. c) serve hsts preload headers at least for https://example.com https://example.com; serve hsts headers for at least https://example.com/favicon.ico https://example.com/favicon.ico d) set your favicon on all pages to https://example.com/favicon.ico https://example.com/favicon.ico e) submit to the hsts preloading site f) remove redirects from http to https on www Modern browsers with preload built after your site is added would always use https. Modern browsers without the preload will load whatever the first page they hit as http, but pickup the preload from the favicon and future page loads will be https. Resources from the first load will likely be http, depending on favicon loading timing. There's no additional MITM risk for modern browsers, because a MITM could avoid your redirect if an http load is attempted just as well as they could mess with your HTML. Older browsers can still go to the http version, although inbound links are likely to be https, because people like to cut and paste from the URL bar, and most people are going to have a modern browser with your site preloaded. Users of older browsers would need to edit the url in the URL bar, a skill they'd likely rapidly develop.

bugmen0t 4y ago

Pervasive traffic monitoring is an attack and it is an attack being carried out in massive scale. I believe HTTPS is the most meaningful and available method out there to stop this attack. If your website does not support using HTTPS you are an accomplice in pervasive monitoring.

noodlesUK 4y ago

I pretty much wholeheartedly disagree with this. HTTPS provides confidentiality, but it also provides integrity, which is arguably much more important for many cases. If you’re browsing around on an older (perhaps unpatched) machine, a plaintext HTTP website can easily have malware embedded in it by another person on the wifi network (with ARP spoofing or whatever). It can also have incorrect links (see sslstrip) that impersonate other websites. It used to be that a major UK bank didn’t use HTTPS for their homepage, only for their online banking application. You would probably think this is fine, but it’s trivially easy to replace the link to said online banking application with one that MITMs you. Requiring HTTPS also provides another benefit, which is that it stops downgrade attacks. If your site is available in plaintext, I can just block access to the secure version in order to do my nefarious business. The internet is a nasty place these days.

jillesvangurp 4y ago

I think there are few excuses left for not having https on your website. Having the option of having an http only variant of your website should likewise not be a thing. A redirect is better than a not found error. IMHO those are the two valid responses for a public http website (go away, or go here instead). As for "updated browsers", anything that doesn't support https (or redirects) in 2022 is not fit for use on the modern internet. Most of the web would in any case be unusable with such a browser already. And essentially everything that shipped in the last 20 years or so would be able to deal with this (with the exception of handling newer TLS versions perhaps). You'd be well advised to not use a browser that hasn't been updated for that long. If somehow you are using such a browser (why?!), you might want to fix that ASAP. Meanwhile, I'll blindly assume the intersection of those users and this audience (hacker news) is extremely small to non existent. If that intersection exists at all, it's probably for some esoteric reasons that have nothing to do with an inability to fix the actual problem (like fixing your browser setup) and is by choice rather than by circumstances. Either way, your problem to solve and not something to waste energy on for website maintainers looking to do the right thing.

maerF0x0 4y ago

IMO it's better to close port 80 entirely because many clients will end up sending unencrypted headers and rely on the redirect, not realizing they've exposed themselves. ===> HTTP GET /your_api Host: passwordleaker.com Authorization: Bearer 12312312321 <=== HTTP/1.0 302 Found Location: https://passwordleaker.com/your_api (but note it's too late)

SahAssar 4y ago
What client are you using that sends Authorization on domains that are not configured (since then you would configure them to use https)? Also, if you are MITM:ed the MITM could still have port 80 open, so you don't actually protect against anything, right?
- maerF0x0 4y ago
  Closing 80 protects against a Mallory that has readonly access to the network between Alice and Bob. Also afaik most http request libraries in many languages would not have such a guard? eg: this code sample in go produces the raw header when I listen with nc https://go.dev/play/p/s1CaOVcGcxS https://go.dev/play/p/s1CaOVcGcxS nc -l 8080 GET / HTTP/1.1 Host: localhost:8080 User-Agent: Go-http-client/1.1 Authorization: Bearer 123123 Accept-Encoding: gzip
  - SahAssar 4y ago
    Yes, because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right?
    - maerF0x0 4y ago
      That's my whole point though. If you build an API but then its up to customers to integrate with you, you can help them avoid one of many pitfalls by not allowing them to do a dumb thing like send private headers over unencrypted channel >because you configured it to go to http, not https. Usually if you have credentials to send you also have a domain configured for those credentials, and then you'd configure the correct address, right? The "you"s in your sentence are actually 2 different actors the one doing configuring is often a not technically excellent client, the "you" who has a domain is the API creator, who can also help out the client by closing 80 or refusing non-TLS traffic on 80.

dingosity 4y ago

meh. the reason i like HTTPS is it makes it difficult for unscrupulous ISPs to insert ads and code into my pages. and yeah. bad guys inserting nefarious cookies as well. it's great the poster hasn't had to deal with such problems, and they're certainly not universal. but they're common enough to just do HTTPS and not worry about it. also... https is adding half a second to load times? pretty sure this is what QUIC and HTTP/3 were designed for. or move your content to akamai or cloudfront or cloudflare or whatever CDN you're comfortable with.

sebazzz 4y ago

Say what you will, but HTTPS did kill http compression.

theandrewbailey 4y ago
What are you talking about? Every web server will both compress and encrypt responses when using HTTPS.
- sebazzz 4y ago
  For static content perhaps, otherwise look up CRIME.

freitasm 4y ago

Article suggests to use Httpseverywhere but it is being deprecated https://www.eff.org/deeplinks/2021/09/https-actually-everywhere https://www.eff.org/deeplinks/2021/09/https-actually-everywh...

sshine 4y ago

> increases it’s overhead by almost 100%. 3.8/2.9 kB is a 31% increase. 1.16/0.62 s is an 87% increase. But okay, let's round up to 100%. The article is citing a page that counter-argues this: > Sites with modern servers load faster over HTTPS than over HTTP because of HTTP/2. > https://istlsfastyet.com/ https://istlsfastyet.com/ --- > But what about sites like https://doesmysiteneedhttps.com https://doesmysiteneedhttps.com? While this website makes a few valid points, it still relies heavily on “fear tactics” that honestly don’t apply for the vast majority of users. It’s overkill. Sorry, but not good enough. 1. "a few valid points": you avoid making your visitors liable in oppressive environments (employers, regimes), you avoid very real content injection (commercial or malicious), and you give the visitor a way to know that content wasn't tampered. That's a few valid points. (The rest are counter-arguments.) 2. "fear tactics": not true. Protecting the integrity of your visitors and your content is nurture, not fear. 3. "don’t apply for the vast majority of users": by making HTTPS standard at practically no cost, you make it work for those for whom it matters. Just because I feel safe on Hacker News doesn't mean that any visitor who goes here will be treated fairly by reading my message.