Re: [NSE] More cipher suites needed in ssl-date

[nnposter () users sourceforge net]

Daniel Miller wrote: 
> On Tue, Jul 22, 2014 at 4:27 PM, <nnposter () users sourceforge net> wrote:
> > The current version of ssl-date.nse supports only the following three
> > cipher suites:
> >
> > TLS_ECDHE_RSA_WITH_RC4_128_SHA
> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> > TLS_RSA_WITH_RC4_128_MD5
> >
> > This restriction is causing issues when used against older Windows
> > systems because they support only the RSA key exchange. This leaves us
> > only with RC4+MD5, which is unreliable because targets tend to have it
> > disabled due to using MD5 or because of the problematic RC4 or simply
> > because the cipher suite is not FIPS-compliant.
> >
> > I am proposing to add a fourth cipher suite that:
> >
> > * Maintains key exchange compatibility by using the RSA key exchange
> > * Is compliant with FIPS (and inherently avoids both RC4 and MD5)
> >
> > The obvious candidate is TLS_RSA_WITH_3DES_EDE_CBC_SHA.
>
> Thanks for this suggestion. In r33300, I added TLS_RSA_WITH_AES_128_CBC_SHA
> to the list of cipher suites in ssl-date and in tls-nextprotoneg, since at
> least the TLS 1.2 RFC says this suite must be included in compliant
> implementations "In the absence of an application profile standard
> specifying otherwise" (https://tools.ietf.org/html/rfc5246#section-9)
>
> If this does not solve your problem, we can easily expand these checks to
> include a few more well-supported cipher suites.

I fully agree with your reasoning of adding a mandatory cipher suite
but I would still also argue for the 3DES cipher suite because Windows
Server 2003 does not seem to support AES without installing KB948963.


Cheers,
nnposter


[1] http://support.microsoft.com/kb/948963
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/