securing unified communications andd2zmdbbm9feqrf.cloudfront.net/2016/anz/pdf/brkucc-2042.pdf ·...

Securing Unified Communications and Certificate Deep Dive

Ryan Ratliff, Technical Leader - Services

• Cisco Unified Communications Manager has a robust set of security features that allow for an effective defense throughout the system. This session will highlight security updates in the latest UCM versions as well as security features like CTL, CAPF, UC Manager PKI, encrypted signalling and media from a foundational, configuration, and troubleshooting perspective.

Abstract

• Secure Network, Secure Endpoints, Secure Call Control

• Hardened appliance model & Toll Fraud Protection

• Certificates & PKI

• Certificate Trust List (CTL) & Initial Trust List (ITL)

• Cisco Product Security

• Q & A

Agenda

Secure Network, Secure Endpoints, Secure Call

Control

Infrastructure Security MeasuresSegregation

• Virtual LANs (VLANs) separates voice and data traffic

• VLAN Access Control Lists (VACLs) limits traffic between devices on the voice VLAN

• QoS Packet Marking ensures UC traffic receives appropriate priority over other traffic

Layer 2

• DHCP Snooping creates binding table

• Dynamic ARP Inspection examines ARP & GARP for violations

• Port Security limits the number of MAC addresses allowed per port

• 802.1x limits network access to authentic devices on assigned VLANs

•Multi-Domain Authentication (MDA) binds two devices to assigned VLANs

•MAC Authentication Bypass (MAB) provides a measure of control over devices which don’t support802.1x

Layer 3

• IP Source Guard examines physical port, VLAN, IP, & MAC for inconsistencies

6

IP Phone Security Features• Cryptographically assured device identity

• Manufacture Installed Certificate(MIC)

• Locally Significant Certificates (LSC)

• Signed firmware images

• Signed & encrypted configuration files

• Mutually authenticated & encrypted signalling & media

• Embedded 802.1x Supplicant

• Positive disconnect for handset & speakerphone

• Positive off-hook indicator for speakerphone

• Disable or block access to voice VLAN for downstream port

7

• Disable web interface

• Disable “settings” button

• Disable SSH access

• FIPS mode (select models)

• Gratuitous ARP rejection

Unified Communications Manager Security

Encrypted Signalling & Media

• SIP & SCCP Phones

• SIP Video Endpoints

• MGCP, H.323, & SIP Trunks

• TAPI & JTAPI Applications

• Meet-me, ad-hoc, & barge Conferences

• Extension Mobility Cross-Cluster

• Intercluster Lookup Service (ILS)

• Location Bandwidth Manager (LBM)

8

Secure Interfaces & Protocols

• Web, CLI, CTI, & LDAP

• HTTPS, TLS, SRTP, SSH, SFTP, SLDAP, & IPSec

Unified Communications Manager Security

• Disallow trivial passwords

• Require minimum length

• Prevent reuse with configurable depth

• Lockout on failed attempts with configurable depth, time span, & duration

• Lockout on inactivity with configurable time span

• Expire after configurable time span

• Expiry warning with configurable time span

User Credential Policies

• Control frequency of credential modifications with configurable time span

• Force credential modification on next attempt

• Prevent credential modification by user

• Lockout by administrator

• Configurable session timeouts

• SAML Single-Sign-On (SSO)

Balancing Risk

Low

Easy or Default

Medium

Moderate and Reasonable

High

Advanced or Not Integrated

Hardened Platform IP VPN Phone UC-Aware Firewall (Inspection)

SELinux – Host Based Intrusion

ProtectionSecure Directory Integration (SLDAP) Phone Proxy

iptables - Integrated Host Firewall Encrypted Configuration Ipsec

Signed Firmware & Configuration TLS & SRTP for Phones & Gateways Rate Limiting

HTTPS Trusted Relay Points (TRP) Managed VPN (Remote Worker)

Separate Voice & Data VLANs QoS Packet Marking Network Anomaly Detection

STP, BPDU Guard, SmartPorts DHCP Snooping Scavenger Class QoS

Basic Layer 3 ACL’s (Stateless) Dynamic ARP Inspection 802.1x & NAC

Phone Security Settings IP Source Guard, Port Security

Cost - Complexity - Resources - Performance - Manpower - Overhead

Cluster Security Mode: Feature Tradeoffs

