Explicit IV in TLS 1.1+

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Explicit IV in TLS 1.1+

Curt Johansson
Hi all,

I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is
using OpenSSL to implement the TLS support. It all seems to work except for the following:

When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which
is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1)
the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes
of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from
the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but
shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated
at all in the key_block so in that case I don't even know where to find it.

The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message?

I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have
misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it.

TIA
Curt Johansson
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicit IV in TLS 1.1+

Matt Caswell-2


On 13/02/18 22:02, Curt Johansson wrote:

> Hi all,
>
> I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is
> using OpenSSL to implement the TLS support. It all seems to work except for the following:
>
> When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which
> is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1)
> the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes
> of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from
> the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but
> shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated
> at all in the key_block so in that case I don't even know where to find it.
>
> The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message?

Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 or
TLSv1.2, then that is what happens. You don't say what version of
OpenSSL you are using. Here is the code that does it for 1.1.1 (i.e.
master branch):

https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954

As can be seen on line 969 we just fill the IV with random bytes.

Perhaps you could provide a wireshark trace of the handshake which might
provide some enlightenment as to what is happening.

Matt


>
> I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have
> misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it.
>
> TIA
> Curt Johansson
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicit IV in TLS 1.1+

Curt Johansson
Hi Matt, thanks for your prompt answer. The testclient is using openssl-1.0.2m and my previous assumption that the IV was derived from the key_block as in TLS 1.0 was wrong.
It seems that when initialising the cipher with the IV is ignored when the crypto is AES and the first 16 bytes of the encrypted payload is used as IV (as per TLS spec). This is a Java issue
and has nothing to do with OpenSSL but assuming this is correct behaviour (I'll have to dig in to that) I use the same logic (in this respect) for TLS1.1 and TLS1.2  assuming that
the client also does which it obviously does not.

Below is the logging from my server handling two authentications (the Finished message that is the first encrypted). The first (TLS1.1) succeeds and the second (1.2) fails. You can see that the decrypted text is correctly padded in the first case (TLS 1.1) indicating that the decryption succeeded but the second (1.2) decrypted buffer does not. The "Finished" message for this (AES; SHA) mac- and block size should be padded with 11 bytes which the first is.
Also as seen I use the same provider and algoritm in the two cases, actually I handle the decryption in the same way for the two TLS-levels


Also added the wireshark output for the two authentications where I've verified that the logged encrypted data really is whats coming in on the line.


Basically when selecting 1.1 in the client everything works as expected but selecting 1.2 the prepended IV is not correct as far as I understand. The testclient vendor says they are using
OpenSLL for TLS handling so I expect that they're not fiddling with any IV bytes at all. Given the version 1.0.2m, can this be explained?


Best
Curt




TLS 1.1
 
04:09:40.295 Cipher provider: SunJCE
04:09:40.295 Cipher algoritm: AES/CBC/NoPadding
04:09:40.295 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
04:09:40.295 Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f, 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f, c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c, 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b]
04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73, b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35, 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3, 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b]

TLS 1.2
04:09:47.779 Cipher provider: SunJCE
04:09:47.779 Cipher algoritm: AES/CBC/NoPadding
04:09:47.779 IV from key_block used in cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d, 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0, a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a, 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c]
04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe, 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad, 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca, 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3, 9c, 8b]



> On 14 Feb 2018, at 0:26 , Matt Caswell <[hidden email]> wrote:
>
>
>
> On 13/02/18 22:02, Curt Johansson wrote:
>> Hi all,
>>
>> I'm developing support for TLS 1.1 and 1.2 in a radius-server that until now only handles TLS 1.0. I'm testing with a testtool that the vendor says is
>> using OpenSSL to implement the TLS support. It all seems to work except for the following:
>>
>> When all key exchange messages are sent from the server and back from the client the client sends the "Finished" message which
>> is the first encrypted with the negotiated symmetric cipher suite. I use AES-128 in block mode and according to the spec (RFC4346 for TLS 1.1)
>> the IV is prepended to the encrypted message (containing the payload, MAC and padding). The message size i right and when (in the server) I use the first 16 bytes
>> of the message received from the client as IV the decryption fails but when I use the mechanism from TLS 1.0 to pick up the IV from
>> the key_block the decryption is successful. I understand that this is one way to generate the IV that I suppose you use which is fine but
>> shouldn't this 16 byte vector be prepended, unecrypted, to the encrypted data that is sent to the server? In TLS 1.2 there is not IV material generated
>> at all in the key_block so in that case I don't even know where to find it.
>>
>> The simple question is, shouldn't the first 16 bytes (assuming AES) of the message (after the 5 byte header) be the unencrypted IV to be used in the decryption of the rest of the message?
>
> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1 or
> TLSv1.2, then that is what happens. You don't say what version of
> OpenSSL you are using. Here is the code that does it for 1.1.1 (i.e.
> master branch):
>
> https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954
>
> As can be seen on line 969 we just fill the IV with random bytes.
>
> Perhaps you could provide a wireshark trace of the handshake which might
> provide some enlightenment as to what is happening.
>
> Matt
>
>
>>
>> I tried to dig in to the OpenSSL source but it's far too long ago I did some serious C coding so I hope someone with a working knowledge can enlighten me. I might have
>> misunderstood the spec but in that case I would be grateful if someone could clarify this specific part of it.
>>
>> TIA
>> Curt Johansson
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

