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

CHAPTER 6 ■ TLS AND SSL
discussion of all of the ways that public keys can be used to help secure key-cards, protect individual
documents, assert the identity of an e-mail author, and encrypt hard drives. Here, we will focus on how
public keys are used in the TLS system.
Public keys are used at two different levels within TLS: first, to establish a certificate authority (CA)
system that lets servers prove “who they really are” to the clients that want to connect; and, second, to
help a particular client and server communicate securely. We will start by describing the lower level—
how communication actually takes place—and then step back and look at how CAs work.
First, how can communication be protected against prying eyes in the first place?
It turns out that public-key encryption is pretty slow, so TLS does not actually use public keys to
encrypt all of the data that you send over the network. Traditional symmetric-key encryption, where
both sides share a big random block of data with which they encrypt outgoing traffic and decrypt
incoming traffic, is much faster and better at handling large payloads. So TLS uses public-key
cryptography only to begin each conversation: the server sends a public key to the client, the client sends
back a suitable symmetric key by encrypting it with the public key, and now both sides hold the same
symmetric key without an observer ever having been given the chance to capture it—since the observer
will not be able to derive (thanks to powerful mathematics!) the server's private key based on seeing the
public key go one way and an encrypted block of data going the other.
The actual TLS protocol involves a few other details, like the two partners figuring out the strongest
symmetric key cipher that they both support (since new ones do get invented and added to the
standard), but the previous paragraph gives you the gist of the operation.
And, by the way, the labels “server” and “client” here are rather arbitrary with respect to the actual
protocol that you wind up speaking inside your encrypted socket—TLS has no way to actually know how
you use the connection, or which side is the one that will be asking questions and which side will be
answering. The terms “server” and “client” in TLS just mean that one end agrees to speak first and the
other end will speak second when setting up the encrypted connection. There is only one important
asymmetry built into the idea of a client and server, which we will learn about in a moment when we
start discussing how the CA works.
So that is how your information is protected: a secret symmetric encryption key is exchanged using
a public-private key pair, which is then used to protect your data in both directions. That alone protects
your traffic against sniffing, since an attacker cannot see any of your data by watching from outside, and
it also means that he cannot insert, delete, or alter the packets passing across a network node since,
without the symmetric key, any change he makes to the data will simply produce gibberish when
decrypted.
TLS Verifies Identities
But what about the other class of attacks we discussed—where an attacker gets you to connect to his
server, and then talks to the real server to get the answers that you are expecting? That possibility is
protected against by having a certificate authority, which we will now discuss.
Do you remember that the server end of a TLS connection starts by sharing a public key with the
client? Well, it turns out that servers do not usually offer just any old public key—instead, they offer a
public key that has been signed by a CA. To start up a certificate authority (some popular ones you might
have heard of are Verisign, GeoTrust, and Thawte), someone simply creates a public-private key pair,
publishes their public key far and wide, and then starts using their private key to “sign” server public
keys by encrypting a hash of their data.
You will recall that only the holder of a private key can encrypt data that can then be decrypted with
the corresponding public key; anyone else in the world who tries will wind up writing data that just turns
into gibberish when passed through the public key. So when the client setting up a TLS connection
receives a public key from the server along with a block of encrypted data that, when decrypted with the
CA's public key, turns into a message that says “Go ahead and trust the server calling itself
db.example.com whose public key hashes to the value 8A:01:1F:…”, then the client can trust that it is
really connecting to db.example.com and not to some other server.
93