SSL Orchestrator Advanced Use Cases: Client Certificate Constrained Delegation (C3D) Support

[Kevin_Stewart]

Introduction

F5 BIG-IP is synonymous with "flexibility". You likely have few other devices in your architecture that provide the breadth of capabilities that come native with the BIG-IP platform. And for each and every BIG-IP product module, the opportunities to expand functionality are almost limitless. In this article series we examine the flexibility options of the F5 SSL Orchestrator in a set of "advanced" use cases.

If you haven't noticed, the world has been steadily moving toward encrypted communications. Everything from web, email, voice, video, chat, and IoT is now wrapped in TLS, and that's a good thing. The problem is, malware - that thing that creates havoc in your organization, that exfiltrates personnel records to the Dark Web - isn't stopped by encryption. TLS 1.3 and multi-factor authentication don't eradicate malware. The only reasonable way to defend against it is to catch it in the act, and an entire industry of security products are designed for just this task. But ironically, encryption makes this hard. You can't protect against what you can't see. F5 SSL Orchestrator simplifies traffic decryption and malware inspection, and dynamically orchestrates traffic to your security stack. But it does much more than that. SSL Orchestrator is built on top of F5's BIG-IP platform, and as stated earlier, is abound with flexibility.

SSL Orchestrator Use Case: Client Certificate Constrained Delegation (C3D)

Using certificates to authenticate is one of the oldest and most reliable forms of authentication. While not every application supports modern federated access or multi-factor schemes, you'll be hard-pressed to find something that doesn't minimally support authentication over TLS with certificates. And coupled with hardware tokens like smart cards, certificates can enable one of the most secure multi-factor methods available. But certificate-based authentication has always presented a unique challenge to security architectures. Certificate "mutual TLS" authentication requires an end-to-end TLS handshake. When a server indicates a requirement for the client to submit its certificate, the client must send both its certificate, and a digitally-signed hash value. This hash value is signed (i.e. encrypted) with the client's private key. Should a device between the client and server attempt to decrypt and re-encrypt, it would be unable to satisfy the server's authentication request by virtue of not having access to the client's private key (to create the signed hash). This makes encrypted malware inspection complicated, often requiring a total bypass of inspection to sites that require mutual TLS authentication.

Fortunately, F5 has an elegant solution to this challenge in the form of Client Certificate Constrained Delegation, affectionally referred to as "C3D". The concept is reasonably straightforward. In very much the same way that SSL forward proxy re-issues a remote server certificate to local clients, C3D can re-issue a remote client certificate to local servers. A local server can continue to enforce secure mutual TLS authentication, while allowing the BIG-IP to explicitly decrypt and re-encrypt in the middle. This presents an immediate advantage in basic load balancing, where access to the unencrypted data allows the BIG-IP greater control over persistence. In the absence of this, persistence would typically be limited to IP address affinity. But of course, access to the unencrypted data also allows the content to be scanned for malicious malware. C3D actually takes this concept of certificate re-signing to a higher level though. The "constrained delegation" portion of the name implies a characteristic much like Kerberos constrained delegation, where (arbitrary) attributes can be inserted into the re-signed token, like the PAC attributes in a Kerberos ticket, to inform the server about the client. Servers for their part can then simply filter on client certificates issued by the BIG-IP (to prevent direct access), and consume any additional attributes in the certificate to understand how better to handle the client. 

With C3D you can maintain strong mutual TLS authentication all the way through to your servers, while allowing the BIG-IP to more effectively manage availability. And combined with SSL Orchestrator, C3D can enable decryption and inspection of content for malware inspection. This article describes how to configure SSL Orchestrator to enable C3D for inbound decrypted inspection. Arguably, most of what follows is the C3D configuration itself, as the integration with SSL Orchestrator is pretty simple.

Note that Client Certificate Constrained Delegation (C3D) is included with Local Traffic Manager (LTM) 13.0 and beyond, but for integration with SSL Orchestrator you should be running 14.1 or later.To learn more about C3D, please see the following resources:

