If the MITM proxy can rip apart SSL then SSL is broken (or the client trusts bad CAs). What's an example of where pinning a SSL session, one that's been establ

If the MITM proxy can rip apart SSL then SSL is broken (or the client trusts bad CAs). What's an example of where pinning a SSL session, one that's been established securely, to a client IP prevents an attack? If SSL is broken, trying to restrict sessions to the IP that initiated them is inadequate security, isn't it? (Arguably it's useful to associate a session with a client IP for unencrypted, http, connections, since in that case cookies can be intercepted passively on the wire, and an attacker can try to reuse those cookies from clients with different IPs, since knocking the real client off the LAN to steal that IP might not be desirable since it could be detected. But a basic assumption with properly functioning, secure SSL connections is that no third party can steal session cookies to begin with other than due to a client or server compromise which IP restrictions won't help with.) What you're mitigating against seems to be only this: an attacker capable of MITMing SSL sessions and capable of stealing session cookies passively from legitimate sessions, but only able to establish connections to the real server from some other public IP, not the client's actual public IP. I don't understand how that could be the case. Serving a blank page or rejecting connections to port 80 still doesn't help, does it? The security vulnerability appears whenever the client even attempts a port 80 connection, since a MITM proxy will happily accept it and MITM it to the real https site. Once a client gets the HSTS header that attack is prevented, but the first contact is always a risk, and I don't see how refusing to support http on the server mitigates that.