Decrypting Fragmented packets - Openssl

This is a discussion on Decrypting Fragmented packets - Openssl ; Hi, I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a SSL packet that I have captured. The cipher that I am using AES256 and I can read the application data in cleartext as a result. The problem comes if the ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Decrypting Fragmented packets

  1. Decrypting Fragmented packets

    Hi,

    I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    SSL packet that I have captured. The cipher that I am using AES256 and
    I can read the application data in cleartext as a result. The problem
    comes if the application data size > 8, which I think has something to
    do with me using a block cipher. I can't seem to decrypt the data
    then. Anyways, after inspecting the packet dumps, I realized that
    sometimes I get fragmented packets.

    For Example,

    17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    2b 18 b1 8d d8 3c 15 3d e9 c7

    This is actually two packets that are using the SSL application
    protocol, each of size 0x20 (The second packet starts on line 3, 6th
    byte onwards). While decrypting, should both these packets be merged
    together and hence treated as a single packet of size 0x40 or should
    packet be processed separately. Since, we are using a block cipher of
    size 256 bits(32 bytes), will it even make a difference?


    Thanks and Regards,
    Vijay Kotari


  2. Re: Decrypting Fragmented packets

    It's hard to approach this without knowing the mode of operation you
    are running CBC, OFB, CTR? Also are you using UDP with varying packet
    sizes?

    Julian

    On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:

    > Hi,
    > I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    > SSL packet that I have captured. The cipher that I am using AES256 and
    > I can read the application data in cleartext as a result. The problem
    > comes if the application data size > 8, which I think has something to
    > do with me using a block cipher. I can't seem to decrypt the data
    > then. Anyways, after inspecting the packet dumps, I realized that
    > sometimes I get fragmented packets.
    > For Example,
    > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > 2b 18 b1 8d d8 3c 15 3d e9 c7
    > This is actually two packets that are using the SSL application
    > protocol, each of size 0x20 (The second packet starts on line 3, 6th
    > byte onwards). While decrypting, should both these packets be merged
    > together and hence treated as a single packet of size 0x40 or should
    > packet be processed separately. Since, we are using a block cipher of
    > size 256 bits(32 bytes), will it even make a difference?
    >
    >
    > Thanks and Regards,
    > Vijay Kotari


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


  3. Re: Decrypting Fragmented packets

    I am using the traffic obtained from s_server and s_client sample programs
    and the keys that have been negotiated by both the programs to decrypt the
    encrypted traffic between the two. That would mean that I am using TCP.
    Also, I am running them under the CBC mode.

    Vijay K.

    On Wed, Jun 25, 2008 at 11:35 AM, Julian wrote:

    > It's hard to approach this without knowing the mode of operation you are
    > running CBC, OFB, CTR? Also are you using UDP with varying packet sizes?
    >
    > Julian
    >
    >
    > On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:
    >
    > Hi,
    >> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    >> SSL packet that I have captured. The cipher that I am using AES256 and
    >> I can read the application data in cleartext as a result. The problem
    >> comes if the application data size > 8, which I think has something to
    >> do with me using a block cipher. I can't seem to decrypt the data
    >> then. Anyways, after inspecting the packet dumps, I realized that
    >> sometimes I get fragmented packets.
    >> For Example,
    >> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    >> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    >> 2b 18 b1 8d d8 3c 15 3d e9 c7
    >> This is actually two packets that are using the SSL application
    >> protocol, each of size 0x20 (The second packet starts on line 3, 6th
    >> byte onwards). While decrypting, should both these packets be merged
    >> together and hence treated as a single packet of size 0x40 or should
    >> packet be processed separately. Since, we are using a block cipher of
    >> size 256 bits(32 bytes), will it even make a difference?
    >>
    >>
    >> Thanks and Regards,
    >> Vijay Kotari
    >>

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



  4. Re: Decrypting Fragmented packets

    Hi,

    I resolved this issue although I am still a little confused about the error
    that I was getting previously. I am outlining the steps that I did before
    when I had the error and what I did to overcome it, so that some kind soul
    here can enlighten me as to why I got the error in the first place.

    I have with me the packets obtained from a SSL conversation. I am using
    AES256_CBC for the encryption. Also, I have the connection keys(master key
    and 2 oiv's) that are being used. I had earlier sent across a few messages
    from my SSL server to client and have been able to decrypt the captured
    packets. Now I sent across a larger sized message(about 20 bytes or so.)

    *Before -> Error*
    The packet dump that I have is

    17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    2b 18 b1 8d d8 3c 15 3d e9 c7

    This is actually two packets but they both were sent for a single
    application message (They are fragmented packets).

    After the usual intialisation steps,
    I called EVP_DecryptUpdate() and EVP_DecryptFinal_ex().
    EVP_DecryptFinal_ex() returns 0 (error). Also, only the first half of my
    application has been decrypted properly, the second half has not been
    decrypted properly. I initally thought that the decryption failed and to
    test this, I sent across a few messages from the same server to the same
    client in the same SSL session. Hence, the original iv's and master key
    being used is the same, but the current iv is different because decryption
    has failed earlier. But I am still able to send across (short) messages and
    decrypt them to obtain the cleartext.

    *After Debugging -> No Error now.*
    I did the same as before, but before passing the packet dump to
    EVP_DecryptUpdate(), I defragmented the packet dump, so now my packet dump
    looks like this.

    17 03 01 00 40 85 99 2a 94 4d 0e 56 2c 81 bc fc
    4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    e9 ab cf 77 e7 76 68 51 17 9e 86 d4 20 6e 31 3e
    7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8
    3c 15 3d e9 c7

    This packet dump is smaller by 5 bytes (The second packet header has been
    removed.) and the size field at byte 4 has been updated to the sum of bytes
    in both packets.

    Now, I am able to send across messages of any size and receive them and so,
    my program works great. But I still puzzled as to why I got the error as
    before? Because I am using CBC, if my decryption fails at any one stage, I
    should not be able to decrypt any further packets right?

    Thanks and Regards,
    Vijay K.

    *
    *On Wed, Jun 25, 2008 at 12:07 PM, Vijay Kotari
    wrote:

    > I am using the traffic obtained from s_server and s_client sample programs
    > and the keys that have been negotiated by both the programs to decrypt the
    > encrypted traffic between the two. That would mean that I am using TCP.
    > Also, I am running them under the CBC mode.
    >
    > Vijay K.
    >
    >
    > On Wed, Jun 25, 2008 at 11:35 AM, Julian wrote:
    >
    >> It's hard to approach this without knowing the mode of operation you are
    >> running CBC, OFB, CTR? Also are you using UDP with varying packet sizes?
    >>
    >> Julian
    >>
    >>
    >> On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:
    >>
    >> Hi,
    >>> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    >>> SSL packet that I have captured. The cipher that I am using AES256 and
    >>> I can read the application data in cleartext as a result. The problem
    >>> comes if the application data size > 8, which I think has something to
    >>> do with me using a block cipher. I can't seem to decrypt the data
    >>> then. Anyways, after inspecting the packet dumps, I realized that
    >>> sometimes I get fragmented packets.
    >>> For Example,
    >>> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >>> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >>> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    >>> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    >>> 2b 18 b1 8d d8 3c 15 3d e9 c7
    >>> This is actually two packets that are using the SSL application
    >>> protocol, each of size 0x20 (The second packet starts on line 3, 6th
    >>> byte onwards). While decrypting, should both these packets be merged
    >>> together and hence treated as a single packet of size 0x40 or should
    >>> packet be processed separately. Since, we are using a block cipher of
    >>> size 256 bits(32 bytes), will it even make a difference?
    >>>
    >>>
    >>> Thanks and Regards,
    >>> Vijay Kotari
    >>>

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

    >
    >



  5. Re: Decrypting Fragmented packets

    Hello,

    owner-openssl-users@openssl.org wrote on 06/25/2008 07:25:12 AM:

    > Hi,
    > I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    > SSL packet that I have captured. The cipher that I am using AES256 and
    > I can read the application data in cleartext as a result. The problem
    > comes if the application data size > 8, which I think has something to
    > do with me using a block cipher. I can't seem to decrypt the data
    > then. Anyways, after inspecting the packet dumps, I realized that
    > sometimes I get fragmented packets.
    > For Example,
    > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > 2b 18 b1 8d d8 3c 15 3d e9 c7
    > This is actually two packets that are using the SSL application
    > protocol, each of size 0x20 (The second packet starts on line 3, 6th
    > byte onwards). While decrypting, should both these packets be merged
    > together and hence treated as a single packet of size 0x40 or should
    > packet be processed separately. Since, we are using a block cipher of
    > size 256 bits(32 bytes), will it even make a difference?


    This two packets should be decrypted separately. You should look at this
    packet from SSL point of view, not TCP point of view.
    It is not important that you have this data in one TCP packet.
    From the other hand this data may come to you with 20 TCP packets too.
    Merging this two packets may work for decryption but will break MAC
    (message authentication code) because when MAC is calculated implied
    message number is used. When you merge this packet - one packet
    will be lost in this calculation.

    Best regards,
    --
    Marek Marcola

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


  6. Re: Decrypting Fragmented packets

    The Nagle algorithm will attempt to coalesce multiple write() calls
    into a single TCP packet. Since TLS/SSL are a record format atop TCP,
    you need to handle the recordss as independent of each other -- i.e.,
    you need to process the first TLS record, and then use the results of
    that processing to process the second TLS record. Otherwise, the
    internal protocol state gets severely fubar'ed.

    Think of this as an attempted attack where Mallory appends a new TLS
    record to a short TCP packet. The only way to be sure that it's not
    an attack is to process each record independently.

    -Kyle H

    On Wed, Jun 25, 2008 at 12:13 AM, Vijay Kotari wrote:
    > Hi,
    >
    > I resolved this issue although I am still a little confused about the error
    > that I was getting previously. I am outlining the steps that I did before
    > when I had the error and what I did to overcome it, so that some kind soul
    > here can enlighten me as to why I got the error in the first place.
    >
    > I have with me the packets obtained from a SSL conversation. I am using
    > AES256_CBC for the encryption. Also, I have the connection keys(master key
    > and 2 oiv's) that are being used. I had earlier sent across a few messages
    > from my SSL server to client and have been able to decrypt the captured
    > packets. Now I sent across a larger sized message(about 20 bytes or so.)
    >
    > Before -> Error
    > The packet dump that I have is
    >
    > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > 2b 18 b1 8d d8 3c 15 3d e9 c7
    >
    > This is actually two packets but they both were sent for a single
    > application message (They are fragmented packets).
    >
    > After the usual intialisation steps,
    > I called EVP_DecryptUpdate() and EVP_DecryptFinal_ex().
    > EVP_DecryptFinal_ex() returns 0 (error). Also, only the first half of my
    > application has been decrypted properly, the second half has not been
    > decrypted properly. I initally thought that the decryption failed and to
    > test this, I sent across a few messages from the same server to the same
    > client in the same SSL session. Hence, the original iv's and master key
    > being used is the same, but the current iv is different because decryption
    > has failed earlier. But I am still able to send across (short) messages and
    > decrypt them to obtain the cleartext.
    >
    > After Debugging -> No Error now.
    > I did the same as before, but before passing the packet dump to
    > EVP_DecryptUpdate(), I defragmented the packet dump, so now my packet dump
    > looks like this.
    >
    > 17 03 01 00 40 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > e9 ab cf 77 e7 76 68 51 17 9e 86 d4 20 6e 31 3e
    > 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8
    > 3c 15 3d e9 c7
    >
    > This packet dump is smaller by 5 bytes (The second packet header has been
    > removed.) and the size field at byte 4 has been updated to the sum of bytes
    > in both packets.
    >
    > Now, I am able to send across messages of any size and receive them and so,
    > my program works great. But I still puzzled as to why I got the error as
    > before? Because I am using CBC, if my decryption fails at any one stage, I
    > should not be able to decrypt any further packets right?
    >
    > Thanks and Regards,
    > Vijay K.
    >
    >
    > On Wed, Jun 25, 2008 at 12:07 PM, Vijay Kotari
    > wrote:
    >>
    >> I am using the traffic obtained from s_server and s_client sample programs
    >> and the keys that have been negotiated by both the programs to decrypt the
    >> encrypted traffic between the two. That would mean that I am using TCP.
    >> Also, I am running them under the CBC mode.
    >>
    >> Vijay K.
    >>
    >> On Wed, Jun 25, 2008 at 11:35 AM, Julian wrote:
    >>>
    >>> It's hard to approach this without knowing the mode of operation you are
    >>> running CBC, OFB, CTR? Also are you using UDP with varying packet sizes?
    >>>
    >>> Julian
    >>>
    >>> On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:
    >>>
    >>>> Hi,
    >>>> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    >>>> SSL packet that I have captured. The cipher that I am using AES256 and
    >>>> I can read the application data in cleartext as a result. The problem
    >>>> comes if the application data size > 8, which I think has something to
    >>>> do with me using a block cipher. I can't seem to decrypt the data
    >>>> then. Anyways, after inspecting the packet dumps, I realized that
    >>>> sometimes I get fragmented packets.
    >>>> For Example,
    >>>> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >>>> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >>>> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    >>>> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    >>>> 2b 18 b1 8d d8 3c 15 3d e9 c7
    >>>> This is actually two packets that are using the SSL application
    >>>> protocol, each of size 0x20 (The second packet starts on line 3, 6th
    >>>> byte onwards). While decrypting, should both these packets be merged
    >>>> together and hence treated as a single packet of size 0x40 or should
    >>>> packet be processed separately. Since, we are using a block cipher of
    >>>> size 256 bits(32 bytes), will it even make a difference?
    >>>>
    >>>>
    >>>> Thanks and Regards,
    >>>> Vijay Kotari
    >>>
    >>> __________________________________________________ ____________________
    >>> OpenSSL Project http://www.openssl.org
    >>> User Support Mailing List openssl-users@openssl.org
    >>> Automated List Manager majordomo@openssl.org

    >>

    >
    >

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


  7. Re: Decrypting Fragmented packets

    Well, I tried it like you guys said, but I keep getting an error from
    EVP_DecryptFinal_ex() (returns 0) and the resulting decrypted packet that I
    got is not right. However, doing it like I said previously, that is
    reassemblng the packets and merging them into one and then passing it to the
    above mentioned Decrypt functions seem to be working fine.

    Also, how is it exactly that you suggest that I go along?
    If I send the message "Hello World" from my server to client and I capture
    the aforementioned packet, lets say, I treat it as two separate records and
    decrypt each record. I now have two decrypted records. Should I merge these
    now? If that were the case, are you implying that my inital message "Hello
    World" has been broken into two parts before it was encrypted? (Maybe one
    part is "Hello" and the other is " World"?) That does not sound right.

    The situation that I am facing can actually be repeated by just running the
    s_server and s_client programs in debug mode and then observing the output.

    Also, in the packet dump that I had posted earlier,

    17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    2b 18 b1 8d d8 3c 15 3d e9 c7

    and comparing this to the packet format
    here.
    I have 32 bytes of application data that should be followed by some amount
    of padding and 20 Bytes of MAC, which is not available here. But I can
    clearly see that the algorithm being used is DHE-RSA-AES256-SHA, specifying
    that SHA is being used. Even, the debug mode in s_server program that I am
    using shows the same data being transmitted.


    Regards,
    Vijay K.

    On Thu, Jun 26, 2008 at 11:30 AM, Kyle Hamilton wrote:

    > The Nagle algorithm will attempt to coalesce multiple write() calls
    > into a single TCP packet. Since TLS/SSL are a record format atop TCP,
    > you need to handle the recordss as independent of each other -- i.e.,
    > you need to process the first TLS record, and then use the results of
    > that processing to process the second TLS record. Otherwise, the
    > internal protocol state gets severely fubar'ed.
    >
    > Think of this as an attempted attack where Mallory appends a new TLS
    > record to a short TCP packet. The only way to be sure that it's not
    > an attack is to process each record independently.
    >
    > -Kyle H
    >
    > On Wed, Jun 25, 2008 at 12:13 AM, Vijay Kotari
    > wrote:
    > > Hi,
    > >
    > > I resolved this issue although I am still a little confused about the

    > error
    > > that I was getting previously. I am outlining the steps that I did before
    > > when I had the error and what I did to overcome it, so that some kind

    > soul
    > > here can enlighten me as to why I got the error in the first place.
    > >
    > > I have with me the packets obtained from a SSL conversation. I am using
    > > AES256_CBC for the encryption. Also, I have the connection keys(master

    > key
    > > and 2 oiv's) that are being used. I had earlier sent across a few

    > messages
    > > from my SSL server to client and have been able to decrypt the captured
    > > packets. Now I sent across a larger sized message(about 20 bytes or so.)
    > >
    > > Before -> Error
    > > The packet dump that I have is
    > >
    > > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > > 2b 18 b1 8d d8 3c 15 3d e9 c7
    > >
    > > This is actually two packets but they both were sent for a single
    > > application message (They are fragmented packets).
    > >
    > > After the usual intialisation steps,
    > > I called EVP_DecryptUpdate() and EVP_DecryptFinal_ex().
    > > EVP_DecryptFinal_ex() returns 0 (error). Also, only the first half of my
    > > application has been decrypted properly, the second half has not been
    > > decrypted properly. I initally thought that the decryption failed and to
    > > test this, I sent across a few messages from the same server to the same
    > > client in the same SSL session. Hence, the original iv's and master key
    > > being used is the same, but the current iv is different because

    > decryption
    > > has failed earlier. But I am still able to send across (short) messages

    > and
    > > decrypt them to obtain the cleartext.
    > >
    > > After Debugging -> No Error now.
    > > I did the same as before, but before passing the packet dump to
    > > EVP_DecryptUpdate(), I defragmented the packet dump, so now my packet

    > dump
    > > looks like this.
    > >
    > > 17 03 01 00 40 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > > e9 ab cf 77 e7 76 68 51 17 9e 86 d4 20 6e 31 3e
    > > 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8
    > > 3c 15 3d e9 c7
    > >
    > > This packet dump is smaller by 5 bytes (The second packet header has been
    > > removed.) and the size field at byte 4 has been updated to the sum of

    > bytes
    > > in both packets.
    > >
    > > Now, I am able to send across messages of any size and receive them and

    > so,
    > > my program works great. But I still puzzled as to why I got the error as
    > > before? Because I am using CBC, if my decryption fails at any one stage,

    > I
    > > should not be able to decrypt any further packets right?
    > >
    > > Thanks and Regards,
    > > Vijay K.
    > >
    > >
    > > On Wed, Jun 25, 2008 at 12:07 PM, Vijay Kotari
    > > wrote:
    > >>
    > >> I am using the traffic obtained from s_server and s_client sample

    > programs
    > >> and the keys that have been negotiated by both the programs to decrypt

    > the
    > >> encrypted traffic between the two. That would mean that I am using TCP.
    > >> Also, I am running them under the CBC mode.
    > >>
    > >> Vijay K.
    > >>
    > >> On Wed, Jun 25, 2008 at 11:35 AM, Julian wrote:
    > >>>
    > >>> It's hard to approach this without knowing the mode of operation you

    > are
    > >>> running CBC, OFB, CTR? Also are you using UDP with varying packet

    > sizes?
    > >>>
    > >>> Julian
    > >>>
    > >>> On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:
    > >>>
    > >>>> Hi,
    > >>>> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    > >>>> SSL packet that I have captured. The cipher that I am using AES256 and
    > >>>> I can read the application data in cleartext as a result. The problem
    > >>>> comes if the application data size > 8, which I think has something to
    > >>>> do with me using a block cipher. I can't seem to decrypt the data
    > >>>> then. Anyways, after inspecting the packet dumps, I realized that
    > >>>> sometimes I get fragmented packets.
    > >>>> For Example,
    > >>>> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > >>>> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > >>>> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > >>>> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > >>>> 2b 18 b1 8d d8 3c 15 3d e9 c7
    > >>>> This is actually two packets that are using the SSL application
    > >>>> protocol, each of size 0x20 (The second packet starts on line 3, 6th
    > >>>> byte onwards). While decrypting, should both these packets be merged
    > >>>> together and hence treated as a single packet of size 0x40 or should
    > >>>> packet be processed separately. Since, we are using a block cipher of
    > >>>> size 256 bits(32 bytes), will it even make a difference?
    > >>>>
    > >>>>
    > >>>> Thanks and Regards,
    > >>>> Vijay Kotari
    > >>>
    > >>> __________________________________________________ ____________________
    > >>> OpenSSL Project http://www.openssl.org
    > >>> User Support Mailing List openssl-users@openssl.org
    > >>> Automated List Manager majordomo@openssl.org
    > >>

    > >
    > >

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



  8. Re: Decrypting Fragmented packets

    The TLS layer can break the stream down to any unit that is convenient
    for it. It could break a "Hello World." string down to "H", "e", "l",
    "l", "o", " ", "W", "o", "r", "l", "d", "." and put each byte into a
    separate record. Most will use some multiple of the block size so
    that minimal padding must be done, but this is not guaranteed.

    As long as the TLS layer handles things in a FIFO stream (meaning, the
    first byte of input is the first byte of output), it doesn't matter
    what 'seems' right -- it is actually correct. (And since TLS is
    specified as occurring above a sequenced and reliable network path
    like TCP, it will be received by the client in the correct order.)

    For reference, please see RFC 2256 (the TLS 1.0 specification).
    Wikipedia will often not have absolutely correct information, and I
    have not proofread it; therefore, I suggest you go to the original
    source. (This can be found at
    ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt. Also, SSL3's final
    internet-draft can be found at
    http://wp.netscape.com/eng/ssl3/draft302.txt.)

    For what it's worth, it's rather difficult for us to figure out what's
    going on without the full debug dump (not merely the questionable
    bytes from the stream that you're seeing.

    -Kyle H

    On Thu, Jun 26, 2008 at 4:56 AM, Vijay Kotari wrote:
    > Well, I tried it like you guys said, but I keep getting an error from
    > EVP_DecryptFinal_ex() (returns 0) and the resulting decrypted packet that I
    > got is not right. However, doing it like I said previously, that is
    > reassemblng the packets and merging them into one and then passing it to the
    > above mentioned Decrypt functions seem to be working fine.
    >
    > Also, how is it exactly that you suggest that I go along?
    > If I send the message "Hello World" from my server to client and I capture
    > the aforementioned packet, lets say, I treat it as two separate records and
    > decrypt each record. I now have two decrypted records. Should I merge these
    > now? If that were the case, are you implying that my inital message "Hello
    > World" has been broken into two parts before it was encrypted? (Maybe one
    > part is "Hello" and the other is " World"?) That does not sound right.
    >
    > The situation that I am facing can actually be repeated by just running the
    > s_server and s_client programs in debug mode and then observing the output.
    >
    > Also, in the packet dump that I had posted earlier,
    >
    > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    > 2b 18 b1 8d d8 3c 15 3d e9 c7
    >
    > and comparing this to the packet format here. I have 32 bytes of application
    > data that should be followed by some amount of padding and 20 Bytes of MAC,
    > which is not available here. But I can clearly see that the algorithm being
    > used is DHE-RSA-AES256-SHA, specifying that SHA is being used. Even, the
    > debug mode in s_server program that I am using shows the same data being
    > transmitted.
    >
    >
    > Regards,
    > Vijay K.
    >
    > On Thu, Jun 26, 2008 at 11:30 AM, Kyle Hamilton wrote:
    >>
    >> The Nagle algorithm will attempt to coalesce multiple write() calls
    >> into a single TCP packet. Since TLS/SSL are a record format atop TCP,
    >> you need to handle the recordss as independent of each other -- i.e.,
    >> you need to process the first TLS record, and then use the results of
    >> that processing to process the second TLS record. Otherwise, the
    >> internal protocol state gets severely fubar'ed.
    >>
    >> Think of this as an attempted attack where Mallory appends a new TLS
    >> record to a short TCP packet. The only way to be sure that it's not
    >> an attack is to process each record independently.
    >>
    >> -Kyle H
    >>
    >> On Wed, Jun 25, 2008 at 12:13 AM, Vijay Kotari
    >> wrote:
    >> > Hi,
    >> >
    >> > I resolved this issue although I am still a little confused about the
    >> > error
    >> > that I was getting previously. I am outlining the steps that I did
    >> > before
    >> > when I had the error and what I did to overcome it, so that some kind
    >> > soul
    >> > here can enlighten me as to why I got the error in the first place.
    >> >
    >> > I have with me the packets obtained from a SSL conversation. I am using
    >> > AES256_CBC for the encryption. Also, I have the connection keys(master
    >> > key
    >> > and 2 oiv's) that are being used. I had earlier sent across a few
    >> > messages
    >> > from my SSL server to client and have been able to decrypt the captured
    >> > packets. Now I sent across a larger sized message(about 20 bytes or so.)
    >> >
    >> > Before -> Error
    >> > The packet dump that I have is
    >> >
    >> > 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >> > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >> > e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    >> > d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    >> > 2b 18 b1 8d d8 3c 15 3d e9 c7
    >> >
    >> > This is actually two packets but they both were sent for a single
    >> > application message (They are fragmented packets).
    >> >
    >> > After the usual intialisation steps,
    >> > I called EVP_DecryptUpdate() and EVP_DecryptFinal_ex().
    >> > EVP_DecryptFinal_ex() returns 0 (error). Also, only the first half of my
    >> > application has been decrypted properly, the second half has not been
    >> > decrypted properly. I initally thought that the decryption failed and to
    >> > test this, I sent across a few messages from the same server to the same
    >> > client in the same SSL session. Hence, the original iv's and master key
    >> > being used is the same, but the current iv is different because
    >> > decryption
    >> > has failed earlier. But I am still able to send across (short) messages
    >> > and
    >> > decrypt them to obtain the cleartext.
    >> >
    >> > After Debugging -> No Error now.
    >> > I did the same as before, but before passing the packet dump to
    >> > EVP_DecryptUpdate(), I defragmented the packet dump, so now my packet
    >> > dump
    >> > looks like this.
    >> >
    >> > 17 03 01 00 40 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >> > 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >> > e9 ab cf 77 e7 76 68 51 17 9e 86 d4 20 6e 31 3e
    >> > 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8
    >> > 3c 15 3d e9 c7
    >> >
    >> > This packet dump is smaller by 5 bytes (The second packet header has
    >> > been
    >> > removed.) and the size field at byte 4 has been updated to the sum of
    >> > bytes
    >> > in both packets.
    >> >
    >> > Now, I am able to send across messages of any size and receive them and
    >> > so,
    >> > my program works great. But I still puzzled as to why I got the error as
    >> > before? Because I am using CBC, if my decryption fails at any one stage,
    >> > I
    >> > should not be able to decrypt any further packets right?
    >> >
    >> > Thanks and Regards,
    >> > Vijay K.
    >> >
    >> >
    >> > On Wed, Jun 25, 2008 at 12:07 PM, Vijay Kotari
    >> > wrote:
    >> >>
    >> >> I am using the traffic obtained from s_server and s_client sample
    >> >> programs
    >> >> and the keys that have been negotiated by both the programs to decrypt
    >> >> the
    >> >> encrypted traffic between the two. That would mean that I am using TCP.
    >> >> Also, I am running them under the CBC mode.
    >> >>
    >> >> Vijay K.
    >> >>
    >> >> On Wed, Jun 25, 2008 at 11:35 AM, Julian wrote:
    >> >>>
    >> >>> It's hard to approach this without knowing the mode of operation you
    >> >>> are
    >> >>> running CBC, OFB, CTR? Also are you using UDP with varying packet
    >> >>> sizes?
    >> >>>
    >> >>> Julian
    >> >>>
    >> >>> On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote:
    >> >>>
    >> >>>> Hi,
    >> >>>> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a
    >> >>>> SSL packet that I have captured. The cipher that I am using AES256
    >> >>>> and
    >> >>>> I can read the application data in cleartext as a result. The problem
    >> >>>> comes if the application data size > 8, which I think has something
    >> >>>> to
    >> >>>> do with me using a block cipher. I can't seem to decrypt the data
    >> >>>> then. Anyways, after inspecting the packet dumps, I realized that
    >> >>>> sometimes I get fragmented packets.
    >> >>>> For Example,
    >> >>>> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc
    >> >>>> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82
    >> >>>> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86
    >> >>>> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11
    >> >>>> 2b 18 b1 8d d8 3c 15 3d e9 c7
    >> >>>> This is actually two packets that are using the SSL application
    >> >>>> protocol, each of size 0x20 (The second packet starts on line 3, 6th
    >> >>>> byte onwards). While decrypting, should both these packets be merged
    >> >>>> together and hence treated as a single packet of size 0x40 or should
    >> >>>> packet be processed separately. Since, we are using a block cipher of
    >> >>>> size 256 bits(32 bytes), will it even make a difference?
    >> >>>>
    >> >>>>
    >> >>>> Thanks and Regards,
    >> >>>> Vijay Kotari
    >> >>>
    >> >>> __________________________________________________ ____________________
    >> >>> OpenSSL Project http://www.openssl.org
    >> >>> User Support Mailing List openssl-users@openssl.org
    >> >>> Automated List Manager majordomo@openssl.org
    >> >>
    >> >
    >> >

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

    >
    >

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


+ Reply to Thread