TLS Support

Transport Layer Security (TLS) provides mechanisms to secure your phone traffic. Typically it is used to protect your SIP and HTTP connections from eavesdropping and tampering.

TLS handshake overview

Initially, when a client wants to establish a secure connection to a server, some parameters are negotiated, this phase is called the handshake procedure. One of these parameters is the supported cipher suites defining the encryption algorithms required to encrypt the traffic. In a next step, the server sends a digital certificate that contains its public encryption key, the trusted certificate authority (issuer) and a signature of the certificate.

The client may reject the connection if the identity of the server or the issuer is unknown. Usually, the client has a list of trusted server certificates and a list of trusted certificate authorities (CA). If the server certificate is considered trusted or if the identification from the server is signed by one of these CAs, the client typically permits the connection and delivers a random number encrypted with the server's public key to the server. As only the server can decrypt this number with its private key, it is used as the session key to encrypt and decrypt the traffic.

Optionally the server can "ask" the client for the certificate. In that case the client must send a TLS certificate. Now the server can authenticate or deny the request based on the client certificate.

If the identification from the server is signed by one of these CAs, the client typically permits the connection and delivers a random number encrypted with the server's public key to the server. As only the server can decrypt this number with its private key, it is used as the session key to encrypt and decrypt the traffic.

Your phone acts as a TLS client in various cases:

• SIP connections with TLS as transport protocol
• Provisioning requests
• Action URL HTTPs requests
• HTTPS requests to an URL triggered by function keys
• Minibrowser applications served by an HTTPS server
• LDAP server providing the business contacts

Setting-Up the phone for TLS

The built-in certificate

Every Snom phone (except the old 3xx series) is produced with a built-in TLS certificate on board.

Every device certificate is issued by the Snom Certification Authority. The built-in certificate contains the the device MAC address into the DN x.509 attribute.

Thanks to the built-in certificate, a server using the TLS protocol can:

• verify the issuer of the certificate, checking the certificate signature against the Snom CA: in other words the server can make sure that the request comes from a Snom phone
• verify the DN of the client certificate, checking the MAC within the offered certificate and the requested resource. The server can authorise the specific device to the resource

Uploading the Phone Certificate

In fact, no special configuration is required. Every out-of-the-box Snom phone has a certificate built-in to the firmware along with its private key. You can retrieve this certificate by pointing your browser to your phone's web interface via secure HTTP (HTTPS). Usually you will have to confirm that you trust this identification since your browser could not identify your phone. After confirming, your connection to the web interface will be encrypted.

You can also specify your own client certificate in the webserver_cert setting. In this case, make sure you are provisioning the certificate and the key in a trusted environment, see below how to provision a custom certificate.

Authentication of the devices

The TLS server can be configured to check the client identity via the TLS authentication: as described into the previous section, during the TLS handshake, the server asks the client for the certificate. The Snom phone will send the built-in certificate, now the server can check the issuer of the client certificate and permit or deny the request.

Since device MAC address is mentioned into the built-in certificate CN, the web server can also authorize or deny the request based on the requested URL and the presented client certificate.

In order to configure the client authentication, you will need to import the Snom Certification Authority certificates into your TLS server.

Upgrade to SHA-2

Snom Certification Authority public certificates

From the following links you can download:

• SHA-1 Snom root CA
• SHA-1 Snom root CA with intermediate certificates

As SHA1 gets widely deprecated and SHA2 becomes more and more the standard, support for it is getting mandatory in real world deployments.

• SHA-2 Snom root CA support starts with v8.9.3.60 and v10.1.X.
• SHA-2 Snom intermediate

Server Authentication

• Version 8.x
  In version 8.x, you do not need to worry about the server identification. Snom phones do not verify server identities by default. Starting with FW version 8.2.30 you can enable a setting to require verification of server certificates though. You can activate the feature on the certificates page of the web interface:
  
  

• Version 10.x
  As of version 10.x, Snom has decided to force the server identity verification. This verification cannot be disabled because that would create a security weakness for the Snom Phones.
  In addition to the server certificate a phone can also verify the identity of the server checking if the certificate DN matches the server name FQDN. This can be done via the setting check_fqdn_against_server_cert. The behaviour of the server name validation can be modified via the setting host_name_validation_flags.

Adding Unknown Certificates

The phone will reject a connection if it cannot verify the identification with the certificate delivered by the server. If this happens, the following notification will appear on the screen:

A certificate is trusted if its signature is signed by a certificate authority. Snom has pre-installed a list of CAs which are listed on the Certificate Authorities tab of the Certificates page. This list is automatically updated based on the Mozilla official list, at every new firmware upgrade.

All rejected certificates are listed in the Unknown Certificates tab. If you want to permanently trust a certificate you can add it as an exception:

After adding it as an exception in the Server Certificates tab a connection from a peer using this certificate will no longer be rejected.

Manually Uploading Certificates

In admin mode, you can manually upload certificates signed by one of the phone’s accepted authorities or server certificates in the Unknown Certificates tab. Every attempt to upload an unknown certificate will fail. In case of upload failures, please refer to the log and make sure your certificate is in DER format and is signed by one of phone's authorities or server certificates.

