Is there a way around HTTPS being redirected to HTTP?

Question

I have come across something of a curious situation that a website (Palestinian News Network) has a valid TLS certificate (see here) but that the website always forces loading of the site via http://.

(This includes the main domains as well as the referenced sub domains.)

So:

1. Is there any way that I as a client can establish if there is a MITM/attacker which is denying/redirecting HTTPS connection? (this cause is suggested by the "HTTPS Everywhere" plugin)

2. Assuming there is no MITM attacker, is there any way that I as a client can force the server to maintain the valid secured connection?

3. What are some methods as to how the server can enforce redirecting valid HTTPS connection? I've found this issue very hard to research as, expectedly, search results are nearly all about doing it the other way around ("how to http --> https" etc. etc.).

Try the website address here, note I am going straight to the secured protocol:

https://english.pnn.ps [mod note: it's HTTPS at last access of Mar 2024]

Answer 1

1. Is there any way that I as a client can establish if there is a MITM/attacker which is denying/redirecting HTTPS connection? (this cause is suggested by the "HTTPS Everywhere" plugin)

Totally depend on site configuration: the redirect may be set only to frontpage or for all resources. There's no generic answer to this question. Nevertheless, since HTTPS is acting at "transport level" where HTTP redirections are application level stuff, you don't have to worry about compromission issue: to be able to redirect you, origin server must fulfill every SSL requirements. So this is 90% sure that this is NOT a MITM attack.

2. Assuming there is no MITM attacker, is there any way that I as a client can force the server to maintain the valid secured connection?

There's no generic answer for that: it totally depends on the way sysadmin configured its server. Maybe the redirection has been configured only for frontpage, maybe it's for all resources provided by website. No way to know without server configuration or field test. Just try & see ...

3. What are some methods as to how the server can enforce redirecting valid HTTPS connection? I've found this issue very hard to research as - expectedly - search results are nearly all about doing it the other way around ("how to http --> https" etc. etc.) .

This is only redirection on a HTTP(S) server. Using Apache webserver, it'll only cost you 1 directive on the HTTPS vhost:

Redirect / http://the_real_domain_with_no_ssl/

HTTP(S) servers don't give a f*ck about security: they just do what you ask. So the HTTPS to HTTP redirection is probably a configuration directive set by administrator.

To conclude, this behaviour is totally human-dependant: HTTP server is just acting as sysadmin want. The HTTPS to HTTP redirection is probably a wanted behaviour. The only explanation is human ... Maybe it's a government order to be able to track opposition and other non-politically-correct peoples.

Answer 2

Theoretically speaking, the answer is, of course, "It depends." Practically speaking however, for the client side the answer is "probably not" and the answer for the server side is "yes, with caveats."

Client-side:

This is the situation you're describing. You visit a site with your browser, explicitly specifying the HTTPS protocol, and are immediately redirected to HTTP. First, this is not uncommon for news or other content delivery sites. They often do this to take advantage of CDNs and caching options that are not available over HTTPS in order to reduce the load on the origin servers.

What can you do about it? Not much. Generally this is going to be achived by issuing a 30x location header with the location changed only to modify the protocol to HTTP. By spec, your user agent is supposed to then navigate to that location. If they are also serving the content in the response body (unlikely) and if you can also induce your user-agent to ignore the location header and not redirect, (not going to happen with a stock browser) then you could theoretically maintain the HTTPS connection. In reality, they're not going to serve the content and best case is you get an empty response secured by HTTPS.

From the server-side, you have better options. You can do the same thing in reverse, (redirect HTTP connections to HTTPS via a location header) disable HTTP entirely and only allow HTTPS connections to the server, and you can better enforce HTTPS-always by using HSTS headers. Big, high value sites (Gmail, for instance) do this with an concept called HSTS preload which is an option compiled into some browsers requiring that any request to the site be converted to HTTPS before the request is sent. This prevents any information from being accidentally leaked to a MitM even if a user specifically tries to send an HTTP request. Any site owner, however, can add an HSTS header that tells clients that for some period of time (specified in the header) that client should do the same thing, and only make requests to that domain over HTTPS, even if the user manually attempts to use HTTP. This cannot protect the first request, but once the HSTS header has been sent future requests, even requests from future sessions will be protected as the HSTS info will be cached locally by the browser until it expires.

Answer 3

You could force your browser to treat the site as though it has HTTP Strict Transport Security (HSTS) enabled. HSTS makes the browser re-write any HTTP navigation (within the specified domain) to HTTPS, before sending the request. As a general rule, this isn't something that is exposed to the user, but there are a few ways you could do it. For example, you could set the browser to go through an HTTPS proxy (with decryption enabled in the proxy, using a cert that the browser trusts), and then make an HTTPS request and intercept the HTTPS response (the one that's redirecting you to HTTP) and add the Strict-Transport-Security header to the response.

HOWEVER, doing this would almost certainly be a bad idea. Your browser would get stuck in a redirect loop; it would request the page over HTTPS, get redirected to HTTP, re-write the HTTP URL as HTTPS (because that's what HSTS does), and request the page over HTTPS again. This loop would continue until the browser hit the maximum number of redirects it allows for an initial request, and then it would just display an error.