Understanding TLS in SIP

Introduction

Session Initiation Protocol (SIP) is the backbone of modern Voice over IP (VoIP) communications. While SIP itself doesn't encrypt voice data, securing the signaling layer with TLS is critical for preventing eavesdropping, man-in-the-middle attacks, and call hijacking. This guide covers how TLS works in SIP environments, common pitfalls, and practical troubleshooting techniques.

SIP Security Fundamentals

SIP communication involves two distinct channels that require separate security considerations:

Signaling plane handles call setup, teardown, and session management. This is where SIP messages like INVITE, BYE, and REGISTER flow. TLS protects this layer.

Media plane carries the actual audio/video streams using RTP (Real-time Transport Protocol). SRTP (Secure RTP) protects this layer, typically with keys exchanged during SIP signaling.

This guide focuses on the signaling plane and TLS.

SIP vs SIPS: Two Approaches to TLS

SIP supports both unencrypted and TLS-encrypted connections; the URI scheme and port indicate which is in use.

Standard SIP (Port 5060)

Unencrypted SIP typically runs on UDP or TCP port 5060. The sip: URI scheme indicates an unencrypted connection:

<sip:alice@example.com>

SIPS - SIP Secure (Port 5061)

SIPS uses TLS on TCP port 5061 by default. The sips: URI scheme mandates TLS:

sips:alice@example.com

When a client sees a sips: URI, it must establish a TLS connection before sending any SIP messages. Unlike SMTP's STARTTLS upgrade mechanism, SIPS uses direct TLS - the connection is encrypted from the first byte.

The Transport Parameter (More Common)

In practice, most implementations use the sip: scheme with a transport=tls parameter rather than sips::

sip:alice@example.com;transport=tls

The key difference: sips: mandates TLS for the entire path (end-to-end), while sip:;transport=tls only enforces TLS for the next hop. Since end-to-end TLS enforcement is difficult to guarantee across federated SIP networks, the transport parameter approach has become the de facto standard.

How TLS Handshake Works in SIP

When a SIP client connects to a SIPS server, the standard TLS handshake occurs:

Server Name Indication (SNI)

SNI is a TLS extension that allows the client to indicate which hostname it's connecting to during the handshake. This is critical in SIP environments where multiple domains may share the same IP address.

The SIP client sends the target hostname in the ClientHello message, allowing the server to present the correct certificate. Without SNI, servers hosting multiple SIP domains would need separate IP addresses for each.

Certificate Validation in SIP

Proper certificate validation is essential for SIP security. The client must verify:

Certificate chain validity. The server certificate must chain to a trusted root CA. Self-signed certificates break this validation unless explicitly trusted.

Hostname matching. The certificate's Subject Common Name (CN) or Subject Alternative Names (SANs) must match the SIP domain. Wildcard certificates (e.g., *.[sip.example.com](http://sip.example.com)) are common in SIP deployments.

⚠️ Real-world caveat: Many SIP providers (including Twilio) do not issue certificates that match their SIP domains. Instead, they require clients to validate the certificate chain (trusted CA) but skip hostname/CN verification. This provides encryption and CA trust but weakens protection against certain man-in-the-middle attacks. Some SIP endpoints like LiveKit presents correctly signed certificates that pass full hostname validation.

Validity period. Certificates have NotBefore and NotAfter timestamps. Expired certificates are a common cause of TLS failures in production.

Revocation status. Ideally, clients check CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) to ensure the certificate hasn't been revoked.

Common TLS Issues in SIP Deployments

These are the issues that most often cause TLS failures in production SIP environments.

Certificate Expiration

The most frequent production issue. SIP certificates expire, and unlike web browsers that show warnings, SIP clients typically fail silently or with cryptic errors. Monitor certificate expiration dates proactively.

Hostname Mismatch

Occurs when connecting to an IP address directly or when the certificate doesn't include all the hostnames used to reach the server. Use SAN certificates that include all variations: the primary domain, any subdomains, and potentially IP addresses if direct IP connections are required.

