Info: How does Network Discovery work at the packet level?

Applies to:

All versions of Certificate Manager, and SSH key manager, TrustAuthority, TrustForce

Summary:

This article describes what happens at the packet level when we launch a discovery.

More info:

The purpose of discovery is to look for public certificates on the ports of Ip Addresses. It does this by emulating HTTPS clients as it contacts each IP Address/port combination. Certificate Manager does not generate any packets on it own, but uses the regular connection/socket code that is part of Microsoft.Net. This article explains what happens at the packet level when the Venafi Encryption Director service initiates a discovery.   

There are two main ways you can setup discovery on a Certificate Manager server. One is wizard based, and discovers single devices at one time, and the other discovers entire subnets, or ranges of subnets. For details on how to setup each Discovery job, see KB 21400338'

For both types of discovery the packet sequence is as follows:

• If you provided a DNS name, the first protocol seen on the wire is reverse lookup using DNS looking for class A type responses.

• Once the ip address is established, an attempt to sync into port 443 ( or the port(s) of your choice)  is made from the Discovery server.  In a multi server environment this can be made from any one of the servers configured for discovery unless you have applied zone restrictions.In other words, a TCP handshake is attempted on port 443- SYN  < SYN ACK > ACK 
• On a positive result, we then first see a reverse DNS look up, and then we see a SSLV2 client hello initiated with its' corresponding 'asks'
• A TLSV1 1514 server hello is then initiated.
• A TLSV1  1099 Certificate, Server Key exchange begins.

This last packet sequence results in the certificate being downloaded, and stored on the Director server, for analysis and import. To ensure the connection is not kept open after this interaction our last packet sent is a reset ( RST) packet. 

TPP TLS/SSL Protocol Compatibility

Once an active TLS/SSL socket has been identified, TPP will make up to four connection attempts offering different SSL/TLS protocol combinations until it successfully retrieves a certificate (or has exhausted all attempts):

1. TLS 1.0, SSL 3.0, or SSL 2.0
2. TLS 1.0, or SSL 3.0
3. TLS 1.2, TLS 1.1, or TLS 1.0
4. SSL 3.0

Note, multiple sets of protocols must be offered as Venafi has experienced that servers may reject connections if TPP offers certain (unsupported) protocols in addition to the supported protocols.

The SSL/TLS protocols and cipher suites available to TPP are governed by the Windows operating system on which it is hosted and the .NET Framework. For example, older versions of Windows and .NET do not have TLS 1.1 or TLS 1.2 enabled by default so scans would find no certificate if the target server only supported either or both of those protocols. 

Similarly, newer versions of Windows and .NET have SSL 3.0 disabled by default so scans would find no certificate if the server only supported that protocol (SSL 2.0 is also disabled by default and has been for a very long time). 

Frequently asked questions:

1: Why do we use a RST packet to close out, rather than a FIN packet? 
A RST is an abortive close that doesn't require a response from the remote side and discards the internal stack buffers right away. On a discovery, we send around a  million connection request in an hour so clearing down quickly is desirable. 

2: What is the network load of a discovery job.

This is answered in this article:  Info: Network load for Discovery

3: What happens if we supply port 80 to scan?

If port 80 is supplied in the scan request, Certificate Manger assumes there is no certificate and only attempts to collect the server identification information from the HTTP header.

4: Is there a way to throttle the network load?

Yes, this is answered in this article: Info: Configuring Discovery Module settings