0

I am trying to get some understanding on differences between unsecured (http:// accessed) and SSL secured (https://) websites on Apache servers. So I am not trying to solve a specific problem right now, but get some understanding so I can solve them in the future. It is a shared host and I only have access to .htaccess. I hope someone may be able to advise. The points are:

  1. If I have an unsecured site accessed as http://example.com/myscript.php, and I then purchase an SSL certificate for it, can it still be accessed by http:// or does it now have to be accessed by https://?
  2. Is it right that one can force access by https:// by rewrite rules in .htaccess? Ie if someone does access it as above, it can effectively be forced to be https://example.com/myscript.php? In that case what has happened to the original http://example.com/myscript.php request sent by the client - was it out on the internet and therefore open to hacking?
  3. I think I am right in saying that using .htaccess to force from https:// to http:// doesn't work, because the secure communication has been set up before .htaccess is accessed?
  4. If there is a redirect in the PHP script from - say myscript1.php to ./myscript2.php (ie another script in the same directory), and the site is SSL secured, does that force access to that second script to be secured or not? If it doesn't, how does one force that?

Hope for some helpful answers, thanks.

closed as too broad by Stephen Ostermiller Apr 26 '18 at 10:25

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1

You have many questions in a single post and I think some core misconception that makes you see things in a strange way, so I hope that the following could help you clear your views or at least trigger some ore explanatory questions.

First I would like to address to terminology points:

  1. Stop saying SSL. I know everyone does, but it is just purely wrong. SSL is an old protocol that does not exist any more. Its successor is TLS and this is what all websites are using right now, there are multiple versions and the latest one, 1.3, should soon become a standard. Related to that, please stop saying "SSL certificate", because it is twice a faulty name. It is an X.509 certificate use for a TLS connection: you can use X.509 certificates for other things (like for email end to end encryption and authentication through S/MIME) and you can do TLS connections without certificates.
  2. Do not hit so often on .htaccess as it is mostly unrelated to the points you raised. First, this is specific to one webserver, namely Apache, where you can use any webserver out there, its configuration will change (format, syntax rules, name, etc.) but will be there to reach the same goal. Second because even with Apache you can configure it in "system" configuration files, such as those in /etc. In fact, when you can, I advise against .htaccess it is more complicated to use correctly (specially for redirects), and can have bad consequences regarding security and performances.

Now for your specific points.

Switching from HTTP to HTTPS

If I have an unsecured site accessed as http://example.com/myscript.php, and I then purchase an SSL certificate for it, can it still be accessed by http:// or does it now have to be accessed by https://?

This is purely a personal choice. As soon as you have configured your website to be available over HTTPS you can decide to shutdown access to it through HTTP or make your server redirect all HTTP accesses to the equivalent ones in HTTPS. This is your decision to make.

Note however that there are various technologies that may force a browser to switch to HTTPS automatically, even without trying HTTP. See for example HTTP Strict Transport Security (HSTS) and HSTS preloading (https://hstspreload.org/) where list of websites are shipped with browsers to make sure they never go back ("downgrade") to HTTP.

Also at some future time browsers will start showing all HTTP website as " insecure". See for example: https://www.cnet.com/news/chrome-warning-insecure-http-websites-expose-passwords-credit-card-numbers/

In summary the move is really towards a web where only HTTPS would exist. Hence it probably may have no sense to keep the HTTP version when you enabled the HTTPS one. But this all depends on your constraints.

(PS: Kudos to have used example.com in your URL; this is the right thing to do. See RFC2606 if you are more curious)

Rewrites from HTTP to HTTPS

Is it right that one can force access by https:// by rewrite rules in .htaccess? Ie if someone does access it as above, it can effectively be forced to be https://example.com/myscript.php? In that case what has happened to the original http://example.com/myscript.php request sent by the client - was it out on the internet and therefore open to hacking?

First, a slight detour at HTTP core features (which are also HTTPS ones since HTTPS is HTTP over TLS). An HTTP server reply to any request with an error code, some headers, and the content. The error code tells the client what is happening. Some error codes were created to clearly cater for the redirect feature, this is error codes 301, 302, 307 and 308 (full details there: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection). In these cases the server in its reply include in the headers the URL of the target of the redirection and the client reads it and goes to fetch it.

With that in mind, if the client starts with an HTTP request and if the server is configured to reply to it with a redirection, then the server will reply again in clear (like the HTTP request) with the needed error code and the final URL, be it with https:// or http://. The client will then just start another query with this new URL.

You are right that the initial HTTP request + reply are in clear and thus are vulnerable: a third party somewhere could intercept and rewrite both the request and the reply, then misleading the client. This is exactly the goal of HSTS preloading: making sure that clients start directly with HTTPS queries.

Rewrites from HTTPS to HTTP

I think I am right in saying that using .htaccess to force from https:// to http:// doesn't work, because the secure communication has been set up before .htaccess is accessed?

Redirection can be done from any URL to any other one, as long as the server is correctly configured to handle this, whatever schemes you are using (the part before the :// in an URL is called a scheme, so for the web it is http or https).

So you can technically absolutely redirect an https://... URL into an http://... This of course makes little sense (you loose all security features that the TLS in HTTPS was providing to you) and can even be seen as an attack.

Now you are mixing multiple things here and you focus on .htaccess which is irrelevant here. Let us try to rephrase/precise your point: for an https:// URL the client will establish a TLS connection to the server inside which it will send its request, so basically the URL requested and some headers. The server will receive that from the TLS connection, and will decide its reply based both on what the client has sent and its own configuration (be it in some .htacess file or somewhere else).

Rewrites for scripts

If there is a redirect in the PHP script from - say myscript1.php to ./myscript2.php (ie another script in the same directory), and the site is SSL secured, does that force access to that second script to be secured or not? If it doesn't, how does one force that?

First an important point to understand: remotely, a client has no way to know what is behind any URL, if it corresponds on the server to a static resource, if it will be redirected, proxied, refused, or if it will launch a program to build the reply, etc. Same for the hierarchy: what you see in the URL may not be reflected as is on disk in the server. For your example, two scripts that seem to be at the same level based on URL comparison could as well be in completely different spots on the webserver.

So redirections, and URLs, will work technically the same way if they have image.png at the end of script.php. Remember also that the "extension" (after the dot) is purely a convention, image.png could correspond to a JPEG image (while silly) and be either a static file on disk or generated on request and same for script.php it could be an image.

Anyway let us try to describe your case. You control www.server1.example and you have the URL https://www.server1.example/myscript1.php. For that URL you want clients to be redirected to https://www.server2.example/myscrip2.php. You control server www.example1.com so you can configure it to enable this redirection.

Here is what will happen:

  1. The client connects to www.server1.example by opening a TLS connection to it and then requests the URL
  2. The server reply will give a redirection error code, like 301 plus the new URL
  3. The client will then open a new connection to www.server2.example completely separate, again with TLS and will request the new URL there.

So, both exchanges are secure because done over TLS. This is a generalization of course, the connections could be different (but still with TLS) if the second URL had again www.server1.example (the first one may get reused since it is the same hostname to send the second requests), or if both hostnames resolve to the same IP, or with newer protocols like HTTP/2 that tries to optimize various things.

But basically it is not the content of the URL that dictates if the connection is secure or not, it is its scheme, and if it is https which is http over TLS instead of just http as scheme.

  • Really helpful answer, thanks. The reason for the varied questions is that I am trying to get the principles clear rather than solve a specific problem, so I can later resolve specific issues. Your answers helped a lot. – nmw01223 Apr 26 '18 at 21:21
  • On (2), I did try it with .htaccess rewrite rules, and it didn't work (reason for the attempt was to stop browsers that default to https from throwing 'not secured' error pages on accessing a site that was not secured). I assumed the reason was that the browser tried to setup secured communications with the server, failed to do so, and therefore never got as far as any .htaccess rewrite rules. – nmw01223 Apr 27 '18 at 3:21
2
  1. Yes, you can access a site via http or https however modern browsers will show a warning if a site is not using SSL
  2. Yes. The code is RewriteCond %{SERVER_PORT} =80 RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

  3. Why would you want to force http when you have a valid certificate?

  4. If you don't have the code in point 2 in place it will redirect to the same protocol as the original page. However with the sample code above all scripts will be https.

  • On point (3), simply because I am trying to understand how it works and what is possible. I did try some rewrite rules to stop access to a non-secured site with https:// from throwing a 'this a non-secured site' error page, and it didn't work. – nmw01223 Apr 27 '18 at 2:58

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