Re: Re: Re: hello everyone - Openssl

This is a discussion on Re: Re: Re: hello everyone - Openssl ; On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote: > I want to know what the 24 byte is. The TLS "record layer" uses a 5 byte header. The actual data is extended with a MAC, and encrypted which ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Re: Re: hello everyone

  1. Re: Re: Re: hello everyone

    On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote:

    > I want to know what the 24 byte is.


    The TLS "record layer" uses a 5 byte header. The actual data
    is extended with a MAC, and encrypted which often adds CBC padding.

    You should not make any assumptions about the length of the encrypted
    data on the wire, there may also be packets for renegotiation if the
    client or server chooses to do that.

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


  2. Re: Re: Re: hello everyone

    > I use openssl as a server to test SSL client of our comany. the SSL client
    > is a part of embedded system
    > I used command as blow in Cygwin.



    From this I take it your embedded client does NOT use OpenSSL code, correct?


    --
    Met vriendelijke groeten / Best regards,

    Ger Hobbelt

    --------------------------------------------------
    web: http://www.hobbelt.com/
    http://www.hebbut.net/
    mail: ger@hobbelt.com
    mobile: +31-6-11 120 978
    --------------------------------------------------
    :I"Ϯrm (Z+K*+1x h[z(Z+ *f*yfh)z{,

  3. Re: Re: Re: hello everyone

    > yes , you are correct , my client does not use Openssl code.

    Okay... Well, this significantly complicates matters as I assume you
    have either (a) written the embedded code from scratch, or (b) use a
    different third party library for that code. Where 'gut feeling' makes
    me bet on (a) here. Correct?

    Anyway. The SSL protocol is standardized, so the problem is not there,
    but your issues are /very/ likely due to subtle bugs and/or lacking
    features in implementing the protocol in the embedded code.

    Maybe an 'open door' but note that SSL is not only 'encrypting' your
    raw data, but also includes protocol messages to signal the other side
    (re-)authentication or other SSL-defined activity is required. One of
    those messages is #23 (decimal) which is 'application_data' (see
    RFC4346 and other relevant spec documents).

    Message #23 does not just contain the 'encrypted application data' as
    is, but includes extra stuff, depending on cipher suite and protocol
    version. CBC ciphers require an IV to start, so the first few bytes
    VERY PROBABLY are the IV being sent to the other side (since you use
    CBC). Within the same message #23 (see RFC4346 for TLS1: appendix
    A.1), you will find trailing data constituting the MAC and padding,
    which will easily account for 24 bytes. (SHA-1 MAC at 160bits = 20
    bytes already; padding may be an 'arbitrary' length.)

    Before we dive into that a little deeper, have a look at the network
    data passed between an *OpenSSL* client and *OpenSSL* server, like the
    s_client/s_server example you showed a little before here: notice
    there that the 'user' gets to see the plaintext data *exactly* as
    typed on the other side, but when you look at the raw TCP packets sent
    up and down, the TCP 'data' (so anything beyond the TCP header in the
    network packet) will contain some /extra/ (mostly encrypted) data as
    well: that's the SSL protocol layer at work. (I refer to s_client +
    s_server here, because you can quickly see those two 'work together
    fine'. This is very complex stuff so we try to go down one level at a
    time.) Your network sniffer apparently is able to decode the protocol
    sufficiently to show you the individual SSL protocol messages as I see
    SSL protocol message (23) explicitly mentioned there.

    However, NEVER think 'application data' == "my encrypted data and that's all"!
    Like I said, there's the IV, MAC and padding in there. And if you
    really want/need to travel all seven levels of Dante's Hell, you may
    wish to read the full SSL/TLS specification and then have a look at
    the actual SSL implementation of OpenSSL. Excellent work in my
    opinion, but like anything concerning cryptography, there's additional
    tweaks in there for security issues found by researchers after the
    specifications were cast in RFC rock. For a prime example of such, may
    I point you to the source code of [ssl/s3_pkt.c] and that includes
    reading the text available at the /~bodo/ URL mentioned in the
    comments there.

    Again, note that the code may be initially hard to read, but that
    wasn't done for 'fun' but because you need to watch out for a zillion
    things all at the same time.


    Generally speaking, I've found that one of the things to quickly break
    not-so-well-done SSL protocol implementations is having your [OpenSSL]
    implementation send an enforced 'cipher suit change' / 'renegotiation'
    message (and 'issue' which would otherwise only be reported for 'long
    transfers' due to internal SSL renegotiate timeout being triggered).
    You can try one example of this sort of neckbreaker by running
    s_client and typing a lone 'R' on a line (that's typing [Enter], [R],
    [Enter]). Hell, that breaks most 'overly naive' application code using
    OpenSSL -- which is /not/ a problem with OpenSSL or SSL itself, but
    rather programmers who cut&paste example code and don't check up on
    specs nor test beyond the 'It Just Works Now(tm)' stage, but I digress
    here.



    Returning to your encrypted 'application data' chunks: as described in
    the tls-cbc.txt (see URL in s3_pkt.c), the data not only contains your
    encrypted plaintext, but also IV, MAC, padding and possibly extra
    (zero length plaintext) data -- at least if I have interpreted the
    tls-cbc.txt, the source code and the protocol correctly. (If I made
    any mistake here, please correct me!)

    Besides, SSL is allowed to fragment / bundle your data in more or
    fewer application_data(23) messages as it deems necessary. (A process
    somewhat comparable to packet fragmentation on the IP and physical
    network layers for non-encrypted network communication protocols.)
    You may find that the code uses *_RT_APPLICATION_DATA #defines for the
    SSL protocol layer message [processing] where application data is
    pushed across the wire.




    Summarizing:

    Your message #23(decimal) 'application_data' consists of cipher-suite
    and protocol dependent 'extra data', next to the straight encrypted
    plaintext you wanted to transmit across the wire. 'extra data' here
    may be any of IV, MAC and padding, though it is not necessarily
    limited to those. See the SSL/TLS RFCs and the OpenSSL ssl/*.[ch] code
    for further investigation.
    Also note that when constructing the protocol on your own that there
    is no 'single correct answer' here: your receiver implementation MUST
    be able to cope with the subtleties here (such as the ones mentioned
    in the tls-cbc.txt text).


    Given the /large/ complexity that comes with a /proper/ implementation
    of the SSL protocol, I would personally advise you to spend your
    efforts on porting OpenSSL to your embedded environment instead of
    crafting your own -- assuming you are trying something like that now
    (the (a) bet I mentioned at the start of this message). I have ported
    OpenSSL to various non-UNIX platforms in the past and it may be more
    or less of a challenge (memory footprint issues can be a factor, as is
    the lack of a C runtime library offering file I/O APIs, etc.) but I
    have found that the problems you will be facing then are of an
    entirely different (and lacking readily available outside /expert/
    help, far more manageable) nature. In the end this leaves you time to
    struggle with OpenSSL API issues you may run into instead. At THAT
    level, extra help is available in the form of, for example, the
    O'Reilly OpenSSL book and the wide range of experience available on
    this mailing list as well, while your current issue reads to me as a
    question only properly answerable by the few people on this earth who
    have actually built an SSL protocol implementation themselves.




    Ah, also have a look at this for the format of those SSL messages,
    including application_data(23) (found these after I wrote the above,
    may be easier to grok):

    message layout in bytes:
    http://en.wikipedia.org/wiki/Secure_Sockets_Layer

    shows a message trace just like yours with a bit of explanation:
    http://blogs.sun.com/sin/entry/ssltap_ing_ssl_and_tls



    --
    Met vriendelijke groeten / Best regards,

    Ger Hobbelt

    --------------------------------------------------
    web: http://www.hobbelt.com/
    http://www.hebbut.net/
    mail: ger@hobbelt.com
    mobile: +31-6-11 120 978
    --------------------------------------------------
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread