5 ms·

My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get aroun

by sdsd 2y ago

My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get around to it eventually, but I find charm in small old sites that haven't implemented modern protocol stuff. My site also uses <font> and <center> tags all over the place. Maybe I'll do some more quirky anachronisms, like only serve the site via HTTP 1.0 or something. Who knows. Since my site has very little functionality, it doesn't really matter, it's just for fun.

layer8 2y ago
That’s fine, but rather unrelated to the article, which is about the situation that you have an API served via HTTPS, and the question of whether you should also have a redirect from HTTP to HTTPS in that case, or rather return an HTTP error.
- sdsd 2y ago
  Yeah, I should have clarified. Nothing to do with the article really, just a random thought. Sorry if too off-topic!
Aachen 2y ago
I can appreciate this and also run a service that is neither meant to be commonly visited (imagine a tor exit node landing page explaining what this IP address is doing, but for a different service) nor will produce or ingest sensitive information For a personal website that people might commonly want to visit, though, consider the second point made in this other comment: https://news.ycombinator.com/item?id=40505294 https://news.ycombinator.com/item?id=40505294 (someone else mentioned this in the thread slightly sooner than me but I don't see it anymore)
cqqxo4zV46cp 2y ago
A HTTP website presents an opportunity for an attacker to MITM a payload that is ultimately executed in a user’s browser. Beyond ‘getting a moustache tattoo on your finger’ quirkiness, HTTP-only websites are really inexcusable beyond some very niche cases.
- sdsd 2y ago
  >Beyond ‘getting a moustache tattoo on your finger’ quirkiness In that case, seems totally worth it. I, like moustache finger tattoos, am aggressively opposed to worrying about being perceived as cool. I will just have to live with being inexcusable.
- valec 2y ago
  not my problem!
HL33tibCe7 2y ago
To me, HTTPS is worth it alone to eliminate the possibility of the ISPs of people reading my site from injecting shit (ads, trackers, etc.) into the responses I send to them. It’s completely trivial to set up, there’s really no downside at this point.
- samatman 2y ago
  This is the somewhat depressing but accurate answer. HTTPS doesn't mean you are communicating sensitive or private data, it means you want the client to see what you send them, and not something else.
- averageRoyalty 2y ago
  To be fair, triviality is relevant to the tooling you run and there are many downsides - extra negotiation and traffic, unsupported on older clients without using up an IPv4 address, certificate expiry, etc. For most cases these are non issues, but there are many scenarios where those things can outweigh the potential of your ISP modifying/reading. If that's still a concern, you can tunnel through your ISP to a more trusted exit point.
OJFord 2y ago
When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Secure site not available Most likely, the web site simply does not support HTTPS. However, it’s also possible that an attacker is involved. If you continue to the web site, you should not enter any sensitive info. If you continue, HTTPS-Only mode will be turned off temporarily for the site. [Continue to HTTP site] (Copied from Firefox on Android) Personally I think that's reason to do it alone, for the price of a free Let's Encrypt cert you can deliver much better UX. You presumably want people to visit your site.
- sdsd 2y ago
  >When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing? >for the price of a free Let's Encrypt cert you can deliver much better UX I'm going to get around to it, I promise haha. Btw if anyone does visit the site, please do sign my guestbook: http://darigo.su/33chan http://darigo.su/33chan (but be warned, a MITM might intercept and alter your comment!!)
  - prettymuchnoone 2y ago
    > Neither desktop firefox nor chrome seem to do this by default they do, you probably just checked the "i'm sure this is safe" button posted a pic on the imageboard hehe
    - sdsd 2y ago
      Thanks for visiting! Receiving guestbook comments is such a delight. Does Chrome also give you this warning on desktop?
      - prettymuchnoone 2y ago
        nope
npsimons 2y ago
Honestly, for public facing read-only websites, it's perfectly fine to redirect HTTP to HTTPS. There's just too many cases where you aren't going to get everyone to put "https:// https://" on the front of URIs when they put them in docs, flyers, etc. You're lucky if you get "http:// http://"! The API security thing, yes, that makes sense. Personally, I run a number of servers for small groups where the sensitive stuff is SSL only - you won't even get an error going to port 80, other than the eventual timeout. But for reasons above, I cannot just turn port 80 off, and it's perfectly safe redirecting to 443.
bruce511 2y ago
I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Being HTTP allows it to be altered along the way. Gor example, and thd least serious, is that your ISP can inject adverts onto your page. Most ISPs don't do this, but quite a few do. Second, a malicious user could inject additional text onto upur pages, proclaiming your love for a political party, some racial or misogynistic slur, or whatever. Third, you're sending a signal to all that you either don't understand the security risks, or don't care about them. This can have consequences (reputationally) if you are in, or going into, a computing career. Making it HTTPS can be fun too!
- foobiekr 2y ago
  The bigger issue is that a malicious interceptor could inject javascript. The site may not use javascript, but the users almost certainly have it turned on, and accessing a non-https site means that any man in the middle can inject malicious javascript. HTTPS is about protecting the client.
  - Thorrez 2y ago
    E.g. China's great firewall sometimes inserts malicious Javascript that causes the client to launch a DDoS attack against Github or other sites China doesn't like. https://en.wikipedia.org/wiki/Great_Cannon https://en.wikipedia.org/wiki/Great_Cannon
