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

CHAPTER 6 ■ TLS AND SSL
Thus man-in-the-middle attacks are thwarted, and it does not matter what tricks an attacker might
use to rewrite packets or try to get you to connect to his server instead of the one that you really want to
talk to. If he does not return to you the server's real certificate, then it will not really have been signed by
the CA and your TLS library will tell you he is a fake; or, if the attacker does return the server's
certificate—since, after all, it is publicly transmitted on the network—then your client will indeed be
willing to start talking. But the first thing that your TLS library sends back will be the encrypted
symmetric key that will govern the rest of the conversation—a key, alas, that the attacker cannot decrypt,
because he does not possess the private key that goes along with the public server certificate that he is
fraudulently waving around.
And, no, the little message that forms the digital signature does not really begin with the words “Go
ahead” followed by the name of the server; instead, the server starts by creating a “certificate” that
includes things like its name, an expiration date, and its public key, and the whole thing gets signed by
the CA in a single step.
But how do clients learn about CA certificates? The answer is: configuration. Either you have to
manually load them one by one (they tend to live in files that end in .crt) using a call to your SSL library,
or perhaps the library you are using will come with some built in or that are provided by your operating
system. Web browsers support HTTPS by coming with several dozen CA certificates, one for each major
public CA in existence. These companies stake their reputations on keeping their private keys absolutely
safe, and signing server certificates only after making absolutely sure that the request really comes from
the owner of a given domain.
If you are setting up TLS servers that will be contacted only by clients that you configure, then you
can save money by bypassing the public CAs and generating your own CA public-private key pair.
Simply sign all of your server's certificates, and then put your new CA's public key in the configurations
of all of your clients.
Some people go one step cheaper, and give their server a “self-signed” certificate that only proves
that the public key being offered to the client indeed corresponds to a working private key. But a client
that is willing to accept a self-signed certificate is throwing away one of the most important guarantees
of TLS—that you are not talking to the wrong server—and so I strongly recommend that you set up your
own simple CA in every case where spending money on “real” certificates from a public certificate
authority does not make sense.
Guides to creating your own certificate authority can be found through your favorite search engine
on the Web, as can software that automates the process so that you do not have to run all of those
openssl command lines yourself.
Supporting TLS in Python
So how can you use TLS in your own code?
From the point of view of your network program, you start a TLS connection by turning control of a
socket over to an SSL library. By doing so, you indicate that you want to stop using the socket for
cleartext communication, and start using it for encrypted data under the control of the library.
From that point on, you no longer use the raw socket; doing so will cause an error and break the
connection. Instead, you will use routines provided by the library to perform all communication. Both
client and server should turn their sockets over to SSL at the same time, after reading all pending data off
of the socket in both directions.
There are two general approaches to using SSL.
The most straightforward option is probably to use the ssl package that recent versions of Python
ship with the Standard Library.
• The ssl package that comes with Python 3.2 includes everything that you need to
communicate securely.
94