openssl / openssl

TLS/SSL and crypto library
https://www.openssl.org
Apache License 2.0
25.93k stars 10.15k forks source link

JA3 Fingerprint match with OpenSSL. #19458

Closed kristof202 closed 1 year ago

kristof202 commented 2 years ago

Hello Developers, i would like to ask. is there any way to send empty renegotiation_info extensions instead of TLS_EMPTY_RENEGOTIATION_INFO_SCSV Cipher even if we need to modify source of Openssl. and also is there any possibilities to serialize the extensions or extensions bytes on my own choice ? Please suggest me. Because i want to match JA3.

mattcaswell commented 2 years ago

is there any way to send empty renegotiation_info extensions instead of TLS_EMPTY_RENEGOTIATION_INFO_SCSV Cipher

No. This is currently not possible.

is there any possibilities to serialize the extensions or extensions bytes on my own choice

I'm not really sure what you mean by this. The order that OpenSSL generated extensions are serialised is fixed and cannot be changed. The contents of those extensions are mostly configurable. There is also the ability to add custom extensions that OpenSSL does not otherwise know about.

sameer-here commented 1 year ago

Per the RFC this workaround (sending TLS_EMPTY_RENEGOTIATION_INFO_SCSV ) is for TLS1.0 and SSLv3.

However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated.

I think this cipher should not be send if the client has disabled SSLv3 and TLS 1.0. @mattcaswell what do you think of that idea?

mattcaswell commented 1 year ago

The section you quote in the RFC is describing the original motivation for why you can signal this in two different ways (either via the SCSV or via an extension). However the RFC itself does not restrict usage of the SCSV to any particular protocol version. At the time of implementation OpenSSL chose the SCSV route and hasn't changed since (presumably since it worked in all protocol versions including SSLv3). These days SSLv3 support is disabled by default. It would be plausible to not send the SCSV if SSLv3 support is disabled. Instead the empty extension would need to be sent. Currently OpenSSL does not support that so it would have to be implemented. That's unlikely to be seen as a priority by the dev team, but if someone wanted to supply a PR to do it then it would be looked at.

sameer-here commented 1 year ago

Thanks Matt, I'll look into sending the empty extension.