8

Background: We have a site which works over HTTPS (HTTP not supported, we use HSTS). It's deployed in 3rd party cloud, which restricts our control and log abilities over server hardware. We cannot force using of client certificate authentication. So basically what we have is public HTTPS site with standard 2-factor authentication (login/pass + SMS), which can be accessed from desktop or mobile browser, and additional API on the same site from inside native mobile apps. Server software is based on .Net/IIS.

We're considering the following scenario - somehow user's computer/smartphone made to trust attacker's certificate, thus allowing classic MiM attack (so user is connected to proxy with trusted certificate, and proxy is connected to our server). One of the common (in some countries) scenarios for that is that Internet provider requires user to trust theirs self-signed certificate.

Leaving aside security on client-side (check certificate thumbprint etc) - is there any way for server (i.e. for our application) to understand that MiM attack is in place?

This is something like this question HTTPS - Can server see details of client side certificate?, but I'm looking not only for ways to detect such attack immediately (which would be good of course if possible), but also for ways which can help us detect such attack in long-run, having for example some historical records.

Improve this question

1 Answer 1

Reset to default
4

A perfect man an the middle attack can probably not detected, but usually these attacks (or legal SSL interceptions in firewalls) are not perfect. I would suggest to have a look at the ClientHello, especially about the ciphers offered by the client. Which ciphers are ordered and in which order a very typical for today's browsers. Man in the middle solutions usually don't care about replicating the exact ciphers but simply use their own cipher set. Other features are protocol version or the use of specific extensions like SNI or ALPN.

Note that you probably don't get much of these features from inside a normal server, i.e. usually you get mostly the final cipher and the protocol version. To get more you might need to instrument the TLS library or sniff the traffic and analyse it later.

Improve this answer
5
  • Thanks Steffen, will take a look, but for now it looks like we cannot access this information without re-implementing TLS handshake by ourselves
    – Lanorkin
    Jan 14, 2016 at 12:47
  • @Lanorkin: you can extract these information from a packet capture too, i.e. without changing anything on the server itself.
    – Steffen Ullrich
    Jan 14, 2016 at 13:05
  • @SteffanUllrich our cloud setup doesn't allow us to monitor network traffic.. or did I misunderstood packet capture thing?
    – Lanorkin
    Jan 14, 2016 at 13:11
  • 1
    @Lanorkin: with these restrictions it is harder. But even tracking the cipher, protocol and user agent of a request might make some observations possible like an unexpected cipher with a specific client.
    – Steffen Ullrich
    Jan 14, 2016 at 14:42
  • @SteffanUllrich For "good" ssl proxy user agent will be the client's one, and looks like in IIS it's not possible to get specific cipher used stackoverflow.com/questions/25009018/… But anyway I think I can use your suggestion to organize some "ping" request from client to separate subdomain / VM which wouldn't suffer that IIS/.Net restrictions, will play with that
    – Lanorkin
    Jan 14, 2016 at 15:23

You must log in to answer this question.

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