Is http to https port forwarding a vulnerability?

Question

I work in an organisation where a TMG server with port forwarding has been used successfully for a number of years to forward all http traffic to https for a particular web application. This meant that http or https would work on URLs for that web application.

Recently this was seen as a security risk and http is no longer being advertised. For users this has caused an issue where all the links they had which were originally http no longer work and they are having to update all their links to https.

I can't quite figure out what the vulnerability is, and if someone could shed some knowledge I would really appreciate it.

How I understand it, there are 2 paths http and https. The TMG server essentially acts as the gatekeeper that sits in front of the organisations network and forces all http traffic down the https route instead, so at no point is there any http traffic into the network.

Also, to add plenty of well recognised organisations still use port forwarding, for example Microsoft teams http:// teams.microsoft.com auto redirects to https:// teams.microsoft.com. Unless they are using a different method of redirect that is more secure?

Thanks in advance

Answer 1

I think you mean redirecting, not port forwarding.

Redirecting from http to https is quite common. This is where the browser initially makes a request to an http URL on port 80, then the web server responds with a 301 or 302 redirect (in the response header) to an https URL, then the browser makes a request to that URL via https on port 443.

security.stackexchange.com is configured this way, as you can see with the following curl command:

curl -v http://security.stackexchange.com/
*   Trying 151.101.65.69...
* TCP_NODELAY set
* Connected to security.stackexchange.com (151.101.65.69) port 80 (#0)
> GET / HTTP/1.1
> Host: security.stackexchange.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< cache-control: no-cache, no-store, must-revalidate
< location: https://security.stackexchange.com/
< server: Microsoft-IIS/10.0
< x-flags: AA
< x-aspnet-duration-ms: 0
< x-request-guid: d6473d9f-2d5d-4543-ae86-0dc6bfa61ca1
< x-is-crawler: 1
< x-providence-cookie: 6d0a8faf-a592-61cf-99da-cf1c434e5d5e
< Transfer-Encoding: chunked
< Accept-Ranges: bytes
< Date: Thu, 16 Jul 2020 13:59:30 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-ewr18134-EWR
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1594907971.551606,VS0,VE4
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=6d0a8faf-a592-61cf-99da-cf1c434e5d5e;  domain=.stackexchange.com; ex

Port forwarding would be something entirely different, and would probably not even work. This would be where the browser makes a request to an http URL on port 80, then a router on the network forwards the request to the web server on port 443. So, the browser thinks it's making an http request (on port 80), but the server sees an incoming connection on port 443, so it thinks it's an https request. I don't have a way to test this, but I would think the browser would never send a `client hello' (because it thinks it's making an http request, not an https request) so the server would eventually time-out the connection.

Answer 2

It's basically an auditor trap. The auditor will see HTTP open and assume that unencrypted communications are possible. When you explain there is redirection, one of three things will happen:

1. They'll accept your explanation and move on.
2. They'll point out clients can submit sensitive data before being redirected.
3. They won't care about your explanation.

This process will repeat with each audit you have and each client who reaches out with concerns about your security. While it is a minor issue, and one that has a reasonable compensating controls, it will resurface enough that eventually you'll consider shutting HTTP down and inconveniencing people with old links.

Answer 3

TL;DR

1. Upgade connections to TLS i.e. HTTP redirect everything from HTTP to HTTPS.
2. Always use valid certificates for the TLS connection.
3. Implement HTTP Strict Transport Security (HSTS, RFC 6797).

Semantics do matter

As @mti2935 suggests, I also believe you are actually talking about redirection. People not familiar with network protocols typically mix the following and use them like they were interchangeable, despite they aren't:

• HTTP redirection (that allows moving the browser to another address; RFC 7231, 6.4 & 7.1.2)
• email forwarding (SMTP feature for Address Correction or Updating; RFC 5321, 3.4),
• DNS aliases (a CNAME pointing to an A pointing to an IP; RFC 1035, 3.3.1, RFC 2219)
• NAT port forwarding (translating a IP:port pair to another IP:port pair inside NAT).

Accessing the site explained step by step

Typically people do not write the entire HTTP protocol addresses. Instead, this might happen:

1. A user simply types example.com to the browser.

2. The browser, by default, completes this. The address bar might show e.g. http://example.com or just example.com without padlock symbol. The full address (http://example.com:80/) also contains the port (80) and the path (/), but default ports can be and are omitted.

   The actual connection is made using the IP address and the hostname is on its own header:

   > GET / HTTP/1.1
   > Host: example.com
   

3. If a redirection is in place, server responds with the new HTTPS location. This connection upgrade to HTTPS, if configured properly to redirect every path, prevents sending data over plain HTTP.

   < HTTP/1.1 301 Moved Permanently
   < Location: https://example.com/
   

   (It doesn't really matter whether the redirection is done by the web server or a firewall, TMG server etc. It's technically the same thing from the client's perspective.)

4. The path is requested again over HTTPS. The address bar might show e.g. https://example.com or just example.com with the padlock symbol. The full address would this time be https://example.com:443/.

5. Now, if the HTTPS site is configured with HTTP Strict Transport Security (HSTS, RFC 6797), it responds with an additional header, e.g.

   < strict-transport-security: max-age=63072000; includeSubDomains; preload
   

   This tells the browser to cache the information that this site must only be accessed using HTTPS with a valid certificate. Next time the site is visited, phases 2 and 3 are omitted; the browser performs an internal redirection to HTTPS, or in other words completes the example.com directly to https://example.com.

Preferred, secure configuration

As the HSTS is the only way to prevent MitM serving fake/malicious content from the plain HTTP http://example.com, in addition to the HTTP redirection you should also have HSTS headers (and obviously valid certificate) in place.

Also, not redirecting from HTTP i.e. having the port 80 closed doesn't prevent MitM from serving content on the HTTP port. This doesn't add security but affects usability. Frankly, it's not even a compromise between the two, but just breaks the bookmarks and manually typed addresses without giving anything back.