For those of you following along at home, there's now a patch at
http://bill.janssen.org/python/ssl-update-diff which applies against
the current trunk. Working code, though I still need to tweak some
import statements for backwards compatibility. I've started updating
the test suite, see Lib/tes
> getpeercert() -- analogue to "getpeeraddr", but returns cert details
This would return three kinds of values:
No certificate received --> None
Certificate received but not validated --> {}
Certificate received and validated --> { full details }
Bill
__
> Can the TLS handshake be made to respect timeouts on sockets, or would
> this require changes deep inside OpenSSL?
I'm not sure. Good test case to try. I believe it will work.
By the way, interested parties should read
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html
and think about
> Should there be an "SSL socket", which is
> just like a regular socket? Does that really provide any additional
> functionality to anyone? Most apps and classes that use TCP sockets
> wrap the socket with socket._fileobject() to get "read" and "write",
> anyway -- can't they just wrap it with s
+1 for mutual authentication, I would use this.
Can the TLS handshake be made to respect timeouts on sockets, or would
this require changes deep inside OpenSSL?
Graham
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
> This is a self-signed cert, and it's still an open question whether
> they should verify, and under what circumstances. I'm currently
> thinking that in the CERT_OPTIONAL regime, they could, but with
> CERT_REQUIRED, they shouldn't.
If an application wanted self-signed certs to verify under
CER
> > The simplest way to do verification is to allow the application to
> > provide a set of root certs that it would like to verify against, and
> > use the built-in OpenSSL verification procedure.
>
> That's good. I don't recall whether you planned for this, however,
> it would then be necessary
> The simplest way to do verification is to allow the application to
> provide a set of root certs that it would like to verify against, and
> use the built-in OpenSSL verification procedure.
That's good. I don't recall whether you planned for this, however,
it would then be necessary to find out
> * Allow certificate validation. This is a bit tricky; typically
> certs are validated against some database of root certificates, so you
> need a whole infrastructure to maintain that database. Currently, we
> don't have one, so no certs can be validated. We could add a switc
> I view TLS as a wrapper around / layer on top of TCP, and so I think the
> API should look like, as well.
I think Martin raises a valid point here, which should at least be
discussed more thoroughly. Should there be an "SSL socket", which is
just like a regular socket? Does that really provide
> Yes, you're right. Of course, STARTTLS is properly regarded as a
> terrible hack :-).
I know you mean that jokingly - but I think it is considered as the
*proper* usage of TLS, with all these "let's use a different well-known
port for TLS over X" being those protocols that are hacks. I believe
> That's somewhat limiting - you should be able to do connection
> upgrades (e.g. SMTP STARTTLS, or HTTP Connection: Upgrade); with
> that design, such usages would not be possible, no?
Yes, you're right. Of course, STARTTLS is properly regarded as a
terrible hack :-).
The actual functionality e
> We add to the socket module a subtype of socket.socket,
> socket.SSLSocket. It has the following constructor:
>
> SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0,
>cert_filename=None, key_filename=None,
>cert_policy=CERT_NONE, ssl_protocol=PROTOCOL_SSLv23)
That's
All right, here's my current design :-).
We add to the socket module a subtype of socket.socket,
socket.SSLSocket. It has the following constructor:
SSLSocket (family=AF_INET, type=SOCK_STREAM, proto=0,
cert_filename=None, key_filename=None,
cert_policy=CERT_NONE, ssl
> I'm very tempted to add an optional parameter to socket.ssl(), which
> will be a callback function which will be passed the remote side's IP
> address and credentials, and which may raise an exception if it
> doesn't like the credentials. The exception would then be re-raised
> from socket.ssl()
> The idea is that if you call socket.ssl() on a socket that's bound to
> an address, the socket is assumed to be server-side, the cert passed
> in is assumed to be a server-side cert, and the SSLObject returned has
> a couple of extra methods, listen() and accept(). Calling accept() does
> the SS
16 matches
Mail list logo
