Por que SSL foi renomeado para TLS no fim dos anos 90

• Em meio à guerra dos navegadores de meados dos anos 1990, cresceu a possibilidade de uma divisão entre o SSL da Netscape e o PCT da Microsoft, e o setor tentou reuni-los em um único padrão aberto
• As primeiras versões do SSL não chegaram a ser lançadas por causa de falhas; mesmo a primeira versão usada na prática, o SSL 2, foi usada por alguns anos, mas tinha limitações criptográficas e práticas
• O PCT da Microsoft era uma extensão própria baseada no SSL 2 e adaptada ao IE e ao IIS, enquanto a Netscape respondeu com o SSL 3.0 para não perder a liderança sobre o padrão
• Netscape e Microsoft concordaram com o processo de padronização aberto da IETF, mas era preciso evitar que parecesse que a IETF estava simplesmente ratificando o protocolo da Netscape
• No fim, o SSL 3.0 recebeu algumas alterações e também mudou de nome; o TLS 1.0 começou, na prática, em uma forma próxima ao SSL 3.1

---

SSL e PCT durante a guerra dos navegadores

• A concorrência entre Netscape e Microsoft nos navegadores em meados dos anos 1990 também afetou a padronização dos protocolos de segurança
• A Netscape desenvolveu o protocolo SSL
  • A versão inicial foi rapidamente quebrada devido a falhas criptográficas e não foi lançada
  • A primeira versão de produção foi o SSL 2, usada por alguns anos
  • O SSL 2 tinha falhas criptográficas e práticas, mas não era uma crise tão dramática a ponto de exigir substituição imediata
• A Microsoft modificou o SSL 2 e adicionou extensões próprias para definir o PCT
  • O PCT era um protocolo derivado do SSL 2
  • Seu suporte era limitado ao IE e ao IIS
• A Netscape também tentou corrigir os problemas do SSL 2, mas não queria que a Microsoft assumisse a liderança ou a propriedade do padrão
  • O resultado foi o desenvolvimento do SSL 3.0, com mudanças maiores

Padronização pela IETF e o nome TLS

• Diversas pessoas do setor e da comunidade tentaram evitar uma situação em que o protocolo sofresse um fork
• A Consensus Development organizou uma reunião entre representantes da Netscape e da Microsoft
  • Tim Dierks trabalhava na época na Consensus Development junto com Christopher Allen
  • Ele escreveu, sob contrato com a Netscape, a implementação de referência do SSL 3.0
  • Bruce Schneier participou da reunião; Paul Kocher, que projetou o protocolo SSL 3, provavelmente também participou; e a Microsoft foi representada por Barbara Fox
• Como resultado das negociações, Microsoft e Netscape concordaram que a IETF assumiria o protocolo e o padronizaria por meio de um processo aberto
  • Esse processo levou Tim Dierks a editar o RFC
• Durante a padronização, o SSL 3.0 recebeu algumas alterações
  • O objetivo era evitar a impressão de que a IETF estava simplesmente ratificando o protocolo da Netscape
  • Pelo mesmo motivo, o nome do protocolo também foi alterado
• O TLS 1.0 que surgiu assim era, na prática, uma versão próxima do SSL 3.1

[GN⁺]

Comentários do Hacker News

• Os números de versão não deixam bem claras as diferenças entre os protocolos, o que aumenta a confusão
  O SSLv2 foi o primeiro SSL amplamente implantado, mas tinha muitos problemas, e o SSLv3 era quase um protocolo novo
  O TLS 1.0 é parecido com o SSLv3, mas recebeu alguns ajustes durante o processo de padronização da IETF; já o TLS 1.1 foi uma revisão bem pequena que corrigiu problemas na forma de uso de cifras de bloco
  O TLS 1.2 foi uma revisão de porte médio que, em resposta às fraquezas do MD5 e do SHA-1, adicionou novos hashes e conjuntos de cifras AEAD, como AES-GCM; e o TLS 1.3, embora reutilize alguns elementos anteriores ao TLS 1.2, é em grande parte quase um protocolo novo
  Todos esses protocolos foram projetados para permitir negociação automática de versão, de modo que cliente e servidor pudessem fazer upgrade de forma independente sem perder conectividade

  • O TLS 1.0 introduziu modularidade com o conceito de “extensões”, então é difícil vê-lo como uma evolução trivial
    Uma dessas extensões eram os tickets de sessão, que permitiam retomada de sessão no lado do servidor sem manter estado sincronizado entre servidores; outra era o Server Name Indication, que permitia ao servidor usar mais de um certificado
  • A negociação automática de versão também viabilizou vários ataques de downgrade ao longo de décadas
  • Deveria ter sido chamado simplesmente de TLS v4.0, não TLS 1.0
    Ter feito as versões seguintes como v1.1, v1.2 e v1.3 também parece teimosia para não admitir que zerar o número da versão foi objetivamente errado
  • Pelo menos não usaram o ano como número de versão

