On 2012-05-30 John Jetmore <[email protected]> wrote: > On Tue, May 29, 2012 at 6:55 PM, John Jetmore <[email protected]> wrote: > > On Tue, May 29, 2012 at 2:38 PM, Andreas Metzler > > <[email protected]> wrote: > > > >> I think you need a rather new OpenSSL to show the bug. - With openssl > >> s_client (and GnuTLS) there are problems with this server if the > >> client tries to use TLS1.1 or TLS1.2. > >> > >> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674990#35
> It's not just the newer openssl, it's some interaction between openssl > and Net::SSLeay. I installed activestate perl on an unstable box, > running an older Net::SSLeay (1.36) and it was able to connect to the > .jp server without any errors. Hello, I would suspect that the older Net::SSLeay does make not use/offer the newer features of current OpenSSL, i.e. t would not do any TLS1.1 or TLS1.2 connections. I cannot quickly check without rebuilding, as the older libnet-ssleay-perl binary debian package requires an older version of perl. (My MX supports TLS1.1, feel free to test against it.) > > [...] but lack of > > error checking in swaks is the cause of the seg fault. Â The funny > > thing is I refactored some TLS stuff for the next release and, while > > doing so, added a bunch of error checking. Â If I test this server with > > the latest swaks in SVN I get this instead of the segfault: > > > > Â -> STARTTLS > > <- Â 220 Go ahead > > *** TLS startup failed (error:00000000:lib(0):func(0):reason(0)) > > *** STARTTLS attempted but failed > > Â -> QUIT > > > > I'll spend some time seeing if I can get a more descriptive error, but > > I think the basic part of the fix is already there. > I sent some time banging on this, and added some more error checking > on general principle, but the error above is the best I can get right > now for some reason, and I think it's likely related to the larger > "why can't this combination of perl/openssl/Net::SSLeay negotiate a > TLSv1 connection with that server" issue. [...] > Other than saying "it won't segfault in the next release", not sure > what else to do here (though I'm open to suggestions if I'm > overlooking something). As swaks is a debugging tool I think it would be nice if there was some enhanced knob to force a specific TLS version (as s_client) does. Other than that I have not got any suggestions. Neither s_client nor gnutls-cli can handle this server gracefully either. ;-) cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
