Tim Hudson, President of OpenSSL Corporation – Interview Series

Tim Hudson is co-author of SSLeay and one of the organizers of the OpenSSL Conference, Prague October 13-15 2026. He has over 30 years of experience in system and network security and is President of OpenSSL Corporation and Chief Technology Officer at Cryptsoft Pty Ltd. Since 1995, his work has included co-founding SSLeay with Eric Young, the cryptographic library that became the OpenSSL Library, co-founding the RSA Security Australia development center, contributing to changes in U.S. encryption export regulations, leading more than 30 FIPS 140 validations, co-chairing the OASIS KMIP and SAM Technical Committees, and speaking at leading security conferences, including RSA Conference, AusCERT, ICMC, LinuxConf, and the OpenSSL Conference.

OpenSSL is a global collaborative open source project that develops and maintains the OpenSSL Library, one of the world’s most widely used cryptographic libraries. Used across operating systems, cloud platforms, enterprise software and connected devices, the OpenSSL Library helps protect billions of secure online interactions every day. Through the OpenSSL Foundation and OpenSSL Corporation, the project is committed to advancing trusted cryptography, supporting sustainable open source development and strengthening the security of the internet.

You co-founded SSLeay with Eric Young in 1995 after recognizing the need for a non-US implementation of SSL, and that work ultimately became the foundation for OpenSSL. What problem were you originally trying to solve, and did you have any sense at the time that the technology could become such a fundamental part of securing the internet.

The problem was entirely concrete, and it was a commercial one before it was anything else. I was at Mincom in Brisbane, and we had customers who needed to secure their communications. There was no way to buy that capability. US export controls on cryptography meant American products either could not be supplied to us at all or came with key sizes so restricted that deploying them would have been dishonest. This was not a philosophical objection to export policy. It was an engineering problem in which the component I needed did not exist in any form I could purchase, and I had customers waiting.

What I did have was knowledge of something most people had forgotten about. Eric Young had written a DES implementation some years earlier: good, clean, freely available code, written for its own sake and entirely unrelated to any of this. Eric was not working on SSL. He was not aware of SSL. When Netscape published the specification, I read it, went to Eric with the problem, and presented it as a relatively modest step from where he already was.

This was not the whole picture. Each part was straightforward but there were a significant number of parts. A DES implementation gives you one symmetric cipher. SSL requires public key cryptography, arbitrary precision arithmetic, ASN.1, X.509 certificate handling, and a protocol state machine, with all of it correct, because in cryptography nearly correct and broken are the same thing. I had presented the scale of it optimistically. Eric worked out soon enough how much of it there was, and relished it, because the scale turned out to be the attraction rather than the obstacle. I am not sure it would have started any other way.

He did the cryptographic core, which is why the library carries his initials. I took on the parts that turn a library into something other people can actually deploy: the application integration, the testing, the documentation, and the community side of it. I also actively sought out anywhere a competing encryption library was in use and converted or replaced it. SSLtelnet, SSLftp, NCSA httpd and a good many other packages were my work, applications built on top of the cryptographic algorithms and protocols Eric implemented. That blend let each of us concentrate on what was actually interesting to us, which I think is the main reason it kept going.

Being in Australia is what made it possible to solve at all, and then it turned out that a great many other people had exactly the same problem for exactly the same reason. Something built to meet a specific customer requirement in Brisbane became useful to everyone outside the United States, and eventually to a good many people inside it as well.

Did we know what it would become? No. Nobody sets out to build critical infrastructure. Critical infrastructure is what you discover you have built, some years later, when you find out who is depending on it. What we thought we were doing was solving a problem in front of us and then answering questions from other people who had hit the same wall. The answering-questions part turned out to matter as much as the code.

You have worked in cryptography and internet security for more than three decades. What has changed most dramatically about the threat landscape during that period, and which security problems have remained surprisingly similar despite enormous advances in technology?

The single biggest change is that attacking systems became a profession with an economic model behind it. In the mid-nineties, the people breaking into systems were largely doing it because it was interesting. Today there is an industry, with specialization, tooling, supply chains, customer support, and in some cases state funding. That changes everything about how you have to think, because you are no longer defending against curiosity. You are defending against someone with a budget, a deadline, and a business case.

The second change is scale and dependency. The average application in 1995 was something you wrote. The average application today is something you assembled, and the majority of the code in it was written by people you have never met and cannot name. The attack surface moved from your code to your dependencies, and most organizations have not adjusted their thinking accordingly.

