JA3 Fingerprint match with OpenSSL.

[kristof202]

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]

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]

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]

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]

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