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 https://virtualandy.wordpress.com
* Rebuilt URL to: https://virtualandy.wordpress.com/
*   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: https://virtualandy.wordpress.com/

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s