Resumo
- A RFC 9887 exige negociação TLS imediatamente após o estabelecimento do TCP, com TLS 1.3 como versão mínima. O TACACS+ só é enviado como dado de aplicação TLS. Servidores TLS MUST NOT aceitar conexões sem TLS, e clientes não fazem fallback quando o TLS falha.
- A linha de base é autenticação mútua por certificados: cada lado valida o caminho do certificado remoto e verifica revogação. PSK e chave pública bruta são alternativas opcionais; o PSK do TLS deve ser diferente do segredo usado na ofuscação TACACS+ legada.
- A operação TLS torna obsoleta a ofuscação legada do TACACS+ e exige o sinalizador de não criptografado, porque o TLS fornece confidencialidade e integridade. 0-RTT é proibido. Tickets de retomada são de uso único, e a revogação deve ser verificada novamente na retomada.
- A IANA atribuiu a porta TCP 300 e o nome de serviço
tacacss. Portas alternativas continuam possíveis, mas exigem consideração operacional explícita. A RFC considera insegura a fase que mistura TLS e não TLS até sua conclusão, recomenda que ela seja minimizada e diz que servidores sem TLS SHOULD ser configurados separadamente; a implantação no mesmo host não é recomendada.
A proibição de fallback descreve o comportamento do protocolo; ela não conclui automaticamente a coordenação da migração. Se os dispositivos não puderem mudar juntos, servidores antigos podem permanecer temporariamente. O risco está na coexistência de dois caminhos, em destinos configurados de modo incorreto e na acessibilidade legada, não apenas no sucesso do novo handshake. A RFC 9887 não informa cobertura de implementações de fornecedores, adoção da porta 300 em produção, duração observada da migração ou incidentes de downgrade.
Também não mede disponibilidade de autoridades certificadoras, latência de verificação de revogação ou efeitos de desempenho da retomada TLS.
Na análise de Theo March, inventário de dispositivos, responsável pelo cutover, prazo para exceções, retirada de regras de firewall, eliminação de segredos legados e evidência de conclusão tornam a mudança auditável. Essas são recomendações operacionais, não obrigações adicionais da RFC. A norma define o transporte, a autenticação, a proibição de fallback, as regras de retomada e a condição insegura da coexistência.
Fixtures de verificação. Monte um cliente compatível com TLS, um servidor que aceite somente TLS, um servidor antigo sem TLS claramente identificado e registros observáveis de conexões na porta TCP 300. Teste um handshake mútuo válido; revogue um certificado e confirme que uma nova conexão e uma retomada o rejeitam; envie bytes iniciais sem TLS ao servidor TLS e confirme que eles não são aceitos como solicitação TACACS+; provoque uma falha TLS e confirme que o cliente não tenta o caminho antigo. No tráfego capturado, verifique a ausência de dados de aplicação em 0-RTT e confirme que um ticket de retomada não pode ser reutilizado. Compare a configuração para provar que o PSK TLS e o segredo legado são distintos. Isso é um desenho de teste concreto, não uma afirmação sobre algum produto ou implantação existente.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