What has stayed remarkably constant is the failure modes. We are still writing bugs in code that parses untrusted input. We are still shipping systems with defaults nobody revisited. Certificates still expire on a Saturday. Credentials still end up in places they should not be. And cryptography is still almost never broken at the mathematics. It is bypassed, misconfigured, or simply not turned on. If you had handed me a list of the top ten root causes of breaches in 1996 and a list from last month, you would struggle to tell them apart. The technology transformed completely. The mistakes did not.

OpenSSL 4.0 was released in April 2026, marking the project’s first major release in several years. What does this release tell us about where cryptographic infrastructure is heading, and which changes do you think will ultimately matter most to organizations that depend on OpenSSL?

The most useful thing to understand about 4.0 is that it is primarily a subtraction release, and that this was the point of it.

We removed the ENGINE interface entirely. We removed SSLv3 and the SSLv2 ClientHello. We disabled deprecated elliptic curves and explicit EC curves at compile time. We made ASN1_STRING opaque and tightened a large number of API signatures. Those are the changes that generate work for people, and they are the changes that matter, because a cryptographic library that only ever accumulates cannot stay secure. Every deprecated code path you keep alive is an attack surface somebody is maintaining on your behalf and nobody is testing.

There are additions: Encrypted Client Hello, RFC 8998 support including the hybrid SM2/ML-KEM group, cSHAKE, SNMP and SRTP KDFs, negotiated FFDHE for TLS 1.2. ECH in particular closes a genuine privacy gap, because Server Name Indication has been leaking the identity of every site you visit since TLS 1.3 shipped. But the removals are the story.

The point I would most want organizations to take away is this: 4.0 is not the LTS release. It is supported until May 2027. The current long-term stable release is 3.5, supported until April 2030, and 3.5 already has the post-quantum algorithms in it. If you want the newest code, run 4.0. If you want a stable target you can build a five-year migration plan around, run 3.5. Choosing the higher number because it is the higher number is a mistake we see people make every cycle.

Post-quantum cryptography has moved from a research problem toward a migration challenge, with OpenSSL already supporting ML-KEM, ML-DSA, and SLH-DSA and hybrid post-quantum key exchange. For business leaders who assume quantum computing is still too distant to worry about, what risks are they overlooking today?

The most common error is treating this as a question about when a cryptographically relevant quantum computer arrives. That is the wrong variable. The right question is how long your data needs to stay confidential, and how long your migration will take. Subtract the second from the first and you have your actual deadline, and for a lot of organizations that deadline is already in the past.

Encrypted traffic can be captured today and stored indefinitely. If the information in it has a twenty-year sensitivity horizon (patient records, personnel files, intellectual property, diplomatic material, financial positions), then an adversary does not need a quantum computer now. They need one eventually, and cheap storage in the meantime. That is not a speculative attack; it is a filing decision.

The second thing being overlooked is that migration is not one project. Key exchange is the easy part, and much of it is already happening: OpenSSL 3.5 made hybrid post-quantum key exchange the TLS default, so a great many organizations are running post-quantum key agreement right now without having made a decision about it. Signatures and the certificate hierarchy are the hard part, because those involve certificate authorities, hardware roots of trust, firmware signing keys, hardware security modules, and devices with fifteen-year field lifetimes that were built on the assumption that RSA would be fine forever.

The third thing is the constraint nobody budgets for: post-quantum signatures are large. An ML-DSA-65 signature is roughly fifty times the size of an ECDSA P-256 signature, and SLH-DSA is larger again. That breaks things: handshake sizes, constrained devices, protocols with hard-coded field limits, satellite and IoT links. You find these problems by testing, not by reading a standard.

One of the challenges with post-quantum migration is that organizations may not even know everywhere cryptography is being used across their applications, infrastructure, devices, and third-party dependencies. How should companies approach cryptographic inventory and crypto-agility so that the next major algorithm transition does not become an emergency?

Start with an uncomfortable truth: you cannot build a cryptographic inventory by sending your vendors a questionnaire. You will get back a mixture of marketing copy, honest uncertainty, and answers that were true three releases ago. I say this having spent a substantial amount of time recently reading hardware vendor documentation in a related field, and the gap between what documentation claims and what a product does is wider than most buyers assume.

You have to look. There are three layers, and they need different techniques. Code you wrote: static analysis, dependency scanning, and grepping for the algorithm identifiers you hard-coded years ago. Code you linked: software bills of materials, extended into cryptographic bills of materials, which is where the CBOM work is genuinely useful. Things you bought or connected to: network observation, because what your systems actually negotiate on the wire is the ground truth and it is frequently not what anyone believed.

