Hello,
Can you confirm, you say the alert is coming from a non-java server, or are you saying your modified handshake is rejected by a Java server? (Or do you think the alert is not received?).
I would turn on ssl debug logging and upload the traces to a gist sharing side so we can review the actual content. You can also check the servers logs why it rejects it.
(It’s strange that you set two ALPN strings but only one is in your excerpt?)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: security-dev <security-dev-r...@openjdk.org> im Auftrag von Filip Petr. <filipakanat...@gmail.com>
Gesendet: Donnerstag, August 31, 2023 4:02 PM
An: security-dev@openjdk.org <security-dev@openjdk.org>
Betreff: Modification of Client hello TLS packet
Gesendet: Donnerstag, August 31, 2023 4:02 PM
An: security-dev@openjdk.org <security-dev@openjdk.org>
Betreff: Modification of Client hello TLS packet
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. 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
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)
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
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/11"});
sslParams.setProtocols(new String[]{"TLSv1.3"});
Any help would be welcome! Thanks in advance!