5 ms·

Hmm, I'm not convinced it's better—but it depends a lot on your threat model. For preventing malware from using stolen cookies on a botnet, it's reasonable to

by md_ 5y ago

Hmm, I'm not convinced it's better—but it depends a lot on your threat model. For preventing malware from using stolen cookies on a botnet, it's reasonable to argue that it's easier for the malware to steal the TLS client cert (which is no less accessible than the cookie jar itself) than it is for the malware to maintain access to the "good" client IP. As silly as IP-binding of sessions is.

ffo 5y ago
To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway. From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
- md_ 5y ago
  Agreed. And TB arguably could have supported hardware-backed key storage—but no implementations I am aware of did this. My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
  - ffo 5y ago
    Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone. If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
SahAssar 5y ago
It can be made much less accessible because it's not meant to be shared with the remote side. A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
- md_ 5y ago
  > It can be made much less accessible because it's not meant to be shared with the remote side. Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver. > A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs. Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.
  - SahAssar 5y ago
    I feel like your comparison is not fair. IP-based threat detection is still not defending against malware or bad browser extension, and it basically cannot be improved since it relies on something that is not a security mechanism but rather a fundamental part of internet routing. It does not cooperate well with mobile roaming, VPNs, NATs or other routing mechanisms as TFA pointed out. You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.
    - md_ 5y ago
      Yeah, I think I agree with you there. The area for improvement for token binding or something like it is quite promising; not so for using IP signals. I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.

by md_ 5y ago

ffo 5y ago

To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway. From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.

md_ 5y ago
Agreed. And TB arguably could have supported hardware-backed key storage—but no implementations I am aware of did this. My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
- ffo 5y ago
  Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone. If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)

SahAssar 5y ago

It can be made much less accessible because it's not meant to be shared with the remote side. A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.

md_ 5y ago
> It can be made much less accessible because it's not meant to be shared with the remote side. Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver. > A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs. Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.
- SahAssar 5y ago
  I feel like your comparison is not fair. IP-based threat detection is still not defending against malware or bad browser extension, and it basically cannot be improved since it relies on something that is not a security mechanism but rather a fundamental part of internet routing. It does not cooperate well with mobile roaming, VPNs, NATs or other routing mechanisms as TFA pointed out. You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.
  - md_ 5y ago
    Yeah, I think I agree with you there. The area for improvement for token binding or something like it is quite promising; not so for using IP signals. I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.