How to prevent HTTPS man-in-middle attack from the server side?

Question

In the HTTPS security model, the weakest part is the list of trusted CA in the browser. There are many ways that someone could inject addition CA to the list that users will trust the wrong guy.

For example, a public computer, or PC in your company. The administrator could force you to trust a CA issued by himself, it could be very insecure with a HTTPS proxy server with HTTPS relay. As a result, they will able to SPY your message, login, and password even browser tell you that your are on trusted SSL connection.

In this case, what can web application developer could do to protect user and also the system?

Answer 1

As a web application developer there is very little you can do about this.

This issue needs to be dealt with further down the stack.

If someone half way around the world wants to:

a. Put a false root CA on someone's computer

b. Issue a cert for your domain under that CA

c. Impersonate your site

d. Point someone's local DNS entry for your domain to a different ip

In none of the above steps is your application involved or consulted so this is where good network administration and security is important.

Aside from that, maybe there's a legitimate reason for someone to do just this locally on their personal network. Who am I to stop them?

This is essentially what corporate web proxy filters do and they are within their rights to do it.

As far as stopping someone malicious from taking the above steps thats something that needs to be put on the administrators of your customers machines.

Answer 2

Theoretically speaking, if the user's terminal is owned by an adversary, you've already lost and there's nothing you can do about it -- if push comes to shove they can filter out your countermeasures or even scrape and spoof the entire site.

In practice, you can do things to make the adversary's job harder, but it's an arms race. You'll likely have to use all the same sorts of countermeasures that malicious software uses against scanners -- because from the adversary's point of view your site is behaving maliciously by trying to prevent itself from being overridden! -- and know that anything you do can and will be rapidly countered if your adversary cares enough.

You could, for example, open sockets or useXmlHttpRequest from JavaScript or applets, but you can't stop your adversary from updating their filters to strip out anything you add.

You might get more mileage by emitting polymorphic output or using other anti-reverse-engineering techniques, so it appears that no two hits to the site produce similar code/resources sent to the browser. It's an inordinate amount of work but gives your adversary a puzzle to chew on if they want to play man in the middle.