Analyzing SSL Inspection Appliance Deployments
License: feature-dependent
This section presents several scenarios in which the Life Insurance Example, Inc. life insurance company (LifeIns) uses SSL inspection on encrypted traffic to help audit their processes. Based on their business processes, LifeIns plans to deploy:
- one ASA FirePOWER device in a passive deployment for the Customer Service department
- one ASA FirePOWER device in an inline deployment for the Underwriting Department
Customer Service Business Processes
LifeIns created a customer-facing website for their customers. LifeIns receives encrypted questions and requests regarding policies from prospective customers through their website and through e-mail. LifeIns’s Customer Service department processes them and returns the requested information within 24 hours. Customer Service wants to expand its incoming contact metrics collection. LifeIns has an established internal audit review for Customer Service.
LifeIns also receives encrypted applications online. The Customer Service department processes the applications within 24 hours before sending the case file to the Underwriting department. Customer Service filters out any obvious false applications sent through the online form, which consumes a fair portion of their time.
Underwriting Business Processes
LifeIns’s underwriters submit encrypted medical information requests online to the Medical Repository Example, LLC medical data repository (MedRepo). MedRepo reviews the requests and transmits the encrypted records to LifeIns within 72 hours. The underwriters subsequently underwrite an application and submit policy and rate decisions. Underwriting wants to expand its metrics collection.
Lately, an unknown source has been sending spoofed responses to LifeIns. Though LifeIns’s underwriters receive training on proper Internet use, LifeIns’s IT department first wants to analyze all encrypted traffic that takes the form of medical responses, then wants to block all spoof attempts.
LifeIns places junior underwriters on six-month training periods. Lately, these underwriters have been incorrectly submitting encrypted medical regulation requests to MedRepo’s customer service department. MedRepo has submitted multiple complaints to LifeIns in response. LifeIns plans on extending their new underwriter training period to also audit underwriter requests to MedRepo.
For more information, see the following sections:
Example: Decrypting Traffic in a Passive Deployment
License: feature-dependent
LifeIns’s business requirements state that Customer Service must:
- process all requests and applications within 24 hours
- improve its incoming contact metrics collection process
- identify and discard incoming false applications
Customer Service does not require additional audit review.
LifeIns plans to passively deploy a Customer Service device.
Traffic from an external network goes to LifeIns’s router. The router routes traffic to the Customer Service department, and mirrors a copy of the traffic to the ASA FirePOWER module for inspection.
On the ASA FirePOWER module, a user in the Access Control and SSL Editor custom role configures SSL inspection to:
- log all encrypted traffic sent to the Customer Service department
- decrypt encrypted traffic sent using the online application form to Customer Service
- not decrypt all other encrypted traffic sent to Customer service, including traffic sent using the online request form
The user also configures access control to inspect the decrypted application form traffic for fake application data and log when fake data is detected.
In the following scenarios, the user submits an online form to Customer Service. The user’s browser establishes a TCP connection with the server, then initiates an SSL handshake. The ASA FirePOWER module receives a copy of this traffic. The client and server complete the SSL handshake, establishing the encrypted session. Based on handshake and connection details, the system logs the connection and acts upon the copy of the encrypted traffic.
For more information, see the following:
Monitoring Encrypted Traffic in a Passive Deployment
License: Any
For all SSL-encrypted traffic sent to Customer Service, the system logs the connection.
The following steps occur:
1. The user submits the plain text request ( info
). The client encrypts this ( AaBb
) and sends the encrypted traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the ASA FirePOWER module.
3. The Customer Service department server receives the encrypted information request ( AaBb
) and decrypts it to plain text ( info
).
4. The module does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it. The module generates a connection event after the session ends.
5. The ASA FirePOWER module receives the connection event.
Not Decrypting Encrypted Traffic in a Passive Deployment
License: Any
For all SSL-encrypted traffic that contains requests about policies, the system allows the traffic without decrypting it and logs the connection.
The following steps occur:
1. The user submits the plain text request ( info
). The client encrypts this ( AaBb
) and sends the encrypted traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the ASA FirePOWER module.
3. The Customer Service department server receives the encrypted information request ( AaBb
) and decrypts it to plain text ( info
).
4. The ASA FirePOWER module does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it. The module generates a connection event after the session ends.
5. The ASA FirePOWER module receives the connection event.
Inspecting Encrypted Traffic with a Private Key in a Passive Deployment
License: Any
For all SSL-encrypted traffic that contains application form data, the system decrypts the traffic and logs the connection.
Note In a passive deployment, if traffic is encrypted with either the DHE or ECDHE cipher suite, you cannot decrypt it with a known private key.
For traffic with legitimate application form information, the system logs the connection.
The following steps occur:
1. The user submits the plain text request ( form
). The client encrypts this ( AaBb
) and sends the encrypted traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the ASA FirePOWER module.
3. The Customer Service department server receives the encrypted information request ( AaBb
) and decrypts it to plain text ( form
).
4. The ASA FirePOWER module uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text ( form
).
The access control policy continues to process the decrypted traffic and does not find fake application information. The module generates a connection event after the session ends.
5. The ASA FirePOWER module receives a connection event with information about the encrypted and decrypted traffic.
In contrast, if the decrypted traffic contains fake application data, the system logs the connection and the fake data.
The following steps occur:
1. The user submits the plain text request ( fake
). The client encrypts this ( CcDd
) and sends the encrypted traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the device.
3. The Customer Service department server receives the encrypted information request ( CcDd
) and decrypts it to plain text ( fake
).
4. The ASA FirePOWER module uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text ( fake
).
The access control policy continues to process the decrypted traffic and finds fake application information. The module generates an intrusion event. After the session ends, it generates a connection event.
5. The ASA FirePOWER module receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the fake application data.
Example: Decrypting Traffic in an Inline Deployment
License: feature-dependent
LifeIns’s business requirements state that Underwriting must:
- audit new and junior underwriters, verifying that their information requests to MedRepo comply with all applicable regulations
- improve its underwriting metrics collection process
- examine all requests that appear to come from MedRepo, then drop any spoofing attempts
- drop all improper regulatory requests to MedRepo’s Customer Service department from the Underwriting department
- not audit senior underwriters
LifeIns plans to deploy a device in an inline deployment for the Underwriting department.
Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the ASA FirePOWER module. LifeIns’s router routes traffic to the destination host.
On the ASA FirePOWER module, a user configures SSL inspection to:
- log all encrypted traffic sent to the Underwriting department
- block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer service department
- decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s junior underwriters to MedRepo’s requests department
- not decrypt encrypted traffic sent from the senior underwriters
The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:
- block decrypted traffic if it contains a spoof attempt, and log the spoof attempt
- block decrypted traffic that contains information not compliant with regulations, and log the improper information
- allow all other encrypted and decrypted traffic
The system reencrypts allowed decrypted traffic before sending it to the destination host.
In the following scenarios, the user submits information online to a remote server. The user’s browser establishes a TCP connection with the server, then initiates an SSL handshake. The module receives this traffic; based on handshake and connection details, the system logs the connection and acts on the traffic. If the system blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL handshake, establishing the encrypted session.
For more information, see the following:
Monitoring Encrypted Traffic in an Inline Deployment
License: Any
For all SSL-encrypted traffic sent to and from the Underwriting department, the system logs the connection.
The following steps occur:
1. The user submits the plain text request ( help
). The client encrypts this ( AaBb
) and sends the encrypted traffic to MedRepo’s Requests department server.
2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.
3. The ASA FirePOWER module does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Underwriting department server receives the encrypted information request ( AaBb
) and decrypts it to plain text ( help
).
6. The ASA FirePOWER module receives the connection event.
Allowing Specific Users’ Encrypted Traffic in an Inline Deployment
License: Control
For all SSL-encrypted traffic originating from the senior underwriters, the system allows the traffic without decrypting it and logs the connection.
The following steps occur:
1. The user submits the plain text request ( help
). The client encrypts this ( AaBb
) and sends the encrypted traffic to MedRepo’s Requests department server.
2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.
3. The ASA FirePOWER module does not decrypt this traffic.
The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Requests department server receives the encrypted information request ( AaBb
) and decrypts it to plain text ( help
).
6. The ASA FirePOWER module receives the connection event.
Blocking Encrypted Traffic in an Inline Deployment
License: Any
For all SMTPS email traffic improperly sent from LifeIns’s underwriting department to MedRepo’s Customer Service department, the system blocks the traffic during the SSL handshake without further inspection and logs the connection.
The following steps occur:
1. Having received the request to establish an SSL handshake from a client’s browser, the Customer Service department server sends the server certificate ( cert
) as the next step in the SSL handshake to the LifeIns underwriter.
2. MedRepo’s router receives the certificate and routes it to the LifeIns underwriter.
3. The ASA FirePOWER module blocks the traffic without further inspection and ends the TCP connection. It generates a connection event.
4. The internal router does not receive the blocked traffic.
5. The underwriter does not receive the blocked traffic.
6. The ASA FirePOWER module receives the connection event.
Inspecting Encrypted Traffic with a Private Key in an Inline Deployment
License: Any
For all SSL-encrypted traffic sent from MedRepo to LifeIns’s underwriting department, the system uses an uploaded server private key to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to the Underwriting department.
The following steps occur:
1. The user submits the plain text request ( stats
). The client encrypts this ( AaBbC
) and sends the encrypted traffic to the Underwriting department server.
2. The external router receives the traffic and routes it to the Underwriting department server.
3. The ASA FirePOWER module uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text ( stats
).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find a spoof attempt. The device passes the encrypted traffic ( AaBbC
), then generates a connection event after the session ends.
4. The internal router receives the traffic and routes it to the Underwriting department server.
5. The Underwriting department server receives the encrypted information ( AaBbC
) and decrypts it to plain text ( stats
).
6. The ASA FirePOWER module receives the connection event with information about the encrypted and decrypted traffic.
In contrast, any decrypted traffic that is a spoof attempt is dropped. The system logs the connection and the spoof attempt.
The following steps occur:
1. The user submits the plain text request ( spoof
), altering the traffic to appear to originate from MedRepo, LLC. The client encrypts this ( FfGgH
) and sends the encrypted traffic to the Underwriting department server.
2. The ASA FirePOWER module uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text ( spoof
).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds a spoof attempt. The ASA FirePOWER module blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.
3. The internal router does not receive the blocked traffic.
4. The Underwriting department server does not receive the blocked traffic.
5. The ASA FirePOWER module receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the spoofing attempt.
Inspecting Specific Users’ Encrypted Traffic with a Re-signed Certificate in an Inline Deployment
License: Control
For all SSL-encrypted traffic sent from the new and junior underwriters to MedRepo’s requests department, the system uses a re-signed server certificate to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to MedRepo.
Note When decrypting traffic in an inline deployment by re-signing the server certificate, the ASA FirePOWER module acts as a man-in-the-middle. It creates two SSL sessions, one between client and ASA FirePOWER module, one between ASA FirePOWER module and server. As a result, each session contains different cryptographic session details.
The following steps occur:
1. The user submits the plain text request ( help
). The client encrypts this ( AaBb
) and sends the encrypted traffic to the Requests department server.
2. The internal router receives the traffic and routes it to the Requests department server.
3. The ASA FirePOWER module uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text ( help
).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find an improper request. The module reencrypts the traffic ( CcDd
), allowing it to pass. It generates a connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Requests department server receives the encrypted information ( CcDd
) and decrypts it to plain text ( help
).
6. The ASA FirePOWER module receives the connection event with information about the encrypted and decrypted traffic.
Note Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is not trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store or the client trusted certificates store.
In contrast, any decrypted traffic that contains information that does not meet regulatory requirements is dropped. The system logs the connection and the non-conforming information.
The following steps occur:
1. The user submits the plain text request ( regs
), which does not comply with regulatory requirements. The client encrypts this ( EeFf
) and sends the encrypted traffic to the Requests department server.
2. The internal router receives the traffic and routes it to the Requests department server.
3. The ASA FirePOWER module uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text ( regs
).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds an improper request. The module blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.
4. The external router does not receive the blocked traffic.
5. The Requests department server does not receive the blocked traffic.
6. The ASA FirePOWER module receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the improper request.