• Na época, a Microsoft era um bicho completamente diferente, então a confusão entre os nomes SSL/TLS não parece tão estranha assim
  A M$ daqueles tempos tentava dominar tudo e, a meu ver, não parou de tentar frear tecnologias abertas da internet nem até o começo dos anos 2010
  Ela conseguiu matar os Java Applets e, na minha opinião, também atrasou JavaScript e CSS de modo geral por vários anos
  No começo dos anos 2000, na empresa, houve pressão para dar suporte às “tecnologias” mais recentes do IE, mas assim que os principais bugs de JS foram corrigidos passamos a dar suporte ao Mozilla 3.0, e depois isso se mostrou uma boa decisão quando uma empresa Fortune 500 começou a usar Mozilla/Firefox em apps internos muito antes de isso se tornar comum

  • Não acho que foi a Microsoft que matou os Java Applets
    Eles sempre funcionaram no IE, que era praticamente o único caminho pelo qual a Microsoft poderia influenciá-los
    Os Applets fracassaram ao se tornarem o exemplo clássico de “Java é lento”; embora isso não fosse necessariamente verdade em geral, era verdade para Applets por causa da espera pelo download e pela inicialização da JVM
    No fim, HTML/JS passou a fazer melhor as funcionalidades dinâmicas que antes exigiam Applets, e o restante em que HTML ainda não bastava ficou com o Flash, até eles desaparecerem
  • Applets morreram por vários motivos
    Mesmo para uma animaçãozinha trivial, o tempo de inicialização do JRE era absurdamente longo; os requisitos de memória e os travamentos eram pesados para a época; e os problemas de compatibilidade das primeiras versões da plataforma Java também eram estranhos
    O modelo de segurança, baseado na suposição de que quem podia obter um certificado de uma CA seria bem-intencionado, também era ridículo, e a tecnologia de sandbox dos navegadores como um todo, não só do IE, ainda era imatura
  • Acho que o apelido “M$” combina mais com os dias de hoje
  • A Microsoft não mudou tanto assim, fora o fato de o departamento de relações públicas ter melhorado
  • A Amazon também tinha https://github.com/aws/s2n-tls
    Havia muita expectativa em torno do s2n, mas ele não parece ter se consolidado muito fora da AWS

• Quem faz uma distinção rígida entre TLS e SSL sabe qual é a diferença e acha que o outro também deveria saber, mas na prática é parecido com a diferença entre .doc e .docx
  São fundamentalmente diferentes, mas para usuários comuns parecem intercambiáveis, e no campo as pessoas em geral só se importam se HTTPS funciona, não muito com o funcionamento interno

  • A principal dificuldade era explicar a usuários comuns que TLSv1.0 é mais novo e melhor que SSLv2/SSLv3
    Lembro de ter discutido bastante com pessoas que achavam que número maior significava melhor
  • Mesmo muito tempo depois de o SSL ter sido descontinuado, as pessoas ainda usam SSL como nome para tráfego de rede criptografado
    Seria muito mais fácil chamar todo tráfego de rede criptografado moderno de TLS, e chamar de SSL só quando se usa SSL de fato por causa de sistemas legados reais

• Acabei de perceber que minha cabeça, inconscientemente, tinha dificuldade de distinguir SSL de TLS
  Só agora, 20 anos depois, entendi por quê

  • Comigo também
    Só depois de 15 anos nessa área é que realmente percebi que ssl e tls são a mesma coisa, e me senti um idiota
  • Fiquei sabendo por volta de 2010, mas antes disso eu também não sabia
    O gatilho foi notar que, em Java, mesmo usando TLSv1.3 hoje, ainda se usa SSLSocket para iniciar uma conexão criptografada

• “Transport Layer Security” é mesmo um nome melhor
  Também é bom dizer “TLS”; já SSL, com dois S seguidos, soa como uma cobra

  • O problema é que TLS já era amplamente usado como abreviação de thread local storage
    Transport Layer Security é amplamente documentado como tendo começado em 1999, enquanto há registros de “Thread Local Storage” pelo menos desde 1996
    Na época, era um termo mais comum no lado da Microsoft, talvez também no IBM/OS/2, enquanto em Pthreads e no Unix em geral havia uma tendência a chamar isso de “thread-specific data”
    O documento do ABI do Itanium, de 2001, pode ter espalhado o termo para o mundo Unix mais amplo, mas parece que a Sun também já usava o termo antes em Solaris e Java
  • Na verdade, acho que SSL é um nome mais adequado
    Em teoria, TLS poderia ser um mecanismo de segurança de camada de transporte sobre o qual se colocaria qualquer protocolo, como IPSec, mas na prática ele fica quase todo preso a sockets TCP
    A variante para UDP, DTLS, e o QUIC também não fazem parte da especificação TLS; e embora exista o TLS no kernel do Linux e infraestrutura parecida no Windows, não é tão simples quanto ativar TLS com uma única flag de socket
  • “SSL” é mais fácil de pronunciar que “TLS”, porque a posição da língua quase não muda entre as três letras
  • O melhor nome é aquele que apareceu primeiro e pegou

