[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Christian Heimes  added the comment:

BPO #31372 and #18369 provide the necessary bits and pieces for your request. I 
didn't have enough time to finish both in time for 3.7 feature freeze. Hostname 
verification improvements and TLS 1.3 were more important.

I'm closing this issue because ssl.wrap_socket() is deprecated and will be 
removed in the future.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Changes by Christian Heimes :


--
assignee:  -> christian.heimes
components: +SSL
versions: +Python 3.7 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Changes by Christian Heimes :


--
assignee: christian.heimes -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Sascha Silbe]

Sascha Silbe added the comment:

Has there been any progress on this? For my application I'd very much like 
"ssh-like" operation, using the public key itself as identifier rather than 
requiring some kind of automated CA setup.

Being able to set a custom verification callback would be great, but just being 
able to cause a dummy callback that accepts any certificate to be used would go 
a long way. The validation could be done after the connection was established 
in this case. For some applications, that may even be the best approach, 
presenting any verification error via the application layer (e.g. HTTP) where 
they are closer to the problem domain and thus make more sense to the user.

--
nosy: +sascha_silbe

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Changes by Christian Heimes :


--
assignee:  -> christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Christian Heimes added the comment:

I may address the issue in my PEP for Python 3.5. Python 3.4 beta 1 will be 
released next week and no new features are allowed in beta and RC phase.

--
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Antoine Pitrou]

Antoine Pitrou added the comment:

getpeercert() has a crappy API to begin with, but we can't change its behaviour 
for fear of breaking existing code (and, even, breaking it security-wise). 
Adding a parameter would make the API even more awful.

Which is why I support Christian's idea of exposing a new API, either:
- to expose the full cert chain (even if not validated)
- or to set the cert verify callback

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Derek Wilson]

Derek Wilson added the comment:

Custom cert validation may make sense in edge cases, so this looks interesting.

But I got here looking to file a bug on the returning empty dict from 
SSLContext.getpeercert - I don't feel like that makes sense. Its not like a 
peer cert doesn't exist just because it doesn't pass verification. 

And I know I can get the binary DER cert, but then I need to figure out how to 
parse it myself? pyasn1 makes me cry. 

It would be really nice if we could get the decoded-into-dict peer cert even 
when verification fails or when CERT_NONE is set. If it isn't possible (or 
advisable) for getpeercert to return the dict, exposing cert decoder would be 
really useful.

Is this related enough to this request or should I file a separate issue?

--
nosy: +underrun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[mpb]

mpb added the comment:

Christian wrote:
> sslsocket gives you access to the peer's cert and chain (with 
> #18233).

Very interesting (and useful).  I've mostly been working with Python
2.7, and I had not fully noticed that Python 3.2+ has a ssl.SSLContext
class.

> I'd rather not implement a full wrapper for X509_STORE_CTX and X509 
> certs. It's way too much code, super complex and easily confuses even 
> experienced developers. Python's ssl module is limited to core 
> functionality by design and choice.

> However I might be intrigue to implement support for
> SSL_CTX_set_cert_verify_callback() or SSL_CTX_set_verify().

SSL_CTX_set_verify() seems (mostly) redundant SSLContext.verify_mode.  
Or am I missing something?

> SSL_CTX_set_cert_verify_callback() has more potential, e.g.
> 
> def cert_verify_callback(sslsocket, storectx, verify_ok):
> context = sslsocket.context
>
> storectx is a minimal X509_STORE_CTX object and verify_ok the boolean
> return value of X509_verify_cert(). Without a cert verify callback
> OpenSSL just uses the return value of X509_verify_cert()
> (ssl/ssl_cert.c:ssl_verify_cert_chain()).

I believe support for SSL_CTX_set_cert_verify_callback() would allow
customized certificate verification, which is what I am looking for.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Christian Heimes added the comment:

> Thanks for the pointer about being able to get the server's DER certificate.  
> That will be useful.  Is there some reason to return DER but not PEM?  Or is 
> this perhaps a bug that could be fixed in a future version of Python's ssl 
> module?

It doesn't matter how getpeercert() returns the raw cert. PEM and DER
encode the X.509 same in ASN.1 notation. PEM is just the base64
representation with some line breaks surrounded BEGIN/END CERTIFICATE lines.

> Christian wrote: "Optional and required verification makes only a 
> differen[ce] for client side certs."
> 
> I believe there is one small exception:  With SSL_VERIFY_NONE, a client will 
> continue talking with a server with an invalid certificate.  With 
> SSL_VERIFY_PEER, when a client fails to verify the server's certificate, the 
> client will terminate the connection.

You are referring to server side certs, that is the server provides a
cert and the client verifies it. I was talking about client side cert
(aka server mode), a rarely used mode in which the client side provides
a cert to the server. In CERT_OPTIONAL mode the client is allowed to
send no cert. CERT_REQUIRED is mapped to SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT.

> Ideally, I would like a client to be able to get both of  the following from 
> the API: (a) the server's certificate (and chain?), and (b) whether or not 
> the certificate (and chain?) is valid (against a given sets of root certs).

In client mode you already have the server's cert and as much of the
chain as the peer (server) provides. SSL_VERIFY_NONE makes no difference
because the server cert is used in the ClientHello / ServerHello
handshake and session key negotiation.

Perhaps you are a bit confused by Python's ssl API. Somebody once made
the choice to return an empty dict from getpeercert(False) when
SSL_VERIFY_NONE is used. That's all. :)
http://hg.python.org/cpython/file/76196691b5d0/Modules/_ssl.c#l1098

> I'm not sure how much of this functionality the Python developers might be 
> interested in putting into Python 3.4?  Given that M2Crypto does not work 
> with Python 3.x at all (at least not yet?), I am interested in finding 
> something that will work with Python 3.x and give me the functionality I want.

I'd rather not implement a full wrapper for X509_STORE_CTX and X509
certs. It's way too much code, super complex and easily confuses even
experienced developers. Python's ssl module is limited to core
functionality by design and choice.

However I might be intrigue to implement support for
SSL_CTX_set_cert_verify_callback() or SSL_CTX_set_verify().
SSL_CTX_set_cert_verify_callback() has more potential, e.g.

def cert_verify_callback(sslsocket, storectx, verify_ok):
context = sslsocket.context

storectx is a minimal X509_STORE_CTX object and verify_ok the boolean
return value of X509_verify_cert(). Without a cert verify callback
OpenSSL just uses the return value of X509_verify_cert()
(ssl/ssl_cert.c:ssl_verify_cert_chain()). sslsocket gives you access to
the peer's cert and chain (with #18233).

The callback could be used for multiple uses cases like cert
blacklisting, too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[mpb]

mpb added the comment:

Oh, I see.  getpeercert (binary_form) is not DER vs. PEM, it is DER vs. dict.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[mpb]

mpb added the comment:

Hi Christian, thanks for the prompt response.

Sorry about choosing the wrong versions - I wasn't thinking that enhancements 
should target future versions, but of course that makes sense.

After submitting the enhancement request, I did dig into the OpenSSL docs, and, 
as Christian points out, I discovered that OpenSSL is not designed in a way 
that makes it easy to implement the enhancement.

Aside: Interestingly, it looks easier to implement the enhancement in PolarSSL, 
and probably also in MatrixSSL and CyaSSL.  Of course, that's not really an 
option.  I did not look at GnuTLS.

Thanks for the pointer about being able to get the server's DER certificate.  
That will be useful.  Is there some reason to return DER but not PEM?  Or is 
this perhaps a bug that could be fixed in a future version of Python's ssl 
module?

Christian wrote: "Optional and required verification makes only a differen[ce] 
for client side certs."

I believe there is one small exception:  With SSL_VERIFY_NONE, a client will 
continue talking with a server with an invalid certificate.  With 
SSL_VERIFY_PEER, when a client fails to verify the server's certificate, the 
client will terminate the connection.