Feature Non Secure Cluster Mixed Mode Cluster

Auto-registration

Signed & Encrypted Phone Configs

Signed Phone Firmware

Secure Phone Services (HTTPS)

CAPF + LSC

IP VPN Phone

Secure Endpoints (TLS & SRTP) 11

Hardened Appliance Model

• SELinux enforcing mode provides host based intrusion protection

• iptables provides host based firewall

• Third party software installations NOT allowed

• Root account disabled, no other uid=0 accounts

• OS and applications are installed with a single package

• All software updates must be signed packages from Cisco

• Secure Management (HTTPS, SSH, SFTP)

• Audit logging

• Active & Inactive partition architecture – easy to fallback if needed

Why is CUCM considered a hardened platform?

Eliminate Toll FraudHow Do Our Customers Prevent Toll Fraud?• Deny network access to unauthorised users

• Partitions and Calling search spaces provide dial plan segmentation and access control

• Device Pool “Calling Search Space for Auto-registration” to limit access to dial plan

• Employ Time of day routing to deactivate segments of the dial plan after hours

• Require Forced Authentication Codes on route patterns to restrict access on long distance or internal calls.

• “Drop Ad hoc Conferences” (CallManager Service Parameter)

• “Block OffNet to OffNet transfer” (CallManager Service Parameter)

• Monitor Call Detail Records

• Employ Multilevel Administration

• Voice Gateways: Call Source Authentication (IOS 15.1(2) feature)

Certificates and PKI

PKI – Public Key Infrastructure

Consists Of…

Public + Private keypair

• Private Key remains secret

• Public Key widely distributed

Allows For…

• Asymmetric key encryption

• one-way encryption and decryption

• Symmetric key encryption

• Public Key exchange used to establish shared-secret between two parties

• Message encryption and authentication protocols

• Digital passport

• Self-signed or CA-Signed

• Contains the owner’s public key

• Proves the identity of a public key’s owner

Digital Certificates

What is a Signed File?

• Encrypted or unencrypted file that contains a signature in addition to the file contents.

How a File is Signed

Validating a Signed File

Unified CM Certificates• Unified CM includes seven certificate types:

• Tomcat (web services)

• CallManager RSA and EC (SIP/SCCP TLS, TFTP config signing, etc.)

• CAPF (CA cert used to sign LSC, only employed on the publisher)

• IPSEC (ipsec tunnels to gateways or other CUCM)

• TVS (Trust Verification Service, security by default)

• ITLRecovery (used as a trust anchor for bulk ITL recovery)

• Default to self-signed certificates, valid for 5 years*

• ITLRecovery is valid for 20 years beginning in 11.0

• Option to have signed by 3rd party CA

• Self-signed, 3rd party CA signed certificates, and trusted certificates managed via OS Admin page

20

• New option to share a single CA signed certificate across all nodes in a cluster

• Each cluster node’s FQDN included as Subject Alternative Name (SAN) in a single certificate, custom SANs can also be included

• Available for Unified CM (UCM + IM&P) and Unity Connection clusters

• Specifically for Tomcat, CallManager, CUP-XMPP & CUP-XMPP-S2S certificate types, CallManager-ECDSA in 11.0

Multi-Server Certificate SupportSimplify Certificate Management In Clustered Environments Of UCM 10.5 And Later

Unified CM Cluster

UCM nodes IM&P nodes

One CA signed Multi-Server Tomcat certificate for the entire Unified CM cluster

Multi-Server CSR

Distribution drop-down provides Multi-server option

Common Name can be edited, defaults to “–ms” suffix

Auto-populated domains, parent domain, and other admin supplied domain names all included in CSR as individual DNS SANs

Multi-Server CSR Workflow

1. All nodes in the cluster need to be installed and powered on

2. Navigate to Publisher’s OS Admin > Cert Mgmt page and generate CSR with distribution set to “Multi-Server”, supply other SANs if required

3. Admin will be prompted for other cluster nodes OS admin credentials to securely replicate CSR throughout the cluster (no prompt when using common credentials)

4. Download CSR and take to CA to procure a signed certificate

a. Depending on the CA, you may need to re-enter each SAN in the CA’s web form

b. Verify the CA signed certificate includes all SANs you requested

5. Upload CA certificate chain to tomcat-trust via Publisher’s Cert Mgmt page (tomcat-trust certs are always replicated throughout the cluster)

