Guia de configuração de TLS e SRTP no SBC: protegendo sinalização SIP e mídia de voz

A sinalização SIP trafega em texto aberto por padrão. O áudio também. Sem criptografia, qualquer pessoa com acesso ao caminho de rede entre dois terminais pode capturar mensagens SIP, extrair metadados de chamada e reconstruir conversações de voz inteiras a partir de pacotes RTP capturados.
TLS e SRTP resolvem esses problemas, mas protegem coisas diferentes. TLS criptografa o canal de sinalização (as mensagens SIP que estabelecem, modificam e encerram chamadas). SRTP criptografa o canal de mídia (os pacotes de voz propriamente ditos). Um Controlador de Borda de Sessão (SBC) é o elemento de rede que aplica ambos na borda da rede de voz.
Este guia cobre as etapas práticas para configurar TLS e SRTP em um SBC: como os dois protocolos dependem um do outro, onde as fronteiras de criptografia pertencem na arquitetura da sua rede, como lidar com ambientes mistos com equipamentos legados e como solucionar os problemas de implantação mais comuns.

Por que SRTP deve ser implantado junto com TLS

É tentador tratar TLS e SRTP como apenas complementares. Não são. A segurança de um depende do outro, e implantar SRTP sem TLS cria uma falsa sensação de segurança.
Eis o motivo. O mecanismo de troca de chaves SRTP mais comum, SDP Security Descriptions (SDES, definido no RFC 4568), embute as chaves de criptografia diretamente no corpo SDP das mensagens SIP. Quando um terminal envia um SIP INVITE para estabelecer uma sessão de mídia criptografada, a oferta SDP inclui um atributo crypto contendo a chave SRTP em codificação base64.
Se esse SIP INVITE trafegar por UDP ou TCP não criptografados, as chaves SRTP ficam visíveis para qualquer pessoa que consiga capturar o tráfego de sinalização. Um atacante que intercepte a troca SIP pode extrair as chaves e descriptografar todos os pacotes SRTP da sessão. A criptografia de voz se torna inútil.
TLS previne isso criptografando a mensagem SIP inteira, incluindo o corpo SDP e seus atributos crypto. Com TLS ativo, um atacante que capture tráfego no caminho de sinalização vê apenas a sessão TLS criptografada, não o conteúdo SIP ou as chaves SRTP dentro dela.
A regra de implantação é simples: nunca implante SRTP sobre sinalização SIP não criptografada em ambiente de produção. O SBC é o lugar certo para aplicar essa regra, porque ele termina e reorigina tanto a sinalização quanto a mídia na borda da rede.

Arquitetura: onde a criptografia se posiciona na sua rede

Um ProSBC operando como Agente de Usuário Back-to-Back (B2BUA) termina sessões SIP em cada lado de forma independente. Essa arquitetura é fundamental para criptografia porque significa que o SBC gerencia dois contextos de segurança completamente separados: um para cada perna da chamada.
Na perna externa (voltada para um provedor de SIP Trunk ou operadora), o SBC pode aplicar TLS e SRTP. Na perna interna (voltada para o IP-PBX, central de atendimento ou terminal), o SBC pode usar qualquer transporte que o equipamento interno suporte. As duas pernas são independentes, cada uma com sua própria política de criptografia.
Isso cria três padrões práticos de implantação.

Padrão 1: criptografia ponta a ponta

Ambos os lados do SBC suportam TLS e SRTP. O SBC pode operar em modo SRTP relay, passando a mídia criptografada sem descriptografá-la. Isso preserva a criptografia ponta a ponta e reduz a carga de processamento do SBC. A sinalização em ambas as pernas é feita via TLS.
Esse padrão é ideal quando tanto a infraestrutura interna quanto os peers externos suportam criptografia moderna. Oferece a postura de segurança mais forte.

Padrão 2: ponte de criptografia

