TLS redirect security

A common technique to help TLS migrations is providing a redirect. For example, this blog, hosted on Wordpress.com, redirects all HTTP requests on port 80 to one using TLS on port 443.

$ curl -v http://virtualandy.wordpress.com
* Rebuilt URL to: /
*   Trying 192.0.78.13...
* TCP_NODELAY set
* Connected to virtualandy.wordpress.com (192.0.78.13) port 80 (#0)
> GET / HTTP/1.1
> Host: virtualandy.wordpress.com
> User-Agent: curl/7.54.0
> Accept: */*
> Referer:
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Mon, 10 Feb 2020 15:15:43 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: /

This looks innocuous. The client only received a 301 redirect. However, the entire HTTP request is sent over the wire in plaintext before the redirect is received by the client.

URIs are leaked in plaintext. Even Basic Access Authentication headers are also leaked. It’s true!

Wireshark screenshot where basic authorization credentials are visible over the wire (login:password)

Tradeoffs

Any security decision has trade offs. In most cases, like what Wordpress.com provides, redirecting a non-TLS connection to TLS is the right decision.

In brownfield environment, customers may have bookmarks, search engines may have indexed the non-TLS address, and difficult to update code could be written to follow URLs that were stored in datastores. Not using TLS redirects can make your customers suffer.

In greenfield environment, only accept TLS and don’t offer HTTP redirects.

Tradeoffs#

Tradeoffs