Ideally, I would like a client to be able to get both of  the following from 
the API: (a) the server's certificate (and chain?), and (b) whether or not the 
certificate (and chain?) is valid (against a given sets of root certs).

Similarly, I would like a Python server to be able to get both of: (a) the 
client's certificate, and (b) whether the certificate is valid (against a given 
set of root certs).

In the latter case, it seems that OpenSSL is even more restrictive!  With 
SSL_VERIFY_NONE, the server will not request (and presumably therefore not even 
receive) a certificate.  With SSL_VERIFY_PEER, the server will terminate the 
connection if the client's certificate does not validate!  Very inconvenient!

Interestingly, I believe I have worked around this limitation in OpenSSL using 
M2Crypto (which is built on top of OpenSSL), by installing my own verifier that 
overrides the built-in verifier.  This is done as follows:

import M2Crypto.SSL
ctx  = M2Crypto.SSL.Context ()
ctx.load_cert ('var/cert.pem')
def verify (*args):  return True
ctx.set_verify (M2Crypto.SSL.verify_peer, 10, verify)

After doing this, both the client and the server can see each other's 
certificates, even if those certificates are invalid.  (Of course I'll have to 
write my own verifier.  "return True" is only useful for testing purposes.)

I'm not sure how much of this functionality the Python developers might be 
interested in putting into Python 3.4?  Given that M2Crypto does not work with 
Python 3.x at all (at least not yet?), I am interested in finding something 
that will work with Python 3.x and give me the functionality I want.

I can probably help with the C OpenSSL code, if needed.  However, I have no 
experience writing Python bindings.

Your thoughts?  Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Christian Heimes]

Christian Heimes added the comment:

I'm setting the version to 3.4 as this is a feature request. 2.7 and 3.3 are in 
feature freeze mode.

OpenSSL doesn't support our idea out of the box. OpenSSL either verifies the 
peer's certificate and chain or doesn't verify the peer's certificate and 
chain. Optional and required verification makes only a different for client 
side certs. Server side certs are always verified in both modes. See 
http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html#NOTES

When you are talking to a server the peer's certificate is always available, 
even in SSL_VERIFY_NONE mode. The server cert's public key is required to 
asymmetrically encrypt part of the session key. It's Python's ssl module that 
doesn't return the cert information in getpeercert() when 
SSL_CTX_get_verify_mode() doesn't have SSL_VERIFY_PEER. You can still get the 
DER encoded peer cert with getpeercert(True).

Now for something completely different: Without verification and the correct 
root cert it's not possible to get the root cert of a peer's chain (see issue 
#18233). AFAIK SSL doesn't provide the full root cert as part of the peer chain 
because the other side is suppose the have a copy of the chain root anyway. 
Different story, though.

--
versions: +Python 3.4 -Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[mpb]

mpb added the comment:

(Oops, I changed the title when I meant to do a search.  Changing it back now.)

--
title: ssl sni -> ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated 
certificates

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated certificates

[mpb]

New submission from mpb:

At present (Python 2.7.[45] and 3.3.[12]), the cert_reqs parameter of 
ssl.wrap_socket can be one of:

ssl.CERT_NONE
ssl.CERT_OPTIONAL
ssl.CERT_REQUIRED

I would find the following additional modes to be useful:
ssl.CERT_OPTIONAL_NO_VERIFY
ssl.CERT_REQUIRED_NO_VERIFY

In these cases, the server's certificate would be available via the 
.getpeercert () method, even if the certificate does not pass verification.

The use case for these modes would be connecting to servers, some of which may 
use valid certificates, and others of which may be using self signed 
certificates.

Another use case might be an "ssh-like" mode of operation.  ssh will warn the 
user of possible man-in-the-middle attacks if a server's public key has changed.

Thanks!

--
components: Library (Lib)
messages: 191796
nosy: mpb
priority: normal
severity: normal
status: open
title: ssl.wrap_socket (cert_reqs=...), getpeercert, and unvalidated 
certificates
type: enhancement
versions: Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com