• K14065425: Configuring Client Certificate Constrained Delegation (C3D): https://support.f5.com/csp/article/K14065425
• Manual Chapter: SSL Traffic Management: https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-system-ssl-administration/ssl-traffic-management.h...
• SSL::c3d iRule reference - not required to use C3D, but adds powerful functionality https://clouddocs.f5.com/api/irules/SSL__c3d.html

The integration of C3D with SSL Orchestrator involves effectively replacing the client and server SSL profiles that the SSL Orchestrator topology creates, with C3D SSL profiles. This is done programmatically with an iRule, so no "non-strict" customization is required at the topology. Also note that an inbound (reverse proxy) SSL Orchestrator topology will take the form of a "gateway mode" deployment (a routed path to multiple applications), or "application mode" deployment (a single application instance hosted at the BIG-IP). See section 2.5 of the SSL Orchestrator deployment guide for a deeper examination of gateway and application modes: https://clouddocs.f5.com/sslo-deployment-guide/

The C3D integration is only applicable to application mode deployments.

Configuration

C3D itself involves the creation of client and server SSL profiles:

Create a new Client SSL profile:

• Configuration
  • Certificate Key Chain: public-facing server certificate and private key. This will be the certificate and key presented to the client on inbound request. It will likely be the same certificate and key defined in the SSL Orchestrator inbound topology.
• Client Authentication
  • Client Certificate: require
  • Trusted Certificate Authorities: bundle that can validate client certificate. This is a certificate bundle used to verify the client's certificate, and will contain all of the client certificate issuer CAs.
  • Advertised Certificate Authorities: optional CA hints bundle. Not expressly required, but this certificate bundle is forwarded to the client during the TLS handshake to "hint" at the correct certificate, based on issuer.

• Client Certificate Constrained Delegation
  • Client Certificate Constrained Delegation: Enabled
  • Client Fallback Certificate (new in 15.1): option to select a default client certificate if client does not send one. This option was introduced in 15.1 and provides the means to select an alternate (local) certificate if the client does not present one. The primary use case here might be to select a "template" certificate, and use an iRule function to insert arbitrary attributes.
  • OCSP: optional client certificate revocation control. This option defines an OCSP revocation provider for the client certificate.
  • Unknown OCSP Response Control (new in 15.1): determines what happens when OCSP returns Unknown. If an OCSP revocation provider is selected, this option defines what to do if the response to the OCSP query is "unknown".

Create a new Server SSL profile:

• Configuration
  • Certificate: default.crt. The certificate and key here are used as "templates" for the re-signed client certificate.
  • Key: default.key

• Client Certificate Configuration Delegation
  • Client Certificate Constrained Delegation: Enabled
  • CA Certificate: local forging CA cert. This is the CA certificate used to re-sign the client certificate. This CA must be trusted by the local servers.
  • CA Key: local forging CA key
  • CA Passphrase: optional CA passphrase
  • Certificate Extensions: extensions from the real client cert to be included in the forged cert. This is the list of certificate extensions to be copied from the original certificate to the re-issued certificate.
  • Custom Extension: additional extensions to copy to forged cert from real cert (OID). This option allows you to insert additional extensions to be copied, as OID values.

• Additional considerations: Under normal conditions, the F5 and backend server attempt to resume existing SSL sessions, whereby the server doesn’t send a Certificate Request message. The effect is that all connections to the backend server use the same forged client cert. There are two ways to get around this:
  • Set a zero-length cache value in the server SSL profile, or
  • Set server authentication frequency to ‘always’ in the server SSL profile

With the client and server SSL profiles built, the C3D configuration is basically done. To integrate with an inbound SSL Orchestrator topology, create a simple iRule and add it to the topology's Interception Rule configuration. Modify the SSL profile paths below to reflect the profiles you created earlier.

### Modify the SSL profile paths below to match real C3D SSL profiles 
when CLIENT_ACCEPTED priority 250 { 
  ## set clientssl 
  set cmd1 "SSL::profile /Common/c3d-clientssl" ; eval $cmd1 
}
when SERVER_CONNECTED priority 250 { 
  ## set serverssl 
  SSL::profile "/Common/c3d-serverssl" 
}

In the SSL Orchestrator UI, either from topology workflow, or directly from the corresponding Interception Rule configuration, add the above iRule and deploy. The above iRule programmatically overrides the SSL profiles applied to the Interception Rule (virtual server), effectively enabling C3D support. At this point, the virtual server will request a client certificate, perform revocation checks if defined, and then mint a local copy of the client certificate to pass to the backend server. Optionally, you can insert additional certificate attributes via the server SSL profile configuration, or more dynamically through additional iRule logic:

### Added in 15.1 - allows you to send a forged cert to the server 
### irrespective of the client side authentication (ex. APM SSO), 
### and insert arbitrary values 
when SERVERSSL_SERVERCERT { 
  ### The following options allow you to override/replace a submitted 
  ### client cert. For example, a minted client certificate can be sent 
  ### to the server irrespective of the client side authentication method. 
  ### This certificate "template" could be defined locally in the iRule 
  ### (Base64-encoded), pulled from an iFile, or some other certificate source.      
  
  # set cert1 [b64decode "LS0tLS1a67f7e226f..."] 
  # set cert1 [ifile get template-cert] 

  ### In order to use a template cert, it must first be converted to DER format 
  # SSL::c3d cert [X509::pem2der $cert1] 

  ### Insert arbitrary attributes (OID:value) 
  SSL::c3d extension 1.3.6.1.4.1.3375.3.1 "TEST" 
}   

If you've configured the above, a server behind SSL Orchestrator that requires mutual TLS authentication can receive minted client certificates from external users, and SSL Orchestrator can explicitly decrypt and pass traffic to the set of malware inspection tools. You can look at the certificate sent to the server by injecting a tcpdump packet between the BIG-IP and server, then open in Wireshark.

tcpdump -lnni [VLAN] -Xs0 -w capture.pcap [additional filters]

Finally, you might be asking what to do with certificate attributes injected by C3D, and really it depends on what the server can support. The below is a basic example in an Apache config file to block a client certificate that doesn't contain your defined attribute.

<Directory />
   SSLRequire "HTTP/%h" in PeerExtList("1.3.6.1.4.1.3375.3.1")
   RewriteEngine on RewriteCond %{SSL::SSL_CLIENT_VERIFY} !=SUCCESS
   RewriteRule .? - [F]
   ErrorDocument 403 "Delegation to SPN HTTP/%h failed. Please pass a valid client certificate"
</Directory>

And there you have it. In just a few steps you've configured your SSL Orchestrator to integrate with Client Certificate Constrained Delegation to support mutual TLS authentication, and along the way you have hopefully recognized the immense flexibility at your command.

Updates

As of F5 BIG-IP 16.1.3, there are some new C3D capabilities:

• C3D has been updated to encode and return the commonName (CN) found in the client certificate subject field in printableString format if possible, otherwise the value will be encoded as UTF8.
• C3D has been updated to support inserting a subject commonName (CN) via 'SSL::c3d subject commonName' command:

when CLIENTSSL_HANDSHAKE {
      if {[SSL::cert count] > 0} {
            SSL::c3d subject commonName [X509::subject [SSL::cert 0] commonName]
      }
}

• C3D has been updated to support inserting a Subject Alternative Name (SAN) via 'SSL::c3d extention SAN' command:

when CLIENTSSL_HANDSHAKE {
     SSL::c3d extension SAN "DNS:*.test-client.com, IP:1.1.1.1"
}

• C3D has been updated to add the Authority Key Identifier (AKI) extension to the client certificate if the CA certificate has a Subject Key Identifier (SKI) extension.

[Kevin_Stewart]

SSL Orchestrator Advanced Use Cases: Client Certificate Constrained Delegation (C3D) Support

[Nikoolayy1]

Great article! Thanks.