On agility, the principle is simple and the practice is not: the algorithm should be a configuration decision, not a code change. If changing a cipher requires a developer, a build, a test cycle and a release, you do not have agility. You have a project. Centralize cryptographic operations behind an interface you control, so that there is one place to change rather than four hundred.

And then the part almost everyone skips: exercise it. Agility you have never used is a claim, not a capability. Pick a quiet weekend, turn an algorithm off in a non-production environment, and find out what breaks. Something will. Better to discover it on your schedule than during a mandated emergency transition.

One useful forcing function is certificate lifetime. The industry is moving to dramatically shorter-lived certificates, which makes manual certificate management untenable and forces the automation you were going to need anyway. If you automate certificate issuance and rotation properly, you have built most of the machinery a future algorithm transition will require.

AI is changing both cybersecurity defense and the capabilities available to attackers. Where do you believe AI genuinely changes the security equation, and where do you think organizations may be focusing too much on the technology while overlooking more fundamental weaknesses?

AI genuinely changes one thing, and I can speak to it directly because it has happened to us.

A substantial number of the vulnerabilities disclosed in OpenSSL this year were found by AI-driven analysis. In January we shipped a release fixing twelve issues, essentially all from one research group using automated analysis, and they contributed patches alongside the reports. In June we fixed a high-severity use-after-free in PKCS#7 verification found by a researcher working with an AI system. That is a real capability change in finding memory-safety and parsing bugs in mature C code that has been reviewed by experts for years. I have seen the same pattern in other cryptographic libraries. Analysing a batch of Bouncy Castle CVEs from this year, the fingerprint of automated code analysis is clear.

The obvious implication is that this cuts both ways. The same techniques are available to whoever wants to use them, on the same codebases, and defenders do not have exclusive access.

The less obvious implication, and the one I would emphasize, is the burden it places on maintainers. Generating a plausible-looking vulnerability report is now nearly free. Triaging one is not. It still costs a human expert real time. Open source security teams, which are usually small and frequently volunteer, are absorbing a rising volume of reports of highly variable quality. The good ones, like the research I mentioned, come with reproducers and patches. The bad ones are a denial-of-service attack on the people you depend on. If your organization is deploying AI against open source code, fund the triage capacity at the other end.

Where I think attention is misplaced: AI does not patch your systems. It does not inventory your assets, rotate your credentials, retire your unsupported hardware, or make someone accountable for the certificate that expires next month. Organizations buying AI security tooling while running software with known unpatched vulnerabilities have their sequencing wrong. The unglamorous work is still where the risk is.

Many organizations invest heavily in tools but remain vulnerable because of configuration mistakes, outdated systems, weak processes, or poor incident preparation. What are the most consequential security mistakes you continue to see, and what should leadership teams have in place before an attack actually occurs?

The most consequential mistake is treating security as a procurement activity. Tools are purchased, budgets are met, dashboards are green, and nobody has asked whether the organization can actually do the fundamental things.

The second is not knowing what you run. You cannot patch software you do not know you have, and most organizations discover the true contents of their estate during an incident. This is why the bill-of-materials work matters, not as a compliance artifact but as the thing you reach for at two in the morning when a critical advisory drops and someone asks whether you are affected.

The third is defaults. Systems get installed, they work, and the configuration is never revisited. Five years later that configuration is a liability, and nobody involved in the original decision still works there.

The fourth is key and certificate management left to individuals. A remarkable proportion of self-inflicted outages are expired certificates that one person was quietly tracking in a spreadsheet until they changed jobs.

Before an incident, leadership needs four things in place. A named decision-maker with the authority to take the business offline, decided in advance and in writing, because the argument about who has that authority is not one you want to have live. Retainers already signed with external forensics and specialist counsel, because that procurement takes weeks and you will have hours. A communications channel that does not depend on the systems that may be compromised. And a restore capability that has actually been tested end-to-end, not a backup regime that has been verified only in the sense that the jobs completed successfully.

Then rehearse it. A tabletop exercise at executive level, once a year, will surface more genuine gaps than another tool.

When a serious cyberattack does happen, executives can suddenly find themselves making technical, legal, operational, and communications decisions under enormous pressure. What separates organizations that respond effectively from those that allow an incident to become substantially worse?

The organizations that handle it well have made the important decisions before the incident, so that during the incident they are executing rather than deliberating. That is most of it.

Beyond preparation, a few things consistently separate good responses from bad ones.

