Resumo

  • Em um handshake completo, o False Start deixava o cliente usar as novas chaves após seu Finished enquanto o Finished do servidor ainda voltava.
  • O handshake comum continuava obrigatório; liberar antes exigia pedido da aplicação, listas criptográficas estreitas, protocolo já escolhido e tratamento explícito da falha posterior.

O primeiro registro ultrapassou a última prova

No fluxo do RFC 5246, o cliente processa certificado e troca de chaves do servidor, envia ChangeCipherSpec e Finished e espera os equivalentes do servidor. Só depois de verificar o Finished remoto entrega dados da aplicação.

O False Start colocou o primeiro registro dentro dessa espera. O cliente já tinha as chaves novas e enviara sua prova. O registro criptografado seguia para o servidor enquanto a confirmação final voltava no sentido oposto.

O RFC 7918 chama o sucesso de validação retroativa. Se o Finished servidor chega correto, o handshake final é o mesmo esperado; mudou o relógio. A ida e volta não foi eliminada: seu tempo foi usado antes de conhecer o resultado.

Cifra pronta, confirmação pendente

O cliente já viu ServerHello, suite, certificado e parâmetros de troca. O registro usa o novo Cipher Spec. Não é texto aberto nem pedido disparado com ClientHello.

Falta o Finished servidor, que confirma segredos e transcript comuns. Se não chega ou falha, o handshake nunca é validado. No fluxo normal, nenhum dado teria saído; com False Start, saiu.

A pergunta passou a ser quais dados podem cruzar enquanto resta uma prova final, não apenas se há criptografia.

Uma escolha do cliente, não uma autorização nova do servidor

O False Start não criou extensão pela qual o servidor concedia permissão. Era comportamento opcional do cliente. Servidor compatível apenas tolerava records protegidos antes do ponto normal da máquina de estados.

Perfil de aplicação ou conhecimento externo podia estabelecer compatibilidade; silêncio não equivalia a consentimento. Reset de middlebox ou servidor mostrava expectativa de ordem, não fraqueza da chave.

A aplicação precisava pedir o recurso. Só ela sabia se a primeira mensagem era leitura sem efeito, credencial ou comando irreversível. A biblioteca fornecia oportunidade; a aplicação respondia pelo significado.

Whitelists cercavam o atalho

O RFC 7918 restringe versão, cifra simétrica, troca de chaves, parâmetros e tipo de certificado cliente. Recomenda famílias efêmeras DHE/ECDHE com sigilo futuro. Na dúvida, não usar False Start.

As cercas impediam que downgrade liberasse dados sob combinação fraca. Também criavam obrigação contínua: update, fallback e default novo podiam ampliar elegibilidade. A lista precisava ser versionada e revisada, não herdada cegamente da biblioteca.

O fato de TLS terminar com sucesso não prova que o envio antecipado foi autorizado sob aquela combinação exata.

O protocolo precisava estar escolhido

O RFC 7301 coloca ALPN nos hellos: o cliente propõe em ClientHello e o servidor escolhe em ServerHello. Antes de falar cedo, o cliente sabe qual gramática interpretará seus bytes.

ALPN não autoriza False Start. Ele fecha uma ambiguidade. Opt-in da aplicação, protocolo escolhido e whitelist precisam apontar para o mesmo perfil. Criptografia forte não corrige bytes entregues ao protocolo errado.

Falhar não chama o registro de volta

Finished válido permite continuar; ausente ou incorreto obriga falha de autenticação. O cliente não deve tratá-la como timeout comum nem repetir automaticamente uma ação perigosa.

Encerrar evita novos usos, mas não recolhe o que já atingiu o peer ou endpoint ativo. Essa irreversibilidade separa confidencialidade do caminho de autorização para revelar naquele instante.

False Start não era 0-RTT

O RFC 8446 trouxe TLS 1.3 e seu 0-RTT diferente. Na retomada, dados podem sair após ClientHello sob chave derivada de PSK anterior; não têm sigilo futuro nem garantia contra replay entre conexões.

False Start ocorre em handshake completo, com chave fresca e depois do Finished cliente. O que falta é o Finished servidor, não proteção contra replay de dados PSK.

O RFC 8470 criou Early-Data e 425 Too Early para HTTP 0-RTT. Não são mecanismos de False Start. O RFC 9325 exige especificação de aplicação para 0-RTT e controles de ALPN e uniformidade. A disciplina é comum; os riscos não.

Fontes e limites

As fontes são RFC 5246, RFC 7301, RFC 7918, RFC 8446, RFC 8470 e RFC 9325. Não medem adoção atual. False Start não enviava texto aberto, não pulava certificado, não retomava sessão e não exigia extensão específica do servidor.