SSL decrypter pre master secret handling

[Wayne Blacklock]

Hello everyone,

I'm currently in the middle of debugging a painful SSL issue. With the same
client server combination we sometimes suffer SSL handshaking errors and
other times we don't. When things go wrong the server (Active Directory)
closes the connection without sending a response. The only clue in the AD
logs is an error 960 and 20. Which I believe corresponds to a
bad_record_mac.

The cipher is TLS_RSA_WITH_AES_128_CBC_SHA

What I have noticed, is that when everything is OK, Wireshark can decrypt
(using the servers private key) the SSL handshake no problem, note this
line from the output:

ssl_decrypt_pre_master_secret:
RSA_private_decrypt
pcry_private_decrypt: stripping 207 bytes, decr_len 255
decrypted_unstrip_pre_master[255]:
pre master secret[48]:

When everything isn't ok, the SSL decryption fails:

ssl_decrypt_pre_master_secret:RSA_private_decrypt
pcry_private_decrypt: stripping 146 bytes, decr_len 255
decrypted_unstrip_pre_master[255]:
<snip>
ssl_decrypt_pre_master_secret wrong pre_master_secret length (109, expected
48)
dissect_ssl3_handshake can't decrypt pre master secret

Now I am no SSL expert, but I don't think this is right. What I hope to
understand and the reason for this post, is how exactly the byte stripping
works... where does the SSL decrypter get 146 from and could this explain
our SSL issues? If so, what exactly is going wrong? I've had a bit of a
look through the TLS spec but it isn't clear to me and so I would
appreciate any and all advice.

Thanks,

Wayne.

[Sake Blok]

Post by Wayne Blacklock
ssl_decrypt_pre_master_secret:RSA_private_decrypt
pcry_private_decrypt: stripping 146 bytes, decr_len 255
<snip>
ssl_decrypt_pre_master_secret wrong pre_master_secret length (109, expected 48)
dissect_ssl3_handshake can't decrypt pre master secret
Now I am no SSL expert, but I don't think this is right. What I hope to understand and the reason for this post, is how exactly the byte stripping works... where does the SSL decrypter get 146 from and could this explain our SSL issues? If so, what exactly is going wrong? I've had a bit of a look through the TLS spec but it isn't clear to me and so I would appreciate any and all advice.

The only situations where I have seen the message "wrong pre_master_secret length" were when the public key in the server certificate did not match the provided private key. Can you verify that the *exact* same certificate is used in both sessions?

As for the amount of stripped data, it is calculated as follows:

/* strip the padding*/
rc = 0;
for (i = 1; i < decr_len; i++) {
if (decr_data_ptr[i] == 0) {
rc = i+1;
break;
}
}

ssl_debug_printf("pcry_private_decrypt: stripping %d bytes, decr_len %d\n",
rc, decr_len);
ssl_print_data("decrypted_unstrip_pre_master", decr_data_ptr, decr_len);
g_memmove(decr_data_ptr, &decr_data_ptr[rc], decr_len - rc);

In other words, the decrypted (unstripped) PreMasterSecret is searched for the first occurrence of the value 0. Everything after the first 0 is then used as the PreMasterSecret and it should be exactly 48 bytes long.

Here is an example:

