Dear Ger, ^_^ the reason is I didn't decrypt the 24 bytes data, so the IV don't update , as a result is the data decrypted is error.
thanks a lot. abc_123_ok 2008-08-04 发件人： Ger Hobbelt 发送时间： 2008-08-04 17:08:38 收件人： openssl-users@openssl.org 抄送： 主题： Re: Re: Re: hello everyone Great! I'm curious: what was the solution? Thanks, Ger On Sat, Aug 2, 2008 at 10:12 AM, abc_123_ok <[EMAIL PROTECTED] > wrote: > 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] > . -- 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 -------------------------------------------------- :��I"袭��r�m���?(ラ觳Z+�K ?│��1ē�x ��hラ觳[�z?ラ觳Z+� ��f�y意灿�� �f＂�h��)z{,��
