Resumo

  • Na RIPE 93, Muhammad Usama Sardar questionou a atestação feita dentro do aperto de mãos TLS. Um teste relatado pela Cocos AI aceitou, no caminho Intel TDX, prova com valor de sessão reutilizado ou divergente e liberou dados da aplicação após o handshake.
  • Outro aviso da Cocos descreve o caminho AMD SEV-SNP quando o valor esperado não é enviado. A versão 0.9.0 migrou para atestação após o handshake; a carta do grupo IETF SEAT exige frescor por conexão e análise formal.

O crachá brilhava. Faltou conferir de quem era o paletó. No aviso original da Cocos AI sobre Intel TDX, o verificador recebia o valor que deveria identificar a sessão TLS atual, mas o caminho testado não o incorporava à política usada para validar a prova do hardware. No ensaio do fornecedor, um relatório externo com reportData divergente ou reaproveitado foi aceito. Bytes da aplicação saíram depois do handshake.

Muhammad Usama Sardar levou a crítica à sessão de Segurança da RIPE 93 em 27 de outubro. Sua pergunta é desconfortável para quem desenha o protocolo: vale embutir mais uma etapa no aperto de mãos se o desenho abre espaço para esquecer a comparação que liga a prova à conexão? O aviso do fabricante mostra onde esse esquecimento virou uma decisão de acesso.

O segundo aviso da Cocos AI trata do caminho AMD SEV-SNP. Na versão 0.8.2, a política de verificação recebia o ReportData esperado apenas se o chamador fornecesse um valor não vazio. Sem ele, uma prova alheia à conexão podia ser aceita. Com valor não vazio, divergências eram rejeitadas. A Cocos informa que a 0.9.0 adotou atestação após o handshake.

Há ainda outro tipo de troca de identidade. A Edgeless Systems descreveu no Contrast uma situação em que um relatório válido de outra máquina podia ser aceito, sob as condições de interceptação e falsificação de relatório ou extração de segredos indicadas no aviso. A versão 1.16.0 introduziu listas de IDs de hardware autorizados. Prova válida, máquina correta e sessão presente são perguntas diferentes.

A carta do grupo IETF SEAT manda vincular a prova à conexão TLS, permitir frescor por conexão e testar formalmente o trabalho enquanto a especificação avança. O enunciado vira teste de bancada: enviar prova velha, omitir o valor esperado, trocar a máquina e verificar se os dados continuam trancados. O carimbo só tem valor quando a fechadura reconhece o visitante de agora.