RE: OpenSSL 0.9.7f released
I've been compiling OpenSSL on a Windows machine using the default nt.mak. OpenSSL 0.9.7e compiled fine this way, but I'm having trouble with 0.9.7f: nasmw -f win32 -o crypto\rc4\asm\r4_win32.obj .\crypto\rc4\asm\r4_win32.asm .\crypto\rc4\asm\r4_win32.asm:30: error: operation size not specified .\crypto\rc4\asm\r4_win32.asm:265: error: operation size not specified .\crypto\rc4\asm\r4_win32.asm:267: error: operation size not specified .\crypto\rc4\asm\r4_win32.asm:271: error: operation size not specified NMAKE : fatal error U1077: 'nasmw' : return code '0x1' Stop. When I use the previous version of /crypto/rc4/asm/rc4-586.pl, it compiles fine. This was obviously triggered by the changes seen here: http://cvs.openssl.org/filediff?f=openssl/crypto/rc4/asm/rc4-586.plv1=1.1.1 .1v2=1.1.1.1.12.1. I've included excerpts of the diff that show which parts of the script are generating the compile errors. Thanks in advance. Matthias Miller stack_push(3); # 3 temp variables add( $d, 8); - and( $x, 0xff); + + # detect compressed schedule, see commentary section in rc4_skey.c... + # in 0.9.7 context ~50 bytes below RC4_CHAR label remain redundant, + # as compressed key schedule is set up in 0.9.8 and later. + cmp(DWP(256,$d),-1); + je(label(RC4_CHAR)); lea( $ty,DWP(-8,$ty,$in)); ... RC4_loop(5,0,1); RC4_loop(6,1,1); + jmp(label(finished)); + + align(16); + # this is essentially Intel P4 specific codepath, see rc4_skey.c, + # and is engaged in 0.9.8 and later context... + set_label(RC4_CHAR); + + lea($ty,DWP(0,$in,$ty)); + mov(swtmp(2),$ty); + + # strangely enough unrolled loop performs over 20% slower... + set_label(RC4_CHAR_loop); + movz ($tx,BP(0,$d,$x)); + add(LB($y),LB($tx)); + movz ($ty,BP(0,$d,$y)); + movb (BP(0,$d,$y),LB($tx)); + movb (BP(0,$d,$x),LB($ty)); + add(LB($ty),LB($tx)); + movz ($ty,BP(0,$d,$ty)); + xorb (LB($ty),BP(0,$in)); + movb (BP(0,$out),LB($ty)); + inc(LB($x)); + inc($in); + inc($out); + cmp($in,swtmp(2)); + jb (label(RC4_CHAR_loop)); + set_label(finished); dec( $x); stack_pop(3); __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Unexpected record when client renegotiates
I am experiencing some problems with OpenSSL renegotiations. The scenario is quite simple: If a server is sending data to the client while the client requests a renegotiation, the client will fail because it encountered an unexpected application data record. I'm unsure whether this is behavior is a bug or whether it is expected behavior. I checked the OpenSSL documentation but was unable to find anything that related this problem. I searched the mailing list archives and discovered that others have already asked about this problem, but I could find no responses to these questions. Here are four related posts, with the most recent posts listed first: * http://groups-beta.google.com/group/mailing.openssl.users/browse_thread/thre ad/21a982b37abc3b1a/b59af8dd1bced845 * http://groups-beta.google.com/group/mailing.openssl.users/browse_thread/thre ad/b4e4dfb5afe85ae5/c0504dc6db750f71 * http://groups-beta.google.com/group/mailing.openssl.users/browse_thread/thre ad/a21dfc5e8e2fd414/1f46224112e3cc4b * http://groups-beta.google.com/group/mailing.openssl.users/browse_thread/thre ad/2324b7b1bab8070c/05d055256fabe8d1 This problem can be demonstrated in the s_server and s_client sample programs. I have tested this with the last stable release (openssl-0.9.7e) as well as with Monday's snapshot (openssl-SNAP-20050214.tar.gz). Here's how to duplicate: -Launch the server and client, using default settings--no command line parameters, and using the certs in apps folder -In the server type a message such as Hello, but do not press enter. -In the client press 'R'; it will display a RENEGOTIATING message. -In the server, press enter to send the Hello message. The client will fail with the following error: 3520:error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected record:.\ssl\s3_pkt.c:1194: In a real-world environment, it appears that when the client requests a renegotiation while the server is streaming data, the client will fail because it received unexpected application data from the server. Is this a limitation of the SSL protocol, of the OpenSSL library, or of the s_server and s_client samples? Also, what is the appropriate way of dealing with this problem? Will OpenSSL eventually support this, or is this something that must be built in each application's protocol? Thank you. Matthias Miller __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