6. Upload signed Tomcat multi-server certificate via Publisher’s Cert Mgmt GUI

7. Restart services on all nodes (utils service restart Cisco Tomcat)

Using the Tomcat certificate as an example

XMPP Multi-Server CSR Workflow

• cup-xmpp & cup-xmpp-s2s multi-server CSRs need to be generated from IM&P nodes

• Auto-populated domains will include

• IM&P node FQDNs

• Presence domains

• Group Chat Server Alias (cup-xmpp-s2s only)

• Email domains, if configured (cup-xmpp-s2s only)

• Restart Cisco XCP Router service after uploading signed cup-xmpp certificate

• Restart Cisco XCP XMPP Federation Connection Manager service after uploading signed cup-xmpp-s2s certificate

XMPP CSR Differences From The Previous Tomcat Workflow

Certificate Key Length & Hash Algorithm OptionsAvailable Across All Server Certificate Types In Unified CM 10.X

Certificate Key Length & Hash Algorithm Options

• New ECDSA certificate with EC encryption added in Unified CM 11.0

• Host portion of certificate CN will end in –EC

• Multi-Server certs will end in –EC-ms

• CallManager-ECDSA cert is included in ITL with role of TFTP

• Key size will limit hash algorithm selection

Key Pair Length Hash algorithm supported

256 bits SHA256, SHA384, SHA512

384 bits SHA384, SHA512

512 bits SHA512

‘set web-security’ CLI command

• CLI command used for updating certificate details including Organisational Unit (OU), Organisational Name (O), Location (L), State (S), and Country (C)

• One DNS SAN can also be added via the cli command (optional)

• SANs for Multi-Server CSRs can also be set from OS Admin CSR GUI

Best Practice: Tomcat Certificate Signed by CA

• Tomcat: HTTPS certificate used for serving CUCM admin, end user self-care page, and UDS

• By default Tomcat is self signed

• Self signed certificates generate ugly security warnings and reinforce bad habits

• Use a CA signed certificate to avoid certificate errors in browser for both end users and admins

• Save time and money with multi-server Tomcat certificate

Avoid Untrusted Certificate Warnings In Browsers And Jabber

Endpoint Certificates

• Manufacturing Installed Certificate (MIC)

• Cisco IP Phones ship from the factory with a unique MIC pre-installed

• MIC is valid for 10 years

• No certificate revocation support

• Locally Significant Certificates (LSC)

• preferred certificate for endpoint identity

• Endpoint support includes IP Phones, TelePresence, Jabber clients, CIPC

• LSC signed by CAPF Service running on CUCM Publisher

• LSC supports the same RSA and EC key sizes as Unified CM

• LSC can be installed, re-issued, deleted in bulk with CUCM Bulk Admin Tool

• LSC signed by CAPF is valid for 5 years

• Paper process required to track certificate expiration*

Cryptographically assured device identity

Endpoint Certificates

• New to UCM 11.0

• Default Key Order is RSA Only with 2048 bit Key Size

• Key Size updated for RSA and EC separately

• No current client support for EC only

• Auto-generated Device Security Profile will have a suffix indicating Key Order and Key Size

CAPF Support for EC Key Sizes

Best Practice: IP Phone MIC• Endpoints can use MICs to authenticate with CAPF for LSC installation

• Use MIC for initial endpoint provisioning of IP Phones before LSC installation is done

• Not recommended to use MIC for TLS, VPN, or 802.1x

• MIC is installed at time of manufacturing and cannot be revoked

• When both LSC and MIC are installed on a device, LSC takes preference

• MIC CA certificates included in both the CallManager and CAPF trust stores:

• CAP-RTP-001

• CAP-RTP-002

• Cisco_Manufacturing_CA

• Cisco_Root_CA_2048

Cisco Manufacturing CA SHA2

• Cisco’s newest IP Phones include MIC certificates signed by this new Manufacturing SHA2 CA

• CUCM 10.5(1)+ includes and trusts the new SHA2 certificate

• Customers on older versions of UCM may need to download the new Manufacturing CA certificate and

1. upload to the CAPF-trust to allow phones to authenticate with CAPF to obtain an LSC

2. upload to the CallManager-trust if customer want to allow phones to authenticate with MIC for SIP 5061

http://www.cisco.com/security/pki/certs/cmca2.cer

8811, 8841, 8851, 8861

