2008/8/4 abc_123_ok <[EMAIL PROTECTED]>: > 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 for posting the resolution. > thanks a lot. You're welcome! Take care, Ger > > ________________________________ > 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豰稛�?(ラ觳Z+並 ?│婍1ē妜 > 娝hラ觳[瑉?ラ觳Z+€ > f瓂意灿 潹 甪＂穐殜)z{,枈 -- 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 --------------------------------------------------