Um lado suporta TLS e SRTP. O outro não. Este é o cenário de implantação mais comum no mundo real, onde o ProSBC está protegendo o sistema de telefonia existente.
Seu provedor de SIP Trunk ou Microsoft Teams exige TLS e SRTP. Seu IP-PBX legado suporta apenas UDP e RTP. O SBC fica entre eles, aceitando SIP/RTP não criptografados do PBX e convertendo para TLS/SRTP em direção ao peer externo. Nenhuma substituição completa do PBX é necessária.
O SBC realiza a conversão RTP-para-SRTP no caminho de mídia e a terminação/originação TLS no caminho de sinalização. A rede interna permanece sem criptografia (e deve ser protegida por outros controles de segurança de rede), enquanto todo o tráfego que cruza a internet pública é totalmente criptografado.

Padrão 3: políticas de criptografia por tronco

Redes reais não são uniformes. Você pode ter algumas conexões de operadora que exigem TLS e SRTP, outras que suportam apenas TLS sem SRTP, e troncos internos onde a criptografia é desnecessária.
Um SBC configurado corretamente permite definir a política de criptografia por grupo de troncos (chamado de Network Access Point, ou NAP, na terminologia do ProSBC). Cada tronco especifica independentemente se TLS é obrigatório, preferencial ou desabilitado, e se SRTP é obrigatório, preferencial ou desabilitado.
Essa granularidade é essencial. Uma política de criptografia global obriga você a criptografar tudo (quebrando conexões legadas) ou não criptografar nada (deixando conexões externas expostas). Políticas por tronco permitem aplicar criptografia exatamente onde necessário.

Configurando TLS: protegendo a sinalização SIP

A configuração de TLS em um SBC envolve quatro etapas: gerenciamento de certificados, configuração do listener, atribuição de política por tronco e TLS mútuo opcional.

Etapa 1: gerenciamento de certificados

Toda conexão TLS requer que o SBC apresente um certificado X.509 válido aos seus peers. O ProSBC define uma configuração padrão para este parâmetro. O certificado deve atender a estes requisitos:
O Common Name (CN) ou Subject Alternative Name (SAN) do certificado deve corresponder ao Fully Qualified Domain Name (FQDN) que peers externos usam para alcançar o SBC. Se o endereço de sinalização do seu SBC é sbc.example.com, o certificado deve ser emitido para esse domínio.
O certificado deve ser emitido por uma Autoridade Certificadora (CA) confiável pelos seus peers. Para SIP trunking em geral, certificados de CAs públicas como DigiCert, Sectigo ou Let’s Encrypt funcionam. No entanto, alguns provedores de serviço podem ter requisitos mais rigorosos nesse sentido, como o Microsoft Teams Direct Routing: o certificado deve ser emitido por uma das CAs na lista publicada de raízes confiáveis da Microsoft.
Instale tanto o certificado público do SBC quanto sua chave privada (como certificado local) e a cadeia completa da CA (como certificados confiáveis) no SBC. Veja os conjuntos de cifras TLS e SRTP suportados na documentação do ProSBC. Certificados intermediários ausentes na cadeia de certificados são uma das causas mais comuns de falhas no handshake TLS.
Estabeleça um processo de “auditoria de certificados”. Um certificado TLS que expire sem renovação causará falhas imediatas de chamada em todos os troncos que o utilizam. Realize auditorias/monitoramento regulares para garantir que nenhum certificado esteja expirado.

Etapa 2: habilitar escuta TLS

Configure o SBC para escutar conexões TLS na interface de sinalização. As configurações principais incluem:
Porta de escuta. A porta TLS padrão para SIP é 5061, mas é totalmente configurável. Se você precisa usar uma porta diferente por razões operacionais ou de segurança, configure conforme necessário. O importante é que seus peers saibam a qual porta se conectar.
Versão mínima de TLS. Se o seu SBC suporta versões antigas de TLS, desabilite TLS 1.0 e TLS 1.1, que possuem vulnerabilidades conhecidas. Defina TLS 1.2 como mínimo. TLS 1.3 é preferido quando ambos os lados o suportam, pois oferece segurança aprimorada e um handshake mais rápido (uma viagem de ida e volta em vez de duas). O ProSBC permite apenas TLS 1.2 quando TLS 1.3 não é utilizado.

Etapa 3: definir políticas de TLS

Defina a política de TLS para todos os grupos de troncos com base nos requisitos dos peers. Por exemplo: TLS (1.3 por padrão, ou 1.2), TCP ou UDP.

Etapa 4: TLS mútuo (mTLS)

O TLS padrão é unidirecional: o SBC apresenta seu certificado ao peer, e o peer o valida. O peer não prova sua identidade ao SBC (nota: o SBC é o cliente e o peer é o servidor neste exemplo).
O TLS mútuo adiciona uma segunda etapa de validação. O SBC também solicita e valida o certificado do peer. Isso impede que dispositivos não autorizados estabeleçam conexões SIP com o SBC, mesmo que conheçam o endereço IP e a porta corretos.
mTLS é obrigatório para Microsoft Teams Direct Routing e recomendado para interconexões com operadoras e qualquer ambiente com requisitos de conformidade regulatória. Para configurar mTLS, instale os certificados CA confiáveis (ou certificados específicos dos peers) no trust store do SBC e configure o tronco para exigir autenticação do peer.

Configurando SRTP: criptografando a mídia de voz

Com TLS protegendo o canal de sinalização, você pode configurar SRTP para criptografia de mídia com segurança. A configuração de SRTP envolve três decisões: método de troca de chaves, criptografia RTP-para-SRTP e comportamento de SRTP relay.

Etapa 1: método de troca de chaves

Dois mecanismos de troca de chaves são usados na prática:
SDES (SDP Security Descriptions, RFC 4568) é o método mais amplamente suportado. As chaves SRTP são trocadas no atributo crypto da oferta ou resposta SDP dentro da sinalização SIP. SDES é simples de configurar e compatível com a maioria dos terminais SIP e provedores de trunking. O requisito fundamental: a sinalização SIP deve trafegar sobre TLS ao usar SDES, porque as chaves são embutidas no corpo SDP em texto aberto.
DTLS-SRTP troca chaves por meio de um handshake DTLS separado no caminho de mídia, independente da sinalização SIP. É obrigatório para aplicações WebRTC, mais complexo de configurar e não depende da sinalização SIP para troca de chaves. DTLS-SRTP é usado principalmente para aplicações de voz e vídeo baseadas em navegador.
(Nota: existem tecnicamente outros métodos de troca chamados ZRTP e MIKEY, mas não são comumente usados na prática).
Para a maioria das implantações de SBC envolvendo SIP trunking, peering com operadoras e plataformas de comunicações unificadas, SDES sobre sinalização protegida por TLS é a abordagem padrão.

Etapa 2: conversão RTP-para-SRTP

Esta é uma das capacidades mais valiosas de um SBC em um ambiente de criptografia mista. Quando um lado da chamada suporta SRTP e o outro não, o SBC converte entre os dois:
O SBC recebe mídia RTP não criptografada do terminal legado. Ele criptografa a mídia como SRTP e a encaminha ao peer com capacidade de criptografia. Na direção reversa, descriptografa SRTP de entrada e envia RTP ao terminal legado.
Essa conversão acontece de forma transparente. Nenhum dos terminais sabe que o outro lado usa um transporte de mídia diferente. O SBC gerencia todo o gerenciamento de chaves, criptografia e descriptografia.
Casos de uso comuns para conversão RTP-para-SRTP incluem conectar um IP-PBX legado (somente RTP) a um provedor de SIP Trunk que exige SRTP, fazer a ponte entre uma plataforma de central de atendimento antiga e Microsoft Teams, e suportar usuários remotos em conexões criptografadas enquanto o PBX da matriz opera sem criptografia internamente.

Etapa 3: SRTP relay

Quando ambos os terminais suportam SRTP, o SBC pode operar em modo relay. Ele passa a mídia criptografada sem descriptografá-la e recriptografá-la. Isso preserva a criptografia ponta a ponta da mídia e reduz a carga de processamento do SBC.
SRTP relay é adequado quando ambos os peers negociam método de troca de chaves e conjuntos de cifras compatíveis, e o SBC não precisa inspecionar ou modificar a mídia (sem transcodificação, sem gravação, sem manipulação de mídia necessária naquela chamada).

Cenários de implantação

Microsoft Teams Direct Routing

Teams Direct Routing possui requisitos específicos de criptografia. O SBC deve suportar TLS (TLS mútuo com as raízes CA publicadas pela Microsoft), e toda a mídia deve usar SRTP. O SBC fica entre a infraestrutura do Teams e sua conectividade PSTN, gerenciando TLS/SRTP em direção ao Teams e qualquer transporte que seu provedor de SIP Trunk suporte no outro lado.
Pontos-chave de configuração: instale um certificado de uma CA aprovada pela Microsoft, configure mTLS no tronco voltado para o Teams, defina SRTP como obrigatório e habilite a conversão RTP-para-SRTP se o seu provedor de SIP Trunk não suportar SRTP.

Peering com provedores de SIP Trunk

Grandes provedores de SIP Trunk (Bandwidth, Telnyx, Twilio, entre outros) agora suportam TLS e SRTP. Habilite TLS no tronco voltado para a operadora e defina SRTP como obrigatório ou preferencial conforme a documentação do provedor. Alguns provedores suportam mTLS; verifique seus guias de configuração.

Integração com PBX legado

Muitas organizações operam IP-PBXs que foram implantados antes de TLS e SRTP se tornarem padrão. Esses sistemas suportam apenas UDP/TCP para sinalização e RTP para mídia. O SBC gerencia a conversão de criptografia sem exigir alterações no PBX.
Configure o tronco voltado para o PBX com TLS desabilitado e SRTP desabilitado. Configure o tronco voltado para o exterior com TLS obrigatório e SRTP obrigatório. O SBC faz a ponte entre os dois domínios de criptografia.

Usuários remotos e em home office

Telefones SIP e softphones conectando pela internet pública devem sempre usar TLS e SRTP. Sem criptografia, um usuário em uma rede Wi-Fi de cafeteria está transmitindo chamadas de voz em texto aberto por uma rede compartilhada.
Configure o tronco do lado de acesso para exigir TLS e SRTP. Isso protege tanto os metadados de sinalização quanto o conteúdo de voz contra interceptação em redes não confiáveis.

Solução de problemas comuns de TLS e SRTP

Falhas no handshake TLS

Certificado expirado é o problema de TLS mais comum. O certificado do SBC expirou e os peers rejeitam a conexão. Verifique as datas de expiração dos certificados e renove antes do vencimento.
CA não confiável ocorre quando o peer não confia na CA que emitiu seu certificado. Instale sua cadeia de certificados (incluindo intermediários) e verifique se o trust store do peer inclui sua CA. Para Teams Direct Routing, confirme que sua CA está na lista aprovada da Microsoft.
Incompatibilidade de FQDN acontece quando o CN ou SAN do certificado não corresponde ao hostname que o peer usa para se conectar. O certificado deve corresponder ao FQDN nos cabeçalhos SIP, não apenas ao endereço IP.
Incompatibilidade de versão TLS ocorre quando seu SBC exige TLS 1.2 mas o peer suporta apenas TLS 1.0, ou o inverso. Verifique as configurações de versão mínima de TLS em ambos os lados.

Falhas na negociação SRTP

Incompatibilidade de conjuntos de cifras acontece quando o SBC oferece um único método de troca de chaves, mas o peer suporta apenas um conjunto diferente. Revise a configuração de conjuntos de cifras em ambos os lados.
Atributo crypto ausente ocorre quando o terminal remoto não inclui um atributo crypto no SDP. Ele pode não suportar SRTP, ou SRTP pode não estar habilitado no lado dele. Se o tronco estiver configurado com SRTP obrigatório, a chamada falhará.
SRTP oferecido mas rejeitado acontece quando o peer inclui atributos crypto na oferta, mas a resposta do SBC os remove, ou vice-versa. Verifique se SRTP está habilitado no tronco correto e se o modo de aplicação não está definido como desabilitado.

Áudio unidirecional após habilitar SRTP

