2

I understand running a website with HSTS can help prevent an attacker using KRACK to downgrade the website to serve HTTP requests.

What if our web server does not support HSTS?

IIS has a setting for a website where it can require SSL requests only.

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP? I would assume the webserver will fail to serve non HTTPS traffic, correct?

Improve this question

2 Answers 2

Reset to default
3

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP?

No.

I would assume the webserver will fail to serve non HTTPS traffic, correct?

No.

The MitM will speak https with your server and http with the client.

The only real defense against sslstrip is HSTS.

According to https://www.tbs-certificates.co.uk/FAQ/en/hsts-iis.html you can set-up HSTS with IIS with the "Add Custom HTTP Response Header" dialog.

Note: HSTS is only active after a first successful https visits. To protect the first visit, you can use the preload mechanism: https://hstspreload.org/ but be careful, it's can't be disabled after!

Improve this answer
1
  • 1
    It might be worth pointing out that HSTS only works after the user visits the site without a MitM, if HSTS is enabled but the attacker is still using SSLstrip nothing changes (unless you get it added to an HSTS preload list, in which case most updated browsers will have it preloaded).
    – AndrolGenhald
    Commented Oct 17, 2017 at 21:55
3

Going HTTPS-only doesn't help protect you in this case. This other question should help illustrate why. In short, if an attacker can force a client to communicate over HTTP then the attacker can get between you and the client and act as a relay - talking to the client in HTTP and the server in HTTPS.

It would be nice if there was a way to force the client never attempt an HTTP call to your server - thankfully you can with HSTS. But the typical HSTS configuration protects your users if, and only if, you can establish a secure connection before an attempted attack. This is because HSTS relies on a Trust On First Use, or TOFU, model. If you can get an HSTS header on the client's machine before any attack then the client will be safe. If an attacker is already in place then they can strip out the HSTS header and continue their attack on the client.

This can be avoided if you pre-load the HSTS header. Pre-laoding HSTS means that you register your domain with the browser vendors and they'll hardcode their browsers to never allow an unsecured connection to your server. This makes an SSLstrip attack very difficult becasue the client will never send an HTTP request to your server. But be careful, HSTS Preload comes with its own set of risks. This other question has some great references to HSTS and HSTS Preloading, please read the questions and top 3 answers for all of the details.

Like Tom mentioned in his answer, you can set up HSTS with a custom HTTP Response Header. You can also do it in your Web.Config file: 

<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

Note: This does not include the preload attribute. It also excludes the includeSubDomains attribute which you may want as well. Again, be very careful with both of these attributes. Don't naively implement them.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .