classification
Title: Add a way to get the peer certificate of a SSL Transport
Type: enhancement Stage: resolved
Components: asyncio Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, mathieui, pitrou, vstinner, yselivanov
Priority: normal Keywords: patch

Created on 2014-10-30 18:18 by mathieui, last changed 2015-09-14 22:02 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
peercert_bin.patch mathieui, 2014-10-30 18:18 simple patch adding a peercert_bin extra info to the transport review
Messages (9)
msg230281 - (view) Author: Mathieu Pasquet (mathieui) Date: 2014-10-30 18:18
Currently, the only workaround is to use transport._sock.getpeercert(True) on the Transport returned by loop.create_connection(), which is not something to be encouraged. It is useful to get such information, for example to perform a manual certificate check against a previously recorded certificate or hash.

I attached a trivial patch adding an extra 'peercert_bin' info, but I do not know if this is the right approach, as other issues of feature disparity might arise when more people try to switch to asyncio. Exposing a proxy SSLSocket object for read-only functions might be more beneficial.
msg230282 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-30 18:24
Thanks for the patch!

> other issues of
> feature disparity might arise when more people try to switch to asyncio. 
> Exposing a proxy SSLSocket object for read-only functions might be
> more beneficial.

I'm not sure that would make a difference. We still have to implement the proxy SSLSocket, which is no easier than adding the extra info by hand. Or did I misunderstand you?
msg230284 - (view) Author: Mathieu Pasquet (mathieui) Date: 2014-10-30 18:48
>I'm not sure that would make a difference. We still have to implement
>the proxy SSLSocket, which is no easier than adding the extra info by
>hand. Or did I misunderstand you?


The difference would be that exposing methods can be more future-proof, as some methods take parameters (like the offender getpeercert(bool), or get_channel_binding() that takes an element of ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need to be covered in the properties. But the API of SSLSocket is stable and small so I don't think it really matters.
msg230287 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-30 18:56
> some methods take parameters (like the offender getpeercert(bool), or 
> get_channel_binding() that takes an element of 
> ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need 
> to be covered in the properties

That's a good point. I don't have any strong feelings either way. Perhaps other people want to chime in?

As for the patch, it will need to add a unit test as well.
msg230319 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2014-10-31 02:26
Maybe

transport.get_extra_info('socket').getpeercert(True)

would be okay, no patch needed?

On Thu, Oct 30, 2014 at 11:56 AM, Antoine Pitrou <report@bugs.python.org>
wrote:

>
> Antoine Pitrou added the comment:
>
> > some methods take parameters (like the offender getpeercert(bool), or
> > get_channel_binding() that takes an element of
> > ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need
> > to be covered in the properties
>
> That's a good point. I don't have any strong feelings either way. Perhaps
> other people want to chime in?
>
> As for the patch, it will need to add a unit test as well.
>
> ----------
> stage:  -> patch review
> versions: +Python 3.5 -Python 3.4
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22768>
> _______________________________________
>
msg230333 - (view) Author: Mathieu Pasquet (mathieui) Date: 2014-10-31 11:22
>Maybe
>transport.get_extra_info('socket').getpeercert(True)
>would be okay, no patch needed?

Thanks, that indeed works; I don't know why I missed it while reading the source. Maybe the docs could use some clarification, though? (users are not supposed to know that _SelectorTransport is subclassed by _SelectorSslTransport, which thus gets the extra info of both)
msg230334 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-31 11:38
> Maybe
> transport.get_extra_info('socket').getpeercert(True)
> would be okay, no patch needed?

That will be problematic with issue22560. The clear-text socket object and the SSL object become unrelated, and it would be logical for get_extra_info('socket') to return the clear-text socket, so either a get_extra_info('ssl') would be needed, or we should expose the SSL properties directly as extra info members.
msg232167 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-12-05 00:48
> Thanks, that indeed works; I don't know why I missed it while reading the source.

Ok, it looks like we can close the issue.

> That will be problematic with issue22560.

In this case, it should be discussed there.
msg250707 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-09-14 22:02
In Python 3.5, it's no more possible to get the peer certificate as binary. See the issue #25114 for a general fix.
History
Date User Action Args
2015-09-14 22:02:34vstinnersetmessages: + msg250707
2014-12-05 07:37:11berker.peksagsetstage: patch review -> resolved
2014-12-05 00:48:38vstinnersetstatus: open -> closed
resolution: not a bug
messages: + msg232167
2014-10-31 11:38:09pitrousetmessages: + msg230334
2014-10-31 11:22:26mathieuisetmessages: + msg230333
2014-10-31 02:26:21gvanrossumsetmessages: + msg230319
2014-10-30 18:56:36pitrousetstage: patch review
messages: + msg230287
versions: + Python 3.5, - Python 3.4
2014-10-30 18:48:31mathieuisetmessages: + msg230284
2014-10-30 18:24:34pitrousetnosy: + pitrou
messages: + msg230282
2014-10-30 18:18:56mathieuicreate