thanks Ger Hobbelt and All, my question have been solved,
thanks a lot. 2008-08-02 abc_123_ok 发件人： Ger Hobbelt 发送时间： 2008-07-30 16:52:00 收件人： openssl-users 抄送： 主题： 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. <off topic> 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. </off topic> 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: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] .
