Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Decrypt SSL fails with testcaseSampleCaptures/snakeoil2_07

From: Daniel Kabs <dkabs@xxxxxxxxxxx>
Date: Tue, 17 Jul 2007 11:49:46 +0200
Hello Tomas,

On Tuesday 17 July 2007 08:46, Kukosa, Tomas wrote:
> it is strange as it works fine for me (on Windows).
> My debug output is attached. Could you try to compare it with your one?
> Where the difference starts?

Thanks for sending your debug output. I compared your output against mine:

The first difference occurs right at the start, where the private key is 
associated:

  ssl_init keys string:
  127.0.0.1,443,http,/tmp/rsasnakeoil2.key
  ssl_init found host entry 127.0.0.1,443,http,/tmp/rsasnakeoil2.key
  ssl_init addr 127.0.0.1 port 443 filename /tmp/rsasnakeoil2.key
  ssl_init private key file /tmp/rsasnakeoil2.key successfully loaded
  association_add TCP port 443 protocol http handle 0x8353a00
  association_find: TCP port 443 found 0x86b4f58
  ssl_association_remove removing TCP 443 - http handle 0x8353a00
  association_add TCP port 443 protocol http handle 0x8353a00
  association_find: TCP port 636 found 0x8671f98
  ssl_association_remove removing TCP 636 - ldap handle 0x8391600
  association_add TCP port 636 protocol ldap handle 0x8391600
  association_find: TCP port 993 found 0x8671fd0
  ssl_association_remove removing TCP 993 - imap handle 0x837c6d8
  association_add TCP port 993 protocol imap handle 0x837c6d8
  association_find: TCP port 995 found 0x8672008
  ssl_association_remove removing TCP 995 - pop handle 0x842b7e0
  association_add TCP port 995 protocol pop handle 0x842b7e0

I think this output is ok as the private key file was loaded successfully.

The debug output continues with only minor differences in the "association 
find" lines. Example:

yours (Windows):
  association_find: TCP port 443 found 02CBB520

mine (Linux):
  association_find: TCP port 443 found 0x86b4f58

Again I think this output is ok. The different pointer addresses are due 
to the different operating systems. 

The output continues without other differences. Event the "pre master 
encrypted[128]" in frame #8 is the same.

After those lines, the following major differences show up.

yours (Windows):
  pcry_private_decrypt: stripping 79 bytes, decr_len 127
  decypted_unstrip_pre_master[127]:
  02 c8 3b d5 a5 24 3c 40 c7 6e 95 b9 46 da b2 79 
  b1 06 ec 61 2d f7 f5 4a b7 62 b6 33 4b b3 05 ef 
  90 14 59 72 08 d5 34 88 41 cc a6 96 f4 dd 97 9a 
  dc 3a 6e 92 1f 3a e4 6b 5b fb 3f ee 46 59 62 f3 
  f3 06 0f d1 1f f4 9d b2 29 08 c6 01 f5 c3 00 03 
  00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65 18 
  87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24 cb 
  7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8 
  pre master secret[48]:
  03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65 
  18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24 
  cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8 

mine (Linux):
  pcry_private_decrypt: stripping 3 bytes, decr_len 128
  decypted_unstrip_pre_master[128]:
  05 06 00 58 14 ed 5f e1 ca 0d 53 d9 87 43 80 4d 
  4f 9e 10 67 24 fc 60 eb f1 ff 3d 1c 74 ef b5 52 
  13 01 cf 06 53 89 ca 80 a2 b8 ee 20 ff 90 92 3a 
  17 c7 0c db fe dd 99 c2 f2 47 21 c1 b7 fa 66 59 
  bc 61 22 0d 58 e2 64 35 63 1e 71 32 c5 aa 26 18 
  ba c8 e4 e2 c2 10 de ab 78 25 b4 d7 de 3b 26 c4 
  8c 24 c5 32 39 a2 08 76 3e d5 55 29 ca 12 da fe 
  2b 9c 32 b5 b9 1a 88 0d d8 01 df 31 75 6f a7 cb 
  ssl_decrypt_pre_master_secret wrong pre_master_secret lenght (125,
  expected 48)
  dissect_ssl3_handshake can't decrypt pre master secret

The first line 

  pcry_private_decrypt: stripping 3 bytes, decr_len 128

is from ssl_private_decrypt() (in packet-ssl-utils.c). I - with my limited 
knowlege of the SSL internals gained from reading the wireshark source 
code - interpret it as follows: the pre master secret has been decrypted. 
It contains padding data. The padding data ends with a byte containing 
zero. The padding is searched and stripped from the decrypted data. On my 
computer, the decrypted data contains only three bytes of padding. This 
is too short.

So I guess decryption in libgcrypt[1] is defective on my computer.

Any ideas what I can do about it?

Cheers
Daniel

[1] libgcrypt version 1.2.3 api-version 1