Troubleshooting Certificates

Unable to Upload CA-signed Certificate

Unsupported CA-Signed Certificates

Common problems associated with CA certs

• 4096-bit cert anywhere in the trust chain

• Unsupported until UCM 11.0, 10.5(2)SU2

• Will upload but TFTP cannot use it to create an ITL

admin:show itl

The checksum value of the ITL file:

d41d8cd98f00b204e9800998ecf8427e(MD5)

da39a3ee5e6b4b0d3255bfef95601890afd80709(SHA1)

Length of ITL file: 0

The ITL File was last modified on Fri Jan 22 11:08:23 EST 2016

Parse ITL File

----------------

Invalid ITL file. Error skipping past version.

Error parsing the ITL File.

TLS connections in Wireshark

• Client: Entity initiating the connection

• Server: Entity receiving the connection

• Wireshark filters:

• ‘ssl’ – Only packets with SSL data

• ‘tcp.port == nnn’ – All TCP packets for the connection including SYN, ACK with no data

TLS connections in Wireshark – TCP vs SSL

SSL

TCP.port == 8443

Certificates in Wireshark

Server Certs can easily be examined from a pcap!

Intermediate Cert

Certificates in Wireshark

Certificate Trust List (CTL) &

Initial Trust List (ITL)

Certificate Trust List (CTL)

• Enabling Mixed Mode to support encrypted signalling and media requires CTL

• Minimum of 2 USB secure tokens required, KEY-CCM-ADMIN-K9= or new KEY-CCM-ADMIN2-K9=

• CTL client produces Certificate Trust List (CTL) file and uploads to CUCM TFTP

• Download the CTL Client from CUCM Admin, install on Windows workstation

• CTL file is downloaded by endpoints and is the basis for endpoint certificate trust

CTL provides a trust mechanism for Cisco endpoints

Certificate Trust List (CTL)

• Unified CM 10.0 supports two different methods of building the CTL

• Classic CTL client, minimum 2 USB tokens required

• New token-less CTL

• Token-less CTL is activated with admin cli command (publisher only),

• utils ctl set-cluster mixed-mode

• CallManager certificate private key is used to sign the CTL, rather than the USB token

• DRS backup !!!

• Other CTL cli commands include

• utils ctl update CTLFile

• utils ctl set-cluster non-secure-mode

New token-less CTL option

Initial Trust List (ITL)

• Unlike the CTL file, the ITL file is built automatically when the cluster is installed or upgraded to 8.0+

• Downloaded by phones at boot or reset, after CTL file

• Has the same format as the CTL File

• Does not require eTokens; uses a soft eToken (the CallManager cert private key)

• Static and Dynamic ITL Files are built

• ITLFile.tlv ITLSEPMAC.tlv

Security by Default component

45

Initial Trust List (ITL) ContentsCertificate Roles: TFTP, CCM+TFTP, SAST, TVS

• TFTP, CCM+TFTP (mixed mode cluster)

• CallManager RSA certificate from the local node

• CallManager ECDSA certificate from the local node (11.0)

• SAST (allowed to sign the ITL file):

• CallManager RSA certificate from local node (8.x, 9.x, 10.x)

• CallManager RSA certificate from every node (11.0)

• ITLRecovery certificate (10.5+)

• TVS:

• All nodes in the cluster

• ITL Contents viewable with CLI show itl

• New to UCM 11.0

• Includes CallManager-ECDSA and CallManager certificates for the entire cluster

• Only served to endpoints when the request for ITL comes in over HTTPS

• No endpoint support today

• Listed after regular ITL in CLI show itl

Extended ITL

Trust Verification Service

• Trust Verification Service (TVS) runs on each CUCM server and authenticates certificates on behalf of the phone

• Provides endpoint trusted certificates scale

• Instead of downloading all the trusted certificates, phones need only to trust TVS

• Up to 3 TVS per phone (primary, secondary and tertiary from CallManagerGroup)

• No support when failover to SRST by phone

• TVS function relies on SBD enabled and correct TVS certificate in the endpoint’s ITL file

Security by Default Component

• ITL file is built by the TFTP service in UCM 8.6+

• TVS service built the ITL file in UCM 8.0 & 8.5

• Each node running TFTP creates a unique ITL

• ITL file is rebuilt when:

• TFTP Service Restarts

• Any certificate inside the ITL changes

• CallManager Group Changes

• IP Phones automatically reset on certificate change (8.6+)

• ITL Signature should always match on endpoint and TFTP server

Managing Security by Default (SBD)ITL File Awareness

Managing Security by Default (SBD)

• “Prepare Cluster for Rollback to pre 8.0” Enterprise parameter empties the ITL file, disabling Security by Default feature

• Disable SBD if customer upgraded but needs to roll cluster back to 6.X, 7.X

• Endpoints cannot use HTTPS Services with SBD Disabled

• Default internal services will fail with SBD disabled prior to 10.5(2)

Disabling Security By Default

How Do Phones Trust the ITL File?

Case 1: Non-Existing CTL File

First ITL File is trusted in a leap of faith (similar to initial CTL)

Subsequent ITL Files must be either

• signed by the same TFTP private key

• or TVS is able to provide the certificate corresponding to the signer

• or ITL is signed with the ITL Recovery Key

Case 2: Existing CTL File

Phone uses the certificates in the CTL File to authenticate the ITL File signature

51

Option 1: Disable SBD Option 2: Use TVS

Pros:

• No cross-cluster certificate exchange

• “old” cluster can be offline

Cons:

• Reduced security due to “leap of faith” as phone moves to new cluster

• Must reset phone every time the parameter is changed.

Pros:

• Seamless user experience

• Phone maintains a trust list at all times.

Cons:

• Requires identity certificate exchange from all TFTP nodes.

• Requires connectivity from phone to both clusters

Migrating Phones Between Clusters

DRS Backup/Restore Certificates & Keys

• The trust anchor for the ITL File is the TFTP private key (CallManager certificate)

• Certificates and private keys are both included in DRS backups

• The backup package is encrypted to protect the private key

• DRS can be used to restore certificates and keys

• Take a fresh backup after regenerating server certificates to insure the ITL trust anchor can be restored in a disaster scenario

53

ITL Recovery Key

• The ITL Recovery key is a new addition to the ITL file in 10.0

• It provides a fallback mechanism to restore trust between endpoints in rare conditions were phones no longer trust the ITL file or new signed configuration files server by TFTP

> show itl

New Key Added To The ITL In 10.0

Backing Up The ITL Recovery Key

> file get tftp ITLRecovery.p12

ITLrecovery Backup Alternative

Troubleshooting CTL and ITL Issues

Invalid ITL/CTL Files

admin:show itl

The checksum value of the ITL file:

d41d8cd98f00b204e9800998ecf8427e(MD5)

da39a3ee5e6b4b0d3255bfef95601890afd80709(SHA1)

Length of ITL file: 0

The ITL File was last modified on Fri Jan 22 11:08:23 EST 2016

Parse ITL File

----------------

Invalid ITL file. Error skipping past version.

Error parsing the ITL File.

Detecting CTL/ITL Mismatches

1. DeviceTLInfo Alarm sent at registration from endpoint to UCM

%UC_-3-DeviceTLInfo: %[DeviceName=SEPD0C789141239][IPv4Address=192.168.100.22][IPv6Address=::][CTL_Signature=22 CB 70 5F 3E 0C 9A A9 43 80 EF 2A 3B 41 92 FC E8 60 7E 3D ][CTL_TFTP_Server=videolab-ucm11a-pub.videolab.local][ITL_Signature=65 B0 1A 7C E9 45 AD F4 CA 9E 88 20 4E C2 C2 3F 36 8D ED D0 ][ITL_TFTP_Server=videolab-ucm11a-pub.videolab.local][UNKNOWN_PARAMTYPE:StatusCode=1][AppID=Cisco CallManager][ClusterID=videolab11a][NodeID=videolab-ucm11a-pub]: Trust List Files are updated or installed

2. Endpoint web page

ITL & CTL in Endpoint Web Server

Remote TL Info – Support by Endpoint Family

Model DeviceTLInfo Alarm CTL/ITL in Web

Server

Firmware Version**

8941 8945

SIP 9.4(2)

89XX 99XX

9.4(2)

69XX

SIP 9.4(1)

78XX 88XX

11.0

8831

10.3(1)

DX

10.2(5)

** Verified version

Fixing CTL/ITL Mismatches

1. Manually erase ITL/CTL at every phone

• Requires Settings Access enabled

• Does not scale

2. Use SIP signalling or endpoint XSI interface to erase the ITL/CTL at every phone

