Provide APIs to help control TLS fingerprints

[pimterry]

Is your feature request related to a problem? Please describe.

There are servers in the wild online (at least all sites using Akamai's CDN bot management feature) which actively block all connections from Node.js clients by examining their TLS fingerprint (more details).

There are some limited options to work around this today, such as reordering cipher suites, but they have security consequences which make this hard to do safely, and which limit the set of valid configurations.

While reordering ciphers has security consequences, reordering the extensions in the client hello is a semantically meaningless & safe change that would make it possible to completely defeat TLS fingerprinting.

Unfortunately, there are no APIs exposed that would allow Node.js developers to do this today.

Describe the solution you'd like

An API to configure the order that TLS extensions are set in the client hello would be perfect. An API or command line option which simply randomized the order for each connection would also be very good (equally effective for this use case I think, but a bit less flexible for advanced tricks, like emulating another TLS client's extension order).

Randomizing once at process startup might potentially be good, perhaps via a command line option, but that creates new per-process fingerprinting opportunities that could be problematic.

Describe alternatives you've considered

Currently the only alternative is changing the list of order of ciphers, which does work to defeat fingerprinting in the short term, but provides limited scope and requires detailed TLS knowledge to do safely.

[pimterry]

(Edit: link was wrong, now fixed, correct URL is https://httptoolkit.tech/blog/tls-fingerprinting-node-js/)

[NichyX]

Yes please!

[bnoordhuis]

This is most likely blocked on openssl growing the necessary infrastructure.

Extensions are currently added to the handshake packet in fixed order, see tls_construct_extensions() in deps/openssl/openssl/ssl/statem/extensions.c.

A workaround is to pipe the tls.Socket into a duplex stream, parse the handshake packet and shuffle the extensions around. Not trivial but not impossible either.

[joaoscheuermann]

This is most likely blocked on openssl growing the necessary infrastructure.

Extensions are currently added to the handshake packet in fixed order, see tls_construct_extensions() in deps/openssl/openssl/ssl/statem/extensions.c.

A workaround is to pipe the tls.Socket into a duplex stream, parse the handshake packet and shuffle the extensions around. Not trivial but not impossible either.

Do you have any exemple code on how to do it?

[tniessen]

A workaround is to pipe the tls.Socket into a duplex stream, parse the handshake packet and shuffle the extensions around. Not trivial but not impossible either.

@bnoordhuis I tried implementing that based on your description in the past, but I don't see how to get past the Finished message. OpenSSL rightfully terminates the handshake with sslv3 alert bad record mac.

[bnoordhuis]

@tniessen The only packet that's modified is the very first one, the ClientHello, everything else is passed through verbatim. It sounds like you're also modifying subsequent packets?

[tniessen]

@bnoordhuis I am only rewriting the ClientHello, but looking at the TLS spec, the ClientHello is part of the Handshake Context, which is hashed and signed for the CertificateVerify and Finished messages. That seems to cause the TLS alert.

[joaoscheuermann]

Seems like this will not be possible with Node JS, it uses Open SSL for TLS.

I wrapped a Socket in a Duplex Stream to intercept and modify the ClientHello record. At the end, im getting this error:

Any Header extension that SSL doesn't requires throw this error... Im not aware of any config options that allow OpenSSL to ignore any headers/extensions that is not requested...