- noirscape 2y ago
  Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps; 1. Install and run certbot (+the DNS plugin for your DNS provider). 2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config. 3. Set up a generic redirect server block to send everything on port 80 to port 443. 4. Reboot nginx. It's at least better than fiddling with openssl directly, but this isn't fun, it's busywork.

by sdsd 2y ago

layer8 2y ago

That’s fine, but rather unrelated to the article, which is about the situation that you have an API served via HTTPS, and the question of whether you should also have a redirect from HTTP to HTTPS in that case, or rather return an HTTP error.

sdsd 2y ago
Yeah, I should have clarified. Nothing to do with the article really, just a random thought. Sorry if too off-topic!

Aachen 2y ago

I can appreciate this and also run a service that is neither meant to be commonly visited (imagine a tor exit node landing page explaining what this IP address is doing, but for a different service) nor will produce or ingest sensitive information For a personal website that people might commonly want to visit, though, consider the second point made in this other comment: https://news.ycombinator.com/item?id=40505294 https://news.ycombinator.com/item?id=40505294 (someone else mentioned this in the thread slightly sooner than me but I don't see it anymore)

cqqxo4zV46cp 2y ago

A HTTP website presents an opportunity for an attacker to MITM a payload that is ultimately executed in a user’s browser. Beyond ‘getting a moustache tattoo on your finger’ quirkiness, HTTP-only websites are really inexcusable beyond some very niche cases.

sdsd 2y ago
>Beyond ‘getting a moustache tattoo on your finger’ quirkiness In that case, seems totally worth it. I, like moustache finger tattoos, am aggressively opposed to worrying about being perceived as cool. I will just have to live with being inexcusable.
valec 2y ago
not my problem!

HL33tibCe7 2y ago

To me, HTTPS is worth it alone to eliminate the possibility of the ISPs of people reading my site from injecting shit (ads, trackers, etc.) into the responses I send to them. It’s completely trivial to set up, there’s really no downside at this point.

samatman 2y ago
This is the somewhat depressing but accurate answer. HTTPS doesn't mean you are communicating sensitive or private data, it means you want the client to see what you send them, and not something else.
averageRoyalty 2y ago
To be fair, triviality is relevant to the tooling you run and there are many downsides - extra negotiation and traffic, unsupported on older clients without using up an IPv4 address, certificate expiry, etc. For most cases these are non issues, but there are many scenarios where those things can outweigh the potential of your ISP modifying/reading. If that's still a concern, you can tunnel through your ISP to a more trusted exit point.

OJFord 2y ago

When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Secure site not available Most likely, the web site simply does not support HTTPS. However, it’s also possible that an attacker is involved. If you continue to the web site, you should not enter any sensitive info. If you continue, HTTPS-Only mode will be turned off temporarily for the site. [Continue to HTTP site] (Copied from Firefox on Android) Personally I think that's reason to do it alone, for the price of a free Let's Encrypt cert you can deliver much better UX. You presumably want people to visit your site.

sdsd 2y ago
>When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing? >for the price of a free Let's Encrypt cert you can deliver much better UX I'm going to get around to it, I promise haha. Btw if anyone does visit the site, please do sign my guestbook: http://darigo.su/33chan http://darigo.su/33chan (but be warned, a MITM might intercept and alter your comment!!)
- prettymuchnoone 2y ago
  > Neither desktop firefox nor chrome seem to do this by default they do, you probably just checked the "i'm sure this is safe" button posted a pic on the imageboard hehe
  - sdsd 2y ago
    Thanks for visiting! Receiving guestbook comments is such a delight. Does Chrome also give you this warning on desktop?
    - prettymuchnoone 2y ago
      nope

npsimons 2y ago

Honestly, for public facing read-only websites, it's perfectly fine to redirect HTTP to HTTPS. There's just too many cases where you aren't going to get everyone to put "https:// https://" on the front of URIs when they put them in docs, flyers, etc. You're lucky if you get "http:// http://"! The API security thing, yes, that makes sense. Personally, I run a number of servers for small groups where the sensitive stuff is SSL only - you won't even get an error going to port 80, other than the eventual timeout. But for reasons above, I cannot just turn port 80 off, and it's perfectly safe redirecting to 443.

bruce511 2y ago

I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https? Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating. Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Being HTTP allows it to be altered along the way. Gor example, and thd least serious, is that your ISP can inject adverts onto your page. Most ISPs don't do this, but quite a few do. Second, a malicious user could inject additional text onto upur pages, proclaiming your love for a political party, some racial or misogynistic slur, or whatever. Third, you're sending a signal to all that you either don't understand the security risks, or don't care about them. This can have consequences (reputationally) if you are in, or going into, a computing career. Making it HTTPS can be fun too!

foobiekr 2y ago
The bigger issue is that a malicious interceptor could inject javascript. The site may not use javascript, but the users almost certainly have it turned on, and accessing a non-https site means that any man in the middle can inject malicious javascript. HTTPS is about protecting the client.
- Thorrez 2y ago
  E.g. China's great firewall sometimes inserts malicious Javascript that causes the client to launch a DDoS attack against Github or other sites China doesn't like. https://en.wikipedia.org/wiki/Great_Cannon https://en.wikipedia.org/wiki/Great_Cannon
noirscape 2y ago
Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps; 1. Install and run certbot (+the DNS plugin for your DNS provider). 2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config. 3. Set up a generic redirect server block to send everything on port 80 to port 443. 4. Reboot nginx. It's at least better than fiddling with openssl directly, but this isn't fun, it's busywork.