Incomplete Certificate Chains

The server must send its own certificate and any intermediate certificates. If only the leaf certificate is sent, clients may fail to validate the chain even though the certificate is legitimate. Verify your server sends the complete chain:

openssl s_client -connect sip.example.com:5061 -showcerts

TLS Version Mismatches

Legacy SIP equipment may only support older TLS versions. TLS 1.0 and 1.1 are deprecated and should be disabled, but doing so may break compatibility with older PBX systems or SIP phones. Audit your client base before disabling older protocols.

Cipher Suite Incompatibility

Modern security requires strong cipher suites, but older SIP devices may not support them. Balance security with compatibility:

# Strong modern ciphers (TLS 1.3)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Acceptable for TLS 1.2
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256

Avoid CBC mode ciphers and anything with RSA key exchange (no forward secrecy).

Multi-IP Deployments and GeoDNS

Large SIP deployments often use multiple servers behind DNS load balancing or GeoDNS. This introduces additional complexity:

Certificate consistency. All servers behind a DNS name must present valid certificates for that name. A single server with an expired or mismatched certificate causes intermittent failures.

Testing specific IPs. When DNS returns multiple IPs, you need to test each one individually. Use OpenSSL to connect to a specific IP while maintaining hostname-based TLS validation via SNI:

# Test specific IP while using hostname for certificate validation (SNI)
openssl s_client -connect 192.0.2.1:5061 -servername sip.example.com
openssl s_client -connect 192.0.2.2:5061 -servername sip.example.com

# First, discover all IPs behind a hostname
dig +short sip.example.com

Certificate timing. When rotating certificates across a fleet, brief windows may occur in which some servers have new certificates and others have old ones. Coordinate deployments carefully.

Mutual TLS (mTLS) in SIP

Standard TLS authenticates only the server. Mutual TLS requires the client to present a certificate, providing stronger authentication for SIP trunking between carriers or for enterprise interconnections.

In mTLS, the handshake includes additional steps for client authentication:

The server validates the client certificate against its trust store, ensuring only authorized SIP endpoints can connect.

SIP-Specific TLS Considerations

SIP headers and routing need to reflect the use of TLS so that secure transport is preserved end to end.

Via Header and Transport

SIP messages include transport information in headers. When using TLS, the Via header indicates the secure transport:

Via: SIP/2.0/TLS client.example.com:5061;branch=z9hG4bK776asdhds

Proxies and B2BUAs must preserve transport consistency through the call path.

Record-Route and Secure Routing

The Record-Route header establishes the path for subsequent requests. When TLS is used, route entries should use sips: URIs to maintain security through the entire dialog:

Record-Route: <sips:proxy.example.com;lr>

SRTP Key Exchange

While TLS protects signaling, media encryption requires SRTP. The most common key exchange methods are:

SDES (SDP Security Descriptions) embeds keys directly in SIP signaling. If TLS protects the signaling, SDES is reasonably secure. Without TLS, keys are exposed in plaintext.

DTLS-SRTP performs a separate key exchange over the media path, independent of signaling security. This is more robust but requires additional protocol support.

ZRTP performs key exchange in the media stream with voice verification. Works independently of signaling security.

Troubleshooting TLS in SIP

When TLS connections fail, these tools and techniques help narrow down the cause.

Diagnostic Commands

Test TLS connectivity with OpenSSL:

# Basic connection test
openssl s_client -connect sip.example.com:5061

# Show full certificate chain
openssl s_client -connect sip.example.com:5061 -showcerts

# Test specific TLS version
openssl s_client -connect sip.example.com:5061 -tls1_2

# Test with SNI (important for shared hosting)
openssl s_client -connect sip.example.com:5061 -servername sip.example.com

Common Error Messages

"certificate has expired" - Check NotAfter date; renew the certificate.

"certificate signed by unknown authority" - Missing intermediate certificates or untrusted root CA.

"hostname mismatch" - Certificate CN/SAN doesn't match the connection hostname.

