- Propósito
- Revisão sobre Segurança no Telefone e CTL
- Configuração
- 1. Obter eTokens USB
- 2. Habilite os Serviços CTL Provider e CAPF
- 3. Download and Install the CTL Client
- 4. Execute o CTL client usando eTokens
- 5. Reinicie os serviços que sejam necessários
- 6. Instale LSC nos telefones
- 7. Criar e aplicar perfis de segurança do telefone
- Solução de problemas
- Lista de Verificação e Reparação
- Referências
Propósito
O objetivo deste documento é atuar como um suplemento ao guia oficial Communications Manager Security Guide, fornecendo exemplos, explicações e diagramas para Segurança no Telefone (Phone Security) usando Listas de Certificados Confiáveis (Certificate Trust Lists - CTL).
Revisão sobre Segurança no Telefone e CTL
Segurança no Telefone com CTL fornece as seguintes funções:
- Autenticação de arquivos baixados do servidor TFTP (configuração, locale, ringlist, etc) usando uma chave de assinatura.
- Criptografia de arquivos de configuração usando uma chave de assinatura.
- Criptografia dos pacotes de sinalização para os telefones IP.
- Criptografia dos pacotes de mídia (áudio) para os telefones IP.
As duas primeiras funções também podem ser fornecidas através da utilização de arquivos ITL. As funções seguintes de criptografia de sinalização e mídia só podem ser fornecidas usando arquivos CTL. Consulte o documento Communications Manager Security By Default and ITL Operation and Troubleshooting para obter mais informações sobre arquivos de configuração autenticados e criptografados.
Configuração
1. Obter eTokens USB
Pelo menos dois eTokens USB são necessários para habilitar Segurança no Telefone. Estes eTokens são a chave para assinar o arquivo CTL, e não devem ser perdidos. Múltiplo eTokens pode ser usado em um arquivo CTL para redundância uma vez que eles são tão importantes. Eles devem ser guardados em lugares seguros, e suas senhas atuais também armazenados de forma segura.
No caso de um token ser perdido ou bloqueado, os outros tokens também utilizados na assinatura inicial do arquivo CTL podem ser utilizados.
Um token será bloqueado depois de 15 tentativas de senha com falha. Assim lembrar a senha e ter os tokens de backup é extremamente importante.
2. Habilite os Serviços CTL Provider e CAPF
O serviço CTL Provider aceita conexões do CTL Client para gerar o arquivo CTL e recolher os certificados de todos os servidores. O serviço CAPF (Certificate Authority Proxy Function) é responsável em assinar e armazenar LSCs (Locally Significant Certificates) para os telefones.
3. Download and Install the CTL Client
A partir de CUCM 8.6, CTL cliente finalmente é suportado no Windows 7. Certifique-se de fazer download do correto CTL client de acordo com o sistema operacional em uso no PC.
4. Execute o CTL client usando eTokens
O CTL client apresentará as seguintes opções quando executado depois de uma primeira instalação:
Set Cisco Unified CallManager Cluster to Mixed Mode:
Desativa auto-registration dos telefones e cria um arquivo CTL.
Set Cisco Unified CallManager Cluster to Non-Secure Mode:
Permite auto-registration dos telefones e deixa qualquer arquivo CTL existente no lugar. Este é o modo padrão, então não pode ser selecionado, a menos que o cluster já esteja em Mixed mode.
Update CTL File:
Isto permite que quaisquer novos certificados ou servidores sejam adicionados ao CTL file.
Escolhendo qualquer uma destas opções vai exigir que um eToken USB seja inserido no PC.
Uma vez inserido, as informações sobre o token são exibidas:
Neste momento, o CTL client realiza conexões na porta TCP 2444 com todos os servidores CUCM no cluster para recolher os certificados de CallManager e CAPF existentes. Isto requer resolução de nomes se estiver usando hostnames em "CCMAdministration > System > Server".
A lista de todos os servidores e certificados é exibida, junto com todos os Tokens, no arquivo CTL existente.
Se apenas um eToken for exibido, a opção "Add Tokens" deve ser usada para adicionar mais outro token antes do cluster poder ser configurado para Mixed Mode.
Quando a opção “Finish” for selecionada, o CTL client vai pedir a senha da chave privada do eToken USB. Isso permite que o eToken seja usado para assinar o arquivo CTL recém-criado, que contém todos os certificados e tokens apresentados acima.
Na figura abaixo a senha foi digitada incorretamente uma vez. O software do eToken adverte que apenas mais 14 tentativas são permitidas antes que o token seja permanentemente bloqueado (invalidado). Uma senha bem-sucedida zera o contador.
Se a senha correta é digitada, o CTL client destrava a chave privada do eToken e a usa para assinar o arquivo CTL. Este arquivo CTL recém-assinado, em seguida, é enviado a cada servidor no cluster usando outra conexão ao serviço CTL Provider na porta TCP 2444. Novamente, isto requer conectividade de rede e resolução de nome do PC a cada servidor no cluster.
5. Reinicie os serviços que sejam necessários
O procedimento recomendado é reiniciar o serviço TFTP nos servidores que o tenham habilitado, seguido pelo reinício do serviço CallManager em todos os servidores que o tenham habilitado. Reiniciando o serviço TFTP permite que processo de TFTP carregue o CTLFile.tlv recém-gerado. Reiniciando o serviço CallManager causará o reinício dos telefones e o download do novo CTL file do servidor TFTP configurado.
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)?
6. Instale LSC nos telefones
Depois que o serviço CAPF é habilitado e os telefones obtém o certificado CAPF baixando o arquivo CTL, os telefones podem se conectar ao CAPF para obter os arquivos LSC.
Configure o campo “Certificate Operation” na página de configuração do telefone (Device -> Phone) ou na página de BAT (Bulk Administration Tool -> Phones -> Update Phones -> Query) com “Install/Upgrade”.
Depois de definir o campo “Certificate Operation”, reinicie aos telefones.
Se “Null String” ou “Existing Certificate” foi escolhido como o modo de autenticação, nenhuma outra ação será necessária.
Se “String” foi escolhido como o modo de autenticação, terá que ser manualmente inserido no telefone.
Settings > Security Configuration > **# > LSC > Update
7. Criar e aplicar perfis de segurança do telefone
Agora finalmente os telefones podem ter segurança habilitada através do Phone Security Profile. Esses profiles são específicos ao modelo do telefone sendo configurado. Um profile precisará ser criado para cada modelo de telefone em uso.
CCMAdministration > System > Security > Phone Security Profile
O campo “Device Security Mode” define o mode de segurança com as seguintes opções:
Non Secure - sinalização e mídia (voz / RTP / Real Time Protocol) não criptografadas
Authenticated - sinalização criptografada e mídia não criptografada
Encrypted - sinalização e mídia criptografadas
O checkbox “TFTP Encrypted Config” controla se o servidor envia ao telefone um arquivo de configuração criptografado ou não. A criptografia do arquivo TFTP é independente da configuração do campo “Device Security Mode”, e um arquivo de configuração criptografado é recomendado em telefones que o suportam.
O Security Profile precisa ser aplicado a nível de dispositivos. Então BAT é o método mais adequado para aplicar Security Profile a um grande número de telefones.
Solução de problemas
Adicionando Security Profile a um cluster traz uma camada adicional que deve ser considerada ao planejar e executar tarefas administrativas. Itens como certificados e datas de expiração dos certificados devem ser levados em consideração. Certas operações administrativas, como mudar hostnames, podem requerer regeneração dos certificados e arquivos CTL.
Esta seção de solução de problemas complementa o guia oficial “Troubleshooting Guide” e fornecerá passos sobre como identificar o estado atual de um cluster e recomendará as ações corretivas necessárias.
Lista de Verificação e Reparação
1. Verifique todos os certificados em todos os servidores.
Colete serial numbers, Common Names e datas de vencimento dos certificados CAPF.pem e CallManager.pem atuais em todos os servidores. Os certificados carregados aos servidores são extremamente importantes. Qualquer incompatibilidade entre os certificados dos servidores pode causar falhas de download de LSC pelos telefones, falhas na autenticação de arquivos de configuração, ou falhas de registro de telefones.
Aqui está o certificado CAPF.pem. Observe a seqüência de caracteres facilmente identificáveis no campo “Common Name”. O CAPF.pem é usada para assinar LSC (Locally Significant Certificates) e para o SSL handshake entre o telefone e o processo CAPF.
Este CAPF.pem expira em 2016, e foi gerado em 05 de abril de 2011. Essas informações nos mostram que datas se atentar no futuro, bem como quais operações aconteceram no passado.
Isso se torna mais evidente quando o certificado CallManager.pem é mostrado. Observe que o certificado CallManager.pem também expira em 2016, mas foi gerado em 23 de agosto de 2011. Algumas operações de regeneração de certificado devem ter sido executadas no cluster em 23 de agosto. Lembre que este certificado é usado no SSL handshake entre telefones e CallManager, bem como pelo processo TFTP para assinar arquivos.
2. Verificar se conteúdo do arquivo CTL corresponde ao conteúdo dos certificados atuais.
Depois de verificar o conteúdo dos certificados, o próximo item é analizar o arquivo CTL em todos os servidores TFTP. O acesso via SSH fornece um comando simples chamado "show ctl". O cabeçalho do arquivo CTL contém a data que o arquivo CTL foi gerado, o CN (Common Name) do eToken USB usado para assinar o CTL, e o serial number do eToken.
Observe que o arquivo CTL foi gerado após a data de geração do certificado CallManager.pem. Isso é bom porque o arquivo CTL deve conter a versão mais recente do CallManager.pem. Se o arquivo CTL tivesse uma data que fosse antes da data de geração do CallManager.pem ou CAPF.pem, o CTL client precisaria ser executado novamente para pegar os últimos certificados.
admin:show ctl
Length of CTL file: 4712
The CTL File was last modified on Wed Aug 31 13:28:03 EDT 2011
Parse CTL File
----------------
Version: 1.2
HeaderLength: 304 (BYTES)
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
3 SIGNERID 2 117
4 SIGNERNAME 56 cn="SAST-ADN4e31f914 ";ou=IPCBU;o="Cisco Systems
5 SERIALNUMBER 10 BD:A3:02:00:00:00:D8:88:64:1F
6 CANAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems
A primeira entrada no arquivo CTL é o certificado completo do eToken. O eToken com um número de série "ADN4f31f914" foi o eToken usado para assinar o arquivo CTL. O número de série está impresso na embalagem do token e no token em si, de modo que o número de série no campo “Subject CN” (Common Name) pode ser útil para saber os tokens utilizados durante a assinatura.
CTL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1178
2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN4e31f914 ";ou=IPCBU;o="Cisco Systems
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems
6 SERIALNUMBER 10 BD:A3:02:00:00:00:D8:88:64:1F
7 PUBLICKEY 140
9 CERTIFICATE 894 67 EB 23 F8 F5 16 55 A9 8E C8 CB 8A 4F 9E A2 0A AB 45 B6 E6 (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
Multiplos tokens podem também ser incluídos dentro do arquivo CTL. Pelo menos 2 eTokens deve estar presente em um arquivo CTL. Um token será utilizado para assinatura e o outro token para backup. O telefone vai confiar em qualquer arquivo CTL assinado por qualquer desses dois tokens.
Este output mostra que o eToken seguinte não foi usado para assinar o arquivo CTL, é apenas o eToken backup. Para poder atualizar o arquivo CTL, pelo menos um dos tokens dentro do arquivo CTL atual deve ser utilizado.
CTL Record #:2
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1180
2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN5bbd7b14 ";ou=IPCBU;o="Cisco Systems
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems
6 SERIALNUMBER 10 AA:C9:20:00:00:00:78:C4:2E:22
7 PUBLICKEY 141
9 CERTIFICATE 895 A4 A3 8D 11 57 5A B8 E2 60 6E AF 4A 54 0A 20 B8 CA 0B D3 40 (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was not used to sign the CTL file.
O próximo registro após os eTokens é o certificado CallManager.pem (denotado pela função como CCM + TFTP). Este certificado é usado pelo CM para assinar arquivos de configuração e estabelecer conexões SSL entre telefones eo servidor CM se um Secure Profile é utilizado no telefone.
Observe que o número de série abaixo corresponde ao número de série do CallManager.pem, na página de OS Administration que vimos anteriormente. Se este número de série esta diferente nesses dois lugares, o CTL client precisará ser executado para sincronizar o arquivo CTL com o que CM está realmente usando no certificado.
CTL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1059
2 DNSNAME 12 14.48.44.80
3 SUBJECTNAME 63 CN=CUCM8-Publisher.bbbburns.lab;OU=AS;O=Cisco;L=RTP;ST=NC;C=US
4 FUNCTION 2 CCM+TFTP
5 ISSUERNAME 63 CN=CUCM8-Publisher.bbbburns.lab;OU=AS;O=Cisco;L=RTP;ST=NC;C=US
6 SERIALNUMBER 8 74:AE:9E:6B:DB:C2:A5:1D
7 PUBLICKEY 140
9 CERTIFICATE 738 00 7A DE F4 25 26 7A FC 5E 02 B4 D2 BB A4 14 42 2B A5 A0 9C (SHA1 Hash HEX)
10 IPADDRESS 4
A última entrada no arquivo CTL é o certificado CAPF. O número de série também deve coincidir com o do CAPF.pem, na página de OS Administration. Assim telefones estarão autorizados a se conectar ao serviço CAPF. Se houver uma incompatibilidade, o mesmo passo de executar novamente o CTL Client precisará ser realizado.
CTL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 991
2 DNSNAME 12 14.48.44.80
3 SUBJECTNAME 61 CN=CAPF-9c4cba7d;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 61 CN=CAPF-9c4cba7d;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 0A:DC:6E:77:42:91:4A:53
7 PUBLICKEY 140
9 CERTIFICATE 674 C7 3D EA 77 94 5E 06 14 D2 90 B1 A1 43 7B 69 84 1D 2D 85 2E (SHA1 Hash HEX)
10 IPADDRESS 4
The CTL file was verified successfully.
Após a conclusão desta etapa, o arquivo CTL vai estar em sincronia com os certificados que constam nos servidores.
3. Verifique se servidores disponibilizam um arquivo CTL via TFTP
O próximo item a verificar no processo de solução de problemas é se o servidor está fornecendo um arquivo CTL via TFTP ou não. Uma forma rápida é fazer uma captura de pacotes no telefone IP ou no servidor TFTP. Abaixo o telefone solicita o arquivo CTL como o primeiro arquivo que ele baixa durante o processo de boot.
O telefone solicitou um arquivo CTL, e se o filtro na captura anterior fosse removido, a transferência do arquivo poderia ser visto em detalhes.
Outro método para verificar se o arquivo CTL é baixado é analizar o Console Log na página web do telefone. Isso exige que "Web Access" em " CCMAdmin > Device > Phone > Product Specific Configuration" esteja "Enabled".
Aqui o Console Log mostra que o arquivo CTL foi baixado:
837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv 846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from 14.48.44.80 847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes
Além da captura de pacotes e Console Logs do telefone, os TFTP traces também mostram transferências de arquivos TFTP. Abaixo uma parte dos TFTP traces que mostram em tempo real o reinício dos telefones.
admin:file tail activelog cm/trace/ctftp/sdi recent
11:08:20.766 |TFTPEngine::isReadRequest[0x9950830~188~14.48.44.202~49530], [CTLSEP0011215A1AE3.tlv] opcode(1), Mode(octet), Serving Count(0)
11:08:20.779 |TID[a5a4fba0] TFTPEngine::processMessage[0x9950830~188~14.48.44.202~49530], Transferred[CTLFile.tlv] Socket[5]
4. Verifique se o telefone valida corretamente e aceita o arquivo CTL.
Após verificar que o servidor CUCM está apresentando um arquivo CTL válido, o próximo passo é o telefone validar esse arquivo CTL.
Console logs do telefone mostram que a assinatura do arquivo CTL foi confiável:
877: NOT 09:13:17.925249 SECD: validate_file_envelope: File sign verify SUCCESS; header length <296>
Status Messages exibidas no telefone também podem ser útil para verificar se um arquivo CTL foi baixado com êxito.
Em Status Messages da página web de um telefone ou no próprio telefone "Settings > Status > Status Messages", a seguinte linha significa que um arquivo CTL (ou arquivo ITL) foi baixado com sucesso e validado:
16:01:16 Trust List Updated
Se o telefone não conseguiu validar o novo arquivo CTL, a mensagem de erro seria
Trust List Update Failed
or
Trust List Verification Failed
Se o telefone falha na validação do arquivo CTL, significa que o CTL existente no telefone não tem os mesmos eTokens dentro dele que os utlizados para assinar o CTL, ou que o CTL estava corrompido.
Um CTL corrompido pode ser verificado com "show ctl", verificando a saída "The CTL File was verified successfully", ou a condição de erro "Verification of the CTL File Failed". Geralmente um arquivo CTL corrompido pode ser reparado executando o CTL client.
Se o arquivo CTL antigo do telefone contém apenas eTokens que não estão mais disponíveis, o arquivo CTL terá de ser excluído do telefone manualmente.
Neste ponto, o dilema é "Será que o telefone baixou o arquivo CTL mais recente?". Status Messages e Console logs do telefone podem ser utilizados para verificação, mas outros métodos também existem.
O método mais simples para verificar se um número de telefones têm o arquivo correto é comparar os tamanhos do arquivo CTL no telefone com o tamanho do arquivo no servidor TFTP.
Primeiro, crie um usuário e senha SSH para o telefone IP em CCMAdministration e habilite SSH no telefone. Reinicie o telefone.
Em seguida acesse o telefone via SSH com o usuário e senha configurados. Quando for solicitado o segundo login use "default/user". Neste exemplo, consta o 7961 e outros modelos similares. Utilize “debug guide for 89XX and 99XX model phones”.
Do telefone:
$ ls -l /tmp/*.tlv
-rw-r--r-- 1 default usr 4712 Oct 04 19:15 /tmp/CTLFile.tlv
-rw-r--r-- 1 default usr 3899 Oct 04 19:15 /tmp/ITLFile.tlv
Do servidor TFTP:
admin:file list tftp *.tlv detail
31 Aug,2011 13:28:03 4,712 CTLFile.tlv
16 Sep,2011 11:15:45 3,899 ITLFile.tlv
Para uma comparação exata do conteúdo, primeiro olhe para o telefone IP para ver o md5sum do CTL e ITL atuais.
Settings > Security Settings > Trust List
Em 8.6(2) e versões posteriores do CUCM, esse hash deve ser visível no servidor com "show ctl" e "show itl". Antes da 8.6(2), use TFTP e md5sum para verificar o hash deste arquivo tal como ele existe no servidor. Este exemplo verifica o hash do arquivo ITL. Basta substituir ITL por CTL e o exemplo vai funcionar para os dois arquivos.
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14.48.44.80 tftp> get ITLSEP0011215A1AE3.tlv Received 5438 bytes in 0.0 seconds tftp> quit jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum ITLSEP0011215A1AE3.tlv b61910bb01d8d3a1c1b36526cc9f2ddc ITLSEP0011215A1AE3.tlv
5. Verifique o conteúdo do CTL no telefone
Um atalho para verificar se o arquivo CTL no telefone corresponde exatamente byte a byte com o arquivo no servidor é apenas olhar na Trust List do telefone.
Settings > Security Settings > Trust List > CTL File
O nome do servidor CM / TFTP coincide com o nome do arquivo CallManager.pem deste servidor.
O CAPF <random string> também corresponde ao certificado CAPF.pem que está atualmente em uso.
6. Verifique a conexão SSL entre o telefone e o serviço CAPF se estiver usando LSC
Agora que o telefone tem um certificado CAPF (Certificate Authority Proxy Function) via o CTL, o telefone pode se conectar ao CAPF para baixar um certificado.
Uma captura de pacotes no servidor pode ser utilizada para verificar se o SSL handshake foi concluído. Aqui o filtro captura todo o tráfego originado do IP do telefone. Em seguida, o arquivo é enviado para outro servidor usando SFTP e o comando “file get”.
admin::utils network capture host ip 14.48.44.202 size ALL count 10000 file CAPF-Install
admin:file get activelog platform/cli/CAPF-Install.cap
A captura de pacotes mostra o SSL handshake que acontece na porta CAPF, TCP 3804. Para visualizar esta troca, clique com o botão direito em qualquer pacote do stream na porta TCP 3804 e vá em "Decode As".
Aqui, o certificado apresentado pelo servidor CAPF coincide com o certificado no CTL e o certificado que o telefone apresentou. Este SSL handshake teve sucesso porque começou a enviar "Application Data", o que seria a troca CAPF.
Posteriormente, o telefone tem um LSC instalado:
Se esse processo tivesse falhado apesar do SSL handshake ter ocorrido com sucesso, o próximo ponto para examinar seriam os CAPF traces. Se o SSL handshake tivesse falhado, seria hora de verificar o certificado CAPF e atualizar o arquivo CTL novamente com o CTL Client.
Os CAPF traces mostram que o telefone se conecta, gera uma chave (que leva algum tempo, como pode ser visto pela diferença de tempo nos traces), e depois o servidor CAPF gera um certificado para o telefone.
10:03:06.983 | debug 3:UNKNOWN:Got a new ph conn 14.48.44.202 on 15
10:03:08.060 | debug TLS HS Done for ph_conn .
10:03:08.065 | debug MsgType : CAPF_MSG_AUTH_REQ
10:03:08.341 | debug MsgType : CAPF_MSG_REQ_IN_PROGRESS
10:03:08.341 | debug 3:SEP0011215A1AE3:CAPF CORE: Rcvd Event: CAPF_EV_REQUEST_IN_PROGRESS in State: CAPF_STATE_AWAIT_KEY_GEN_RES
10:03:21.148 | debug 3:SEP0011215A1AE3:Incoming Phone Msg:
10:03:21.158 | debug MsgType : CAPF_MSG_KEY_GEN_RES
10:03:21.162 | debug Generated the cert
10:03:21.724 | debug 3:SEP0011215A1AE3:Certificate upgrade successful
7. Verifique a conexão SSL entre o telefone e o servidor para registo
Agora que o telefone tem um CTL e LSC, o próximo passo é o registro do telefone no CCM de forma segura. Para telefones SCCP isso acontece na porta TCP 2443.
Use os mesmos passos de antes para capturar todos os pacotes desse telefone em específico.
A primeira coisa que é diferente é o telefone fazendo download de SEP<MAC Address>.cnf.xml.enc.sgn. Isso significa que o arquivo de configuração foi criptografado conforme estabelecido no Device Security Profile.
Aqui, o telefone se conecta na porta TCP 2443. Assim esta porta deve ser decodificado como SSL no Wireshark. O CUCM apresenta o certificado CallManager.pem (verificável pelo número de série e common name) e depois pede o certificado do telefone. Como antes o SSL handshake foi concluído com êxito já que a fase Application Data é iniciada.
Além da captura de pacotes, o registo do telefone via Secure SCCP também é visível no Cisco CallManager SDI trace:
10:38:26.621 |SdlSSLTCPListener::verify_cb pre-verified=1,cert verification errno=0,depth=0
10:38:26.626 |New connection accepted. DeviceName=, TCPPid = [1.100.13.7], IPAddr=14.48.44.202, Port=51948,
10:38:29.051 |StationD: (0000048) ClusterSecurityMode = (1) DeviceSecurityMode = (3)
10:38:29.051 |StationD: (0000048) TLS Connection Cipher - INFO:deviceName=SEP0011215A1AE3, Cipher=AES128-SHA, Security Mode=3
8. Verifique as chamadas criptografadas
As chamadas que possuem tanto criptografia de sinalização como de mídia mostrarão o ícone de um cadeado no canto inferior direito da janela da chamada. Isto corresponde a Device Security Mode: Encrypted.
As chamadas que possuem criptografia de sinalização entre ambas as extremidades, mas que não possuem criptografia de mídia mostrarão o ícone de um escudo. Isso corresponde a Device Security Mode: Authenticated.
O estado de segurança do lado menos seguro é utilizado para determinar qual ícone será mostrado e qual modo de segurança será usado. Dê uma olhada nos exemplos da tabela abaixo:
Phone A
Phone BIcon Displayed
| Encrypted | Encrypted | Lock - Encrypted Audio |
| Encrypted | Authenticated | Shield - Unencrypted Audio |
| Encrypted | None | None - Unencrypted Audio |