pre master encrypted[128]:
76 1b 1b ea c3 5e 59 de 9a 3b b9 f7 4e bf 91 09
b7 38 e8 ad 34 6c 3c e8 26 f8 e9 f6 5d 82 a9 a5
44 c6 0a fe ae 85 6d 01 1f 5d 11 4d 1f 16 d2 4a
64 13 ad 32 c2 92 1d 54 b8 f2 6b d2 bb a5 7b 55
73 87 69 ff 33 bb 9f aa 57 27 3a 58 43 61 29 46
c2 12 6d f3 6d c8 98 4b df 72 7a 7c 67 72 89 5d
c5 3d 5d 8f c5 d8 43 68 86 f6 70 f0 d9 b7 91 36
1c 8a a4 bd 64 b0 27 d4 c0 2d 03 dd 92 f7 df 36
ssl_decrypt_pre_master_secret:RSA_private_decrypt
pcry_private_decrypt: stripping 79 bytes, decr_len 127
decrypted_unstrip_pre_master[127]:
02 54 f5 61 13 68 03 30 97 14 1f e9 cc 7c 2c 3b
d2 b0 f6 db 18 f7 2b 81 e0 46 ad 51 dd 26 b3 fe
94 48 ab 8a 52 db 97 e3 df 9e e4 30 64 96 3e d1
b4 9a 13 8f e4 ad c0 1d 98 10 e8 dc 0d 89 02 85
5c 03 3b 5b 9e 71 51 3a df 30 20 40 be 9e 00 03
01 90 36 b9 c6 b5 f1 2d 7d 3b 6b 3c bb 6a 7c ed
9a 4c 38 1e 07 67 c6 07 fb 51 5a 0c 2e 2b 3b 41
96 5a 6f fc d2 88 86 59 ff aa 82 7f e5 bb 42
pre master secret[48]:
03 01 90 36 b9 c6 b5 f1 2d 7d 3b 6b 3c bb 6a 7c
ed 9a 4c 38 1e 07 67 c6 07 fb 51 5a 0c 2e 2b 3b
41 96 5a 6f fc d2 88 86 59 ff aa 82 7f e5 bb 42

Hope this helps!

Cheers,
Sake

[Wayne Blacklock]

Post by Wayne Blacklock
ssl_decrypt_pre_master_secret:RSA_private_decrypt
pcry_private_decrypt: stripping 146 bytes, decr_len 255
<snip>
ssl_decrypt_pre_master_secret wrong pre_master_secret length (109, expected 48)
dissect_ssl3_handshake can't decrypt pre master secret
Now I am no SSL expert, but I don't think this is right. What I hope to
understand and the reason for this post, is how exactly the byte stripping
works... where does the SSL decrypter get 146 from and could this explain
our SSL issues? If so, what exactly is going wrong? I've had a bit of a
look through the TLS spec but it isn't clear to me and so I would
appreciate any and all advice.
The only situations where I have seen the message "wrong pre_master_secret
length" were when the public key in the server certificate did not match
the provided private key. Can you verify that the *exact* same certificate
is used in both sessions?

So I suppose this is my next question. We're using a Java based
implementation. We have the root cert in our trust store. My understanding
is the public key should come from the server during the SSL transaction
and ServerHello right? We don't have the servers certificate in our key
store, just the root cert so the key has to be coming from the server
during the ServerHello.

I have compared good and bad transactions at the packet SSL level and I can
see no differences (except for the secrets). The key coming from the server
is the same.

Thanks for your help.

[Sake Blok]

Post by Sake Blok

Post by Wayne Blacklock
ssl_decrypt_pre_master_secret:RSA_private_decrypt
pcry_private_decrypt: stripping 146 bytes, decr_len 255
<snip>
ssl_decrypt_pre_master_secret wrong pre_master_secret length (109, expected 48)
dissect_ssl3_handshake can't decrypt pre master secret
Now I am no SSL expert, but I don't think this is right. What I hope to understand and the reason for this post, is how exactly the byte stripping works... where does the SSL decrypter get 146 from and could this explain our SSL issues? If so, what exactly is going wrong? I've had a bit of a look through the TLS spec but it isn't clear to me and so I would appreciate any and all advice.

The only situations where I have seen the message "wrong pre_master_secret length" were when the public key in the server certificate did not match the provided private key. Can you verify that the *exact* same certificate is used in both sessions?
So I suppose this is my next question. We're using a Java based implementation. We have the root cert in our trust store. My understanding is the public key should come from the server during the SSL transaction and ServerHello right? We don't have the servers certificate in our key store, just the root cert so the key has to be coming from the server during the ServerHello.

To be more precise, the Public Key is part of the server Certificate which is sent to the client in the SSL Handshake message "Cerfificate", this message comes after the ServerHello, but as TCP is a streaming protocol, the (start of the) Certificate handshake message is often in the same packet as the ServerHello.

Post by Sake Blok
I have compared good and bad transactions at the packet SSL level and I can see no differences (except for the secrets). The key coming from the server is the same.

Are you able to share (handshake messages of) the good and bad SSL traces?

Cheers,
Sake