search

prbinu / tls-scan

An Internet scale, blazing fast SSL/TLS scanner ( non-blocking, event-driven )
https://prbinu.github.io/tls-scan
Other
283 stars 54 forks source link

Query about handeling the input domain names #14

Closed ealashwali closed 6 years ago

ealashwali commented 5 years ago

Hi, just want to make sure from few points please for accurate description of the tool's function. I looked at the code already and did some inspection, I assume few points, but it is better to confirm from you as an author. I will appreciate your reply.

1) If I am using tls-scan command without any enumeration options, just with custom ciphersuites, then tls-scan will act as a regular client, and the session reuse is disabled by default (I do not add the --session-reuse).

./tls-scan --infile=input.csv --port=443 --cacert=../../../../../etc/ssl/certs/ca-certificates.crt --concurrency=10 --ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384" --outfile=output.json

2)tls-scan tries to connect to the domain name "as is". I just want to make sure that it does not make a second attempt by adding "www." prefix if the connection to the original domain has failed as some scanners do. If this is the case, this is what I need but just need to make sure please.

3) If tls-scan could not establish a connection to a domain because it does not support any ciphersuites that exist in the server side, then I expect tls-scan will just terminate the session (as far as I can see it print error Error encountered while reading in the screen) and move on. No further handshakes attempts made?

I hope my assumptions are clear to you. I just need you to confirm please.

prbinu commented 5 years ago

Hi, just want to make sure from few points please for accurate description of the tool's function. I looked at the code already and did some inspection, I assume few points, but it is better to confirm from you as an author. I will appreciate your reply.

  1. If I am using tls-scan command without any enumeration options, just with custom ciphersuites, then tls-scan will act as a regular client, and the session reuse is disabled by default (I do not add the --session-reuse).

./tls-scan --infile=input.csv --port=443 --cacert=../../../../../etc/ssl/certs/ca-certificates.crt --concurrency=10 --ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384" --outfile=output.json

that is correct.

2)tls-scan tries to connect to the domain name "as is". I just want to make sure that it does not make a second attempt by adding "www." prefix if the connection to the original domain has failed as some scanners do. If this is the case, this is what I need but just need to make sure please.

no redirects or reconnects.

  1. If tls-scan could not establish a connection to a domain because it does not support any ciphersuites that exist in the server side, then I expect tls-scan will just terminate the session (as far as I can see it print error Error encountered while reading in the screen) and move on. No further handshakes attempts made?

I think handshake is attempted for each ciphers, irrespective of what ciphersuites the server sends (in ServerHello). Though it is less optimal, the Server may respond differently with different ClientHello ciphers, so it is better to ignore. Are you seeing a different behavior?

I hope my assumptions are clear to you. I just need you to confirm please.

ealashwali commented 5 years ago

If tls-scan could not establish a connection to a domain because it does not support any ciphersuites that exist in the server side, then I expect tls-scan will just terminate the session (as far as I can see it print error Error encountered while reading in the screen) and move on. No further handshakes attempts made?

I am not doing any enumeration options. Just a simple client as the command above. What I get when I try to connect to a server that does not support the client's ciphersuites is this error: Error encountered while reading. Also, I see a single ClientHello in packet inspection (Wireshark). This is what I expect and I think is the correct behavior.

This is one example: ./tls-scan --connect=alfred.com --port=443 --cacert=../../../../../etc/ssl/certs/ca-certificates.crt --concurrency=10 --timeout=5 --ciphers="ECDHE-ECDSA-AES128-GCM-SHA256"

Output:

host: alfred.com; ip: ; error: Network; errormsg:                      Error encountered while reading
 pid: 11283 | ciphers: (0) |dns-lookup: 1 |network-error: 1 |dns-errcount: 0 |remote-close-error: 0 |unknown-error: 0 |connect-error: 1 |timeout-error: 0 |tls-handshake: 0 |gross-tls-handshake: 0 |elapsed-time: 0.291550 secs

In a normal client, I think this should be the case. A single handshake. Enumeration is different thing where multiple handshakes each one offers a single ciphersuite. But just need to make sure that the tool acts as a simple client with a single handshake if I specify the ciphersuites. I do not want enumeration in my case.