> -----Original Message----- > From: [email protected] [mailto:owner-openssl- > [email protected]] On Behalf Of Garrison, Jim (ETW) > Sent: Tuesday, June 12, 2012 10:41 AM > To: [email protected] > Subject: RE: Configure OpenSSL to skip SSL1 & SSL2? > > > -----Original Message----- > > From: [email protected] [mailto:owner-openssl- > > [email protected]] On Behalf Of Jeffrey Walton > > Sent: Monday, June 11, 2012 8:38 PM > > To: [email protected] > > Subject: Re: Configure OpenSSL to skip SSL1 & SSL2? > > > > On Mon, Jun 11, 2012 at 4:32 PM, Garrison, Jim (ETW) > > <[email protected]> wrote: > > > I am trying to connect to a subversion server that requires https, > > > and for some reason, is configured to require SSL3 or TLS1. It > > > refuses to respond to SSL or SSL2. > > You are lucky its responds to SSLv3. I would shut it down too (TLSv1 > > is not too far away for me, either). > > So, the question remains. Is this something that can be configured at > runtime? > > Also, If the server disallows certain protocols, shouldn't its SSL > implementation > respond with a negotiation sequence when the client attempts to use a > disallowed protocol? Is the total lack of response to an SSL1 CLIENT HELLO > surprising, or is that the expected behavior? The server is Apache. > > > > > > I’ve done some troubleshooting using s_client and confirmed that if > > > I let s_client start with the default protocol the server never > > > responds to the CLIENT HELLO: > > > > > > $ openssl s_client -connect server.domain.com:443 > > > CONNECTED(00000003) > > > write:errno=104 > > > --- > > > no peer certificate available > > > --- > > > No client certificate CA names sent > > > --- > > > SSL handshake has read 0 bytes and written 320 bytes > > > --- > > > New, (NONE), Cipher is (NONE) > > > Secure Renegotiation IS NOT supported > > > Compression: NONE > > > Expansion: NONE > > > --- > > > Watching this in Wireshark I see: > > > Client Server > > > -------syn----------> > > > <------ack----------- > > > --SSL CLIENT HELLO--> > > > <------ack----------- > > > [60 second pause] > > > <------rst-----------
After more research I have discovered that the problem is not an old protocol, but maybe a too-new protocol. Here are the two cases: * openssl s_client -connect gbit:443 This sends a TLSv1.2 handshake inside a TLSv1.0 CLIENT HELLO, and Apache fails to respond. * openssl s_client -connect gbit:443 -tls1 This sends a TLSV1.0 handshake inside a TLSV1.0 CLIENT HELLO. Apache accepts the connection Is this expected behavior? AFAICT Apache does not have a config option to explicitly enable TLSv1.2 negotiation.
