On Jan 8, 2004, at 4:10 PM, [EMAIL PROTECTED] wrote:
Hi Mark,
1) Is the ssltest.nasl plugin reliant on identifying openssl via the HTTP
server header? Will it still run if someone intentionally modifies the
header to hide its version, etc.?
No. ssltest.nasl identifies the remote version of OpenSSL based on its behavior
to a certain action. Note that SSL does not imply HTTP on top of it, so the plugin
will check for any kind of service running on top of SSL instead of just focusing on web
servers.
2) Does the test actually test for all three of the original bugs,
CAN-2003-0545, CAN-2003-0543, and CAN-2003-0544 as well as the later bug
from November CAN-2003-0851? (I get no grep hits on the latter CAN in my
plugins directory)
No, it checks for _none_ of these bugs (as it would be otherwise destructive).
The fixed version of OpenSSL changed its behavior : in the past, if you connected
to it and sent it a certificate, it would read it and parse it anyway. In the fixed
version, if you send a certificate whereas the remote SSL service did not ask you
to, OpenSSL sends you an error message.
3) Is the client cert noted in ssltest.nasl actually a copy of a client
side certificate that has bad ASN.1 encoding?
No, otherwise the check would be destructive (ie: it would crash the remote SSL
service, which is something we don't want to do).
4) Is there another, perhaps manual, way to determine the SSL version or
code base of a device from a "black box" perspective? If there is no HTTP
header, how might someone go about fingerprinting the service?
You'd need to do "SSL fingerprinting" - send on-the-edge SSL requests
(on the edge protocol-wise), and look at how the remote SSL stack responds
to them. openssl_overflow_generic_test.nasl and ssltest.nasl could be good
starting points for such a tool. If you look closely at ssltest, you'll see that it
can inherently distinguish MS CryptoAPI and Novell from OpenSSL, by
submiting a request asking for SSLv15 (which does not exist), and looking
at the answer (only OpenSSL rejects this request).
By coming up with a lot of 'dirty tricks' like this, you could probably do
a good SSL fingerprinting tool. Now, given the complexity of SSL, it might
not be very easy to distinguish two sub-versions of the same library too easily.
I hope this helps,
-- Renaud
_______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