Isso pode ser causado por diversos fatores, incluindo um problema de interoperabilidade com implementações SRTP, uma questão de negociação SRTP via SIP/SDP, ou pode ser um simples problema de rede. Quando SRTP é habilitado, a mídia pode usar portas diferentes ou características de transporte diferentes. Verifique se os firewalls entre o SBC e os terminais permitem as portas de mídia SRTP. Confirme que a configuração NAT não está reescrevendo cabeçalhos de pacotes SRTP. Use captura de pacotes para confirmar que a mídia está fluindo em ambas as direções.

Interrupções na renovação de certificados

Substituir um certificado em um SBC de produção pode causar breves interrupções de serviço se não for feito com cuidado. Melhor prática: carregue o novo certificado junto com o existente, verifique se os handshakes TLS funcionam com o novo certificado em um ambiente de teste e depois mude o SBC de produção para o novo certificado durante uma janela de manutenção.

Ferramentas de diagnóstico

Capturas de trace SIP (mostrando o conteúdo completo da mensagem SIP, incluindo atributos crypto do SDP) e captura de pacotes ao vivo (equivalente ao Wireshark no próprio SBC) são as ferramentas primárias. A documentação cobre a solução de problemas de TLS e áudio passo a passo. Use traces SIP para verificar se as sessões TLS estão estabelecidas, se o SDP inclui atributos crypto e se SRTP foi negociado com sucesso na resposta SDP.

Lista de boas práticas

Seguir estas práticas ajudará a garantir que sua implantação de TLS e SRTP seja segura, manutenível e resiliente.

1. Implante TLS antes de SRTP.Proteja o canal de sinalização primeiro para proteger a troca de chaves SRTP.
2. Use TLS 1.2 ou superior.Desabilite TLS 1.0 e 1.1 em todos os troncos.
3. Aplique criptografia em todos os troncos voltados para o exterior.Todo tráfego que cruza a internet pública deve usar TLS e SRTP.
4. Configure políticas por tronco.Troncos diferentes possuem requisitos diferentes.
5. Configure lembretes para verificar expiração de certificados.Alertas de 30 dias e 7 dias.
6. Use mTLS para peering com operadoras.TLS unidirecional não é suficiente para conexões de alta segurança.
7. Habilite conversão RTP-para-SRTP para integração com legados.Não deixe terminais legados como desculpa para pular SRTP em troncos externos.
8. Teste com capturas de pacotes.Após habilitar a criptografia, verifique com uma captura que a sinalização está criptografada por TLS e que os payloads de mídia aparecem como SRTP criptografado.
9. Documente a política de criptografia por tronco.Mantenha uma matriz de quais troncos usam TLS, SRTP, mTLS e qual método de troca de chaves. Essa documentação é essencial para auditorias de conformidade.
10. Revise os conjuntos de cifras regularmente.Padrões criptográficos evoluem. Mantenha sua pilha atualizada, leia as notas de versão e deprecie algoritmos fracos conforme as orientações mudem.

O que procurar em um SBC para criptografia

Nem todos os SBCs lidam com criptografia da mesma forma. Se você está avaliando um SBC para uma implantação que requer TLS e SRTP, procure estas capacidades:

Políticas de TLS e SRTP por tronco

O SBC deve permitir configurar criptografia de forma independente em cada grupo de troncos. Configurações exclusivamente globais não funcionam em redes reais com requisitos mistos.

Conversão RTP-para-SRTP

Sem essa capacidade, você não consegue criptografar mídia para terminais legados. Essa única capacidade frequentemente determina se uma migração para voz criptografada é possível sem substituir a infraestrutura existente.

SRTP relay

Para cenários de criptografia ponta a ponta, o SBC deve conseguir passar a mídia criptografada sem descriptografá-la.

Arquitetura B2BUA

Terminação SIP completa e reoriginação em cada perna habilita contextos de criptografia independentes. SBCs baseados em SIP proxy não conseguem fornecer o mesmo nível de controle de criptografia.

Configurações de TLS configuráveis

Portas, conjuntos de cifras, versões de TLS e gerenciamento de certificados devem ser todos configuráveis, não codificados em modo fixo.

Ferramentas de diagnóstico integradas

Captura de pacotes ao vivo e capacidades de trace SIP no próprio SBC são essenciais para solucionar problemas de criptografia sem implantar infraestrutura de monitoramento externa.

Perguntas frequentes