• Requires Settings Access enabled

• 3rd party applications are available but may be expensive

3. Revert to the old ITL file on the TFTP server

• Requires the fix for CSCts01319

• Must be able to identify the current ITL on the phone

• Only available via remotesupport account through TAC

• >utils itl reset localkey

• Restart phones after running this command on the publisher

• Similar procedure available for tokenless CTL (watch out for CSCux73531)

Reset ITL TrustRecover phones not accepting config changes or new ITL files

Cisco Product Security Awareness

Cisco Secure Development Lifecyclewww.cisco.com/go/csdl

Cisco PSIRT Has Your Back

• Dedicated, global team managing security vulnerability information related to Cisco products and networks

• Responsible for Cisco Security Advisories, Responses and Notices

• Interface with security researchers and hackers

• Assist Cisco product teams in securing products

• Subscribe (RSS or email) to Cisco notification service

Product Security Incident Response Team (PSIRT) - www.cisco.com/go/psirt

http://www.cisco.com/cisco/support/notifications.html

http://www.cisco.com/go/psirt

Product Security Awareness

• Subscribe/Monitor PSIRT security advisories, responses and notices

• Consult advisory details to understand impact, workarounds, and other details

• Reference linked Cisco Applied Mitigation Bulletins (AMB) when available

• Make preparations to patch systems via upgrade or COP files

• Verify DRS backups available before patching critical systems

Complete Your Online Session Evaluation

Learn online with Cisco Live!

Visit us online after the conference

for full access to session videos and

presentations.

www.CiscoLiveAPAC.com

Give us your feedback and receive a

Cisco 2016 T-Shirt by completing the

Overall Event Survey and 5 Session

Evaluations.– Directly from your mobile device on the Cisco Live

Mobile App

– By visiting the Cisco Live Mobile Site http://showcase.genie-connect.com/ciscolivemelbourne2016/

– Visit any Cisco Live Internet Station located

throughout the venue

T-Shirts can be collected Friday 11 March

at Registration

http://www.ciscoliveapac.com/

http://showcase.genie-connect.com/ciscolivemelbourne2016/

Thank you

Backup Slides

Certificate Example: Self-signed tomcat.pem

Known Caveats – Multi-Server CallManager certs

• Not recommended to use Multi-Server CSR for CallManager certificate on older 10.X releases.

• known caveats exist pre 10.5(2)SU2

• CSCur79530, CSCuq02712, CSCur97909

• CallManager certificates should not be signed by a CA with 4096 bit key -CSCur67631 (this is unrelated to Multi-Server certificate usage)

• All of these defects addressed in 10.5(2)SU2

• No known defects related to Tomcat, CUP-XMPP or CUP-XMPP-S2S Multi-Server certificate usage

Specific to CallManager.pem certificate

Lock Icon – Non Secure Video Considerations• Allows administrator to determine what encryption criteria must be met to

display the lock icon

• Old Service Parameter: “Override BFCP Application Encryption Status When Designating Call Security Status”

• Renamed 10.0 service parameter: Secure Call Icon Display Policy

TLS Ciphers SIP Line/Trunk Establishing a ConnectionTLS Ciphers Option Cipher Order Client Certificate

AES-256 SAH384 ciphers only RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_AES_256_GCM_SHA384

CallManager

AES-128 SHA256 ciphers only RSA preferred TLS_ECDHE_RSA_AES_128_GCM_SHA256


CallManager

AES-256, AES-128 ciphers ECDSA preferred TLS_ECDHE_ECDSA_AES_256_GCM_SHA384


TLS_ECDHE_RSA_AES_256_GCM_SHA384


TLS_RSA_WITH_AES_128_CBC_SHA1

CallManager

AES-256, AES-128 ciphers ECDSA only TLS_ECDHE_ECDSA_AES_256_GCM_SHA384


CallManager-ECDSA

AES-256, AES-128 ciphers RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384





CallManager

AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1 CallManager

TLS Ciphers SIP Line/Trunk Receiving a ConnectionTLS Ciphers Option Cipher Order

















AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1

TLS Ciphers Secure CTI Manager Receiving a ConnectionTLS Ciphers Option Cipher Order

















AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1

securing unified communications andd2zmdbbm9feqrf.cloudfront.net/2016/anz/pdf/brkucc-2042.pdf ·...

Documents