Difference in packet contents - Openssl

This is a discussion on Difference in packet contents - Openssl ; Hi, While observing some packet dump, I noticed that while sending the same application data over twice, different packet dumps were obtained in both cases. This was done in the same SSL session, so the connection keys being used are ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Difference in packet contents

  1. Difference in packet contents

    Hi,

    While observing some packet dump, I noticed that while sending the same
    application data over twice, different packet dumps were obtained in both
    cases. This was done in the same SSL session, so the connection keys being
    used are all the same. Is this expected behavior or am I reading the packet
    dumps wrong?


    Thanks and Regards,
    Vijay K.


  2. Re: Difference in packet contents

    Hi,

    If you are using Stream Cipher or CBC mode block cipher, then the same
    application data will produce different encrypted data, since the two
    encryption (cipher) algorithms perform encryption using the previous
    block and current block (CBC mode block cipher) or previous stream
    data (Stream Cipher).
    That is the reason why you are observing different packet dumps for
    same application data.

    thanks,
    Lakshmi Prasanna

    On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari wrote:
    > Hi,
    >
    > While observing some packet dump, I noticed that while sending the same
    > application data over twice, different packet dumps were obtained in both
    > cases. This was done in the same SSL session, so the connection keys being
    > used are all the same. Is this expected behavior or am I reading the packet
    > dumps wrong?
    >
    >
    > Thanks and Regards,
    > Vijay K.
    >
    >
    >




    --
    thanks,
    Lakshmi Prasanna
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: Difference in packet contents

    Hi,

    You mean you are using RSA for encryption???
    Normally, this will not be the case. DHE-RSA is used for Key exchange
    and/or Authentication but nor for encryption. Just verify the Server
    Hello Message you received, it consists a string like
    DHE_RSA_WITH_. The "something" part indicates the
    Encryption algorithm and the MAC algorithm to be used.

    RSA will not be used for encryption since it is very slow in
    encrypting large amount of data...

    -- Lakshmi Prasanna

    On Mon, Jun 16, 2008 at 3:24 PM, Vijay Kotari wrote:
    > Hi,
    >
    > No, I don't think that is it. I am using Public-key cryptography. To be
    > specific, I am using the DHE-RSA.
    >
    > Thanks,
    > Vijay K.
    >
    > On Mon, Jun 16, 2008 at 3:11 PM, lakshmi prasanna
    > wrote:
    >>
    >> Hi,
    >>
    >> If you are using Stream Cipher or CBC mode block cipher, then the same
    >> application data will produce different encrypted data, since the two
    >> encryption (cipher) algorithms perform encryption using the previous
    >> block and current block (CBC mode block cipher) or previous stream
    >> data (Stream Cipher).
    >> That is the reason why you are observing different packet dumps for
    >> same application data.
    >>
    >> thanks,
    >> Lakshmi Prasanna
    >>
    >> On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari
    >> wrote:
    >> > Hi,
    >> >
    >> > While observing some packet dump, I noticed that while sending the same
    >> > application data over twice, different packet dumps were obtained in
    >> > both
    >> > cases. This was done in the same SSL session, so the connection keys
    >> > being
    >> > used are all the same. Is this expected behavior or am I reading the
    >> > packet
    >> > dumps wrong?
    >> >
    >> >
    >> > Thanks and Regards,
    >> > Vijay K.
    >> >
    >> >
    >> >

    >>
    >>
    >>
    >> --
    >> thanks,
    >> Lakshmi Prasanna

    >
    >




    --
    thanks,
    Lakshmi Prasanna
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: Difference in packet contents

    Hi,

    I am using DHE-RSA-AES256-SHA, which would mean that it uses DHE-RSA
    for the handshake and then AES256 for the application data transfer
    coupled with SHA for message authentication according to you. Can you
    please point me to some link that confirms the same?

    But that still does not resolve my issue. I don't mean to bombard you
    with too much data but this is the packet dump that I got for both
    instances.


    0000 - 17 03 01 00 20 86 bd 69-7e 07 71 32 f0 e0 27
    14 .... ..i~.q2..'.
    0010 - 38 17 ad e7 68 9d 19 09-6c c5 fa 56 64 60 fc 7e
    8...h...l..Vd`.~
    0020 - e2 92 f9 fa b9 17 03 01-00 20 2b fc 38 6e ad a6 ......... +.
    8n..
    0030 - 05 8e 4e cd ae ce 59 61-1c 22 69 7b f8 2d 7a eb ..N...Ya."i{.-
    z.
    0040 - 1b de 40 ac 0b 8d d3 03-79
    b7 ..@.....y.


    0000 - 17 03 01 00 20 85 a8 56-37 07 7a 63 96 fd 12
    ad .... ..V7.zc....
    0010 - 75 2c 42 97 8c 69 2a 6c-87 36 2e 2d ad f5 12 1b u,B..i*l.
    6.-....
    0020 - d9 c5 ee c8 88 17 03 01-00 20 2e 3f 39 51 1a 6f ......... .?
    9Q.o
    0030 - 99 8d d0 56 26 9e 15 97-3c fd b4 b7 00 92 50
    9d ...V&...<.....P.
    0040 - 98 52 6f 51 b8 1d 23 83-8b
    dc .RoQ..#...

    The payload sizes in both cases is 20 bytes but the bytes that follow
    are not the same. Actually, this is the packet dump that I got by
    using the sample s_server and s_client programs with the debug option
    for getting the packet dumps. Perhaps, you can simulate the same at
    your end?

    Gladly appreciate any help on this.


    Thanks and regards,
    Vijay K.


    P.S. : For some reason, I clicked on "reply" instead of "reply all"
    and hence two of my emails are missing from the conversation above. In
    any case, this email should cover up all those loose ends. Sorry for
    the missing emails.

    On Jun 16, 3:07*pm, alaks...@intoto.com ("lakshmi prasanna") wrote:
    > Hi,
    >
    > You mean you are using RSA for encryption???
    > Normally, this will not be the case. DHE-RSA is used for Key exchange
    > and/or Authentication but nor for encryption. Just verify the Server
    > Hello Message you received, it consists a string like
    > DHE_RSA_WITH_. The "something" part indicates the
    > Encryption algorithm and the MAC algorithm to be used.
    >
    > RSA will not be used for encryption since it is very slow in
    > encrypting large amount of data...
    >
    > -- Lakshmi Prasanna
    >
    >
    >
    > On Mon, Jun 16, 2008 at 3:24 PM, Vijay Kotari wrote:
    > > Hi,

    >
    > > No, I don't think that is it. I am using Public-key cryptography. To be
    > > specific, I am using the DHE-RSA.

    >
    > > Thanks,
    > > Vijay K.

    >
    > > On Mon, Jun 16, 2008 at 3:11 PM, lakshmi prasanna
    > > wrote:

    >
    > >> Hi,

    >
    > >> If you are using Stream Cipher or CBC mode block cipher, then the same
    > >> application data will produce different encrypted data, since the two
    > >> encryption (cipher) algorithms perform encryption using the previous
    > >> block and current block (CBC mode block cipher) or previous stream
    > >> data (Stream Cipher).
    > >> That is the reason why you are observing different packet dumps for
    > >> same application data.

    >
    > >> thanks,
    > >> Lakshmi Prasanna

    >
    > >> On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari
    > >> wrote:
    > >> > Hi,

    >
    > >> > While observing some packet dump, I noticed that while sending the same
    > >> > application data over twice, different packet dumps were obtained in
    > >> > both
    > >> > cases. This was done in the same SSL session, so the connection keys
    > >> > being
    > >> > used are all the same. Is this expected behavior or am I reading the
    > >> > packet
    > >> > dumps wrong?

    >
    > >> > Thanks and Regards,
    > >> > Vijay K.

    >
    > >> --
    > >> thanks,
    > >> Lakshmi Prasanna

    >
    > --
    > thanks,
    > Lakshmi Prasanna
    > __________________________________________________ ____________________
    > OpenSSL Project * * * * * * * * * * * * * * * *http://www.openssl.org
    > User Support Mailing List * * * * * * * * * *openssl-us...@openssl.org
    > Automated List Manager * * * * * * * * * * * * *majord...@openssl.org



  5. Re: Difference in packet contents

    00 - 17 03 01 00 20 86 bd 69-7e 07 71 32 f0 e0 27 14
    10 - 38 17 ad e7 68 9d 19 09-6c c5 fa 56 64 60 fc 7e
    20 - e2 92 f9 fa b9 17 03 01-00 20 2b fc 38 6e ad a6
    30 - 05 8e 4e cd ae ce 59 61-1c 22 69 7b f8 2d 7a eb
    40 - 1b de 40 ac 0b 8d d3 03-79 b7

    ************************************************** ************
    00 - 17 03 01 00 20 85 a8 56-37 07 7a 63 96 fd 12 ad
    10 - 75 2c 42 97 8c 69 2a 6c-87 36 2e 2d ad f5 12 1b
    20 - d9 c5 ee c8 88 17 03 01-00 20 2e 3f 39 51 1a 6f
    30 - 99 8d d0 56 26 9e 15 97-3c fd b4 b7 00 92 50 9d
    40 - 98 52 6f 51 b8 1d 23 83-8b dc

    Sorry again for the bad formatting.

    Regards,
    Vijay K.

    On Jun 16, 3:38*pm, Vijay Kotari wrote:
    > Hi,
    >
    > I am using DHE-RSA-AES256-SHA, which would mean that it uses DHE-RSA
    > for the handshake and then AES256 for the application data transfer
    > coupled with SHA for message authentication according to you. Can you
    > please point me to some link that confirms the same?
    >
    > But that still does not resolve my issue. I don't mean to bombard you
    > with too much data but this is the packet dump that I got for both
    > instances.
    >
    > 0000 - 17 03 01 00 20 86 bd 69-7e 07 71 32 f0 e0 27
    > 14 * .... ..i~.q2..'.
    > 0010 - 38 17 ad e7 68 9d 19 09-6c c5 fa *56 64 60 fc 7e
    > 8...h...l..Vd`.~
    > 0020 - e2 92 f9 *fa *b9 17 03 01-00 20 2b fc 38 6e ad a6 * .........+.
    > 8n..
    > 0030 - 05 8e 4e cd ae ce 59 61-1c 22 69 7b f8 2d 7a eb * ..N...Ya."i{.-
    > z.
    > 0040 - 1b de 40 ac 0b 8d d3 03-79
    > b7 * * * * * * * * * * * * * * ..@.....y.
    >
    > 0000 - 17 03 01 00 20 85 a8 56-37 07 7a 63 96 fd *12
    > ad * .... ..V7.zc....
    > 0010 - 75 2c 42 97 8c 69 2a 6c-87 36 2e 2d ad f5 *12 1b * u,B..i*l.
    > 6.-....
    > 0020 - d9 c5 ee c8 88 17 03 01-00 20 2e 3f *39 51 1a 6f * *..........?
    > 9Q.o
    > 0030 - 99 8d d0 56 26 9e 15 97-3c fd *b4 b7 00 92 50
    > 9d * ...V&...<.....P.
    > 0040 - 98 52 6f *51 b8 1d 23 83-8b
    > dc * * * * * * * * * * * * * * *.RoQ..#...
    >
    > The payload sizes in both cases is 20 bytes but the bytes that follow
    > are not the same. Actually, this is the packet dump that I got by
    > using the sample s_server and s_client programs with the debug option
    > for getting the packet dumps. Perhaps, you can simulate the same at
    > your end?
    >
    > Gladly appreciate any help on this.
    >
    > Thanks and regards,
    > Vijay K.
    >
    > P.S. : For some reason, I clicked on "reply" instead of "reply all"
    > and hence two of my emails are missing from the conversation above. In
    > any case, this email should *cover up all those loose ends. Sorry for
    > the missing emails.
    >
    > On Jun 16, 3:07*pm, alaks...@intoto.com ("lakshmi prasanna") wrote:
    >
    > > Hi,

    >
    > > You mean you are using RSA for encryption???
    > > Normally, this will not be the case. DHE-RSA is used for Key exchange
    > > and/or Authentication but nor for encryption. Just verify the Server
    > > Hello Message you received, it consists a string like
    > > DHE_RSA_WITH_. The "something" part indicates the
    > > Encryption algorithm and the MAC algorithm to be used.

    >
    > > RSA will not be used for encryption since it is very slow in
    > > encrypting large amount of data...

    >
    > > -- Lakshmi Prasanna

    >
    > > On Mon, Jun 16, 2008 at 3:24 PM, Vijay Kotari wrote:
    > > > Hi,

    >
    > > > No, I don't think that is it. I am using Public-key cryptography. To be
    > > > specific, I am using the DHE-RSA.

    >
    > > > Thanks,
    > > > Vijay K.

    >
    > > > On Mon, Jun 16, 2008 at 3:11 PM, lakshmi prasanna
    > > > wrote:

    >
    > > >> Hi,

    >
    > > >> If you are using Stream Cipher or CBC mode block cipher, then the same
    > > >> application data will produce different encrypted data, since the two
    > > >> encryption (cipher) algorithms perform encryption using the previous
    > > >> block and current block (CBC mode block cipher) or previous stream
    > > >> data (Stream Cipher).
    > > >> That is the reason why you are observing different packet dumps for
    > > >> same application data.

    >
    > > >> thanks,
    > > >> Lakshmi Prasanna

    >
    > > >> On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari
    > > >> wrote:
    > > >> > Hi,

    >
    > > >> > While observing some packet dump, I noticed that while sending the same
    > > >> > application data over twice, different packet dumps were obtained in
    > > >> > both
    > > >> > cases. This was done in the same SSL session, so the connection keys
    > > >> > being
    > > >> > used are all the same. Is this expected behavior or am I reading the
    > > >> > packet
    > > >> > dumps wrong?

    >
    > > >> > Thanks and Regards,
    > > >> > Vijay K.

    >
    > > >> --
    > > >> thanks,
    > > >> Lakshmi Prasanna

    >
    > > --
    > > thanks,
    > > Lakshmi Prasanna
    > > __________________________________________________ ____________________
    > > OpenSSL Project * * * * * * * * * * * * * * * *http://www.openssl.org
    > > User Support Mailing List * * * * * * * * * *openssl-us...@openssl.org
    > > Automated List Manager * * * * * * * * * * * * * majord...@openssl.org



  6. Fwd: Difference in packet contents

    ---------- Forwarded message ----------
    From: lakshmi prasanna
    Date: Mon, Jun 16, 2008 at 6:06 PM
    Subject: Re: Difference in packet contents
    To: Vijay Kotari


    Hi,

    You can find information on this page "
    http://developer.mozilla.org/en/docs...uction_to_SSL:.

    Actually AES algorithm is not used in CBC mode here, so you should get the
    same encrypted data for both the blocks.
    I am not sure why it is showing different encrypted data for the same plain
    text.
    I dont have the programs that you have mentioned. Will get back to you once
    I look into that.

    thanks,
    --lakshmi prasanna


    On Mon, Jun 16, 2008 at 3:59 PM, Vijay Kotari
    wrote:
    > Hi,
    >
    > I am using DHE-RSA-AES256-SHA, which would mean that it uses DHE-RSA for

    the
    > handshake and then AES256 for the application data transfer coupled with

    SHA
    > for message authentication according to you. Can you please point me to

    some
    > link that confirms the same?
    >
    > But that still does not resolve my issue. I don't mean to bombard you with
    > too much data but this is the packet dump that I got for both instances.
    >
    >
    > 0000 - 17 03 01 00 20 86 bd 69-7e 07 71 32 f0 e0 27 14 .... ..i~.q2..'.
    > 0010 - 38 17 ad e7 68 9d 19 09-6c c5 fa 56 64 60 fc 7e 8...h...l..Vd`.~
    > 0020 - e2 92 f9 fa b9 17 03 01-00 20 2b fc 38 6e ad a6 .........

    +.8n..
    > 0030 - 05 8e 4e cd ae ce 59 61-1c 22 69 7b f8 2d 7a eb ..N...Ya."i{.-z.
    > 0040 - 1b de 40 ac 0b 8d d3 03-79 b7

    ...@.....y.
    >
    >
    > 0000 - 17 03 01 00 20 85 a8 56-37 07 7a 63 96 fd 12 ad .... ..V7.zc....
    > 0010 - 75 2c 42 97 8c 69 2a 6c-87 36 2e 2d ad f5 12 1b u,B..i*l.6.-....
    > 0020 - d9 c5 ee c8 88 17 03 01-00 20 2e 3f 39 51 1a 6f .........

    ..?9Q.o
    > 0030 - 99 8d d0 56 26 9e 15 97-3c fd b4 b7 00 92 50 9d ...V&...<.....P.
    > 0040 - 98 52 6f 51 b8 1d 23 83-8b dc
    > .RoQ..#...
    >
    > The payload sizes in both cases is 20 bytes but the bytes that follow are
    > not the same. Actually, this is the packet dump that I got by using the
    > sample s_server and s_client programs with the debug option for getting

    the
    > packet dumps. Perhaps, you can simulate the same at your end?
    >
    > Gladly appreciate any help on this.
    >
    >
    > Thanks and regards,
    > Vijay K.
    >
    > On Mon, Jun 16, 2008 at 3:37 PM, lakshmi prasanna
    > wrote:
    >>
    >> Hi,
    >>
    >> You mean you are using RSA for encryption???
    >> Normally, this will not be the case. DHE-RSA is used for Key exchange
    >> and/or Authentication but nor for encryption. Just verify the Server
    >> Hello Message you received, it consists a string like
    >> DHE_RSA_WITH_. The "something" part indicates the
    >> Encryption algorithm and the MAC algorithm to be used.
    >>
    >> RSA will not be used for encryption since it is very slow in
    >> encrypting large amount of data...
    >>
    >> -- Lakshmi Prasanna
    >>
    >> On Mon, Jun 16, 2008 at 3:24 PM, Vijay Kotari
    >> wrote:
    >> > Hi,
    >> >
    >> > No, I don't think that is it. I am using Public-key cryptography. To be
    >> > specific, I am using the DHE-RSA.
    >> >
    >> > Thanks,
    >> > Vijay K.
    >> >
    >> > On Mon, Jun 16, 2008 at 3:11 PM, lakshmi prasanna
    >> > wrote:
    >> >>
    >> >> Hi,
    >> >>
    >> >> If you are using Stream Cipher or CBC mode block cipher, then the same
    >> >> application data will produce different encrypted data, since the two
    >> >> encryption (cipher) algorithms perform encryption using the previous
    >> >> block and current block (CBC mode block cipher) or previous stream
    >> >> data (Stream Cipher).
    >> >> That is the reason why you are observing different packet dumps for
    >> >> same application data.
    >> >>
    >> >> thanks,
    >> >> Lakshmi Prasanna
    >> >>
    >> >> On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari
    >> >> wrote:
    >> >> > Hi,
    >> >> >
    >> >> > While observing some packet dump, I noticed that while sending the
    >> >> > same
    >> >> > application data over twice, different packet dumps were obtained in
    >> >> > both
    >> >> > cases. This was done in the same SSL session, so the connection keys
    >> >> > being
    >> >> > used are all the same. Is this expected behavior or am I reading the
    >> >> > packet
    >> >> > dumps wrong?
    >> >> >
    >> >> >
    >> >> > Thanks and Regards,
    >> >> > Vijay K.
    >> >> >
    >> >> >
    >> >> >
    >> >>
    >> >>
    >> >>
    >> >> --
    >> >> thanks,
    >> >> Lakshmi Prasanna
    >> >
    >> >

    >>
    >>
    >>
    >> --
    >> thanks,
    >> Lakshmi Prasanna

    >
    >




    --
    thanks,
    Lakshmi Prasanna



    --
    thanks,
    Lakshmi Prasanna


  7. Re: Difference in packet contents

    The only mode that should cause the same encrypted data to be sent
    twice in exactly the same manner is "ECB" -- Electronic Code Book.
    Because this has been recognized by cryptographers as being vulnerable
    to many different cryptographic analysis techniques, I am not aware of
    any SSL/TLS implementation that uses it.

    -Kyle H

    On Mon, Jun 16, 2008 at 5:36 AM, lakshmi prasanna wrote:
    >
    >
    > ---------- Forwarded message ----------
    > From: lakshmi prasanna
    > Date: Mon, Jun 16, 2008 at 6:06 PM
    > Subject: Re: Difference in packet contents
    > To: Vijay Kotari
    >
    >
    > Hi,
    >
    > You can find information on this page
    > "http://developer.mozilla.org/en/docs/Introduction_to_SSL:.
    >
    > Actually AES algorithm is not used in CBC mode here, so you should get the
    > same encrypted data for both the blocks.
    > I am not sure why it is showing different encrypted data for the same plain
    > text.
    > I dont have the programs that you have mentioned. Will get back to you once
    > I look into that.
    >
    > thanks,
    > --lakshmi prasanna
    >
    > On Mon, Jun 16, 2008 at 3:59 PM, Vijay Kotari
    > wrote:
    >> Hi,
    >>
    >> I am using DHE-RSA-AES256-SHA, which would mean that it uses DHE-RSA for
    >> the
    >> handshake and then AES256 for the application data transfer coupled with
    >> SHA
    >> for message authentication according to you. Can you please point me to
    >> some
    >> link that confirms the same?
    >>
    >> But that still does not resolve my issue. I don't mean to bombard you with
    >> too much data but this is the packet dump that I got for both instances.
    >>
    >>
    >> 0000 - 17 03 01 00 20 86 bd 69-7e 07 71 32 f0 e0 27 14 .... ..i~.q2..'.
    >> 0010 - 38 17 ad e7 68 9d 19 09-6c c5 fa 56 64 60 fc 7e 8...h...l..Vd`.~
    >> 0020 - e2 92 f9 fa b9 17 03 01-00 20 2b fc 38 6e ad a6 .........
    >> +.8n..
    >> 0030 - 05 8e 4e cd ae ce 59 61-1c 22 69 7b f8 2d 7a eb ..N...Ya."i{.-z.
    >> 0040 - 1b de 40 ac 0b 8d d3 03-79 b7
    >> ..@.....y.
    >>
    >>
    >> 0000 - 17 03 01 00 20 85 a8 56-37 07 7a 63 96 fd 12 ad .... ..V7.zc....
    >> 0010 - 75 2c 42 97 8c 69 2a 6c-87 36 2e 2d ad f5 12 1b u,B..i*l.6.-....
    >> 0020 - d9 c5 ee c8 88 17 03 01-00 20 2e 3f 39 51 1a 6f .........
    >> .?9Q.o
    >> 0030 - 99 8d d0 56 26 9e 15 97-3c fd b4 b7 00 92 50 9d ...V&...<.....P.
    >> 0040 - 98 52 6f 51 b8 1d 23 83-8b dc
    >> .RoQ..#...
    >>
    >> The payload sizes in both cases is 20 bytes but the bytes that follow are
    >> not the same. Actually, this is the packet dump that I got by using the
    >> sample s_server and s_client programs with the debug option for getting
    >> the
    >> packet dumps. Perhaps, you can simulate the same at your end?
    >>
    >> Gladly appreciate any help on this.
    >>
    >>
    >> Thanks and regards,
    >> Vijay K.
    >>
    >> On Mon, Jun 16, 2008 at 3:37 PM, lakshmi prasanna
    >> wrote:
    >>>
    >>> Hi,
    >>>
    >>> You mean you are using RSA for encryption???
    >>> Normally, this will not be the case. DHE-RSA is used for Key exchange
    >>> and/or Authentication but nor for encryption. Just verify the Server
    >>> Hello Message you received, it consists a string like
    >>> DHE_RSA_WITH_. The "something" part indicates the
    >>> Encryption algorithm and the MAC algorithm to be used.
    >>>
    >>> RSA will not be used for encryption since it is very slow in
    >>> encrypting large amount of data...
    >>>
    >>> -- Lakshmi Prasanna
    >>>
    >>> On Mon, Jun 16, 2008 at 3:24 PM, Vijay Kotari
    >>> wrote:
    >>> > Hi,
    >>> >
    >>> > No, I don't think that is it. I am using Public-key cryptography. To be
    >>> > specific, I am using the DHE-RSA.
    >>> >
    >>> > Thanks,
    >>> > Vijay K.
    >>> >
    >>> > On Mon, Jun 16, 2008 at 3:11 PM, lakshmi prasanna
    >>> > wrote:
    >>> >>
    >>> >> Hi,
    >>> >>
    >>> >> If you are using Stream Cipher or CBC mode block cipher, then the same
    >>> >> application data will produce different encrypted data, since the two
    >>> >> encryption (cipher) algorithms perform encryption using the previous
    >>> >> block and current block (CBC mode block cipher) or previous stream
    >>> >> data (Stream Cipher).
    >>> >> That is the reason why you are observing different packet dumps for
    >>> >> same application data.
    >>> >>
    >>> >> thanks,
    >>> >> Lakshmi Prasanna
    >>> >>
    >>> >> On Mon, Jun 16, 2008 at 2:35 PM, Vijay Kotari
    >>> >> wrote:
    >>> >> > Hi,
    >>> >> >
    >>> >> > While observing some packet dump, I noticed that while sending the
    >>> >> > same
    >>> >> > application data over twice, different packet dumps were obtained in
    >>> >> > both
    >>> >> > cases. This was done in the same SSL session, so the connection keys
    >>> >> > being
    >>> >> > used are all the same. Is this expected behavior or am I reading the
    >>> >> > packet
    >>> >> > dumps wrong?
    >>> >> >
    >>> >> >
    >>> >> > Thanks and Regards,
    >>> >> > Vijay K.
    >>> >> >
    >>> >> >
    >>> >> >
    >>> >>
    >>> >>
    >>> >>
    >>> >> --
    >>> >> thanks,
    >>> >> Lakshmi Prasanna
    >>> >
    >>> >
    >>>
    >>>
    >>>
    >>> --
    >>> thanks,
    >>> Lakshmi Prasanna

    >>
    >>

    >
    >
    >
    > --
    > thanks,
    > Lakshmi Prasanna
    >
    >
    >
    > --
    > thanks,
    > Lakshmi Prasanna

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  8. RE: Difference in packet contents


    > While observing some packet dump, I noticed that while sending
    > the same application data over twice, different packet dumps
    > were obtained in both cases.


    Good.

    > This was done in the same SSL session, so the connection keys
    > being used are all the same. Is this expected behavior or am I
    > reading the packet dumps wrong?


    This is expected behavior. Imagine if the first message was "attack at dawn"
    and the second message was "attack at noon". Would you be happy if a
    man-in-the-middle could change the second message to "attack at dawn" (by
    replacing the end of the second exchange with a copy of the end of the
    first)? I know I wouldn't be.

    DS


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  9. Re: Difference in packet contents

    @DS
    Nicely put.

    So, if I was to try to decrypt/encrypt one of these messages, I would need
    the key and the iv and something else? Because if just the key and iv are
    sufficient to encrypt/decrypt the data, then how are the different encrypted
    messages generated for the same cleartext?

    On Tue, Jun 17, 2008 at 12:04 AM, David Schwartz
    wrote:

    >
    > > While observing some packet dump, I noticed that while sending
    > > the same application data over twice, different packet dumps
    > > were obtained in both cases.

    >
    > Good.
    >
    > > This was done in the same SSL session, so the connection keys
    > > being used are all the same. Is this expected behavior or am I
    > > reading the packet dumps wrong?

    >
    > This is expected behavior. Imagine if the first message was "attack at
    > dawn"
    > and the second message was "attack at noon". Would you be happy if a
    > man-in-the-middle could change the second message to "attack at dawn" (by
    > replacing the end of the second exchange with a copy of the end of the
    > first)? I know I wouldn't be.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



  10. Re: Difference in packet contents

    Vijay Kotari wrote:
    > @DS
    > Nicely put.
    >
    > So, if I was to try to decrypt/encrypt one of these messages, I would
    > need the key and the iv and something else? Because if just the key and
    > iv are sufficient to encrypt/decrypt the data, then how are the
    > different encrypted messages generated for the same cleartext?
    >


    http://en.wikipedia.org/wiki/Cipher_block_chaining

    -jb
    --
    Real computer scientists don't comment their code. The identifiers are
    so long they can't afford the disk space.
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  11. Re: Difference in packet contents

    Hi,

    Actually, AES is by default implemented in CBC (Cipher Block Chaining
    )mode in TLSv1. Refer RFC 3268.
    Since the encryption is done in CBC mode, you will not get the same
    encrypted text for identical plain text.

    --lakshmi prasanna

    On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan
    wrote:
    >
    > Vijay Kotari wrote:
    >>
    >> @DS
    >> Nicely put.
    >>
    >> So, if I was to try to decrypt/encrypt one of these messages, I would need the key and the iv and something else? Because if just the key and iv are sufficient to encrypt/decrypt the data, then how are the different encrypted messages generated for the same cleartext?
    >>

    >
    > http://en.wikipedia.org/wiki/Cipher_block_chaining
    >
    > -jb
    > --
    > Real computer scientists don't comment their code. The identifiers are
    > so long they can't afford the disk space.
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org




    --
    thanks,
    Lakshmi Prasanna
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  12. Re: Difference in packet contents

    Yup, that solves it.

    Another matter that's been troubling me is the output that I get when I run
    the s_server program with the debug option. At the end of the handshake,
    when the server sends the Finished Packet to the client, the following
    packet dump is obtained.

    write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
    0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
    0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
    0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
    0030 - 16 fd f6 09 71

    Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
    Byte 0x01 and 0x02 -> SSL v.3.1
    Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5
    before it, totals to the 53 bytes shown at the very beginning.
    Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does not
    correspond to any standard message type. It should, in my opinion show, 0x14
    which is the message type for the Finished packet. I ran the same program a
    few times I keep getting what appears to me as random bytes each time. When
    I run the s_server program with both the msg and debug options, the output
    from the msg tallies with my observation above. I was not sure if the actual
    packet contents that were being sent as both the msg and debug option seemed
    to contradict each other.

    I then wrote a sniffer to check the actual packet contents and they
    corresponded to those received from debug mode which now leads to me believe
    this -> That, in the "Finish" packet, the message type, message length and
    the handshake message are all encrypted. Am I right in thinking so? In which
    case, I wonder, if the client were to receive such a packet, which
    coincedentally were to have its Byte 0x05 as some standard message type,
    will it not proceed to treat that packet correspondingly instead of treating
    it as a Finished packet? Taking this even further, the whole idea of having
    20 as a standard message type for a finished packet would be useless.

    I realise that the above is a pretty lengthy description of the problem that
    I am facing and will be more than happy to elaborate on any part of it that
    is ambigous. I am obviously wrong somewhere and it would be great if someone
    can point where exactly.


    Thanks a lot,
    Vijay K.


    On Tue, Jun 17, 2008 at 4:53 PM, lakshmi prasanna
    wrote:

    > Hi,
    >
    > Actually, AES is by default implemented in CBC (Cipher Block Chaining
    > )mode in TLSv1. Refer RFC 3268.
    > Since the encryption is done in CBC mode, you will not get the same
    > encrypted text for identical plain text.
    >
    > --lakshmi prasanna
    >
    > On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan
    > wrote:
    > >
    > > Vijay Kotari wrote:
    > >>
    > >> @DS
    > >> Nicely put.
    > >>
    > >> So, if I was to try to decrypt/encrypt one of these messages, I would

    > need the key and the iv and something else? Because if just the key and iv
    > are sufficient to encrypt/decrypt the data, then how are the different
    > encrypted messages generated for the same cleartext?
    > >>

    > >
    > > http://en.wikipedia.org/wiki/Cipher_block_chaining
    > >
    > > -jb
    > > --
    > > Real computer scientists don't comment their code. The identifiers are
    > > so long they can't afford the disk space.
    > > __________________________________________________ ____________________
    > > OpenSSL Project http://www.openssl.org
    > > User Support Mailing List openssl-users@openssl.org
    > > Automated List Manager majordomo@openssl.org

    >
    >
    >
    > --
    > thanks,
    > Lakshmi Prasanna
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



  13. Re: Difference in packet contents

    Hi,

    Actually, the Handshake Message becomes the data for record protocol.
    so the Handshake message for Finished message contains a header that
    has 20 in the type field to indicate Finished message. This Handshake
    message including the Header and Data, is encrypted using the keys
    generated during negotiation.
    I think that's the reason why, after the Record protocol Header data
    (5 bytes) nothing makes sense as it is encrypted.

    --Lakshmi Prasanna

    On Tue, Jun 17, 2008 at 5:41 PM, Vijay Kotari wrote:
    > Yup, that solves it.
    >
    > Another matter that's been troubling me is the output that I get when I run
    > the s_server program with the debug option. At the end of the handshake,
    > when the server sends the Finished Packet to the client, the following
    > packet dump is obtained.
    >
    > write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
    > 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
    > 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
    > 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
    > 0030 - 16 fd f6 09 71
    >
    > Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
    > Byte 0x01 and 0x02 -> SSL v.3.1
    > Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5
    > before it, totals to the 53 bytes shown at the very beginning.
    > Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does not
    > correspond to any standard message type. It should, in my opinion show, 0x14
    > which is the message type for the Finished packet. I ran the same program a
    > few times I keep getting what appears to me as random bytes each time. When
    > I run the s_server program with both the msg and debug options, the output
    > from the msg tallies with my observation above. I was not sure if the actual
    > packet contents that were being sent as both the msg and debug option seemed
    > to contradict each other.
    >
    > I then wrote a sniffer to check the actual packet contents and they
    > corresponded to those received from debug mode which now leads to me believe
    > this -> That, in the "Finish" packet, the message type, message length and
    > the handshake message are all encrypted. Am I right in thinking so? In which
    > case, I wonder, if the client were to receive such a packet, which
    > coincedentally were to have its Byte 0x05 as some standard message type,
    > will it not proceed to treat that packet correspondingly instead of treating
    > it as a Finished packet? Taking this even further, the whole idea of having
    > 20 as a standard message type for a finished packet would be useless.
    >
    > I realise that the above is a pretty lengthy description of the problem that
    > I am facing and will be more than happy to elaborate on any part of it that
    > is ambigous. I am obviously wrong somewhere and it would be great if someone
    > can point where exactly.
    >
    >
    > Thanks a lot,
    > Vijay K.
    >
    >
    > On Tue, Jun 17, 2008 at 4:53 PM, lakshmi prasanna
    > wrote:
    >>
    >> Hi,
    >>
    >> Actually, AES is by default implemented in CBC (Cipher Block Chaining
    >> )mode in TLSv1. Refer RFC 3268.
    >> Since the encryption is done in CBC mode, you will not get the same
    >> encrypted text for identical plain text.
    >>
    >> --lakshmi prasanna
    >>
    >> On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan
    >> wrote:
    >> >
    >> > Vijay Kotari wrote:
    >> >>
    >> >> @DS
    >> >> Nicely put.
    >> >>
    >> >> So, if I was to try to decrypt/encrypt one of these messages, I would
    >> >> need the key and the iv and something else? Because if just the key and iv
    >> >> are sufficient to encrypt/decrypt the data, then how are the different
    >> >> encrypted messages generated for the same cleartext?
    >> >>
    >> >
    >> > http://en.wikipedia.org/wiki/Cipher_block_chaining
    >> >
    >> > -jb
    >> > --
    >> > Real computer scientists don't comment their code. The identifiers are
    >> > so long they can't afford the disk space.
    >> > __________________________________________________ ____________________
    >> > OpenSSL Project http://www.openssl.org
    >> > User Support Mailing List openssl-users@openssl.org
    >> > Automated List Manager majordomo@openssl.org

    >>
    >>
    >>
    >> --
    >> thanks,
    >> Lakshmi Prasanna
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> User Support Mailing List openssl-users@openssl.org
    >> Automated List Manager majordomo@openssl.org

    >
    >




    --
    thanks,
    Lakshmi Prasanna
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  14. Re: Difference in packet contents

    Hello,

    owner-openssl-users@openssl.org wrote on 06/17/2008 02:11:14 PM:

    > Yup, that solves it.
    >
    > Another matter that's been troubling me is the output that I get when I

    run the s_server
    > program with the debug option. At the end of the handshake, when the

    server sends the
    > Finished Packet to the client, the following packet dump is obtained.
    >
    > write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
    > 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
    > 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
    > 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
    > 0030 - 16 fd f6 09 71
    >
    > Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
    > Byte 0x01 and 0x02 -> SSL v.3.1
    > Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5

    before it, totals
    > to the 53 bytes shown at the very beginning.
    > Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does

    not correspond
    > to any standard message type. It should, in my opinion show, 0x14 which

    is the message
    > type for the Finished packet. I ran the same program a few times I keep

    getting what
    > appears to me as random bytes each time. When I run the s_server program

    with both the
    > msg and debug options, the output from the msg tallies with my

    observation above. I was
    > not sure if the actual packet contents that were being sent as both the

    msg and debug
    > option seemed to contradict each other.
    >
    > I then wrote a sniffer to check the actual packet contents and they

    corresponded to
    > those received from debug mode which now leads to me believe this ->

    That, in the
    > "Finish" packet, the message type, message length and the handshake

    message are all
    > encrypted. Am I right in thinking so? In which case, I wonder, if the

    client were to
    > receive such a packet, which coincedentally were to have its Byte 0x05

    as some standard
    > message type, will it not proceed to treat that packet correspondingly

    instead of
    > treating it as a Finished packet? Taking this even further, the whole

    idea of having 20
    > as a standard message type for a finished packet would be useless.
    >
    > I realise that the above is a pretty lengthy description of the problem

    that I am facing
    > and will be more than happy to elaborate on any part of it that is

    ambigous. I am
    > obviously wrong somewhere and it would be great if someone can point

    where exactly.
    Finished packet is the first packet with encrypted contents.
    If you look at packets dump, you will see ChangeCipherSpec packet Finished
    packet.
    All packet after ChangeCipherSpec should use encryption, this is something
    like switch witch turn on encryption.
    So, Finished packet should be decrypted before analysed.

    Best regards,
    --
    Marek Marcola

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  15. Re: Difference in packet contents

    Hi,

    I do know for a fact that part of the Finish message is encrypted. My
    question was actually if the Message type field is also part of the
    encrypted part? In which case, as I had pointed out earlier, there is a
    chance that the first byte of the encrypted {message_type + message} can be
    equal to one of the Standard Message types hence misleading the client to
    the type of packet that is actually being sent. To put it another way, IMHO,
    it does not make sense to have a field in a packet whose value does not give
    us any information of the packet itself. i.e. if the field contains 14 (in
    base 10), should it be interpreted as a Finish packet with encrypted data
    whose first byte also happens to be 14 or a ServerHelloDone packet?


    Regards,
    Vijay K.

    On Tue, Jun 17, 2008 at 6:32 PM, wrote:

    > Hello,
    >
    > owner-openssl-users@openssl.org wrote on 06/17/2008 02:11:14 PM:
    >
    > > Yup, that solves it.
    > >
    > > Another matter that's been troubling me is the output that I get when I

    > run the s_server
    > > program with the debug option. At the end of the handshake, when the

    > server sends the
    > > Finished Packet to the client, the following packet dump is obtained.
    > >
    > > write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
    > > 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
    > > 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
    > > 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
    > > 0030 - 16 fd f6 09 71
    > >
    > > Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
    > > Byte 0x01 and 0x02 -> SSL v.3.1
    > > Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5

    > before it, totals
    > > to the 53 bytes shown at the very beginning.
    > > Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does

    > not correspond
    > > to any standard message type. It should, in my opinion show, 0x14 which

    > is the message
    > > type for the Finished packet. I ran the same program a few times I keep

    > getting what
    > > appears to me as random bytes each time. When I run the s_server program

    > with both the
    > > msg and debug options, the output from the msg tallies with my

    > observation above. I was
    > > not sure if the actual packet contents that were being sent as both the

    > msg and debug
    > > option seemed to contradict each other.
    > >
    > > I then wrote a sniffer to check the actual packet contents and they

    > corresponded to
    > > those received from debug mode which now leads to me believe this ->

    > That, in the
    > > "Finish" packet, the message type, message length and the handshake

    > message are all
    > > encrypted. Am I right in thinking so? In which case, I wonder, if the

    > client were to
    > > receive such a packet, which coincedentally were to have its Byte 0x05

    > as some standard
    > > message type, will it not proceed to treat that packet correspondingly

    > instead of
    > > treating it as a Finished packet? Taking this even further, the whole

    > idea of having 20
    > > as a standard message type for a finished packet would be useless.
    > >
    > > I realise that the above is a pretty lengthy description of the problem

    > that I am facing
    > > and will be more than happy to elaborate on any part of it that is

    > ambigous. I am
    > > obviously wrong somewhere and it would be great if someone can point

    > where exactly.
    > Finished packet is the first packet with encrypted contents.
    > If you look at packets dump, you will see ChangeCipherSpec packet Finished
    > packet.
    > All packet after ChangeCipherSpec should use encryption, this is something
    > like switch witch turn on encryption.
    > So, Finished packet should be decrypted before analysed.
    >
    > Best regards,
    > --
    > Marek Marcola
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



  16. Re: Difference in packet contents

    The whole Finish message, (ie., Handshake protocols Header indicating
    this message as Finished message, and the encrypted Data) is encrypted
    and sent.
    At the other end the packet is decrypted. This decryption is done
    because a Change Cipher Spec message has been received before this
    message by the other end.
    After decrypting the received message, it finds the expected Finished
    message, and verifies the data sent in the Finished message.

    -- Lakshmi Prasanna

    On Tue, Jun 17, 2008 at 6:51 PM, Vijay Kotari wrote:
    > Hi,
    >
    > I do know for a fact that part of the Finish message is encrypted. My
    > question was actually if the Message type field is also part of the
    > encrypted part? In which case, as I had pointed out earlier, there is a
    > chance that the first byte of the encrypted {message_type + message} can be
    > equal to one of the Standard Message types hence misleading the client to
    > the type of packet that is actually being sent. To put it another way, IMHO,
    > it does not make sense to have a field in a packet whose value does not give
    > us any information of the packet itself. i.e. if the field contains 14 (in
    > base 10), should it be interpreted as a Finish packet with encrypted data
    > whose first byte also happens to be 14 or a ServerHelloDone packet?
    >
    >
    > Regards,
    > Vijay K.
    >
    > On Tue, Jun 17, 2008 at 6:32 PM, wrote:
    >>
    >> Hello,
    >>
    >> owner-openssl-users@openssl.org wrote on 06/17/2008 02:11:14 PM:
    >>
    >> > Yup, that solves it.
    >> >
    >> > Another matter that's been troubling me is the output that I get when I

    >> run the s_server
    >> > program with the debug option. At the end of the handshake, when the

    >> server sends the
    >> > Finished Packet to the client, the following packet dump is obtained.
    >> >
    >> > write to 099EB570 [099FADC0] (53 bytes => 53 (0x35))
    >> > 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b
    >> > 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3
    >> > 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5
    >> > 0030 - 16 fd f6 09 71
    >> >
    >> > Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress.
    >> > Byte 0x01 and 0x02 -> SSL v.3.1
    >> > Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5

    >> before it, totals
    >> > to the 53 bytes shown at the very beginning.
    >> > Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does

    >> not correspond
    >> > to any standard message type. It should, in my opinion show, 0x14 which

    >> is the message
    >> > type for the Finished packet. I ran the same program a few times I keep

    >> getting what
    >> > appears to me as random bytes each time. When I run the s_server program

    >> with both the
    >> > msg and debug options, the output from the msg tallies with my

    >> observation above. I was
    >> > not sure if the actual packet contents that were being sent as both the

    >> msg and debug
    >> > option seemed to contradict each other.
    >> >
    >> > I then wrote a sniffer to check the actual packet contents and they

    >> corresponded to
    >> > those received from debug mode which now leads to me believe this ->

    >> That, in the
    >> > "Finish" packet, the message type, message length and the handshake

    >> message are all
    >> > encrypted. Am I right in thinking so? In which case, I wonder, if the

    >> client were to
    >> > receive such a packet, which coincedentally were to have its Byte 0x05

    >> as some standard
    >> > message type, will it not proceed to treat that packet correspondingly

    >> instead of
    >> > treating it as a Finished packet? Taking this even further, the whole

    >> idea of having 20
    >> > as a standard message type for a finished packet would be useless.
    >> >
    >> > I realise that the above is a pretty lengthy description of the problem

    >> that I am facing
    >> > and will be more than happy to elaborate on any part of it that is

    >> ambigous. I am
    >> > obviously wrong somewhere and it would be great if someone can point

    >> where exactly.
    >> Finished packet is the first packet with encrypted contents.
    >> If you look at packets dump, you will see ChangeCipherSpec packet Finished
    >> packet.
    >> All packet after ChangeCipherSpec should use encryption, this is something
    >> like switch witch turn on encryption.
    >> So, Finished packet should be decrypted before analysed.
    >>
    >> Best regards,
    >> --
    >> Marek Marcola
    >>
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> User Support Mailing List openssl-users@openssl.org
    >> Automated List Manager majordomo@openssl.org

    >
    >




    --
    thanks,
    Lakshmi Prasanna
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  17. Re: Difference in packet contents

    Hello,

    owner-openssl-users@openssl.org wrote on 06/17/2008 03:21:08 PM:

    > Hi,
    >
    > I do know for a fact that part of the Finish message is encrypted. My

    question was
    > actually if the Message type field is also part of the encrypted part?

    In which case, as
    > I had pointed out earlier, there is a chance that the first byte of the

    encrypted
    > {message_type + message} can be equal to one of the Standard Message

    types hence
    > misleading the client to the type of packet that is actually being sent.

    To put it
    > another way, IMHO, it does not make sense to have a field in a packet

    whose value does
    > not give us any information of the packet itself. i.e. if the field

    contains 14 (in base
    > 10), should it be interpreted as a Finish packet with encrypted data

    whose first byte
    > also happens to be 14 or a ServerHelloDone packet?


    Finished packet is built with:

    Protcol header:
    ---------------
    22 - protocol (1 byte)
    3 - ssl/tls wersion (2 bytes, this and next)
    0/1
    len1 - data length (2 bytes, this and next)
    len2

    Handshake header:
    -----------------
    20 - type
    hs_len1 - handhsake data length (3 bytes, this and next two)
    hs_len2
    hs_len3

    Handshake data:
    ---------------
    signed digest1 - MD5 for RSA
    signed digest2 - SHA1 for RSA,DSA

    SSL/TLS is built with layers, encryption is used ad record layer
    where handshake layer and data layer are above this layer.
    From record layer point of view there is not difference between
    application data and handshake packet, all is encrypted and send
    to other party or decrypted and send to layer above.
    There is only one sign of type of data sent: first byte
    which tells what kind of data is carried by packet but this is
    used to defend against reply attacks too (this byte is used in MAC
    calculation).

    So, in case of Finised packet, record layer puts handshake header and
    data,
    add MAC and PAD, encrypt this, encapsulate encrypted data with 5 byte
    protocol header and sent to peer:

    protocol_header, {handshake_header,handshake_data,MAC,PAD}
    ^^^^^^^^^^ ENCRYPTED ^^^^^^^^^^^^^^^^^^^^
    Best regards,
    --
    Marek Marcola

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread