Tim Hudson, Presidente da OpenSSL Corporation – Série de Entrevistas

Tim Hudson é coautor do SSLeay e um dos organizadores da OpenSSL Conference, Praga, 13 a 15 de outubro de 2026. Ele tem mais de 30 anos de experiência em segurança de sistemas e redes e é Presidente da OpenSSL Corporation e Diretor de Tecnologia (CTO) da Cryptsoft Pty Ltd. Desde 1995, seu trabalho inclui cofundar o SSLeay com Eric Young, a biblioteca criptográfica que se tornou a OpenSSL Library, cofundar o centro de desenvolvimento da RSA Security Australia, contribuir para mudanças nas regulamentações de exportação de criptografia dos EUA, liderar mais de 30 validações FIPS 140, co‑presidir os Comitês Técnicos OASIS KMIP e SAM, e palestrar em conferências de segurança de destaque, incluindo a RSA Conference, AusCERT, ICMC, LinuxConf e a OpenSSL Conference.

OpenSSL é um projeto global colaborativo de código aberto que desenvolve e mantém a OpenSSL Library, uma das bibliotecas criptográficas mais amplamente usadas no mundo. Utilizada em sistemas operacionais, plataformas de nuvem, softwares empresariais e dispositivos conectados, a OpenSSL Library ajuda a proteger bilhões de interações online seguras todos os dias. Por meio da OpenSSL Foundation e da OpenSSL Corporation, o projeto está comprometido em avançar a criptografia confiável, apoiar o desenvolvimento sustentável de código aberto e fortalecer a segurança da internet.

Você cofundou o SSLeay com Eric Young em 1995 após reconhecer a necessidade de uma implementação de SSL fora dos EUA, e esse trabalho acabou se tornando a base do OpenSSL. Qual problema você estava tentando resolver originalmente, e tinha alguma noção na época de que a tecnologia poderia se tornar uma parte tão fundamental da segurança da internet?

O problema era totalmente concreto, e era comercial antes de ser qualquer outra coisa. Eu estava na Mincom em Brisbane, e tínhamos clientes que precisavam proteger suas comunicações. Não havia como comprar essa capacidade. As restrições de exportação dos EUA sobre criptografia significavam que produtos americanos ou não podiam ser fornecidos a nós ou vinham com tamanhos de chave tão restritos que seu uso seria desonesto. Não se tratava de uma objeção filosófica à política de exportação. Era um problema de engenharia em que o componente que eu precisava não existia em nenhuma forma que eu pudesse adquirir, e eu tinha clientes aguardando.

O que eu tinha era o conhecimento de algo que a maioria das pessoas havia esquecido. Eric Young havia escrito uma implementação de DES alguns anos antes: código bom, limpo, livremente disponível, escrito por prazer e totalmente alheio a tudo isso. Eric não trabalhava com SSL. Ele não tinha conhecimento de SSL. Quando a Netscape publicou a especificação, eu a li, fui até o Eric com o problema e apresentei‑o como um passo relativamente modesto a partir do que ele já tinha.

Isso não era o quadro completo. Cada parte era simples, mas havia um número significativo de partes. Uma implementação de DES fornece um cifrador simétrico. SSL requer criptografia de chave pública, aritmética de precisão arbitrária, ASN.1, manipulação de certificados X.509 e uma máquina de estado de protocolo, tudo correto, porque em criptografia quase correto e quebrado são a mesma coisa. Eu apresentei a escala de forma otimista. Eric percebeu rapidamente o quanto havia, e gostou, porque a escala acabou sendo a atração e não o obstáculo. Não tenho certeza de que teria começado de outra forma.

Ele fez o núcleo criptográfico, por isso a biblioteca carrega suas iniciais. Eu assumi as partes que transformam uma biblioteca em algo que outras pessoas podem realmente implantar: a integração de aplicação, os testes, a documentação e o lado comunitário. Também procurei ativamente qualquer biblioteca de criptografia concorrente em uso e a converti ou substituí. SSLtelnet, SSLftp, NCSA httpd e muitos outros pacotes foram meu trabalho, aplicações construídas sobre os algoritmos e protocolos criptográficos que o Eric implementou. Essa combinação permitiu que cada um de nós se concentrasse no que realmente nos interessava, o que acredito ser a principal razão de sua continuidade.

Estar na Austrália foi o que tornou tudo isso possível, e então descobrimos que muitas outras pessoas tinham exatamente o mesmo problema pelos mesmos motivos. Algo construído para atender a um requisito específico de cliente em Brisbane tornou‑se útil para todos fora dos Estados Unidos, e eventualmente para muitas pessoas dentro deles também.

Sabíamos o que isso se tornaria? Não. Ninguém parte para construir infraestrutura crítica. Infraestrutura crítica é o que você descobre que construiu, alguns anos depois, quando percebe quem depende dela. O que pensávamos estar fazendo era resolver um problema à nossa frente e depois responder a perguntas de outras pessoas que encontraram a mesma barreira. A parte de responder perguntas acabou sendo tão importante quanto o código.

Você trabalha com criptografia e segurança da internet há mais de três décadas. O que mudou de forma mais dramática no panorama de ameaças durante esse período, e quais problemas de segurança permaneceram surpreendentemente semelhantes apesar dos enormes avanços tecnológicos?

A mudança maior foi que atacar sistemas se tornou uma profissão com um modelo econômico por trás. No meio dos anos 90, as pessoas que invadiam sistemas o faziam principalmente porque achavam interessante. Hoje há uma indústria, com especialização, ferramentas, cadeias de suprimentos, suporte ao cliente e, em alguns casos, financiamento estatal. Isso muda tudo em termos de como você deve pensar, porque você não está mais defendendo contra curiosidade. Você está defendendo contra alguém com orçamento, prazo e caso de negócio.

A segunda mudança é escala e dependência. A aplicação média em 1995 era algo que você escrevia. A aplicação média hoje é algo que você monta, e a maior parte do código nela foi escrita por pessoas que você nunca conheceu e não pode nomear. A superfície de ataque passou do seu código para suas dependências, e a maioria das organizações ainda não ajustou seu pensamento de acordo.

O que permaneceu notavelmente constante são os modos de falha. Ainda escrevemos bugs em código que analisa entrada não confiável. Ainda entregamos sistemas com padrões que ninguém revisitou. Certificados ainda expiram num sábado. Credenciais ainda acabam em lugares onde não deveriam estar. E a criptografia ainda quase nunca é quebrada na matemática. Ela é contornada, configurada incorretamente ou simplesmente não ativada. Se você me desse uma lista das dez principais causas de violações em 1996 e outra do mês passado, teria dificuldade em diferenciá‑las. A tecnologia se transformou completamente. Os erros não.

OpenSSL 4.0 foi lançado em abril de 2026, marcando a primeira grande versão do projeto em vários anos. O que esse lançamento nos diz sobre a direção da infraestrutura criptográfica, e quais mudanças você acha que realmente importarão mais para as organizações que dependem do OpenSSL?

A coisa mais útil de entender sobre o 4.0 é que ele é, principalmente, um lançamento de subtração, e esse era o objetivo.

Removemos completamente a interface ENGINE. Eliminamos o SSLv3 e o ClientHello do SSLv2. Desativamos curvas elípticas depreciadas e curvas EC explícitas em tempo de compilação. Tornamos o ASN1_STRING opaco e apertamos um grande número de assinaturas de API. Essas são as mudanças que geram trabalho para as pessoas, e são as mudanças que importam, porque uma biblioteca criptográfica que só acumula não pode permanecer segura. Cada caminho de código depreciado que você mantém vivo é uma superfície de ataque que alguém está mantendo em seu nome e ninguém está testando.

Há adições: Encrypted Client Hello, suporte ao RFC 8998 incluindo o grupo híbrido SM2/ML‑KEM, cSHAKE, KDFs SNMP e SRTP, FFDHE negociado para TLS 1.2. O ECH, em particular, fecha uma lacuna genuína de privacidade, porque o Server Name Indication tem vazado a identidade de cada site que você visita desde que o TLS 1.3 foi lançado. Mas as remoções são a história.

O ponto que eu mais gostaria que as organizações retivessem é este: 4.0 não é a versão LTS. Ela tem suporte até maio de 2027. A versão estável de longo prazo atual é a 3.5, com suporte até abril de 2030, e a 3.5 já inclui os algoritmos pós‑quânticos. Se você quer o código mais novo, use a 4.0. Se quer um alvo estável para construir um plano de migração de cinco anos, use a 3.5. Escolher o número maior só porque é maior é um erro que vemos as pessoas cometerem a cada ciclo.

Criptografia pós‑quântica passou de um problema de pesquisa para um desafio de migração, com o OpenSSL já suportando ML‑KEM, ML‑DSA e SLH‑DSA e troca de chaves híbrida pós‑quântica. Para líderes empresariais que assumem que a computação quântica ainda está muito distante para se preocupar, quais riscos eles estão subestimando hoje?

O erro mais comum é tratar isso como uma questão de quando um computador quântico relevante para criptografia chegará. Essa é a variável errada. A pergunta correta é quanto tempo seus dados precisam permanecer confidenciais e quanto tempo sua migração levará. Subtraia o segundo do primeiro e você tem seu prazo real, e para muitas organizações esse prazo já está no passado.

O tráfego criptografado pode ser capturado hoje e armazenado indefinidamente. Se a informação nele tem um horizonte de sensibilidade de vinte anos (registros de pacientes, arquivos de pessoal, propriedade intelectual, material diplomático, posições financeiras), então um adversário não precisa de um computador quântico agora. Ele precisará de um eventualmente, e de armazenamento barato enquanto isso. Isso não é um ataque especulativo; é uma decisão de arquivamento.

A segunda coisa que está sendo negligenciada é que a migração não é um único projeto. A troca de chaves é a parte fácil, e grande parte dela já está acontecendo: o OpenSSL 3.5 tornou a troca de chaves híbrida pós‑quântica o padrão TLS, de modo que muitas organizações já estão usando acordos de chave pós‑quânticos sem ter tomado uma decisão a respeito. Assinaturas e a hierarquia de certificados são a parte difícil, porque envolvem autoridades certificadoras, raízes de confiança de hardware, chaves de assinatura de firmware, módulos de segurança de hardware e dispositivos com vida útil de quinze anos que foram construídos sob a suposição de que RSA seria suficiente para sempre.

A terceira coisa é a restrição que ninguém orça: assinaturas pós‑quânticas são grandes. Uma assinatura ML‑DSA‑65 tem aproximadamente cinquenta vezes o tamanho de uma assinatura ECDSA P‑256, e a SLH‑DSA é ainda maior. Isso rompe coisas: tamanhos de handshake, dispositivos restritos, protocolos com limites de campo codificados, links de satélite e IoT. Você descobre esses problemas testando, não lendo um padrão.

Um dos desafios da migração pós‑quântica é que as organizações podem nem saber onde a criptografia está sendo usada em suas aplicações, infraestrutura, dispositivos e dependências de terceiros. Como as empresas devem abordar o inventário criptográfico e a agilidade criptográfica para que a próxima grande transição de algoritmo não se torne uma emergência?

Comece com uma verdade desconfortável: você não pode construir um inventário criptográfico enviando um questionário aos seus fornecedores. Você receberá uma mistura de textos de marketing, incertezas honestas e respostas que eram verdadeiras três versões atrás. Digo isso tendo passado um tempo considerável lendo documentação de fornecedores de hardware em um campo relacionado, e a lacuna entre o que a documentação afirma e o que o produto realmente faz é maior do que a maioria dos compradores imagina.

Você tem que procurar. Existem três camadas, e cada uma requer técnicas diferentes. Código que você escreveu: análise estática, varredura de dependências e busca pelos identificadores de algoritmo que você codificou há anos. Código que você vinculou: listas de materiais de software, estendidas para listas de materiais criptográficos, onde o trabalho de CBOM realmente se mostra útil. Coisas que você comprou ou conectou: observação de rede, porque o que seus sistemas realmente negociam na camada de transporte é a verdade de base e frequentemente não é o que alguém acreditava.

Quanto à agilidade, o princípio é simples e a prática não: o algoritmo deve ser uma decisão de configuração, não uma mudança de código. Se mudar um cifrador requer um desenvolvedor, uma compilação, um ciclo de teste e um lançamento, você não tem agilidade. Você tem um projeto. Centralize as operações criptográficas atrás de uma interface que você controla, de modo que haja um único ponto a mudar em vez de quatrocentos.

E então a parte que quase ninguém faz: exercite‑a. Agilidade que você nunca usou é uma afirmação, não uma capacidade. Escolha um fim de semana tranquilo, desative um algoritmo em um ambiente não‑produzido e descubra o que quebra. Algo quebrará. É melhor descobrir isso no seu cronograma do que durante uma transição de emergência mandatória.

Uma função forçadora útil é a vida útil dos certificados. A indústria está migrando para certificados de vida muito curta, o que torna a gestão manual inviável e força a automação que você precisaria de qualquer forma. Se você automatizar a emissão e rotação de certificados corretamente, já terá construído a maior parte da maquinaria que uma futura transição de algoritmo exigirá.

IA está mudando tanto a defesa de cibersegurança quanto as capacidades disponíveis para atacantes. Onde você acredita que a IA realmente altera a equação de segurança, e onde acha que as organizações podem estar focando demais na tecnologia enquanto ignoram fraquezas mais fundamentais?

A IA realmente muda uma coisa, e posso falar sobre isso diretamente porque aconteceu conosco.

Um número considerável de vulnerabilidades divulgadas no OpenSSL este ano foram encontradas por análise impulsionada por IA. Em janeiro lançamos uma versão que corrigia doze problemas, praticamente todos de um único grupo de pesquisa que usava análise automatizada, e eles contribuíram com patches junto aos relatórios. Em junho corrigimos um uso após liberação de alta gravidade na verificação PKCS#7 encontrado por um pesquisador que trabalhava com um sistema de IA. Isso representa uma mudança real de capacidade na detecção de bugs de segurança de memória e de parsing em código C maduro que tem sido revisado por especialistas por anos. Vi o mesmo padrão em outras bibliotecas criptográficas. Ao analisar um lote de CVEs do Bouncy Castle deste ano, a assinatura da análise de código automatizada é clara.

A implicação óbvia é que isso corta os dois lados. As mesmas técnicas estão disponíveis para quem quiser usá‑las, nos mesmos códigos‑fonte, e os defensores não têm acesso exclusivo.

A implicação menos óbvia, e que eu enfatizaria, é a carga que isso coloca nos mantenedores. Gerar um relatório de vulnerabilidade plausível agora é quase gratuito. Triá‑lo não é. Ainda custa tempo real de um especialista humano. Equipes de segurança de código aberto, que geralmente são pequenas e frequentemente voluntárias, estão absorvendo um volume crescente de relatórios de qualidade muito variável. Os bons, como a pesquisa que mencionei, vêm com reproduções e patches. Os ruins são um ataque de negação de serviço contra as pessoas de quem você depende. Se sua organização está implantando IA contra código aberto, financie a capacidade de triagem do outro lado.

Onde acho que a atenção está equivocada: a IA não corrige seus sistemas. Ela não faz inventário dos seus ativos, não rotaciona suas credenciais, não aposenta seu hardware não suportado, nem responsabiliza alguém pelo certificado que expira no próximo mês. Organizações que compram ferramentas de segurança baseadas em IA enquanto executam software com vulnerabilidades conhecidas e não corrigidas têm a sequência errada. O trabalho pouco glamouroso ainda é onde está o risco.

Muitas organizações investem fortemente em ferramentas, mas permanecem vulneráveis por causa de erros de configuração, sistemas desatualizados, processos fracos ou preparação inadequada para incidentes. Quais são os erros de segurança mais consequentes que você continua vendo, e o que as equipes de liderança devem ter em prática antes que um ataque realmente ocorra?

O erro mais consequente é tratar a segurança como uma atividade de aquisição. Ferramentas são compradas, orçamentos são cumpridos, painéis ficam verdes, e ninguém perguntou se a organização realmente pode fazer as coisas fundamentais.

O segundo é não saber o que você está executando. Você não pode corrigir software que não sabe que possui, e a maioria das organizações descobre o verdadeiro conteúdo de seu patrimônio durante um incidente. É por isso que o trabalho de lista de materiais importa, não como um artefato de conformidade, mas como a coisa que você procura às duas da manhã quando um alerta crítico cai e alguém pergunta se você está afetado.

O terceiro são as configurações padrão. Sistemas são instalados, funcionam, e a configuração nunca é revisitada. Cinco anos depois, essa configuração é uma responsabilidade, e ninguém envolvido na decisão original ainda trabalha lá.

O quarto é a gestão de chaves e certificados deixada a indivíduos. Uma proporção notável de interrupções auto‑infligidas são certificados expirados que uma pessoa acompanhava silenciosamente em uma planilha até mudar de emprego.

Antes de um incidente, a liderança precisa de quatro coisas em prática. Um tomador de decisão nomeado com autoridade para desligar o negócio, decidido antecipadamente e por escrito, porque a discussão sobre quem tem essa autoridade não é algo que você queira ter ao vivo. Contratos de retenção já assinados com peritos forenses externos e consultoria especializada, porque essa aquisição leva semanas e você terá horas. Um canal de comunicação que não dependa dos sistemas que podem ser comprometidos. E uma capacidade de restauração que realmente tenha sido testada de ponta a ponta, não um regime de backup verificado apenas no sentido de que os jobs concluíram com sucesso.

Então pratique. Um exercício de mesa ao nível executivo, uma vez por ano, revelará lacunas mais genuínas do que outra ferramenta.

Quando um ataque cibernético sério acontece, executivos podem se ver tomando decisões técnicas, legais, operacionais e de comunicação sob enorme pressão. O que separa organizações que respondem efetivamente daquelas que permitem que um incidente se agrave substancialmente?

As organizações que lidam bem com isso tomaram as decisões importantes antes do incidente, de modo que durante o incidente elas estão executando, não deliberando. Essa é a maior parte.

Além da preparação, alguns pontos separam consistentemente boas respostas de respostas ruins.

Elas separam a investigação técnica da trilha executiva e de comunicação, com uma interface definida entre elas. Quando as mesmas pessoas tentam conter uma intrusão e redigir uma notificação ao cliente, ambos os trabalhos são feitos mal.

Elas preservam evidências antes de remediar. O impulso de reconstruir a máquina comprometida imediatamente é forte e destrói as informações necessárias para estabelecer o escopo. Se você não pode responder “o que mais eles tocaram?”, não pode dizer credivelmente a ninguém que o incidente acabou.

Elas aceitam que informações iniciais são provisórias e comunicam de acordo. A maior parte do dano reputacional que observei veio não da violação, mas de declarações iniciais confiantes que tiveram que ser retractadas. Dizer “isto é o que sabemos, isto ainda não sabemos, e isto é quando vamos atualizar vocês” não é fraqueza. É a única posição que você não terá que reverter.

E, crucialmente, criam condições onde engenheiros podem dar notícias ruins aos executivos. O padrão de falha que mais vejo é uma organização onde a exposição legal era tão evidente que ninguém queria ser a pessoa que anotasse o que realmente aconteceu. O incidente então piora em silêncio. Se seus engenheiros gerenciam sua própria responsabilidade ao invés do incidente, você tem um problema de governança que nenhuma quantidade de ferramenta vai consertar.

OpenSSL ocupa uma posição incomum como infraestrutura crítica de código aberto usada em todo o ecossistema tecnológico, enquanto a OpenSSL Corporation foca em atender comunidades comerciais ao lado da OpenSSL Foundation, operada independentemente. Como você equilibra as necessidades de empresas, desenvolvedores, reguladores e da comunidade open‑source mais ampla quando decisões sobre segurança e compatibilidade podem afetar uma grande parte da internet?

A resposta honesta é que você não as equilibra tentando agradar a todos em cada decisão. Você as equilibra tendo uma política publicada e aplicando‑a de forma previsível, para que as pessoas possam planejar ao seu redor mesmo quando não gostam de um resultado específico.

