[Python-Dev] Proposal for better SSL errors

[Gregory P. Smith]

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.PROTOCOL_TLSv1)
> >>> ctx.verify_mode = ssl.CERT_REQUIRED
> >>> sock = socket.create_connection(("svn.python.org", 443))
> >>> sock = ctx.wrap_socket(sock)
> Traceback (most recent call last):
> [...]
> ssl.SSLError: [Errno 1] _ssl.c:420: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE: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.PROTOCOL_TLSv1)
> >>> ctx.verify_mode = ssl.CERT_REQUIRED
> >>> sock = socket.create_connection(("svn.python.org", 443))
> >>> sock = ctx.wrap_socket(sock)
> Traceback (most recent call last):
> [...]
> ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed (_ssl.c:494) [88296 refs]
>
>
> Not only does the error string contain more valuable information (the
> mnemonics "SSL" and "CERTIFICATE_VERIFY_FAILED" indicate, respectively,
> in which subpart of OpenSSL and which precise error occurred), but they
> are also introspectable:
>
> >>> e = sys.last_value
> >>> e.library
> 'SSL'
> >>> e.reason
> 'CERTIFICATE_VERIFY_FAILED'
>
> (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>