The pandemic of incomplete OpenSSL error handling | Blog of Julian Andres Klode

July 3, 2026

The pandemic of incomplete OpenSSL error handling

Recently a person reported a bug in APT saying that TLS is failing on FIPS<br>systems with MD5 errors, and suggested we call ERR_clear_error() around<br>TLS operations.

Like any serious software engineer would do, I said No. Just because one component<br>failed to handle its errors does not mean I can go around and discard all errors<br>in another place - the program should have failed earlier (or discarded the error<br>when it was determined to be safe).

Little did I know that people have for years been using this approach as a best<br>practice: Codebases everywhere are littered with calls to ERR_clear_error()<br>before performing TLS, and upstream themselves suggest to do just that.

This is a major, systemic, pandemic of incomplete error handling. We cannot<br>just discard unrelated errors if they become inconvenient. The code that<br>caused the error needs to be fixed to handle it.

This isn&rsquo;t all. It seems many authors are not familiar with libraries using a<br>stack of errors, and there is a second anti-pattern:

Call an OpenSSL operation, check the top-level error, and then discard all<br>errors if deemed &ldquo;not too bad&rdquo;. This has the same problem: Unrelated errors<br>get silently discarded.

I would strongly encourage everyone to inspect their code bases for any calls<br>to ERR_clear_error() and whether they are safe or one of the bad patterns<br>above (or maybe you find a new pattern). You may want to use error stack<br>functionality ofERR_set_mark (https://docs.openssl.org/3.4/man3/ERR_set_mark/)<br>to essentially &ldquo;push&rdquo; and &ldquo;pop&rdquo; an error context of your own as a guard around<br>multiple OpenSSL operations.

To the OpenSSL authors, I would suggest not encouraging devastating security<br>practices that fundamentally break any trust in software.

We need to do better than this.

Reactions from Mastodon

Replies from Mastodon can only be shown when JavaScript is enabled. This<br>might cause requests to mastodon.social to be made.

Copyright © 2018-2020 Julian Andres Klode, articles licensed under CC BY-SA 4.0.

Comments are provided by Mastodon and copyright of their authors.

This website does not store any personally identifiable information. As part of standard web server<br>access_log logging, it stores requests and the user agents and shortened IP addresses used to make<br>them. It does, however, load some avatars from mastodon.

Powered by Hugo, and the Ernest theme.