Chapter 15: SSL Inspection

Home Prev	cOS Stream 4.00.02 Administration Guide	Next

The feature SSL Inspection allows cOS Stream to apply its range of security features, for example IPS, to flows which are encrypted using SSL/TLS. This is done by the firewall detecting the opening of an SSL/TLS flow on an interface and sending the initiating client the SSL certificate instead of the final destination sending it. The firewall can then decrypt the traffic and process it as plain text before forwarding it on to the original destination in either plain text or re-encrypted form.

The typical scenario which this Clavister NetShield Firewall feature is intended for is illustrated in the diagram below. Here, a remote client is opening an SSL/TLS flow across the public Internet to a server. The firewall mediates the communication so it appears to be the server from the client's perspective and appears to be the client from the server's perspective. Neither the client or the server are aware that the firewall is applying additional security checks to the traffic that flows between them.

Figure 15.1. SSL Inspection

A key requirement for setting up SSL inspection is having the certificates used by the destination server available for upload to the firewall. There is no requirement for anything extra to be installed on the connecting client.

A Summary of SSL Inspection Setup

Setting up SSL inspection with cOS Stream involves the following steps:

Upload the server certificate files to cOS Stream using SCP. This consists of the SSL certificate (with its private key) and any certificate chain file if the SSL certificate was signed by an intermediate CA. The public key of the SSL certificate will be sent to clients along with any intermediate chain. The chain allows a client to validate an SSL certificate not signed directly by a CA.
Create Certificate objects in cOS Stream for the uploaded certificate files.

The Certificate objects must be added as children of a CertificateStore object. The default store called ipsec could be used for this purpose but it is often better to create a new store and give it a name such as sslins. Any reference to a Certificate object must be qualified by the name of the store in which it is found. For example, sslins/my_ca_cert.
Create an SSLInspectionProfile object. This has properties to set parameters such as the minimum SSL version.
Add one or more child SSLServer objects to the SSLInspectionProfile parent. More than one SSLServer will be defined if name-based virtual hosting is being used where a single server (usually a web server) is hosting multiple DNS hostnames on the same IP address. The ServerNameIndication property of the SSLServer objects is used to decide which is used. The default SSLServer object is always the first in the list so the ordering is important.

The relevant Certificate objects for the SSL certificate and the certificate chain must also be associated with each SSLServer object. These are the same certificates that would be used by the destination server. The SSL certificate should have a SubjectAltName field that contains the relevant domain name.
Associate the SSLInspectionProfile with an IPRule object which triggers on the traffic to be inspected as it passes through the firewall. The rule might use address translation like SAT or it might be a simple Allow rule with no translation.
Create another rule that will perform some action on the unencrypted traffic. For example, an IPSRule. This rule must trigger on the same filtering criteria as the IPRule above. There is no explicit association between this second rule and the IPRule other that they trigger on the same traffic.

The filtering criteria of say, an IPSRule, does not have to be identical with the criteria of the IPRule. The IPSRule could have a wider filter. However, a narrower filter should not be used since it might not then process all the unencrypted SSL traffic.

Note the IPSRule acts independently of the IPRule and will process any traffic that triggers it, including any plain text traffic.

SSLInspectionProfile Properties

The SSLInspectionProfile object is the basic building block for configuring SSL inspection. It is associated with an IPRule object to configure SSL inspection. The same SSLInspectionProfile object can be associated with multiple IPRule objects for different concurrent traffic flows.

The key properties for the SSLInspectionProfile object are the following:

Name

This is mandatory and is a logical name used when referring to the profile in an IPRule.
AllowedCipherSuites

This is optional and usually does need to be changed from the default. The default suites are listed under the SSLInspectionProfile entry of the separate CLI Reference Guide.
MinTLSVersion

This is optional and the default value is TLSv1.2.
ServerConnection

This is optional and specifies if the traffic between the firewall and the server should be encrypted or should be plain-text. The default value is SSL/TLS meaning that encryption should be used.
ServerCertMatching

This is optional and if enabled (the default) it enforces the requirement that the SSL certificate that is set in the triggering SSLServer object is an exact copy of the SSL certificate used by the server. This is a check to make sure the correct server has been selected.
DetectOpportunisticTLS

When this property is disabled (the default), a plain text flow that changes to an encrypted TLS flow on the same port number by using STARTTLS will not then be subject to SSL inspection. In other words, cOS Stream will not try to detect STARTTLS.

When enabled, cOS Stream scans plain text flows looking for STARTTLS and if it is detected anywhere in a flow, SSL inspection will then be used to perform decryption and any associated security scanning.

Having this option enabled can improve security with the trade-off that there is a slight increase in processing load on the system. If the server does not support STARTTLS then this property should be left as disabled.

SSLServer Properties

One or more SSLServer objects should be added as children to an SSLInspectionProfile object. As stated previously, multiple instances would be needed if name-based virtual hosting is being used, where a single server (usually a web server) is hosting multiple DNS hostnames on the same IP address. A single destination server would require just one SSLServer object.

The key properties for the SSLServer object are the following:

Name

A logical name for the server. This is optional and is only used when cOS Stream displays server information.
ServerNameIndication

This is mandatory and is used to match the SNI string sent by the SSL client. It can contain one or more asterisk "*" wildcards. For example, *.example.com. If the value is set to a single asterisk on its own then it will match any SNI sent by the client. Scanning the list always stops after a match is found so list ordering can be important.

If there is no SNI match, the first SSLServer object in the list is used as the default and this is also used as a default if the client does not send an SNI.
Certificate

This is mandatory and is the Certificate object corresponding to the host SSL certificate files (public and private key files).
IntermediateCerts

