# 💡 Proposal We are considering to move forward with our proposed TLS fingerprint library imitation system with delegation based design. Before we actually proceed with that, it might worth spending some time to discuss about this design to see whether there is any deal breakers for the Application team. And the proposed design is as follows: 1. The TLS connection fingerprint imitation works by delegating TLS handshake to purpose-built web assembly binaries. 2. The WASM handshaker are built using third party open source TLS library implementations with an adapter that communicate with both TLS delegation host and TLS library to bidirectionally pipe the connection, and, export the connection secret at the end of connection. 3. The TLS delegation host is an application that utilize system socket API to create connection with remote host, bidirectionally forward the content of the connection between remote host and WASM handshaker and, once received the connection secret, take over the connection. 4. During the take over, TLS delegation host will examine and decrypt the handshake packets to extract important information such as ALPN, ALPS, in order to pass these information to its user. 5. Once the take over is finished, the TLS delegation host will encrypt/decrypt the connection and pass them to its user. The handshaker will be closed then. Other possible design we considered includes building another imitation based library just like how utls has been done, This design would also work, and easier to use in Rust, while require more maintenance and has more attack surface for active attackers. (See also: https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items/194) <!-- Use this template to request a feature or propose some change in the browser. The issue will likely be edited many times over its life to flesh out the various questions, so if you don't know the answers to something, jut leave it blank! The issue's title MUST provide a succinct description of proposal. Some good (hypothetical) titles: - Remove 'Safer' option from Security Level - Bundle uBlock Origin by default - Replace NoScript with faith-based JavaScript sand-boxing --> ## User Story The primary usecase of the TLS fingerprint imitation library in Tor Browser is communicating with circumvention setting and bridge distribution servers. With the unified signaling library design, the signaling library embedded in Tor browser would use this TLS imitation library for its operation. Depending on how this signaling library is integrated, this design could have different implications. <!-- Provide a high-level summary of the proposed feature, the problem it solves, and what it would allow users to do if implemented. --> ## Security and Privacy Implications <!-- How would this proposal interact with our the browser's threat model? Would this feature negatively affect the browser's security or privacy guarantees? --> ### Security <!-- Outline any security implications this feature would introduce. The browser's security requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#21-security-requirements --> The handshaker binary has linked in third party dependencies. These libraries are complex enough that they cannot be independently verified by us to be correct and bug free. Within the containment of WASM runtime, these bug could inflict a limited amount of damage to user, like sending content to remote server or generate weak or backdoored shared key, even if these handshaker has no access to local file system or other source of information by design. The risk of using complex third party library are limited, but not eliminated by the WASM runtime boundary. ### Privacy <!-- Outline any privacy implications this feature would introduce. The browser's privacy requirements can be found in our threat model document here: - https://gitlab.torproject.org/tpo/applications/wiki/-/wikis/Design-Documents/Tor-Browser-Design-Doc#22-privacy-requirements --> ## Accessibility Implications <!-- Would this proposal affect or interact with the browser's usability for users with accessibility needs (e.g. vision or mobility issues). What problems would need to be solved to ensure these users are not left behind? --> None. There shouldn't be any user observable change. ## Other Trade-Offs <!-- Beyond the security, privacy and accessibility implications, what other implications are there for users? --> Each handshaker would add 1-3 MB of size to the final binary. These WASM binary does not need to marked as executed or shipped as a part of original download package. If the signaling library is already running inside a WASM interpreter, then this WASM runtime for handshaker would add another layer of virtualization. ## Prior Art ### Does this feature exist in other browsers? - [ ] Yes - [ ] Firefox - [ ] Firefox ESR - [ ] Other (please specify) - [x] No ### Does this feature exist as an extension? If yes, which one provides this functionality? <!-- Do not edit beneath this line <3 --> ---