Cisco Cisco Web Security Appliance S690 Guía Del Usuario
A-8
Cisco IronPort AsyncOS 7.7 for Web User Guide
Appendix A HTTPS Reference
Decrypting HTTPS Traffic
After the two separate HTTPS connections are established, the following actions occur:
1.
Encrypted data is received from the server.
2.
The temporary, symmetric key negotiated with the server is used to decrypt the data.
3.
Access Policies are applied to the decrypted traffic as if it were a plaintext HTTP connection. For
more information about Access Policies, see
more information about Access Policies, see
4.
Assuming the Access Policy group allows the client to receive the data, the data is encrypted using
the temporary, symmetric key negotiated with the client.
the temporary, symmetric key negotiated with the client.
5.
Encrypted data is sent to the client.
Note
No decrypted data is cached. However, access logs for decrypted HTTP transactions are saved to disk.
Mimicking the Server Digital Certificate
When the appliance performs the SSL handshake with the client, it mimics the server digital certificate
and sends the new certificate to the client. To mimic the server digital certificate, it reuses most field
values and changes some field values.
and sends the new certificate to the client. To mimic the server digital certificate, it reuses most field
values and changes some field values.
The mimicked certificate is the same as the server certificate except for the following fields:
•
Issuer. The issuer comes from the generated or uploaded root certificate configured in the appliance.
•
Signature Algorithm. This field is always “sha1WithRSAEncryption” or “dsaWithSHA1”
depending upon on whether the root certificate the appliance uses contains an RSA or DSA key.
depending upon on whether the root certificate the appliance uses contains an RSA or DSA key.
•
Public Key. The appliance replaces the public key in the original certificate with a public key it
generates that matches bit strength from the original certificate and for which it has a matching
private key generated as well. For example, if the server certificate uses a 2048 bit RSA key, the
appliance generates a new 2048 bit RSA key.
generates that matches bit strength from the original certificate and for which it has a matching
private key generated as well. For example, if the server certificate uses a 2048 bit RSA key, the
appliance generates a new 2048 bit RSA key.
•
X509v3 Extensions. All X509v3 extensions are removed except for the following:
–
Basic Constraints
–
Subject Alternative Name
–
Key Usage
–
Subject Key Identifier
–
Extended Key Usage
For example, the appliance removes the Authority Key Identifier and the Authority Information
Access X509v3 extensions.
Access X509v3 extensions.
Working with Root Certificates
The Web Security appliance mimics the HTTPS server to which a client originally sent a connection
request. In order to establish a secure connection with the client pretending to be the requested server,
the appliance must send a server certificate to the client signed by a root certificate authority configured
in the appliance.
request. In order to establish a secure connection with the client pretending to be the requested server,
the appliance must send a server certificate to the client signed by a root certificate authority configured
in the appliance.
When you enable the HTTPS Proxy on the appliance, you can configure the root certificate information
that the appliance uses to sign its server certificates.
that the appliance uses to sign its server certificates.