PDF(5.7 KB) View with Adobe Reader on a variety of devices
ePub(67.3 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(67.5 KB) View on Kindle device or Kindle app on multiple devices
Updated:February 9, 2017
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
#7 The proxy sends back a 407. This means that the proxy does not allow traffic due to a lack of proper authentication. If you look at the HTTP headers in this response, you will see a "Proxy-authenticate: NTLM". This tells the client that an acceptable method of authentication is NTLM. Likewise, if the header "Proxy-authenticate: Basic" is present, the proxy tells the client that basic credentials are acceptable. If both headers are present (common), the client decides which method of authentication it will use.
One thing to note is that the authentication header is "Proxy-authenticate:". This is because the connection in capture uses explicit forward proxy. If this were a transparent proxy deployment, the response code would be 401 instead of 407 and the headers would be "www-authenticate:" instead of "proxy-authenticate:".
#8 The proxy FINs this TCP socket. This is correct and normal.
#15 On a new TCP socket the client performs another GET request. This time notice that the GET contains the HTTP header "proxy-authorization:". This contains an encoded string that contains details regarding the User / Domain.
If you expand the Proxy-authorization > NTLMSSP, you will see the decoded information sent in the NTLM data. In the "NTLM Message Type", you will notice that it is "NTLMSSP_NEGOTIATE". This is the first step in the three-way NTLM handshake.
#17 The proxy responds with another 407. Another "proxy-authenticate" header is present. This time it contains an NTLM challenge string. If you expand it further, you will see the NTLM Message Type is "NTLMSSP_CHALLENGE". This is the second step in the three-way NTLM handshake.
In NTLM authentication, the Windows domain controller sends a challenge string to the client. The client then applies an algorithm to the NTLM challenge which factors in the user's password in the process. This allows the domain controller to verify that the client knows the correct password without ever sending the password across the line. This is much more secure than basic credentials, in which the password is sent in plain text for all sniffing devices to see.
#18 The client sends a final GET. Note that this GET is on the SAME TCP socket as that the NTLM Negotiate and NTLM Challenge occurred on. This is vital to the NTLM process. The entire handshake must occur on the SAME TCP socket, otherwise authentication will be invalid.
In this request the client sends the modified NTLM Challenge (NTLM Response) to the proxy. This is the final step in the three-way NTLM handshake.
#21 The proxy sends back an HTTP response. This means that the proxy accepted the credentials and has decided to serve up the content.