Uploading Server Certificates via Provisioning

You can upload a server certificate using auto provisioning. For this, the download link to the certificate needs to be placed within the XML.

The certificates settings (<certificates> tag) contains the trusted server certificates. This XML tag can be used either inside the <settings> tag or as an individual XML file whose URL is listed inside <setting-files> tag

The tag contains an attribute with the URL of the certificate file to fetch:

<certificate url="http://some.url/certificate.der" />

Beginning with firmware release 8.7.5.52/8.9.3.41 a second variant of this tag is supported, where the content of the certificate file is included as a base64 encoded string:

<certificate type="base64">...</certificate>

The benefit of this variant is that the certificate is immediately available after processing the line in the provisioning XML.

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

If you decide to provide the download link(s) in an additional XML file, this is how it could look like: 

<certificates>
 <certificate url="http://192.168.1.101/trusted_cert1.DER" />
 <certificate url="http://192.168.1.101/trusted_cert2.DER" />
</certificates>

The attributes url and base64 can be combined in the same file, as the following example:

<?xml version="1.0" encoding="utf-8" ?>
<certificates>
   <certificate url="http://192.168.1.101/trusted_cert1.DER" />
   <certificate url="http://192.168.1.101/trusted_cert2.DER" />
   <certificate type="base64">
 MIIG9zCCBd+gAwIBAgIIUf9BRQhu9JwwDQYJKoZIhvcNAQELBQAwdTELMAkGA1UE
 BhMCREUxJTAjBgNVBAoTHFQtU3lzdGVtcyBJbnRlcm5hdGlvbmFsIEdtYkgxHzAd
 BgNVBAsTFlQtU3lzdGVtcyBUcnVzdCBDZW50ZXIxHjAcBgNVBAMTFVRlbGVTZWMg
 QnVzaW5lc3MgQ0EgMTAeFw0xODA0MTkxMDQ3MTlaFw0yMDA3MTkyMzU5NTlaMIGl
 MQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsG
 A1UECxMUU0lQLVRydW5rLnRlbGVrb20uZGUxEjAQBgNVBAsTCVNJUC1UcnVuazEY
 [...]
 [...]
 MBYGA1UEAxMPdGVsLnQtb25saW5lLmRlMRwwGgYDVQQIExNOb3JkcmhlaW4tV2Vz
 dGZhbGVuMQ0wCwYDVQQHEwRCb25uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
 CgKCAQEAwl6iq3B9EBJe9z34yCikyfla+ZSKE4gQUpo3hLLz2zXKiQildQc6qB6g
 MzYvwjVJI64t5S2CbqEybBtrPn0FiziseDRZKnt+bkuIqZNPOYtkE1akGgdjIieV
 Wjg6oD37+BCCqyq60gq0FbsGgjlwiNb68jL7dUXzRi2lgxtwk86+g/QFg+3rQts/
 3GREGNhwVbu4mUIrnnphaUA8BnUeGi++8j9d21ZF/uW2pIQqVBItYDflBee+qGfk
   </certificate>
</certificates>

Tech Notes

Phone's Web Server Certificate

The phone uses the built-in certificate also as a certificate for the web user interface when accessed via HTTPS. Currently Snom phones come with SHA1(RSA, 1024 bit key length) or SHA2(RSA, 2048 bit key length) certificates.

Starting from firmware 8.9.3.40 it is possible to switch the certificate via the setting phone_cert_type to a SHA256 certificate .

Supported Cipher Suites

Limitations

• No support of Certificate Revocation Lists (CRL).
• No support for Certificate Lifecycle Management (e.g. SCEP).

• Page:
  A150 / A170 DECT Encryption
• Page:
  Can I provide encrypted user passwords via mass deployment
• Page:
  Can I use self-signed certificates for secure provisioning
• Page:
  Can I use two snom phones for VPN without additional equipment
• Page:
  Does the Snom UC Firmware Support SHA256 and TLS. 1.2
• Page:
  Does this phone series support encrypted calls via TLS and SRTP
• Page:
  Dynamic Blacklist Check
• Page:
  How can I set up Snom phones for TCP support
• Page:
  How do I secure my Snom phone
• Page:
  How to load a SIP client certificate on the DECT base M300, M700, M900
• Page:
  How to migrate to version 10.1.x
• Page:
  I'm unable to cancel the Warning messages from the Phone menu
• Page:
  Install and configure L2TP on Snom Deskphones
• Page:
  Key lock on Snom phones
• Page:
  M200SC - VPN Configuration Guide
• Page:
  Port Authentication via 802.1x - EAP-TLS
• Page:
  Protecting Snom devices against customer interference
• Page:
  Secure provisioning of Snom phones
• Page:
  Securing Snom phones more effectively
• Page:
  Security and Privacy
• Page:
  Security FAQ
• Page:
  Security How-to
• Page:
  Support for OpenVPN redundancy
• Page:
  TLS - HTTPS no longer works after upgrade from version 8.x to 10.x
• Page:
  TLS Support
• Page:
  Virtual Private Network - VPN
• Page:
  VPN Issue
• Page:
  Where can I find the supported CAs