Mailing List Archive: SSL cipher list is completely bogus

SSL cipher list is completely bogus

Jun 24, 2002, 9:03 AM

Post #1 of 3 (1670 views)

Hi,

The Nessus SSL plugin shows a completely incorrect cipher list. The
plugin calls OpenSSL's SSL_get_ciphers() function, which returns the
list of ciphers supported by *our* host, not the remote. This may
depend on the protocol version and/or OpenSSL settings, so it is not
always the same, though.

The list of ciphers supported by the remote end is not easily
available in SSLv3/TLSv1. The client sends a list of cipher suite
proposals in the "Client Hello" packet, and the server chooses one of
them. Thus, the only way to obtain the list of supported cipher suites
is to try all known suites one by one.

In SSLv2, this information is available (at least in theory),
because the Hello messages are different.

I have written a small Perl script which tries the known cipher suites
one by one; converting it to NASL shouldn't be a big problem...
Any volunteers? :-)

Best regards,

Pasi

--
Pasi Eronen E-mail pasi.eronen@nixu.com
Nixu Oy Tel +358 50 5123499
Mäkelänkatu 91, 00610 Helsinki Fax +358 9 4781030

Re: SSL cipher list is completely bogus [ In reply to ]

arboi at noos

Jul 14, 2002, 6:53 AM

Post #2 of 3 (1616 views)

Permalink

Pasi Eronen <pasi.eronen@nixu.com> writes:

> The list of ciphers supported by the remote end is not easily
> available in SSLv3/TLSv1.

So I suppose that the right way to test this would be:

on our side, select only "null" ciphers and try to negociate a
connection.
Then only weak/export ciphers...
... 56 bits ciphers...
... strong ciphers...

And then print warnings according to what worked and did not work.

> In SSLv2, this information is available (at least in theory),
> because the Hello messages are different.

I fixed the script.

> I have written a small Perl script which tries the known cipher suites
> one by one

Well, is this necessary, after all?

> converting it to NASL shouldn't be a big problem...

Not to NASL. To C.

Re: SSL cipher list is completely bogus [ In reply to ]

reinke at e-softinc

Jul 15, 2002, 10:17 AM

Post #3 of 3 (1610 views)

Permalink

Unless something has changed that I'm not aware of, with SSLv3/TLSv1,
the server never gives a message to the effect of "this is
the list of ciphers that I will support based on what you gave me".
That means that the only indication is the actual acceptance of
a cipher, meaning that you can only provide one at a time for
testing acceptance by the server.

Therefore - the correct methodology is the perl script's approach -
a one by one connection attempt for each possibility, and recording
whether or not the server accepted it.

It's for this reason that we've never bothered to report on ciphers
in our SSL server surveys (e.g.
https://secure1.securityspace.com/s_survey/sdata/200206/protciph.html)
because it just raises the overhead too much.

Thomas

Michel Arboi wrote:
>
> Pasi Eronen <pasi.eronen@nixu.com> writes:
>
> > The list of ciphers supported by the remote end is not easily
> > available in SSLv3/TLSv1.
>
> So I suppose that the right way to test this would be:
>
> on our side, select only "null" ciphers and try to negociate a
> connection.
> Then only weak/export ciphers...
> ... 56 bits ciphers...
> ... strong ciphers...
>
> And then print warnings according to what worked and did not work.
>
> > In SSLv2, this information is available (at least in theory),
> > because the Hello messages are different.
>
> I fixed the script.
>
> > I have written a small Perl script which tries the known cipher suites
> > one by one
>
> Well, is this necessary, after all?
>
> > converting it to NASL shouldn't be a big problem...
>
> Not to NASL. To C.