RE: verify HTTPS 'vulnerabilities'

Hi Dan,

I would first check out the NASL script in Nessus to see the exact
code that was able to detect these issues. As you already know the IP
is correct, I wouldn't follow this up any further.

After that I would use Mozilla and configure the settings to allow
connections to the cypher Nessus is reporting. If the connection is
allowed and you get a basic auth prompt, voila!

If you know any logins on the box why not brute force the basic
auth...why stop at these issues?

Cheers,
Jordan

List,

Simple question:

I have a report from Nessus telling me that a web server is offering
'export class' cyphers for it's SSL/TLS service. Nessus also managed
to obtain an internal IP address from the host (which is correct).
Only HTTPS is open.

However the target host requires basic authentication, and I don't
have any credentials to obtain access. I would like to verify these
manually, and would usually just use something like wfetch. However,
I'm not getting the usual prompt that my encryption is too weak.
Instead in the response I can see a message saying the page cannot be
displayed. There is also no sign of the internal IP address.

Can anyone tell me how they would prove that they are not false
positives (I know the IP address is correct, but the client may want
to replicate the vulnerability so they can be sure when they go to fix
it)?

thanks

Dan