APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O handshake precisa de parâmetros compatíveis entre cliente e servidor. TLS 1.0 e 1.1 foram descontinuados; uma dependência antiga exige inventário e migração controlada, não reativação global como solução duradoura. Em TLS 1.3, a cipher suite define AEAD e hash, enquanto grupos e algoritmos de assinatura são negociados separadamente. Não assumes que alterar uma lista de suites resolve toda a incompatibilidade. ALPN permite negociar o protocolo de aplicação, como HTTP/2, e deve ser observado quando TLS funciona mas os extremos discordam sobre o que falar depois. Esta aula cobre aplicações com certificados e conceitos selecionados, sem afirmar que todos os modos TLS exigem a mesma troca de certificados.
Aplicação guiada
mTLS pode autenticar o cliente, mas a aplicação ainda precisa de associar essa identidade a permissões. Num caso fictício, renovar o certificado altera o identificador usado pelo mapeamento; o handshake é válido e a operação é negada. Correlaciona a identidade e os logs de autorização antes de alargar acessos. Outro trade-off é 0-RTT: dados antecipados têm risco de replay entre ligações e não devem ser tratados como se tivessem todas as garantias dos dados normais. Analisa efeitos de repetição e proteções da aplicação antes de ativar operações com efeitos financeiros. Um ganho de latência não substitui os requisitos de integridade da operação.
Handshake mTLS válido e acesso funcional negado podem coexistir sem contradição.
Armadilhas comuns
Suite como todos os parâmetros; certificado renovado como upgrade TLS; CA confiável como papel universal; 0-RTT como replay impossível.
Tópicos relacionados: Chaves, certificados e confiança · Identidade, nome e tempo · Renovação e certificado servido
Verifica negociação, autenticação e autorização como etapas com evidência própria.
Referência: TLS 1.3 selected handshake and replay semantics · DR TLS/certificates 2026-09; selected TLS 1.2/1.3, RFC 9525 identity and OpenSSL 3.5 diagnostics