Kurt, You're correct that sslscan uses SSLv3_client_method() - it also uses the SSLv2, TLS1.0, 1.1 and 1.2 equivalents as well depending on which protocols are enabled in OpenSSL (and which ones it's told to scan with commandline options). TLSv1.2 is supported (it can be forced with --tls12) - not sure why that wouldn't be working for you.
I'm fully expecting SSLv3 to stop working in sslscan on Debian (just like it did when SSLv2 was disabled a while back). I installed sid so that I could patch sslscan so it would still build and run properly (albeit with a warning message) if there was no SSLv3 support in the library) - which is when I found that SSLv3 was still working despite the appearance that it wouldn't. Once the SSLv3 stuff is properly gone I can look at patching sslscan, and also updating the script that comes with it to rebuild OpenSSL with SSLv2 (and now SSLv3) support). Thanks, ~Robin On 18/10/14 13:28, Kurt Roeckx wrote: > On Sat, Oct 18, 2014 at 01:06:29PM +0100, rbsec wrote: >> Kurt, >> >> Just realised that I'd replied to you off-list - my bad. >> >> I'm not really sure where this should be logged as separate bug (or a >> security issue?) - I'll leave that up to you guys. > So my current understanding is that sslscan uses > SSLv3_client_method(), and that that is probably the only way to > still set up an SSL 3.0 connection. > > I don't plan to bring back SSL 3.0 support, just assume that it's > going to go away. > > sslscan also doesn't seem to support TLS 1.1 or higher for some > reason? > > > Kurt > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org