You can use something like Channel ID[1] to bind the D-H connection into the bearer token used for authentication (i.e., an OATH token). This won't protect ag

You can use something like Channel ID[1] to bind the D-H connection into the bearer token used for authentication (i.e., an OATH token). This won't protect against a MITM attack per se, but laptops and mobile devices tend to connect to a number of different networks, and if the MITM proxy is located close to the user, it's hard to make sure that all possible connection avenues from the laptop in question can be intercepted (including if the user hops on and off a VPN). If the user manages to connect to the server without going through the MITM, the channel ID will be different and so this can be noticed. [1] http://tools.ietf.org/id/draft-balfanz-tls-channelid-00.txt http://tools.ietf.org/id/draft-balfanz-tls-channelid-00.txt If the MITM proxy servers are located close to the server, this problem goes away, but now the problem is since the ID information is passed after the D-H encryptionis established, and laptops move around, the MITM proxy would have to attack everyone's SSL connection. This increases the likelihood that someone will notice, and more importantly would require a huge amount of computing equipment. This is not something that you could hide in a phone closet --- and given how carefully most data centers measure power utilization and air conditioning load, a massive MITM proxy farm would be easily noticed.