TLS11-TLS12.pcapng (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Explicit IV in TLS 1.1+

Matt Caswell-2


On 15/02/18 03:52, Curt Johansson wrote:

> Hi Matt, thanks for your prompt answer. The testclient is using
> openssl-1.0.2m and my previous assumption that the IV was derived
> from the key_block as in TLS 1.0 was wrong. It seems that when
> initialising the cipher with the IV is ignored when the crypto is AES
> and the first 16 bytes of the encrypted payload is used as IV (as per
> TLS spec). This is a Java issue and has nothing to do with OpenSSL
> but assuming this is correct behaviour (I'll have to dig in to that)
> I use the same logic (in this respect) for TLS1.1 and TLS1.2
> assuming that the client also does which it obviously does not.
>
> Below is the logging from my server handling two authentications (the
> Finished message that is the first encrypted). The first (TLS1.1)
> succeeds and the second (1.2) fails. You can see that the decrypted
> text is correctly padded in the first case (TLS 1.1) indicating that
> the decryption succeeded but the second (1.2) decrypted buffer does
> not. The "Finished" message for this (AES; SHA) mac- and block size
> should be padded with 11 bytes which the first is. Also as seen I use
> the same provider and algoritm in the two cases, actually I handle
> the decryption in the same way for the two TLS-levels
>
>
> Also added the wireshark output for the two authentications where
> I've verified that the logged encrypted data really is whats coming
> in on the line.
>
>
> Basically when selecting 1.1 in the client everything works as
> expected but selecting 1.2 the prepended IV is not correct as far as
> I understand. The testclient vendor says they are using OpenSLL for
> TLS handling so I expect that they're not fiddling with any IV bytes
> at all. Given the version 1.0.2m, can this be explained?

My best guess is that the calculated client write key is probably
incorrect on the server side (which probably implies either the master
or pre-master secret is wrong). You might need to instrument OpenSSL to
dump out the internal secrets at various points and compare them with
your calculations on the server to verify that they are the same.

Matt

>
>
> Best Curt
>
>
>
>
>
> TLS 1.1
>
> 04:09:40.295 Cipher provider: SunJCE 04:09:40.295 Cipher algoritm:
> AES/CBC/NoPadding 04:09:40.295 IV from key_block used in cipher init:
> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:40.295
> Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f,
> 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f,
> c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c,
> 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b]
> 04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73,
> b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35,
> 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3,
> 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b]
>
> TLS 1.2 04:09:47.779 Cipher provider: SunJCE 04:09:47.779 Cipher
> algoritm: AES/CBC/NoPadding 04:09:47.779 IV from key_block used in
> cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
> 04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d,
> 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0,
> a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a,
> 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c]
> 04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe,
> 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad,
> 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca,
> 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3,
> 9c, 8b]
>
>
>
>> On 14 Feb 2018, at 0:26 , Matt Caswell <[hidden email]> wrote:
>>
>>
>>
>> On 13/02/18 22:02, Curt Johansson wrote:
>>> Hi all,
>>>
>>> I'm developing support for TLS 1.1 and 1.2 in a radius-server
>>> that until now only handles TLS 1.0. I'm testing with a testtool
>>> that the vendor says is using OpenSSL to implement the TLS
>>> support. It all seems to work except for the following:
>>>
>>> When all key exchange messages are sent from the server and back
>>> from the client the client sends the "Finished" message which is
>>> the first encrypted with the negotiated symmetric cipher suite. I
>>> use AES-128 in block mode and according to the spec (RFC4346 for
>>> TLS 1.1) the IV is prepended to the encrypted message (containing
>>> the payload, MAC and padding). The message size i right and when
>>> (in the server) I use the first 16 bytes of the message received
>>> from the client as IV the decryption fails but when I use the
>>> mechanism from TLS 1.0 to pick up the IV from the key_block the
>>> decryption is successful. I understand that this is one way to
>>> generate the IV that I suppose you use which is fine but
>>> shouldn't this 16 byte vector be prepended, unecrypted, to the
>>> encrypted data that is sent to the server? In TLS 1.2 there is
>>> not IV material generated at all in the key_block so in that case
>>> I don't even know where to find it.
>>>
>>> The simple question is, shouldn't the first 16 bytes (assuming
>>> AES) of the message (after the 5 byte header) be the unencrypted
>>> IV to be used in the decryption of the rest of the message?
>>
>> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1
>> or TLSv1.2, then that is what happens. You don't say what version
>> of OpenSSL you are using. Here is the code that does it for 1.1.1
>> (i.e. master branch):
>>
>> https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954
>>
>>
>>
As can be seen on line 969 we just fill the IV with random bytes.

