3dgiordano
commented
1 year ago Hi @NEC-Maeta
Decryption with Wireshark is a bit complex process.
What we usually use is Charles proxy for the capture of http requests, negotiation and all the information around http, as well as its decryption.
The http2 plugin uses Jetty behind, and so it meets the specifications at the level that the jetty team implemented them. The plugin is not a browser, and the jetty people did not implement a bowser either, so the technology that exists is the one implemented at the level of their http client.
We haven't had a need to use Wireshark lately, we know some things have been difficult lately with TLS and Java.
We know of a project used by some developers at jetty that is being used to allow Wireshark to capture the secrets in the JVM's TLS negotiations in order to decrypt packets in Wireshark. You can try it https://github.com/neykov/extract-tls-secrets
Since jetty relies on the entire JVM implementation of SSL/TLS, the decryption system is theoretically supported. We haven't had the need to test it yet for use with Wireshark.
Wireshark also recommend the same tool, and also another tool https://github.com/jsslkeylog/jsslkeylog
If you find the projects that decrypt the secrets in JVM useful, we appreciate your feedback.
Regards David
NEC-Maeta
Hi!!!!!!!!!!!!
·question How to decrypt HTTP2 sampler communication with wireshark
·the purpose I would like to confirm the behavior of HTTP2 as a protocol in order to establish an HTTP2 load test. Verifying packet decryption with wireshark.
・Tried contents
Refer to the official wireshark page and import the server-side RSA private key into wireshark. https://gitlab.com/wireshark/wireshark/-/wikis/TLS
Because the key exchange method must be RSA for decryption,Specify RSA for https.cipherSuites in system.properties.
https.cipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
・result It was not decrypted. It has been confirmed that this method can be used for decryption in HTTP/1.1.
Looking at the Client Hello from wireshark, I see system.properties not applied due to missing TLS_RSA_WITH_AES_128_CBC_SHA. The event does not change even if you specify the cipher suite from -Dhttps.cipherSuites in the command.
Cipher Suites (23 suites) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
The RFC found that RSA was deprecated. Does this mean that the HTTP2 plugin or Java disables RSA by default and thus the decryption is failing? https://datatracker.ietf.org/doc/html/rfc9113#name-tls-12-cipher-suites https://datatracker.ietf.org/doc/html/rfc9113#BadCipherSuites
If there is no way to decrypt it at present, I will give up.
◆Environment◆ Windows 10 (Azure) jmeter 5.5 jdk-20 http2 plugin 2.0.2
CentOS 8 (Azure) Apache 2.4