8 ms·

So if I just redirect all http requests to https, what unexpected consequences might I run into? Not-for-profit hobby site/community with a couple hundred regu

So if I just redirect all http requests to https, what unexpected consequences might I run into? Not-for-profit hobby site/community with a couple hundred regular users. Have been running https with Let's Encrypt certs for a year but not advertising or defaulting to it. No legacy systems or other entanglements. There is a forum that allows users to post inline images and media from other domains.

hughes 10y ago
If you load any external scripts that are not secure, they might no longer work. Chrome blocks such scripts by default[1]. Depending on your server setup, if you run multiple web domains from the same server then web clients that do not support SNI may fail[2]. [1] https://support.google.com/chrome/answer/1342714 https://support.google.com/chrome/answer/1342714 [2] http://stackoverflow.com/q/21956663/796554 http://stackoverflow.com/q/21956663/796554
regecks 10y ago
If you have absolute URLs (http://..../foo.jpg http://..../foo.jpg) saved in documents or a database or something like that, you would need to rewrite them to be protocol-relative or just https:// https:// .
- ReverseCold 10y ago
  Hmm, but they said SSL is already enabled if you visit the site with https. Shouldn't redirecting http > https be completely risk free then or am I missing something?
  - CharlesW 10y ago
    I think the reply was suggesting that "not advertising or defaulting to [HTTPS]" implies that a quick check for absolute HTTP URLs would be Good Thing.
    - colemickens 10y ago
      Basically every single reply to the GP is making the same point about http assets loaded from a page loaded over https... Surely the GP wouldn't have asked the question they did if their https site was already broken...
  - chipperyman573 10y ago
    If you visit a secure site (https), embedding insecure items (http) will fail because they could do just as much damage as loading the entire page over http.
    - Buge 10y ago
      It depends on what the insecure item is. If it's just an image, it won't fail, it will just grey out the https and not display a lock icon. https://mixed.badssl.com/ https://mixed.badssl.com/
      - nailer 10y ago
        That's current behavior, but I wouldn't guarantee it will remain that way, an http image compromises the integrity of the site: it could be manipulated to change the meaning. Imagine reading a news site using an unencrypted CDN and whoever runs the WiFi (or the country you're in) is replacing the images with similar yet different ones, giving a different impression that what the creator intended. You could do this quite subtly as a way to influence people by making certain figures appear more sinister. These warnings tend to get tougher over time, so what's grey now may be red next year.
  - rogerdpack 10y ago
    Appears it should be OK unless some inline embedded images are hard coded to "http://" http://" in which case the browser will, I believe, refuse to even try and load them, so you may need to fix that. If they're all relative you're good to go :)
- discreditable 10y ago
  In the future, the upgrade-insecure-requests CSP directive[1] might help with this problem. I'm not sure what browsers have implemented it yet though. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
nkozyra 10y ago
Well, there is still overhead for using HTTPS, particularly for the handshake. This is unlikely to be palpable at your size, though.
- Klathmon 10y ago
  The overhead is negligible with the prefetching browsers do, and even that is closing fast with things like TCP fast-open. Plus TLS false start and TLS resumption are already here and work great for repeat visits to remove that extra overhead. Performance isn't an excuse for not using TLS anymore.
  - nkozyra 10y ago
    Oh I agree it's no excuse, OP just asked what the tradeoff/cost was. There is still some but as you say it's negligible and especially so for a very small site like that.
davidgerard 10y ago
IME, mixed-content warnings. Tracking down those can be a nuisance. If users can add inline images, you'll basically not be able to avoid these. Let's Encrypt certs work on pretty much every device. (Some Comodo certs don't work on older Android, for instance - we hit this at work and switched those sites to Let's Encrypt, problem solved.)
mpclark 10y ago
Just did this this week. The only unexpected effect I found was that all our Facebook likes were reset to zero. FB must consider the two versions of each page as being separate and different.
- askvictor 10y ago
  What type of redirect did you implement? Just curious; this sounds somewhat like the cname vs redirect argument for www. to bare domain name.
  - mpclark 10y ago
    It's a Nginx directive that rewrites requests from http to https with a 301
byuu 10y ago
You mentioned community. If you have a forum or message board where people can select their own avatars or post image links, then you'll enjoy the land of mixed content warnings. Add the header "Content-Security-Policy: upgrade-insecure-requests" and the mixed content errors will go away, but you'll experience a new problem. About 30% of images/avatars will break, and of those, roughly 10% of them will cause the page loading animation to keep going for 2-3 minutes before finally timing out. I presume this is due to some sort of server misconfiguration on their part, as most non-HTTPS sites fail fast. Give it a few months and users will slowly update their avatars and stick to sources that support HTTPS (like imgur), but don't expect the problem to ever go away completely.
- londons_explore 10y ago
  Run a reverse proxy to host all the user content on your own domain under https instead. Eg. https://yourdomain.com/usercontent/worldofcats.com/foobar.jpg https://yourdomain.com/usercontent/worldofcats.com/foobar.jp... There exist simple php scripts which can do that for you. Beware to sanitize the URL very well, and probably enforce file size rules.
  - robryk 10y ago
    Don't do this on your domain. Have a separate domain for user content (and, if the content isn't public, better have many separate domains and distribute the content between them; maybe even have a per-user domain). Browsers can be convinced that a particular resource is an html page even if the content-type is wrong.

hughes 10y ago

If you load any external scripts that are not secure, they might no longer work. Chrome blocks such scripts by default[1]. Depending on your server setup, if you run multiple web domains from the same server then web clients that do not support SNI may fail[2]. [1] https://support.google.com/chrome/answer/1342714 https://support.google.com/chrome/answer/1342714 [2] http://stackoverflow.com/q/21956663/796554 http://stackoverflow.com/q/21956663/796554

regecks 10y ago

If you have absolute URLs (http://..../foo.jpg http://..../foo.jpg) saved in documents or a database or something like that, you would need to rewrite them to be protocol-relative or just https:// https:// .

ReverseCold 10y ago
Hmm, but they said SSL is already enabled if you visit the site with https. Shouldn't redirecting http > https be completely risk free then or am I missing something?
- CharlesW 10y ago
  I think the reply was suggesting that "not advertising or defaulting to [HTTPS]" implies that a quick check for absolute HTTP URLs would be Good Thing.
  - colemickens 10y ago
    Basically every single reply to the GP is making the same point about http assets loaded from a page loaded over https... Surely the GP wouldn't have asked the question they did if their https site was already broken...
- chipperyman573 10y ago
  If you visit a secure site (https), embedding insecure items (http) will fail because they could do just as much damage as loading the entire page over http.
  - Buge 10y ago
    It depends on what the insecure item is. If it's just an image, it won't fail, it will just grey out the https and not display a lock icon. https://mixed.badssl.com/ https://mixed.badssl.com/
    - nailer 10y ago
      That's current behavior, but I wouldn't guarantee it will remain that way, an http image compromises the integrity of the site: it could be manipulated to change the meaning. Imagine reading a news site using an unencrypted CDN and whoever runs the WiFi (or the country you're in) is replacing the images with similar yet different ones, giving a different impression that what the creator intended. You could do this quite subtly as a way to influence people by making certain figures appear more sinister. These warnings tend to get tougher over time, so what's grey now may be red next year.
- rogerdpack 10y ago
  Appears it should be OK unless some inline embedded images are hard coded to "http://" http://" in which case the browser will, I believe, refuse to even try and load them, so you may need to fix that. If they're all relative you're good to go :)
discreditable 10y ago
In the future, the upgrade-insecure-requests CSP directive[1] might help with this problem. I'm not sure what browsers have implemented it yet though. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

nkozyra 10y ago

Well, there is still overhead for using HTTPS, particularly for the handshake. This is unlikely to be palpable at your size, though.

Klathmon 10y ago
The overhead is negligible with the prefetching browsers do, and even that is closing fast with things like TCP fast-open. Plus TLS false start and TLS resumption are already here and work great for repeat visits to remove that extra overhead. Performance isn't an excuse for not using TLS anymore.
- nkozyra 10y ago
  Oh I agree it's no excuse, OP just asked what the tradeoff/cost was. There is still some but as you say it's negligible and especially so for a very small site like that.

davidgerard 10y ago

IME, mixed-content warnings. Tracking down those can be a nuisance. If users can add inline images, you'll basically not be able to avoid these. Let's Encrypt certs work on pretty much every device. (Some Comodo certs don't work on older Android, for instance - we hit this at work and switched those sites to Let's Encrypt, problem solved.)

mpclark 10y ago

Just did this this week. The only unexpected effect I found was that all our Facebook likes were reset to zero. FB must consider the two versions of each page as being separate and different.

askvictor 10y ago
What type of redirect did you implement? Just curious; this sounds somewhat like the cname vs redirect argument for www. to bare domain name.
- mpclark 10y ago
  It's a Nginx directive that rewrites requests from http to https with a 301

byuu 10y ago

You mentioned community. If you have a forum or message board where people can select their own avatars or post image links, then you'll enjoy the land of mixed content warnings. Add the header "Content-Security-Policy: upgrade-insecure-requests" and the mixed content errors will go away, but you'll experience a new problem. About 30% of images/avatars will break, and of those, roughly 10% of them will cause the page loading animation to keep going for 2-3 minutes before finally timing out. I presume this is due to some sort of server misconfiguration on their part, as most non-HTTPS sites fail fast. Give it a few months and users will slowly update their avatars and stick to sources that support HTTPS (like imgur), but don't expect the problem to ever go away completely.

londons_explore 10y ago
Run a reverse proxy to host all the user content on your own domain under https instead. Eg. https://yourdomain.com/usercontent/worldofcats.com/foobar.jpg https://yourdomain.com/usercontent/worldofcats.com/foobar.jp... There exist simple php scripts which can do that for you. Beware to sanitize the URL very well, and probably enforce file size rules.
- robryk 10y ago
  Don't do this on your domain. Have a separate domain for user content (and, if the content isn't public, better have many separate domains and distribute the content between them; maybe even have a per-user domain). Browsers can be convinced that a particular resource is an html page even if the content-type is wrong.