Always On VPN SSTP and HSTS

HTTP Strict Transport Security (HSTS) is a feature commonly used by websites to protect against protocol downgrade attacks, where an attacker forces the use of insecure HTTP instead of HTTPS. If successful, the attacker can intercept unencrypted communication between the client and the web server. This is undesirable for obvious reasons. As such, web server administrators implement an HTTP response header named Strict-Transport-Security with some additional settings that instruct the user agent, in this case, a web browser, to only use secure HTTPS when communicating with the web server. Attempts to use HTTP will not work.

VPN and SSTP

As security is always a top concern when building an Always On VPN infrastructure, careful attention must be paid to VPN protocol configuration to ensure optimal security. Secure Socket Tunneling Protocol (SSTP) is a popular VPN protocol for Always On VPN user tunnel connections. SSTP uses Transport Layer Security (TLS) for encryption, so administrators are encouraged to implement recommended security configurations, such as disabling insecure protocols like TLS 1.0 and TLS 1.1 and optimizing TLS cipher suites as described here.

SSTP with HSTS

It would seem that enabling HSTS on a Windows RRAS VPN server would be ideal for improving SSTP security. However, that’s not the case. HSTS prevents protocol downgrade attacks from HTTPS to HTTP, but SSTP already uses HTTPS exclusively, making the use of HSTS irrelevant. If an attacker attempted a protocol downgrade attack on an SSTP VPN connection, it would fail because the service does not support HTTP between the client and the VPN gateway. Additionally, even if it were possible to configure RRAS to send an HSTS response header, it would be ignored by the client because the user agent is not a web browser.

Additional Information

Always On VPN SSTP Security Configuration

Always On VPN SSTP and TLS 1.3

Always On VPN SSTP Certificate Renewal

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN SSTP Certificate Binding Error

SSL and TLS Training for Always On VPN Administrators

Leave a comment

5 Comments

  1. Ed Morgan

     /  September 30, 2022

    Hi,

    We use IKEv2 because it is more secure, even though the UDP ports do get blocked in some place.s

    Is there a way to make SSTP as secure?

    Reply
  2. Gary

     /  March 9, 2023

    Greetings,
    We’re a retail company that follows PCI compliance guidelines for credit card processors, and our audits are failing because our VPN infrastructure for remote work uses OpenVPN AS, which doesn’t support HSTS. As you pointed out, it’s unneccessary. Our CC processor is denying our disputes, and this is the only remaining issue with our audit.
    Do you have any thoughts on how we can work around this issue?

    Reply
    • I’m not sure, to be honest. Typically explaining the situation to an auditor resolves the issue. It might be possible to front the VPN server with a load balancer and add an HSTS header, but it’s not something I’ve tried myself. It could also have unintended consequences. If you go that route, be sure to let me know how it works. 🙂

      Reply
      • To clarify, if you were to use a load balancer to send an HSTS header, it would only be helpful for getting your auditor to sign off that the service uses HSTS. It would serve no purpose whatsoever in terms of improving security. As I noted in this post, HSTS only works with web browser user agents. SSTP would simply ignore the header. Also, SSTP can’t use HTTP anyway, so again, no point in doing this other than to pass your audit. 🙂

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading