This article describes the steps necessary to configure SBC Edge for Standard and Mutual TLS (MTLS).

In this section:

Standard TLS

Overview

Transport Layer Security (TLS) is a cryptographic protocol providing communication security over the Internet which is designed to prevent eavesdropping and tampering. In TLS, the server proves its identity to the client.

Standard TLS handshake

  1. The client sends a ClientHello message with a list of the supported cipher suites, random number, the supported TLS versions and the compression methods.
  2. The server sends a ServerHello message with the TLS version, a random number, the strongest cipher suite, and a compression method from the client's list.
  3. The server sends its own certificate.
  4. The server sends a ServerHelloDone message.
  5. The client sends a key depending on the cipher selected, and then begins computing the master secret.
  6. The client sends the ChangeCipherSpec message - authentication and encryption starts.
  7. The client sends its Finished message, which the server decrypts and verifies.
  8. The server sends a ChangeCipherSpec message, which the client decrypts and verifies.
  9. The server sends a Finished message.

The encrypted application messages then start flowing until the session ends.

Standard TLS Handshake

SBC Edge Configuration for Standard TLS

In order to configure SBC Edge for standard TLS, both Mutual Authentication and Verify Peer Server Certificate fields in the TLS Profile must be set to Disabled. For details, refer to Creating and Modifying TLS Profiles.

 

Enabling Fallback Compatibility Mode will allow reversion of the connection to an earlier, less secure, version of TLS (for example to SSLv3), thus weakening the security level. For details, refer to Creating and Modifying TLS Profiles.

Mutual TLS (MTLS)

MTLS Overview

Mutual TLS provides mutual identity authentication of the server and the client through the exchange and verification of their digital certificates.

Mutual TLS Handshake

Verify Peer Server Certificate can only be disabled if MTLS is disabled.

MTLS Illustration Notes

Step 3 - Always takes place when Mutual Authentication is enabled. If MTLS is disabled, then Verify Peer Server Certificate can be disabled.
Step 4 - This action takes place when MTLS is enabled and Validate Server FQDN is enabled. If Verify Peer Server Certificate is disabled, the Validate Server FQDN is also disabled. Validate Server FQDN is an enhanced security feature of SBC Edge, which can be disabled if the common name in the certificate is an IP address (some ITSP's do that). The Validate Server FQDN Enabled option allows SBC Edge to perform an FQDN match of an incoming peer certificate CN or SAN against the host configured in the SIP Server table of SBC Edge (protocol must be TLS and the Host FQDN).
Steps 5, 6, 7 and 8 - If MTLS is enabled, steps 5, 6, and 7 are mandatory and point 8 could be made optional but the steps 5 through 8 are performed by default. If MTLS is disabled, steps 5 through 8 will not be performed.
Step 8 - This action takes place when MTLS is enabled and Validate Client FQDN is enabled. If MTLS is disabled, the Validate Client FQDN is also disabled. Validate Client FQDN is an enhanced security feature of SBC Edge, which can be disabled if the common name in the certificate is an IP address (some ITSP's do that). The Validate Client FQDN Enabled option allows SBC Edge to perform an FQDN match of an incoming peer certificate CN or SAN against a reverse DNS lookup of the IP address to an FQDN.

SBC Edge Configuration for MTLS

In order to configureSBC Edge for MTLS, you must enable Mutual Authentication. For details, refer to Creating and Modifying TLS Profiles.

If you want to validate the client FQDN, you must enable Validate Client FQDN.

 

 

If you want to check and verify the TLS profile that was used, you must capture a debug log of the SIP subsystem at DEBUG level and search for the TLS Profile string. The example log below is when MTLS is enabled and client and server FQDN validation is disabled, for example when ITSP uses an IP address instead of a FQDN in the CN of the certificate:

Dump: TLS Client socket uses TLS Profile #1 'ITSP TLS Profile' {ver=TLS1, mutual=Yes, validate client:server FQDN=No:No, verify peer=Yes, cipher=AES128 & 3DES Sha, selfsigned=No

  • No labels