5

TLS-OBC is an RFC proposal that increases SSL/TLS security by using certificates on both ends of the TLS connection. What's special here is that the client is permitted to dynamically create a local, self signed certificate.

It can also protect users from the "Related Domain Cookie Attack", more info here

Are there any known issues that would cause a problem with pre-existing Browser Certificate deployments and TLS-OBC?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536

1 Answers1

3

(TLS-OBC is not yet a RFC, just a proposal, and, as all drafts, can be subject to change.)

As presented, TLS-OBC is an extension to the SSL/TLS protocol. There is a scheme for such extensions, which can be added at the end of the ClientHello and ServerHello messages. Nothing related to TLS-OBC happens unless the client and then the server agree to use them. Possibly, some very old and buggy servers could choke on the ClientHello from the client, but the same can be said of every other extension and it does not prevent browsers from using, for instance, the Server Name Indication. So no real issue there.

Possible issues that I see with this draft include:

  • When TLS-OBC is used, the server should not send a list of accepted CA, and the client MUST ignore them anyway. This means that a given server accepts either OBC-type certificates, or standard certificates, but not both. Moreover, the server must make this decision before knowing the target path, so it is a server-wide setting.

  • The OBC is remarkably efficient at tracking clients -- that's its point, really, when it is used as a "strengthening of the cookie". This implies the same kind of privacy issues than cookies. I suppose that browsers implementing TLS-OBC will provide the same kind of choice than with cookies (i.e. a way to deny OBC usage with some specific servers).

  • Contrary to normal client certificates, OBC do not prevent institutional Man-in-the-Middle attacks (when a proxy servers creates a fake server certificate on-the-fly -- this assumes that an accomplice CA is installed in the client trust store, which is a relatively common setup in some big organization which want to monitor their employees closely). The "attacker" (possibly a legitimate attacker, as a sysadmin) just has to substitute his own OBC.

Mostly, I do not see clearly in what way OBC really increases security.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    Your points are valid except that, the third point regarding institutional man-in-the-middle attack isn't an issue with the draft because TLS OBC threat model doesn't cover attacker installing anything on client m/c i.e TLS OBC doesn't aim to solve that type of man-in-middle attack. This draft has now expired and in place a new draft TLS Channel IDs is in consideration. – useratuniv Feb 17 '13 at 21:58