[Python-Dev] Proposal for better SSL errors (original) (raw)

Gregory P. Smith greg at krypto.org
Sun May 27 04:31:55 CEST 2012

On Sat, May 26, 2012 at 12:28 PM, Antoine Pitrou <solipsis at pitrou.net>wrote:

Hello, In http://bugs.python.org/issue14837 I have attached a proof-of-concept patch to improve the exceptions raised by the ssl module when OpenSSL signals an error. The current situation is quite dismal, since you get a sometimes cryptic error message with no viable opportunities for programmatic introspection: >>> ctx = ssl.SSLContext(ssl.PROTOCOLTLSv1) >>> ctx.verifymode = ssl.CERTREQUIRED >>> sock = socket.createconnection(("svn.python.org", 443)) >>> sock = ctx.wrapsocket(sock) Traceback (most recent call last): [...] ssl.SSLError: [Errno 1] ssl.c:420: error:14090086:SSL routines:SSL3GETSERVERCERTIFICATE:certificate verify failed

SSLError instances only have a "errno" attribute which doesn't actually contain a meaningful value. With the posted patch, the above error becomes: >>> ctx = ssl.SSLContext(ssl.PROTOCOLTLSv1) >>> ctx.verifymode = ssl.CERTREQUIRED >>> sock = socket.createconnection(("svn.python.org", 443)) >>> sock = ctx.wrapsocket(sock) Traceback (most recent call last): [...] ssl.SSLError: [Errno 5] [SSL: CERTIFICATEVERIFYFAILED] certificate verify failed (ssl.c:494) [88296 refs] Not only does the error string contain more valuable information (the mnemonics "SSL" and "CERTIFICATEVERIFYFAILED" indicate, respectively, in which subpart of OpenSSL and which precise error occurred), but they are also introspectable: >>> e = sys.lastvalue >>> e.library 'SSL' >>> e.reason 'CERTIFICATEVERIFYFAILED' (these mnemonics correspond to OpenSSL's own #define'd numeric codes. I find it more Pythonic to expose the mnemonics than the numbers, though. Of course, the numbers <-> mnemnonics mappings can be separately exposed) You'll note there is still a "Errno 5" in that error message; I don't really know what to do with it. Hard-wiring the errno attribute to something like None might break existing software, although that would be unlikely since the current errno value is quite meaningless and confusing (it has nothing to do with POSIX errnos). To clarify a bit my request, I am asking for feedback on the principle more than on the implementation right now.

+1 I like it. It is better than what we have today.

As for the misleading errno attribute, since it is not a posix errno I think it could be hard wired to 0 for SSL errors if and only if openssl is not actually setting it to something meaningful. The fact that an exception was raised is the error and what the exception was about in the case of SSL errors can come from your new library and reason attributes.

There is a long term caveat to the overall approach: It still leaves the exception details being OpenSSL specific. If someone wants to ditch OpenSSL and use something else such as NSS (for example) in a future _ssl implementation what would its exception error info story look like?

I would go ahead with this work regardless. It improves on what we have today. Defining a nicer way for SSL exceptions that is library agnostic is a larger project that should be done independent of making what we have today easier to work with.

-gps -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120526/a3093431/attachment-0001.html>

More information about the Python-Dev mailing list