4 ms·

Binding a session to an IP is just a defense in depth measure. On its own it doesn't buy you a lot, but it is something and it can matter in a small set of circ

Binding a session to an IP is just a defense in depth measure. On its own it doesn't buy you a lot, but it is something and it can matter in a small set of circumstances. I would not recommend this as a generalized approach, but I was trying to answer the question. Also, httponly and secure don't help you with a mitm that is ripping apart your SSL. Also, if they type in http:// http://, they simply don't get anything. If you serve even one thing over http:// http://, you give a tool like sslstrip the foothold it needs. Again, this is appropriate for a subset of applications and situations, not a broad, consumer oriented site.

harshreality 12y ago
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.
mike-cardwell 12y ago
"Also, if they type in http:// http://, they simply don't get anything" If I were writing an SSL strip style tool, I'd make sure it listened on port 80 and 443, and then even if the end-site didn't support http, I'd still pick up the http connection and forward it on to the real site via HTTPS. I don't see the value in not providing a HTTP redirect. A MITM can still pick up a HTTP connection, even if you're not listening for it yourself...
- bitexploder 12y ago
  Because, the user's browser will remember that it should be HTTPS. With HSTS the user's browser will refuse to go to the HTTP at all. Thats how HSTS works, the browser remembers that the site has the HSTS setting. HSTS also prevents the overriding of the bad certificate message. It is like anti-ssl strip. HSTS is harder to get around than this :)
  - mike-cardwell 12y ago
    I know how HSTS works. I was responding to the claim that offering a HTTP service which redirects to HTTPS somehow reduces security, even when HSTS is in use.

harshreality 12y ago

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.

mike-cardwell 12y ago

"Also, if they type in http:// http://, they simply don't get anything" If I were writing an SSL strip style tool, I'd make sure it listened on port 80 and 443, and then even if the end-site didn't support http, I'd still pick up the http connection and forward it on to the real site via HTTPS. I don't see the value in not providing a HTTP redirect. A MITM can still pick up a HTTP connection, even if you're not listening for it yourself...

bitexploder 12y ago
Because, the user's browser will remember that it should be HTTPS. With HSTS the user's browser will refuse to go to the HTTP at all. Thats how HSTS works, the browser remembers that the site has the HSTS setting. HSTS also prevents the overriding of the bad certificate message. It is like anti-ssl strip. HSTS is harder to get around than this :)
- mike-cardwell 12y ago
  I know how HSTS works. I was responding to the claim that offering a HTTP service which redirects to HTTPS somehow reduces security, even when HSTS is in use.