"handshake failure" - Usually cipher suite or TLS version incompatibility.

"connection refused" - Server not listening on port 5061, or firewall blocking.

Packet Capture Analysis

For deep troubleshooting, capture and analyze the TLS handshake:

# Capture TLS handshake (can't decrypt, but shows handshake issues)
tcpdump -i eth0 -w sip-tls.pcap port 5061

# Analyze in Wireshark with TLS dissector

Look for:

• ClientHello cipher suites offered
• ServerHello cipher suite selected
• Certificate details
• Alert messages indicating failures

Best Practices

Automate certificate renewal. Use ACME/Let's Encrypt or a similar automated certificate management system. Manual renewal processes inevitably fail.

Monitor certificate expiration. Alert at 30, 14, and 7 days before expiration. Include certificate monitoring in your operational dashboards.

Test all endpoints. In multi-IP deployments, regularly test each IP address mapped to a DNS name. One bad server causes intermittent user-facing failures.

Maintain TLS version currency. Plan migration paths away from deprecated TLS versions. Test client compatibility before disabling older protocols.

Use strong cipher suites. Prefer AEAD ciphers (GCM, ChaCha20-Poly1305) with ECDHE key exchange for forward secrecy.

Implement mTLS for trunks. Inter-carrier and inter-enterprise SIP trunks benefit from mutual authentication.

Log TLS events. Capture TLS negotiation details (version, cipher, certificate info) in logs for troubleshooting and security auditing.

Conclusion

TLS in SIP environments requires attention to certificate lifecycle management, consistent configuration across distributed deployments, and compatibility with diverse client ecosystems. While the protocol mechanics mirror standard HTTPS deployments, the operational challenges of VoIP infrastructure—real-time requirements, legacy equipment, and multi-server architectures- demand robust monitoring and testing practices.

Understanding the interaction between SIP signaling security (TLS) and media security (SRTP) is essential for building truly secure voice communications. Neither alone provides complete protection; both must be properly implemented and maintained.

References

LiveKit

• SIP Secure Trunking

SIP Core

• RFC 3261 - SIP: Session Initiation Protocol (core specification)
• RFC 3263 - Locating SIP Servers (DNS procedures for SIP, including NAPTR/SRV)
• RFC 3329 - Security Mechanism Agreement for SIP
• RFC 5630 - The Use of the SIPS URI Scheme in SIP

TLS and Transport Security

• RFC 8446 - TLS 1.3
• RFC 5246 - TLS 1.2
• RFC 6066 - TLS Extensions (includes SNI - Server Name Indication)
• RFC 5765 - Security Issues and Solutions in Peer-to-Peer SIP
• RFC 5922 - Domain Certificates in SIP
• RFC 5765 - Connection Reuse in SIP

Media Security (SRTP)

• RFC 3711 - SRTP: Secure Real-time Transport Protocol
• RFC 4568 - SDP Security Descriptions (SDES key exchange)
• RFC 5763 - DTLS-SRTP Framework
• RFC 5764 - DTLS-SRTP (Datagram TLS for key exchange)
• RFC 6189 - ZRTP: Media Path Key Agreement for Unicast Secure RTP

Certificate and Identity

• RFC 5280 - X.509 PKI Certificate and CRL Profile
• RFC 6125 - Representation and Verification of Domain-Based Application Service Identity (hostname verification)
• RFC 4474 - Enhancements for Authenticated Identity Management in SIP (SIP Identity)
• RFC 8224 - Authenticated Identity Management in SIP (STIR)
• RFC 8225 - PASSporT: Personal Assertion Token (SHAKEN)
• RFC 8226 - Secure Telephone Identity Credentials

Related Standards

• RFC 3550 - RTP: Real-Time Transport Protocol
• RFC 4566 - SDP: Session Description Protocol
• RFC 8445 - ICE: Interactive Connectivity Establishment
• RFC 8825 - WebRTC Overview
• RFC 8827 - WebRTC Security Architecture