They separate the technical investigation from the executive and communications track, with a defined interface between them. When the same people are trying to contain an intrusion and draft a customer notification, both jobs are done badly.

They preserve evidence before they remediate. The instinct to rebuild the compromised machine immediately is powerful and it destroys the information you need to establish scope. If you cannot answer “what else did they touch,” you cannot credibly tell anyone the incident is over.

They accept that early information is provisional and communicate accordingly. Most of the reputational damage I have observed came not from the breach but from confident early statements that had to be retracted. Saying “here is what we know, here is what we do not yet know, here is when we will update you” is not weakness. It is the only position you will not have to reverse.

And critically: they create conditions where engineers can tell executives bad news. The failure pattern I have seen most often is an organization where the legal exposure was so evident that nobody wanted to be the person who wrote down what actually happened. The incident then gets worse in silence. If your engineers are managing their own liability rather than the incident, you have a governance problem that no amount of tooling will fix.

OpenSSL sits in an unusual position as critical open-source infrastructure used throughout the technology ecosystem, while the OpenSSL Corporation focuses on serving commercial communities alongside the independently operated OpenSSL Foundation. How do you balance the needs of enterprises, developers, regulators, and the broader open-source community when decisions about security and compatibility can affect such a large portion of the internet?

The honest answer is that you do not balance them by trying to make everyone happy in each decision. You balance them by having a published policy and applying it predictably, so that people can plan around you even when they dislike a particular outcome.

Predictability is what we owe our users. We ship feature releases in April and October. We say in advance which release is long-term stable and until when. We announce significant removals well ahead of them happening. The ENGINE removal in 4.0 was described publicly months before the release, and agreed by both the Corporation and the Foundation. Anyone who was surprised by it in April had not been paying attention, and we had made it as easy as we reasonably could to pay attention.

The structural answer is the separation itself. The Foundation exists to serve the open source library and the community around it. The Corporation exists to serve organizations with commercial requirements (support commitments, FIPS validation, specific timelines) and to make the whole thing financially sustainable. Keeping those distinct means neither set of needs is quietly resolved in the other’s favor. When enterprise requirements and community requirements genuinely conflict, that conflict happens between two organizations with clear remits rather than inside one person’s head.

The other part is listening properly, which requires actual mechanisms rather than assumptions. That is a large part of why we run the conference, which is in Prague this October, and why the community infrastructure exists. It is very easy for maintainers to develop confident theories about what users need. It is considerably more useful to be in a room with them.

Looking at the next decade, what security or cryptographic transition do you believe organizations are still underestimating today, and what lessons from the evolution of SSL, OpenSSL, and the past 30 years of internet security should leaders apply as they prepare for it?

The transition I think is most underestimated is not post-quantum cryptography as an algorithm problem. It is machine identity and the certificate hierarchy underneath everything.

Post-quantum key exchange will be largely solved by defaults, and much of it already has been. What will not be solved by defaults is the trust infrastructure: root certificates in hardware, firmware signing keys burned into devices, HSMs with a decade of remaining service life, industrial and medical systems that will still be running in 2040 with cryptographic assumptions baked in at manufacture. Those cannot be updated by shipping a new library version, and in some cases cannot be updated at all. The scale of that replacement problem is not currently reflected in anyone’s capital planning.

Running alongside it is a regulatory transition. The Cyber Resilience Act in Europe, and comparable frameworks elsewhere, will change the obligations attached to shipping software with components you did not write. Most organizations have not worked through what that means for their dependency on open source, or for the people maintaining it.

Three lessons from thirty years:

1. Transitions take a decade longer than announced. SSLv3 was deprecated in 2015, disabled by default in 2016, and we finally removed the code in April 2026. That is eleven years, for a protocol everyone agreed was broken. Plan post-quantum migration against that reality, not against the press release.
2. Defaults are the only security control that works at scale. Anything requiring every administrator to make a correct decision will not happen. The reason hybrid post-quantum key exchange has deployed as fast as it has is that it is on by default and requires no decision at all. Design for the people who will never read your documentation, because that is nearly everyone.
3. You depend on fewer people than you think. Almost every organization on earth relies on cryptographic code maintained by a very small number of individuals. That was true when it was two of us in Brisbane, and the structure has not fundamentally changed even as the stakes have risen by orders of magnitude. Whatever you are planning for the next decade, some part of it rests on a maintainer you have never contacted and are not funding. That is worth knowing before you need them.

Thank you for the great interview. Readers who wish to learn more should visit OpenSSL.