Op 19 mei 2014, om 15:04 heeft Dirk-Willem van Gulik <di...@webweaving.org> het volgende geschreven:
> Op 17 mei 2014, om 14:15 heeft Dr Stephen Henson > <shen...@opensslfoundation.com> het volgende geschreven: >> On 14/05/2014 10:23, Dirk-Willem van Gulik wrote: >>> Now I must be getting rusty - we have in the config file >>> >>> SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA >>> SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3 >>> >>> with the first resolving nicely with >>> >>> openssl ciphers -ALL:ECDHE-RSA-AES256-SHA >>> >>> to just >>> >>> ECDHE-RSA-AES256-SHA ... >>> So my assumption is that this server will insist on talking above - and = > >>> nothing else. >>> >>> And on the wire - if I observer the Server Hello I see: >>> >>> Secure Sockets Layer >>> TLSv1.2 Record Layer: Handshake Protocol: Server Hello >>> ... >>> Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = >>> (0xc030) >>> >>> which is sort of what i expect. ….. >>> However when I throw > >>> >>> https://www.ssllabs.com/ssltest/analyze.html >>> >>> their analyzer at it - it seems to be quite able to convince the server = >>> to say hello=92s with >>> >>> SSLv3 Record Layer: Handshake Protocol: Server Hello >>> Content Type: Handshake (22) >>> Version: SSL 3.0 (0x0300) >>> ... >>> Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) …. >> >> It looks like OpenSSL isn't receiving that cipher string properly or if it is >> being overridden by something else possible elsewhere in the config file. You >> can probe individual ciphersuites using s_client like this: >> >> openssl s_client -connect www.hostname.com:443 \ >> -cipher ECDHE-RSA-AES256-GCM-SHA384 >> >> If it isn't supported the connection shouldn't complete. > > Right - yet it does - and matches the suites found by www.ssllabs.com as > well. I’ll instrument OpenSSL a bit to see > what it actually receives and thinks it is doing. > > Perhaps apache manages to confuse some context. Ok - so OpenSSL is not at fault. It is in apache config land that we confuse contexts between virtualhosts; the ___default__:443, the *:443 and the ‚base’ virtual hosts - and I think that this is almost a ‚must’ as soon as SNI is active. And we cannot really solve it with -ALL or !ALL. Will dig a bit deeper - but my guess is that the ‚best’ solution may well be a WARN flag if we detect an ‚override’ on the same ssl context and/or an INFO flag that shows the per VHOST actual result. Will puzzle a bit, Dw