Previsibilidade é o que devemos aos nossos usuários. Lançamos versões de recursos em abril e outubro. Anunciamos com antecedência qual versão é estável de longo prazo e até quando. Anunciamos remoções significativas bem antes de acontecerem. A remoção do ENGINE no 4.0 foi descrita publicamente meses antes do lançamento, e acordada tanto pela Corporação quanto pela Fundação. Quem ficou surpreso em abril não estava prestando atenção, e fizemos o possível para facilitar a atenção.

A resposta estrutural é a própria separação. A Fundação existe para servir a biblioteca open source e a comunidade ao seu redor. A Corporação existe para servir organizações com requisitos comerciais (compromissos de suporte, validação FIPS, cronogramas específicos) e tornar tudo financeiramente sustentável. Manter essas duas entidades distintas significa que nenhum conjunto de necessidades é resolvido silenciosamente a favor do outro. Quando requisitos empresariais e comunitários realmente conflitam, o conflito ocorre entre duas organizações com mandatos claros, e não dentro da cabeça de uma única pessoa.

A outra parte é ouvir corretamente, o que requer mecanismos reais em vez de suposições. Essa é uma grande parte do porquê organizamos a conferência, que acontece em Praga neste outubro, e por que a infraestrutura comunitária existe. É muito fácil para mantenedores desenvolverem teorias confiantes sobre o que os usuários precisam. É consideravelmente mais útil estar em uma sala com eles.

Olhando para a próxima década, qual transição de segurança ou criptográfica você acredita que as organizações ainda subestimam, e que lições da evolução do SSL, OpenSSL e dos últimos 30 anos de segurança da internet os líderes devem aplicar ao se prepararem?

A transição que acho mais subestimada não é a criptografia pós‑quântica como problema de algoritmo. É a identidade de máquina e a hierarquia de certificados que sustenta tudo.

A troca de chaves pós‑quântica será amplamente resolvida por padrões, e grande parte já foi. O que não será resolvido por padrões é a infraestrutura de confiança: certificados raiz em hardware, chaves de assinatura de firmware gravadas em dispositivos, HSMs com uma década de vida útil restante, sistemas industriais e médicos que ainda estarão operando em 2040 com suposições criptográficas incorporadas na fabricação. Esses não podem ser atualizados enviando uma nova versão da biblioteca, e em alguns casos não podem ser atualizados de forma alguma. A escala desse problema de substituição ainda não está refletida no planejamento de capital de ninguém.

Ao lado disso há uma transição regulatória. O Cyber Resilience Act na Europa, e estruturas comparáveis em outros lugares, mudarão as obrigações ao distribuir software com componentes que você não escreveu. A maioria das organizações ainda não analisou o que isso significa para sua dependência de código aberto, ou para as pessoas que o mantêm.

Três lições de trinta anos:

1. Transições levam uma década a mais do que o anunciado. O SSLv3 foi depreciado em 2015, desativado por padrão em 2016, e finalmente removemos o código em abril de 2026. Isso são onze anos, para um protocolo que todos concordaram estar quebrado. Planeje a migração pós‑quântica contra essa realidade, não contra o comunicado de imprensa.
2. Os padrões são o único controle de segurança que funciona em escala. Qualquer coisa que exija que cada administrador tome a decisão correta não acontecerá. O motivo pelo qual a troca de chaves híbrida pós‑quântica foi implantada tão rapidamente é que ela vem ativada por padrão e não requer decisão alguma. Projete para as pessoas que nunca lerão sua documentação, porque isso é quase todo mundo.
3. Você depende de menos pessoas do que imagina. Quase toda organização no planeta depende de código criptográfico mantido por um número muito pequeno de indivíduos. Isso era verdade quando éramos dois em Brisbane, e a estrutura não mudou fundamentalmente mesmo à medida que os riscos aumentaram por ordens de magnitude. Seja o que for que você planeje para a próxima década, alguma parte dela repousa sobre um mantenedor que você nunca contatou e não financia. Isso vale a pena saber antes de precisar dele.

Obrigado pela ótima entrevista. Leitores que desejam saber mais devem visitar OpenSSL.