The IETF TOKBIND working group (https://datatracker.ietf.org/wg/tokbind/about) attempted to solve the problem of stolen bearer tokens by associating them with the TLS connection itself, so they couldn't be moved to another system. Eventually Google refused TOKBIND. If something won't be added to Chrome it won't matter. The rumored justification was TOKBIND would change/break web development.
Doing mutual TLS, as you suggest, breaks enterprise-deployed in-line TLS proxies (Bluecoat, et al). To avoid that breakage, while still providing mutual TLS, the new hotness seems a normal TLS 1.3 handshake (which appeases TLS proxies) and then upgrading to mutual TLS within that TLS connection (https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2).
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
tokbind, mtls, tls 1.3's new dance
Date: 2022-05-16 04:40 pm (UTC)Doing mutual TLS, as you suggest, breaks enterprise-deployed in-line TLS proxies (Bluecoat, et al). To avoid that breakage, while still providing mutual TLS, the new hotness seems a normal TLS 1.3 handshake (which appeases TLS proxies) and then upgrading to mutual TLS within that TLS connection (https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2).