Info: Understanding SSL/TLS Certificate Discovery Scans

Applies to:

Certificate Discovery Scans (not including SSH discovery)

SSL/TLS

Discovery work will be broken into blocks to be picked up by the discovery engines.  If Discovery zoning is employed discovery engines will pick up the work they are able to process in their assigned discovery zone. If no discovery zone's are defined the discovery engines will pick up the work randomly.

If the IP address is part of the server's subnet then an ARP request is performed to determine if the host actually exists on the network. If the ARP request fails then no TCP handshake will be attempted. If the ARP request succeeds then TPP will attempt a TCP handshake.

If the IP is not part of the server's subnet then the server will not perform and ARP request and will simply begin the TCP handshake.

After each successful test of an open TCP connection, the connection is reset and is remade before a two-way SSL handshake is attempted over the listening port.

The handshake process includes the client and server negotiating cipher suite and SSL/TLS protocol version, during which a single protocol version is agreed between TPP (the client) and endpoint (the server).

Certificate retrieval will only be made using the first successfully negotiated protocol, regardless of any other versions being supported on the endpoint.

Note that the certificate is provided in the SERVER HELLO, which occurs before the session key is exchanged.

SSL/TLS Negotiation:

Note this is different to the validation behaviour, where multiple connections over the five SSL\TLS protocol versions (SSL 2.0, 3.0, TLS 1.0, 1.1 and 1.2) are made to ascertain what’s supported by the endpoint.

Q. Why could a wire trace enumerate a higher number of connections between a TPP engine and a single IP address over different ports e.g. 10 between TPP host and target server 10.10.10.1:443 and 20 to 10.10.10.2:443?

A. Because even though discovery only needs to successfully negotiate one protocol, it may require multiple attempts. 

Some legacy servers are not able to complete the SSL Handshake when the client presents protocol options it doesn’t understand so it is necessary to try again using a different set i.e. that’s the reason discovery has the different protocol sets to try; so that if a client for example presents TLS 1.2 ciphers to a server that only understands SSL 3.0 and TLS 1.0, the server might reject the connection even when the client has included SSL 3.0 ciphers, too.

Protocol settings in Platforms determine which outgoing SSL/TLS protocol versions are supported for web services endpoints (such as the SOAP or REST APIs offered by CAs) and for Discovery.

Where a protocol (e.g. TPP outgoing on TLS 1.2) is not supported by the target OS, but that is the ONLY protocol enabled on the target, expected behaviour is that a two-way handshake will fail and a certificate will not be retrieved.

Note also, that in terms of on-the-wire analysis of data communications during network discovery, TPP makes use of .NET libraries, so some of the low-level connection behaviours are solely governed by Microsoft’s implementation decisions.  

If the discovery engine is AD joined it will periodically generate standard AD/Windows protocol traffic (such as Ldap and Kerberos), as for example in the process of verifying its AD provider every 15 minutes.

However, this doesn’t imply that a standalone TPP server - with only discovery enabled – will not make similar calls.

As a member of the same TPP context, it shares dependencies (such as an AD provider), and since it leverages the same .NET code it can make the same calls e.g. the AD provider performing heartbeat checks.

That being said the actual discovery scan's are not reliant on the AD being available, should you decide to block AD traffic for Discovery only engines.