1

Background

I've added an SSL cert using Lets Encrypt/Certbot on my Debian 9 (Stretch) host.

To modify my Apache configuration, essentially certbot copies the vhost.conf file, wraps it with and inserts Include, SSLCertificateFile and SSLCertificateKeyFile entries.

And the old HTTP vhost.conf file is modified to simply redirected to HTTP to HTTPS using Rewrite rules.

I am happy for the site to be HTTPS for all end-users, but there may be circumstances where I would like a PHP script to be able to request something from localhost via HTTP, and forcing those requests to use HTTPS when the traffic is entirely local seems unnecessary.

For the purposes of this question, I have reverted the old HTTP vhost.conf file so it will serve HTTP traffic as before.

Question

So my question is, if I put this in my HTTP vhost file, will it work correctly?

<If "%{req:Upgrade-Insecure-Requests} == '1'">
    Redirect permanent "/" "https://mydomain.ltd/"
</If>

From my testing, it certainly appears to work 100% correctly, but my concern is that I am new to SSL and whilst it is broadly straightforward, there's a lot of potential for edge-cases where things might not work as intended.

Further Wittering

I like my proposed solution as it should redirect all users with a modern browser to use HTTPS without entirely preventing HTTP access. I also prefer using Redirect permanent over rewrite rules as it's simpler, and presumably more efficient. But again, the fact that rather a high proportion of advice on the internet suggests using the rewrite method is slightly troubling!

UPDATE 2019-08-20 Just to clarify, by "work correctly", I mean the site will be accessible to all and, for most users, serve content via HTTPS.

I specifically want to avoid any issues that might prevent some users from being able to use the site.

Probably worth me mentioning that the site(s) I'm dealing with are basic brochureware sites that don't especially need SSL to be used safely.

Improve this question
5
  • You might need to specify what you mean by working correctly. There are security drawbacks of doing it your way and obviously it won't work on older/subpar browsers, but if that's acceptable to you, then it should be fine. – Trickytree22 Aug 19 '19 at 9:14
  • @Trickytree22 I've added an update at the end of my post. You said "and obviously it won't work on older/subpar browsers". By "won't work", do you mean won't be served via HTTPS but by HTTP, or do you mean it'll break horribly?! I'm rather keen to avoid the later! :D – Peter Ryan Aug 20 '19 at 17:17
  • I honestly can't answer that, as not supported by browser probably mean different things for different browsers. My guess is that they won't break horribly, and just default to some pre-set. Why do you need to make http connections on localhost though? Doesn't php's filesystem functionality work for your needs? php.net/manual/en/ref.filesystem.php – Trickytree22 Aug 20 '19 at 20:18
  • I wondered if someone would ask that! So I'm not doing this just yet and may never, but when generating page output, sometimes it can be resource intensive to generate parts of the output (e.g. lets say the menu items are being pulled from a DB) even though they are comparatively static. So the logical step would be to cache those parts. My thinking is that I could stick a simple front-end proxy on there to cache all content. Then I just make requests to the local server for each part of the page and those parts will use cache where available. Not sure if good idea yet... but you did ask! :D – Peter Ryan Aug 21 '19 at 20:10
  • I get that you would cache certain parts. It still doesn't explain why you wouldn't use the filesystem functionality (unless you plan on using several servers for loadbalancing). In the situation you provided however, your server will, at some point, provide the cached file as output. You can either do that immediately with the filesystem functionality or use additional resource-demanding options in between. – Trickytree22 Aug 22 '19 at 7:51
2

It appears that search engine spiders such as Googlebot don't send the Upgrade-Insecure-Requests: 1 header. I looked at several people who show the headers that Googlebot sends and none of them show the Upgrade-Insecure-Requests header.

It is a good idea to show your redirects to search engine robots. As such, you should implement them in such a way that they get shown to Googlebot. As such I would recommend using the if expression:

<If "! -R '127.0.0.0/8'">

Where

Improve this answer
2
  • Good point search engine bots, so I'll go with that method. Do you know if I can (or should) match for IPv6 localhost ::1 ? Thanks for your reply btw!! :D – Peter Ryan Aug 21 '19 at 19:55
  • That sounds right but I don't have any experience with ipv6 – Stephen Ostermiller♦ Aug 21 '19 at 21:08
-1

As i understand it isn't possible to run a script on HTTP, if the domain setup is HTTPS. The script will be not able to force HTTP for itself. For such scripts i would create a special subdomain, which would remain HTTP - specially for running HTTP scripts. I could be wrong.

Improve this answer
1
  • I suspect you're talking about client-side (Java)scripts, which will have restrictions on what connections they can set up. What I'm trying to do is server-side scripts connecting to the local server, e.g. a PHP script using (say) cURL to make a request to the server it's running on. There should be no restrictions for that AFAIK. – Peter Ryan Aug 20 '19 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.