>If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? If you co

>If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss. >And how would you feel if people on the same LAN could see and modify all your interactions with those services? The fact that they physically can doesn't mean they will. For 2 & 3: https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed. With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.