> From: [email protected] On Behalf Of Kurt Roeckx via RT > Sent: Saturday, 15 June, 2013 11:08
> On Fri, Jun 14, 2013 at 08:09:56PM -0400, Dave Thompson wrote: > > > From: [email protected] On Behalf Of Kurt Roeckx > > > Sent: Thursday, 13 June, 2013 03:13 > > > > > > When talking to an exchange server I get some weird behaviour when > > > > using the 1.0.1e version. I get a TLS 1.0 connection, but the > > > > problems go away when using -no_tls1_2 <snip> > > > > 140527452698280:error:1408F10B:SSL > > > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: > > > > > > That's really weird, unless the server isn't actually doing starttls > > correctly (in spite of offering it). If you can get this to recur, > > try with -state -debug to see exactly where/what is happening. > It's apparently first read after (good) handshake; see below. > I can reproduce this with several servers. <snip> > > > One thing I've noticed is that -no_tls1_2 has as effect that the > > > cipher gets changed from DES-CBC3-SHA to RC4-MD5. > > > > > I don't see why that would result; -no_tls1_2 excludes the 1.2-only > > suites (SHA2 and GCM) from ClientHello, but it still has akRSA-DES3CBC > > preferred over akRSA-RC4 (and akRSA-RC4-SHA over akRSA-RC4-MD5!). > > Are you sure there's nothing else different? Can you get a wire trace, > > or -msg or -debug? > > I've attached 2 log files: > openssl s_client -connect mail.megacontractinginc.com:25 > -starttls smtp -crlf -state -msg -debug &> state_debug.log > openssl s_client -connect mail.megacontractinginc.com:25 > -starttls smtp -crlf -state -msg -debug -no_tls1_2 &> > state_debug_no_tls1_2.log > > One other thing I've learned so far is that with openssl 0.9.8 it > also negiotaties RC4-MD5 and not DES-CBC3-SHA. > Since 0.9.8 only offers upto 1.0 that is somewhat consistent. If you can and care to try 1.0.0, I'd expect it to be like 0.9.8. Looking at your state_debug.log (which tries 1.2) I see: read/write preliminary SMTP as normal write ClientHello: offer 1.2 read ServerHello: agree 1.0 DES-CBC3-SHA rest of handshake normal Aside: I notice your build (here and in no-1.2) doesn't offer IDEA, so I'll guess it was built by longtime anti-patent person. Then we have: > 250 OK > 214-This server supports the following commands: > 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY These appear to be leftover (in mbuf) from the preliminary phase. Then we write 2 encrypted app records, length x18 and x20. The first is presumably the empty-fragment "fix" for CBC<=1.0, and the latter some SMTP command you input of length 4 to 11. Then we read valid header for encrypted app record with length 0x98 and that much apparent ciphertext, which presumably didn't decrypt to a good complete app record because we don't display anything but intsead read for another header and get: > 0000 - 6f 6e 61 31 13 ona1. which is not a correct or even plausible header, so we alert. It would be nice to see what the (partial?) decrypt looks like, but rather a nuisance to write the code to do so. Maybe later. It still is odd for the server to choose (RSA)DES3-SHA for 1.2 but (RSA)RC4-MD5 for 1.1 and 1.0, when DES3-SHA is still offered earlier in the list. Maybe somehow the 1.2 negotiation confused the server into selecting DES3-SHA but not implementing it correctly?? Looking something up, I was reminded DES3-SHA was MUST-implement for 1.1 -- but DHEDSS-DES3-SHA was for 1.0, and that's the same after premaster&keys are negotiated, so if anything that's a reason for it to work correctly. I suggest trying the default=1.2 with -cipher RC4-MD5; if that works try RC4-SHA with default=1.2 and also -no_tls1_2 and/or exact -tls1. Conversely try -no_tls1_2 and/or -tls1 with -cipher DES-CBC-SHA . ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
