Modification of Client hello TLS packet

[Stephen Farrell]

Hiya,

On 31/08/2023 15:00, Filip Petr. wrote:
> My goal is for a community of automation experts to have a perfectly
> matched Client hello (JA3 hash) fingerprint as modern commercial browsers
> so they can do their job more successfully. For this to happen one must add
> 8 additional extensions to the Client hello request.

Can't help with your query, sorry, but worth noting that
work on encrypted client hello (ECH) is progressing towards
completion in the IETF, and a pre-standards version is
deployed now in browsers (albeit behind a flag for both FF
and chromium-derived browsers).

If, as I'd hope, ECH gets finalised early next year and
then deployed, that'll change the profile of the ClientHello
possibly significantly.

As this is something on which I'm working [1] I'd be happy
to discuss how to get ECH support working, then deployed,
in this context too, so if that's of interest, just ping
me.

Cheers,
S.

[1] https://defo.ie



> Those changes were
> done under /sun/security/ssl. Mostly modifying SSLExtension.java file by
> adding additional extensions. My goal is to have perfectly working adjusted
> extensions and to use TLS1.3 on top of that. The extensions that my Java
> client using standard Java net library had prior me adding new ones were:
> 1.key_share
> 2. signature_algorithms_cert
> 3. psk_key_exchange_modes
> 4. supported_versions
> 5. signature_algorithms
> 6. application_layer_protocol_negotiation
> 7. supported_group
> 8. status_request
> 9. server_name
> 
> After the change to match Chrome's extensions it became:
> 1. TLS_GREASE (0x5a5a)
> 2. status_request
> 3. ec_point_formats
> 4. supported_groups
> 5. signed_certificate_timestamp
> 6. application_settings
> 7. server_name
> 8. application_layer_protocol_negotiation
> 9. key_share
> 10. extended_master_secret
> 11. extensionRenegotiationInfo
> 12. session_ticket
> 13. supported_versions
> 14. signature_algorithms
> 15. psk_key_exchange_modes
> 16. TLS_GREASE (0x3a3a)
> 17. padding
> 
> The reason for me making this post is because when I
> add application_settings extension, the module doesn't work for certain
> websites such as for google domains and for some it works perfectly fine. I
> analysed in Wireshark the requests they were all properly done but for some
> weird reason, Java gives back following exceptions once I encounter some
> sites it crashes on
> 
> 1. Received fatal alert: decode_error
> 2. Unknown handshake type size, Handshake.msg_type = 25
> 3. Received fatal alert: unexpected_message
> 
> 
> Unfortunately I don't know how to track fatal alerts and their cores so I'm
> not sure how I can handle this. Why does Java crash on this simple
> extension such as application_settings? It holds nothing but following
> 
>   {
>          "name": "application_settings (17513)",
>          "protocols": [
>            "h2"
>          ]
>        }
> 
> 
> That's pretty much it. Once I remove this extension, the module works
> just fine with the rest added ones. I should add on top that i do
> these 2 following lines as my ssl configuration prior creating java
> client
> 
> sslParams.setApplicationProtocols(new String[] {"h2", "http/1.1"});
> sslParams.setProtocols(new String[]{"TLSv1.3"});
> 
> Any help would be welcome! Thanks in advance!
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1197 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230831/9b292b28/OpenPGP_0xE4D8E9F997A833DD.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230831/9b292b28/OpenPGP_signature.sig>