2

When i use Wireshark to decrypt an Openssl sample(by importing server private RSA key) https://github.com/matthewarcus/ssl-demo it works perfect.

And i want to do the same thing with Botan CLI tools(another encryption library) using selfsigned cert and key(RSA_2048bits). I configed server using following commands

botan tls_server selfsignedCer.cer serverPrivate.pem --port=9999

client

botan tls_client localhost --port=9999

resulting

Alert:unrecognized name
Certificate validation status: Cannot establish trust
Handshake complete ,TLS v1.2 using RSA_WITH_AES_256_CBC_SHA256
Session ID : (long hex there)

Since handshake completed, I go look into wireshark, but there is no 'SSL decrypted data' section as showed below(so it means wireshark cant decrypt that):

this is the one i cant built with Botan Below is my success sample using Openssl sample , I can see the 'decrypted SSL data' section this is the one with openssl

Is wireshark only able to decrypt TLS implemented by openssl?(but I think the implementation has no effect on TLS) Or I did something wrong? Oringinal capture file and key provided below. https://drive.google.com/open?id=0B4wOLdBNMGUUQng1ak1qVFdkX0U the first 30s are the one with botan, then i stop the communication and start another openssl sample on around 40s, all using the same key

Community
  • 1
TTZ
  • 41
  • 3
  • I don't really understand what you are asking. The title is about decrypting in wireshark. But the text is about problems with the handshake and does not mention any problems with decrypting. And then there is something about session ticket which are not related to any of this. Could you please make clear what you are actually asking and remove everything which is irrelevant? – Steffen Ullrich Aug 15 '17 at 12:12
  • I have edited it a little bit. Hope it is better now. – TTZ Aug 15 '17 at 14:30
  • I suggest that you provide the actual pcap and private key so that one can reproduce the problem. Just looking at the images does not really help to determine the cause of your problem. – Steffen Ullrich Aug 15 '17 at 15:24

1 Answers1

2

The first connection in your capture, frames 1-28, presumably botan, uses the Encrypt-then-MAC extension of RFC 7366; that is, the client offers/requests it and the server agrees. Based on looking at the SSL debug log Wireshark apparently does not implement this, at least through 2.0 (I'm not on 2.2 yet), since it apparently tries to decrypt the whole message including the MAC and then unpad which is completely wrong for EtM. It definitely does not decode the extension in the Hello messages (leaving it as "Unknown 22"), which I would expect if the related functionality were implemented.

The second connection, frames 29-48, is apparently OpenSSL, which does not implement EtM and therefore does not offer it in ClientHello; your (botan) server is apparently happy to negotiate a session without it, albeit using an AEAD ciphersuite (TLS_RSA_WITH_AES_256_GCM_SHA384 0x9C) which solves the weakness EtM was intended to address.

Intriguingly your botan client also offers the ticket extension RFC 5077, but the server didn't actually send a ticket for that handshake, while it did do so for the same offer from OpenSSL. I don't see any obvious reason for the difference -- which to be clear is permitted at the server's choice.

PS: you might see if you can get your client to prefer, or even require, AEAD ciphersuites, instead of offering only AES(256)CBC as it did in this capture. If the handshake selects an AEAD suite then EtM has no effect on the encryption so Wireshark should handle it.

Community
  • 1
dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • thank you , i changed the client's ciphersuite to TLS_RSA_WITH_AES_256_GCM_SHA384 .Then wireshark can decrypt the message, thank you for your help – TTZ Sep 01 '17 at 15:02