>>
>> Perhaps you could provide a wireshark trace of the handshake which
>> might provide some enlightenment as to what is happening.
>>
>> Matt
>>
>>
>>>
>>> I tried to dig in to the OpenSSL source but it's far too long ago
>>> I did some serious C coding so I hope someone with a working
>>> knowledge can enlighten me. I might have misunderstood the spec
>>> but in that case I would be grateful if someone could clarify
>>> this specific part of it.
>>>
>>> TIA Curt Johansson
>>>
>> -- openssl-users mailing list To unsubscribe:
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Explicit IV in TLS 1.1+

Curt Johansson
Hi Matt,
I had an error in my PRF that is new for TLS 1.2. Now it works.
Thanks for pointing me in the right directionand THANK YOU all for
devoting time to this important project.

Best regards
Curt


> On 15 Feb 2018, at 12:12 , Matt Caswell <[hidden email]> wrote:
>
>
>
> On 15/02/18 03:52, Curt Johansson wrote:
>> Hi Matt, thanks for your prompt answer. The testclient is using
>> openssl-1.0.2m and my previous assumption that the IV was derived
>> from the key_block as in TLS 1.0 was wrong. It seems that when
>> initialising the cipher with the IV is ignored when the crypto is AES
>> and the first 16 bytes of the encrypted payload is used as IV (as per
>> TLS spec). This is a Java issue and has nothing to do with OpenSSL
>> but assuming this is correct behaviour (I'll have to dig in to that)
>> I use the same logic (in this respect) for TLS1.1 and TLS1.2
>> assuming that the client also does which it obviously does not.
>>
>> Below is the logging from my server handling two authentications (the
>> Finished message that is the first encrypted). The first (TLS1.1)
>> succeeds and the second (1.2) fails. You can see that the decrypted
>> text is correctly padded in the first case (TLS 1.1) indicating that
>> the decryption succeeded but the second (1.2) decrypted buffer does
>> not. The "Finished" message for this (AES; SHA) mac- and block size
>> should be padded with 11 bytes which the first is. Also as seen I use
>> the same provider and algoritm in the two cases, actually I handle
>> the decryption in the same way for the two TLS-levels
>>
>>
>> Also added the wireshark output for the two authentications where
>> I've verified that the logged encrypted data really is whats coming
>> in on the line.
>>
>>
>> Basically when selecting 1.1 in the client everything works as
>> expected but selecting 1.2 the prepended IV is not correct as far as
>> I understand. The testclient vendor says they are using OpenSLL for
>> TLS handling so I expect that they're not fiddling with any IV bytes
>> at all. Given the version 1.0.2m, can this be explained?
>
> My best guess is that the calculated client write key is probably
> incorrect on the server side (which probably implies either the master
> or pre-master secret is wrong). You might need to instrument OpenSSL to
> dump out the internal secrets at various points and compare them with
> your calculations on the server to verify that they are the same.
>
> Matt
>
>>
>>
>> Best Curt
>>
>>
>>
>>
>>
>> TLS 1.1
>>
>> 04:09:40.295 Cipher provider: SunJCE 04:09:40.295 Cipher algoritm:
>> AES/CBC/NoPadding 04:09:40.295 IV from key_block used in cipher init:
>> [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 04:09:40.295
>> Encrypted: [f5, 21, 77, 27, f7, bf, 31, 1f, b9, 74, 14, 50, be, 5f,
>> 66, 21, 1b, 4e, b, 33, 78, 3b, b8, 31, a3, 7c, c2, 93, f6, ec, a, 8f,
>> c4, 28, 71, cb, 82, b4, 12, c2, 6b, 56, f2, 9e, c8, b0, 2b, 64, 7c,
>> 89, ef, bb, 68, 6b, 73, 6b, 80, 3a, 1b, 7, 33, 4e, 36, 6b]
>> 04:09:40.296 Decrypted: [a6, c7, bc, 87, 7, 2, 85, c, c3, c7, 91, 73,
>> b3, 85, 19, 21, 14, 0, 0, c, 1, 6f, 1e, 4e, 97, d0, c4, 10, a9, 35,
>> 37, bc, 2a, 87, 79, 78, 4c, 4, 88, a1, fd, 35, 42, 26, 56, 51, b3,
>> 36, d, 3b, be, 4a, b, b, b, b, b, b, b, b, b, b, b, b]
>>
>> TLS 1.2 04:09:47.779 Cipher provider: SunJCE 04:09:47.779 Cipher
>> algoritm: AES/CBC/NoPadding 04:09:47.779 IV from key_block used in
>> cipher init: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>> 04:09:47.779 Encrypted: [80, 83, 98, 6b, 55, 98, 73, b4, f6, 22, 2d,
>> 88, b, 4d, af, 6f, 2d, d6, 1e, 9, 1d, b1, 94, f4, 49, 20, 15, d2, a0,
>> a0, 35, c5, 95, 3d, d3, 35, fd, 92, ef, a6, 0, 7d, 49, 3, 70, 5e, 5a,
>> 57, e3, f9, 89, 3f, 83, 11, cf, 82, 4e, a3, 87, 6e, 9e, 97, 9c, 7c]
>> 04:09:47.779 Decrypted: [f1, 4e, b3, 18, 26, d7, ae, 12, bf, 5d, fe,
>> 2a, 18, a1, 6f, 19, 60, 73, 26, c8, 74, 7c, c6, a6, a1, 65, d3, ad,
>> 45, f9, e3, 42, aa, e0, bd, 1d, a0, 18, b3, f3, 94, 28, 4e, 2a, ca,
>> 24, 25, 70, 7c, a9, f6, 19, 17, f5, ef, ee, b, 30, 2f, ec, 4d, b3,
>> 9c, 8b]
>>
>>
>>
>>> On 14 Feb 2018, at 0:26 , Matt Caswell <[hidden email]> wrote:
>>>
>>>
>>>
>>> On 13/02/18 22:02, Curt Johansson wrote:
>>>> Hi all,
>>>>
>>>> I'm developing support for TLS 1.1 and 1.2 in a radius-server
>>>> that until now only handles TLS 1.0. I'm testing with a testtool
>>>> that the vendor says is using OpenSSL to implement the TLS
>>>> support. It all seems to work except for the following:
>>>>
>>>> When all key exchange messages are sent from the server and back
>>>> from the client the client sends the "Finished" message which is
>>>> the first encrypted with the negotiated symmetric cipher suite. I
>>>> use AES-128 in block mode and according to the spec (RFC4346 for
>>>> TLS 1.1) the IV is prepended to the encrypted message (containing
>>>> the payload, MAC and padding). The message size i right and when
>>>> (in the server) I use the first 16 bytes of the message received
>>>> from the client as IV the decryption fails but when I use the
>>>> mechanism from TLS 1.0 to pick up the IV from the key_block the
>>>> decryption is successful. I understand that this is one way to
>>>> generate the IV that I suppose you use which is fine but
>>>> shouldn't this 16 byte vector be prepended, unecrypted, to the
>>>> encrypted data that is sent to the server? In TLS 1.2 there is
>>>> not IV material generated at all in the key_block so in that case
>>>> I don't even know where to find it.
>>>>
>>>> The simple question is, shouldn't the first 16 bytes (assuming
>>>> AES) of the message (after the 5 byte header) be the unencrypted
>>>> IV to be used in the decryption of the rest of the message?
>>>
>>> Yes, assuming you have negotiated an AES CBC ciphersuite in TLSv1.1
>>> or TLSv1.2, then that is what happens. You don't say what version
>>> of OpenSSL you are using. Here is the code that does it for 1.1.1
>>> (i.e. master branch):
>>>
>>> https://github.com/openssl/openssl/blob/master/ssl/record/ssl3_record.c#L954
>>>
>>>
>>>
> As can be seen on line 969 we just fill the IV with random bytes.
>>>
>>> Perhaps you could provide a wireshark trace of the handshake which
>>> might provide some enlightenment as to what is happening.
>>>
>>> Matt
>>>
>>>
>>>>
>>>> I tried to dig in to the OpenSSL source but it's far too long ago
>>>> I did some serious C coding so I hope someone with a working
>>>> knowledge can enlighten me. I might have misunderstood the spec
>>>> but in that case I would be grateful if someone could clarify
>>>> this specific part of it.
>>>>
>>>> TIA Curt Johansson
>>>>
>>> -- openssl-users mailing list To unsubscribe:
>>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>>
>>
>>
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users