Preventing man in the middle attack while using https

Question

I am writing a little app similar to omegle. I have a http server written in Java and a client which is a html document. The main way of communication is by http requests (long polling).

I've implemented some sort of security by using the https protocol and I have a securityid for every client that connects to the server. When the client connects, the server gives it a securityid which the client must always send back when it wants a request.

I am afraid of the man in the middle attack here, do you have any suggestions how I could protect the app from such an attack.

Note that this app is build for theoretical purposes, it won't be ever used for practical reasons so your solutions don't have to be necessarily practical.

Grapnel

Answer 1

HTTPS does not only do encryption, but also authentication of the server. When a client connects, the server shows it has a valid and trustable certificate for its domain. This certificate can not simply be spoofed or replayed by a man-in-the-middle.

Yukoyukon

This is true only if the client is set to verify certificates correct? I was wondering if there was any data on what % of clients have this turned on, for example when people write client apps to consume an API. Are there any companies you've seen that document this well to help client apps verify certs correctly? Thanks! – Anti

Answer 2

Simply enabling HTTPS is not good enough because the web brings too many complications.

For one thing, make sure you set the secure flag on the cookies, or else they can be stolen.

It's also a good idea to ensure users only access the site via typing https://<yourdomain> in the address bar, this is the only way to ensure an HTTPS session is made with a valid certificate. When you type https://<yourdomain>, the browser will refuse to let you on the site unless the server provides a valid certificate for <yourdomain>.

If you just type <yourdomain> without https:// in front, the browser wont care what happens. This has two implications I can think of off the top of my head:

1. The attacker redirects to some unicode domain with a similar name (ie: looks the same but has a different binary string and is thus a different domain) and then the attacker provides a valid certificate for that domain (since he owns it), the user probably wouldn't notice this...

2. The attacker could emulate the server but without HTTPS, he would make his own secured connection to the real server and become a cleartext proxy between you and the server, he can now capture all your traffic and do anything he wants because he owns your session.

Irrespirable