• Fiquei curioso sobre o que as pessoas costumam dizer quando precisam dizer a alguém que deve acessar um site com segurança, ou em situações em que faria sentido usar o termo TLS/SSL

  1. se dizem SSL ou TLS
  2. qual é a idade, ou se já trabalhavam antes de 1999
  • Normalmente digo SSL
    Por muito tempo nem sabia que TLS era “a mesma coisa”, e mesmo agora que sei, 9 em cada 10 vezes ainda digo SSL
    Tenho 38 anos e comecei a trabalhar em 2011, mas fiz programação de rede pela primeira vez por volta de 2004–2005
    Acabei de olhar outra tela e vi que uma função à qual adicionei um if há alguns minutos também se chamava sslCertNotBefore
    Acho que parte do problema é que programadores normalmente não lidam diretamente com TLS
    Criei um sistema que extraía informações detalhadas de certificados em conexões HTTPS, e puxar as informações necessárias da biblioteca padrão do Java deu bastante trabalho
    Quando tudo é tratado automaticamente de forma invisível, fica difícil errar, mas essa caixa-preta não ajuda muito a disseminar uma compreensão profunda de como o TLS realmente funciona
  • Parece que a razão de a maioria chamar de SSL é que SSL aparece no nome das bibliotecas que lidam com comunicação segura
    Incluindo a dominante OpenSSL, além de BoringSSL, LibreSSL, wolfSSL etc.
    Entre as bibliotecas com TLS no nome há GnuTLS, mbedTLS, s2n-tls e RustTLS, mas são relativamente menos usadas
  • Normalmente digo SSL
    É mais provável que seja entendido do que o TLS, que é mais preciso, e ninguém mais usa SSL 3.0 de verdade
    Nomes de bibliotecas clássicas como OpenSSL também têm SSL
    Mas pode ser apenas hábito da época em que aprendi SSL durante as guerras da criptografia dos anos 1990, quando era preciso conseguir a versão “US only” do Netscape para usar criptografia SSL de verdade
  • Normalmente digo “https”
    Porque às vezes até pessoas comuns sabem o que isso significa
  • Hoje em dia venho dizendo cada vez mais “TLS”, mas até apenas 1 ou 2 anos atrás eu quase sempre dizia “SSL”
    Mesmo assim, às vezes ainda escapa SSL
    Tenho 51 anos e comecei a trabalhar em TI em meados dos anos 90

• Tenho a impressão de que o TLS 1.0 trouxe melhorias bastante grandes em relação ao SSL 3.0
  Lendo o texto, parece que só mudaram algumas coisas para parecer diferente

  • A principal diferença está no padding
    Quando foi divulgado previamente que o ataque POODLE afetava apenas o SSL3 e não o TLS1.0, só com essa informação já dava para prever que seria um oráculo de padding
    Os dois são bem parecidos, e é justo dizer que havia algumas “correções de bugs”
    Pode ser que eu tenha esquecido algumas coisas por já fazer muito tempo, e talvez tenha deixado passar detalhes porque SSL3 e TLS1.0 sempre foram implementados juntos
  • As mudanças foram pequenas, menores do que em qualquer outra revisão de versão
    Em linhas gerais, foi mais o IETF não aprovando o protocolo SSL 3.0 tal como estava e marcando território
  • Houve mudanças e melhorias significativas, sem dúvida, mas não foi uma reformulação completa como o SSL 3.0

• Um texto relacionado é “Randomness and the Netscape Browser”, da Dr. Dobb's Journal, de janeiro de 1996
  https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
  É um texto escrito em 1996, e a linguagem usada já soa bem diferente da de publicações atuais, o que dá uma sensação de envelhecimento

  • Depende de quais publicações você lê
    Assim como em 1996, textos atuais da LWN [1], por exemplo, têm um estilo bem parecido
    Talvez sejam um pouco menos rígidos por mirar um público um pouco mais amplo
    [1] https://lwn.net/
  • Os autores desse texto encontraram aquela falha de segurança e também apareceram na capa do New York Times: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

• Lembro que “SSL and TLS: Designing and Building Secure Systems”, de Eric Rescorla, foi muito útil para entender a história do TLS e como chegamos até aqui
  É um livro de 2001, mas já alertava sobre alguns problemas que depois viraram CVEs, e dá para encontrá-lo usado por alguns dólares

• Por volta de 2014, eu diria que já havia um consenso muito firme de que o SSL 2.0 era gravemente falho
  Nem o handshake era autenticado corretamente