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

C H A P T E R 6
■ ■ ■
TLS and SSL
The short story is this: before you send sensitive data across a network, you need proof of the identity of
the machine that you think is on the other end of the socket, and while sending the data, you need it
protected against the prying eyes of anyone controlling the gateways and network switches that see all of
your packets. The solution to this problem is to use Transport Layer Security (TLS). Because earlier
versions of TLS were called the Secure Sockets Layer (SSL), nearly all of the libraries that you will use to
speak TLS actually still have SSL somewhere in the name.
Simple enough?
The actual libraries introduced in this chapter, and all of the program listings that we will discuss,
are going be about TLS; that is really the only take-home coding lesson you will find here. But we will do
the actual examples last, once you have enough context to understand what they can—and cannot—do
for the security of your network programs.
Computer Security
The subject of computer security is vast, with its own pundits, blogs, magazines, conferences, academic
journals, consultancies, and product lines. And the subject is deserving of this extensive treatment: it is
important, it is often done badly, and we programmers are still—as a profession—a very long way from
even beginning to consistently get it right.
The field also has its share of charlatans and con men. And, of course, there are legions who work to
subvert security mechanisms. Script kiddies seek surreptitious control over thousands of Windows
desktops to power their next denial-of-service attack against their middle school. Organized criminals
want to steal millions of dollars (or pounds sterling, or yen, or rupees, depending on their jurisdiction)
through intercepted credit card numbers and identity theft. Militaries and governments seek to protect
their own information systems while gaining the ability to commandeer or disable those of their rivals.
How can we competently dare to write programs that will be on the same network as such
significant threats?
It may be foolish for me to attempt to answer this question; I should perhaps, at this point, be
sending you right into the vast literature on the subject of secure software, and not risking offering you a
few pointers when volumes of wisdom are what you really need. But since some readers may read this
book on a tight schedule, tasked with adding TLS to some hastily written network program just days
before it ships, I will go ahead and offer a few short thoughts on creating half-decent software.
First, always have thorough tests. Use Ned Batchelder's coverage tool to measure how much of your
code is being tested at all. Freely refactor your code until testing each module is not just possible, but
downright convenient! When a module is difficult to test, that is an excellent signal that the module has
too many hard-coded entanglements with other parts of the code, and that it will be difficult to predict
how the system as a whole will behave. The ease with which code can be tested, in other words, is often
directly related to how easy it is to draw a boundary around which other parts of the system the code can
directly affect.
87