I am developing a Web application using ASP.Net MVC. I deployed the application in IIS(V8) and now doing the Web app hardening process. I configured the SSL in IIS and the Web app is functioning using SSL only(using secured cookies etc..).

I did some security tests and one test I did was trying to intercept the SSL traffic using a proxy. I used BurpSuite for this test and did install the Burp's certificate in my browser.

I can easily inspect all HTTPS traffic using the Burp tool. I know this is possible only if we install the interceptor's certificate in the client browser. Otherwise it will give the broken SSL notification.


My problem is how we can prevent any interceptor analysing the HTTPS traffic even if someone installs the interceptor's certificate in the client browser?


I heard that if we implement HSTS (HTTP Strict Transport Security) we can resolve this issue.


Does implementing the HSTS solving the problem I have? If so, what is the most effective way of implementing it (Do we need to implement it in the application level or in the Hosting (IIS) level) ?

If the HSTS not solving this problem, what are the other alternatives we have to secure this scenario?

1 Answer 1


Being able to intercept SSL traffic with an imported root certificate is not considered a weakness of the web application. It's a browser design decision to allow the import of custom local trust anchors.

Does implementing the HSTS solving the problem I have?

No. A HTTP Strict Transport Security header just enforces HTTPS. HSTS doesn't care which certificate you use as long as it's valid. That is, with HSTS you won't be able to select "Add an exception" for an invalid certificate anymore. But when a certificate is trusted by an imported CA (like the Burp root certificate), HSTS doesn't make a difference.

My problem is how we can prevent any interceptor analysing the HTTPS traffic even if someone installs the interceptor's certificate in the client browser?

You can't. If you locally import a trusted root certificate, a website can't instruct your browser to reject it anyways.

Note that there is also the HTTP Public Key Pinning (HPKP) header that a server can send to enforce a particular certificate chain. (This might be the concept you're after, rather than HSTS.) But even this header doesn't overrule local trusted root certificates. (E.g. Google, Facebook and Github all still load through the Burp proxy despite sending HPKP headers that would theoretically reject the Burp CA.)

From "What HPKP is but isn't":

HPKP does not protect against local attacks, such as malware intercepting traffic. As long as the malware has the ability to get a root certificate installed on your machine, there’s nothing HPKP can do.

This is also explained in the Chromium Security FAQ:

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

So there is no common way to achieve what you want - are you sure you really need to block local root certificates? If a user installs the Burp certificate into their browser to intercept SSL traffic they made a conscious choice after all. Here's how the Chromium FAQ justifies that behavior:

We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should.

  • Thats for your detailed explanation ! Jan 6, 2017 at 21:58

You must log in to answer this question.

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