On 08/12/14 13:53, Kurt Roeckx wrote: > On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote: >>>> Just one other point: if somebody is trying sending the client hello >>>> using SSL v2 record layer but indicating support for TLS v1.0, should >>>> TLSv1_method or SSLv23_method accept that? >>> I would expect that both should support that. >> With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with >> >> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number >> >> Error code = 336130315 file=s3_pkt.c line=348 > So I start an s_server with: > openssl s_server -tls1 > > And then: > openssl s_client: TLSv1 > openssl s_client -tls1: TLSv1 > > I tried the s_server and s_client on both jessie and wheezy. This > should just work. > > If both sides drop the -tls1 of course changes to TLSv1.2. > > But it really should always work, and if doesn't I'd argue that's > a bug. > > But you say that it sends an SSLv2 compatible client hello. By > default it shouldn't be doing that unless you change the ciphers > suite to include SSLv2 ciphers and aren't using any extentions, > and as far as I know you currently can't disable extentions in > either wheez or jessie. It is the opposite - the remote system is sending the SSLv2 compatible client hello. The Debian/repro system is the server side.
I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
