Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 6 ■ TLS AND SSL
The Linksys router here at my house, by contrast, uses a self-signed certificate that can provide
encryption but fails to provide a signature that can be verified against any of the famous CAs in the
certfiles.crt file. So, with the conservative settings in our sslclient.py program, the connection fails:
$ python sslclient.py ten22.rhodesmill.org
Traceback (most recent call last):
...
ssl.SSLError: [Errno 1] _ssl.c:480: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Interestingly, Google (as of this writing) provides a single www.google.com certificate not only for that
specific domain name, but also for its google.com address since all that is hosted there is a redirect to the
www name:
$ python sslclient.py google.com
Certificate error: hostname 'google.com' doesn't match u'www.google.com'
$ python sslclient.py www.google.com
The document https://www.google.com/ is 9014 bytes long
Writing an SSL server looks much the same: code like that in Listing 3-1 is supplemented so that the
client socket returned by each accept() call gets immediately wrapped with wrap_socket(), but with
different options than are used with a client. In general, here are the three most popular ways of using
wrap_socket() (see the ssl Standard Library documentation to learn about all of the rest of its options):
The first form is the one shown in Listing 6–1, and is the most common form of the call seen in clients:
wrap_socket(sock, ssl_version=ssl.PROTOCOL_SSLv3,
» cert_reqs=ssl.CERT_REQUIRED, ca_certs=ca_certs_path)
Here the client asserts no particular identity—at least, TLS provides no way for the server to know
who is connecting. (Since the connection is now encrypted, of course, a password or cookie can now be
passed safely to the server; but the TLS layer itself will not know who the client is.)
Servers generally do not care whether clients connect with certificates, so the wrap_socket() calls
that they make after an accept() use a different set of named parameters that provide the documents
that establish their own identity. But they can neglect to provide a database of CA certificates, since they
will not require the client to present a certificate:
wrap_socket(sock, server_side=True, ssl_version=ssl.PROTOCOL_SSLv23,
» cert_reqs=ssl.CERT_NONE,
» keyfile="mykeyfile", certfile="mycertfile")
Finally, there do exist situations where you want to run a server that checks the certificates of the
clients that are connecting. This can be useful if the protocol that you are wrapping provides weak or
even non-existent authentication, and the TLS layer will be providing the only assurance about who is
connecting. You will use your CA to sign client certificates for each individual or machine that will be
connecting, then have your server make a call like this:
wrap_socket(sock, server_side=True, ssl_version=ssl.PROTOCOL_SSLv23,
» cert_reqs=ssl.CERT_REQUIRED, ca_certs=ca_certs_path,
» keyfile="mykeyfile", certfile="mycertfile")
Again, consult the ssl chapter in the Standard Library if you need to delve into the options more
deeply; the documentation there has been getting quite a bit better, and might cover edge cases that we
have not had room to discuss here in this chapter.
If you are writing clients and servers that need to talk only to each other, try using PROTOCOL_TLSv1 as
your protocol. It is more modern and secure than any of the protocols that have SSL in their names. The
only reason to use SSL protocols—as shown in the foregoing example calls, and which are also currently
97