Cisco Cisco Web Security Appliance S690 Guía Del Usuario
A-7
Cisco IronPort AsyncOS 7.7 for Web User Guide
Appendix A HTTPS Reference
Decrypting HTTPS Traffic
Figure A-3
HTTPS Connection
The Web Security appliance does not have access to the server’s private key, so in order to inspect the
traffic between the client and the server, it must intercept the connection and break the connection into
two separate connections. The appliance acts as an intermediary between the client and the server
pretending to be the server to the client, and the client to the server. This is sometimes referred to as
being the “man in the middle.”
traffic between the client and the server, it must intercept the connection and break the connection into
two separate connections. The appliance acts as an intermediary between the client and the server
pretending to be the server to the client, and the client to the server. This is sometimes referred to as
being the “man in the middle.”
shows an HTTPS connection between a client and a HTTPS server that goes through the Web
Security appliance.
Figure A-4
HTTPS Connection Decrypted by the Web Security Appliance
Notice that in
, there are two different HTTPS connections, one between the client and the
appliance, and one between the appliance and the server. The appliance performs the SSL handshake
twice, once with the client and again with the server:
twice, once with the client and again with the server:
•
SSL handshake with the server. When the appliance performs the SSL handshake with the server,
it acts as if it were the client sending a request to the server. After it establishes a secure connection
with the server, it can begin receiving the encrypted data. Because it acts as the client and
participates in the SSL handshake, it has agreed upon a temporary symmetric key with the server so
it can decrypt and read the data the server sends. Also, the appliance receives the server’s digital
certificate.
it acts as if it were the client sending a request to the server. After it establishes a secure connection
with the server, it can begin receiving the encrypted data. Because it acts as the client and
participates in the SSL handshake, it has agreed upon a temporary symmetric key with the server so
it can decrypt and read the data the server sends. Also, the appliance receives the server’s digital
certificate.
•
SSL handshake with the client. When the appliance performs the SSL handshake with the client,
it acts as if it were the requested server providing data the client requests. In order to perform the
SSL handshake with the client, it must send the client its own digital certificate. However, the client
expects the certificate of the requested server, so the appliance mimics the requested server’s
certificate by specifying a root certificate authority uploaded or configured by an appliance
administrator.
it acts as if it were the requested server providing data the client requests. In order to perform the
SSL handshake with the client, it must send the client its own digital certificate. However, the client
expects the certificate of the requested server, so the appliance mimics the requested server’s
certificate by specifying a root certificate authority uploaded or configured by an appliance
administrator.
For more information about how the server mimics the server’s certificate, see
Note
Because the appliance signs the server certificate with a different root certificate authority and
sends that to the client, you must verify the client applications on the network recognize the root
certificate authority. For more information, see
sends that to the client, you must verify the client applications on the network recognize the root
certificate authority. For more information, see
.
Client
Server
Client
Server
Web Security Appliance