This is the Certificate object corresponding to any certificate chain file provided by an intermediate CA. If there is no chain then no value would be specified for this property.

The SSL Inspection Processing Sequence

The following sequence occurs during SSL inspection processing:

A new flow arrives on an Ethernet port which triggers the IPRule targeting SSL traffic.
If the flow is not SSL but the rule triggers anyway (perhaps because the Service of the IPRule includes other protocols) then the traffic is processed by the rule as normal but without SSL inspection being involved.
If the traffic is an SSL flow that triggers the IPRule and its TLS/SSL version is allowed by the rule's SSLInspectionProfile then all the profile's SSLServer children are scanned for a match.
Selecting an SSLServer object is done using the Server Name Indication (SNI) value sent by the SSL client (most web browsers support this feature). The SNI is sent by the client during the initial SSL handshake and indicates which server the client is trying to connect to (for example, "server.example.org"). It is compared against the ServerNameIndication property of each SSLServer in the list and scanning stops after the first match is found.
If no match is found, or if the SSL client did not send an SNI value, the first SSLServer object in the list is always used as the default server.
The SSL certificate (and any chain) associated with the matched SSLServer object selected are then sent to the client exactly as the server would have done.
As traffic flows, cOS Stream decrypts it and applies any other triggering rule to the resulting plain text data (for example, an IPSRule).
If the unencrypted flow is not dropped by another rule, it is forwarded to the destination server, with the firewall now pretending to be the client.

Note that the forwarding is done using plain text or re-encrypted into SSL depending on the value of the ServerConnection property of the SSLInspectionProfile object. By default, it is re-encrypted.
The destination server now processes the traffic that has come from the client, unaware that it has been forwarded by the firewall.
The server sends its reply back to the firewall and if it is encrypted it is unencrypted by the cOS Stream and subject to the same processing as the original client traffic.
If the returning traffic is not dropped by any security checks, it is re-encrypted by the cOS Stream and returned to the client as though it had come directly from the server.
The client receives the encrypted reply from the server and is not aware that the firewall has mediated the communication.

Example 15.1. Setting Up SSL Inspection

This example shows how to set up SSL inspection for clients sending HTTP and HTTPS traffic across the Internet to a web server located behind a Clavister NetShield Firewall on a DMZ. The following assumptions will be made:

The firewall's Ethernet interface if2 is connected to the Internet and has the public IPv4 address wan_ip.
The protected server is located on the network if3_net which is connected to the firewall's if3 Ethernet interface.
The server has the private IPv4 address my_server_ip and the URL www.example.com.
The server has SSL certificate files as well as a certificate chain file which are available for upload to the firewall.
HTTP and HTTPS flows to the server will be subject to a SAT rule which will translate the destination IP address from if2_ip to my_server_ip.
HTTPS flows between the firewall and the server will also be encrypted using SSL and returning traffic from the server will therefore also be subject to SSL inspection and be examined for threats using IPS. HTTP flows will also be subject to IPS processing but they will automatically bypass SSL inspection.
Following SSL inspection, traffic will be re-encrypted into SSL before forwarding to the server.

Command-Line Interface

1. Upload the server's SSL certificate files to the firewall using SCP

2. Create Certificate objects for the uploaded files:

Create a CertificateStore for SSL inspection:

System:/> add CertificateStore sslins

Add the Certificate objects as children of the store:

System:/> cc CertificateStore sslins
System:/CertificateStore/sslins> add Certificate my_ssl_cert
			Type=Local
			CertificateData=file://my_ssl_cert.cer
			PrivateKey=file://my_ssl_cert.key

System:/CertificateStore/sslins> add Certificate my_ssl_chain_cert
			Type=Remote
			CertificateData=file://my_ssl_chain.cer

System:/CertificateStore/sslins> cc
System:/>

3. Create an SSLInspectionProfile object:

System:/> add SSLInspectionProfile my_ssl_prof
			ServerConnection=SSL/TLS

4. Create an SSLServer object as a child for the server:

System:/> cc SSLInpectionProfile my_ssl_prof
System:/SSLInspectionProfile/my_ssl_prof> add SSLServer
			ServerNameIndication=www.example.com
			Certificate=sslins/my_ssl_cert
			IntermediateCerts=sslins/my_ssl_cert_chain
			Name=example_server
System:/SSLInpsectionProfile/my_ssl_prof> cc
System:/>

5. Create a custom service for HTTP/HTTPS traffic:

System:/> add Service ServiceTCPUDP http-all DestinationPorts=80,443

6. Create a 1:1 SAT rule for flows from the Internet to the server:

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule
			SourceInterface=if2
			SourceNetwork=all-nets-ip4
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Action=Allow
			DestinationTranslation=SAT
			SetDestinationAddress=Offset
			NewDestinationIP4=my_server_ip
			SSLInspectionProfile=my_ssl_prof
			Name=http_wan_to_server
System:/IPRuleSet/main> cc
System:/>

7: Create an IPS signature group to apply to the decrypted SSL traffic:

System:/> cc IntrusionPrevention 
System:/IntrusionPrevention> add IPSSignatureGroup my_ssl_group
			IncludeCategory=IPS_WEB_*

8. Create an IPS rule that triggers on the same SSL traffic:

System:/IntrusionPrevention> add IPSRule
			SourceInterface=if2
			SourceNetwork=all-nets-ip4
			DestinationInterface=core
			DestinationNetwork=wan_ip
			Service=http-all
			Name=ssl_ips

9. Add the signature group to the IPS rule:

System:/IntrusionPrevention> cc IPSRule 1(srv_rule) 
System:/IntrusionPrevention/IPSRule/1(ssl_ips)> add IPSRuleAction
			Action=Protect
			SignatureGroup=my_ssl_group