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:
- 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.
- 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
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
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.
www.server1.example and you have the URL
https://www.server1.example/myscript1.php. For that URL you want clients to be redirected to
You control server
www.example1.com so you can configure it to enable this redirection.
Here is what will happen:
- The client connects to
www.server1.example by opening a TLS connection to it and then requests the URL
- The server reply will give a redirection error code, like
301 plus the new URL
- 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.