[Top] [All Lists]

Re: [ietf-smtp] TLS1.3

2020-04-29 17:03:17
Jeremy Harris writes:

For amusement, I see this week failing attempts to send messages
from what should be a reasonably large operator, using TLS1.3 ...
and failing to handle a client-cert request in the handshake.

It emits a fatal "unexpected message" alert.  Turn off the
client-cert request, and it works fine.

Name withheld to protect the guilty.

I wouldn't necessarily blame the operator. It's almost a sure bet that they're using OpenSSL, and this developer's opinion is that OpenSSL is one of the worst, most confusing, and the most poorly documented API libraries in existence.

It just so happens I'm in the middle of sort of like a modern version of playing chess by mail. You know: you and your partner halfway across the world have identical chessboards set up, and you have a turn-based game, by postal mail, going on. I recall reading about those things, a long time ago. Except that this is more like an interactive, turn-based debugging session, rather than a chess match. After a few days' worth of back-and-forth, things have reached the stage where it's been determined that the OpenSSL library is reporting an error code that its own documentation describes thusly:

         Some non-recoverable, fatal I/O error occurred. The OpenSSL error
         queue may contain more information on the error. For socket I/O on
         Unix systems, consult errno for details.

And, immediately after that, the code in question does "consult errno", and finds that it's zero. No error has occured, according to the operating system.

Who to believe? And what exactly is someone supposed to do, with the SSL connection, at this point?

Random Googling around found a few similar, but not identical, reports of various other OpenSSL API functions randomly changing their behavior, depending on the negotiated version of TLS, to the confusion of the application code that expects existing behavior from them.

All my new code uses GnuTLS. The GnuTLS API is very logical, and very easily adaptable to either C or C++ code. Its very clear who owns what resource, unlike OpenSSL, where object ownership is rather …fluid, so for years various apps turn out to be trying to use various library objects after they're freed, or they leak memory, etc…

Attachment: pgp2m1w2GRWje.pgp
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>