Hi Victor, Thanks for advising me and for the links. I'm learning a lot, despite the bad news ....
Thanks. Kind regards loredana Il giorno mer 16 feb 2022 alle ore 15:30 Viktor Dukhovni < openssl-us...@dukhovni.org> ha scritto: > On Wed, Feb 16, 2022 at 11:16:03AM +0100, mary mary wrote: > > > But now the issue would become different, and I'll try to share it > > possibly even if the subject changes, in case i could get advice. I > > needed the private key for adding it in wireshark for decoding some > > encrypted messages exchanged between "my" server and a client. If the > > private key does not exist, how we could decode the messages? > > Well, now that we're past the XY problem, there's good news and bad > news. > > Good news: > > * If you control the server, the server's private key is typically > stored in the server's private key file (possible same as its > certificate file). If the server is OpenSSL rather than Java > based, it would typically already be in PEM format, ... > > Bad news: > > * Even with the server's private key, you generally can't decrypt TLS > traffic, when, as is typical and best-practice, the negotiated > cipher has forward-secrecy (uses DH or ECDH key exchange). > > To actually decode the traffic, you'd need to configure the server or > client to record the session "master secret". A client-side example > is discussed in: > > > https://resources.infosecinstitute.com/topic/decrypting-ssl-tls-traffic-with-wireshark/ > > Alternatively, In the blog post at: > > > https://blog.didierstevens.com/2020/12/14/decrypting-tls-streams-with-wireshark-part-1/ > > there's an example which downgrades the client TLS parameters to use at > most TLS 1.2 and RSA key transport (instead of DH), which then makes it > it possible to use the server's private key to decrypt the traffic. > > -- > Viktor. >
