On Friday 12 March 2010 14:44:15 Thomas Reinke wrote: > Michael Meyer wrote: > > *** Chandrashekhar B <bchan...@secpod.com> wrote: > >>> On Friday 12 March 2010 10:06:42 Jan-Oliver Wagner wrote: > >>>> * migrate ssl_ciphers to use GnuTLS > >>> > >>> Is this the C check? If so, I would prefer not to move to > >>> GnuTLS. GnuTLS is rather conservative in what ciphers it > >>> supports and may therefore miss weak ciphers because it > >>> doesn't support them rather than because the scanned service doesn't. > >> > >> Yes, agree, let us invalidate this plugin and write in NASL. > > > > But this means, do this check with GnuTLS because NASL is linked > > against it. So this will not solve Tim's concern. Or am I mistaken? > > Didn't someone have a potential solution for this (Chandra?) suggesting > ssl-enum? I believe, IIRC, it was a tool set that tested for ALL > ciphers and didn't need an SSL library to do so (went straight to the > protocol level). It was a C based tool, but it was not very > complicated. In either case, you could either make this tool > available to be called from a nasl plugin, or with a bit more > effort, duplicate the functionality in nasl. In both cases, you > are not reliant on the scanner library's SSL cipher set limitations.
Me I think (I've mentioned it at various times since the last devcon), although Chandra may have picked up on it. Different libraries support different cipher suites, my suggested GSoC project was to implement a script that can talk to servers built with each of them. ssl-enum does this as do a couple of others. My point was that in the mean time, replacing OpenSSL with GNU/TLS for this C plugin adds extreme regressions and that I disagreed that it should happen. Tim -- Tim Brown <mailto:t...@openvas.org> <http://www.openvas.org/>
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
