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

CHAPTER 6 ■ TLS AND SSL
If you do ever want to exercise some application-level IP access control in a particular program,
simply examine the IP address returned by the accept() method on the socket with which your
application is listening:
sc, sockname = s.accept()
if not sockname[0].startswith('192.168.'):
» raise RuntimeError('connectors are not allowed from another network')
If you are interested in imposing the very specific restriction that only machines on your local
subnet can connect to a particular service, but not machines whose packets are brought in through
gateways, you might consider the SO_DONTROUTE option described in Chapter 2. But this restriction, like
all rules based only on IP address, implies a very strong trust of the network hardware surrounding your
machine—and therefore falls far short of the kind of assurance provided by TLS.
Finally, I note that the Ubuntu folks—who use Python in a number of their system and desktop
services—maintain their own package for accessing libwrap0, a shared-library version of Wietse's old
code, based on a Python package that was released on SourceForge in 2004. It allows them to do things
like the following:
>>> from pytcpwrap.tcpwrap import TCPWrap
>>> TCPWrap('foo', None, '130.207.244.244').Allow()
False
But since this routine can be rather slow (it always does a reverse DNS lookup on the IP address),
the Python code uses tabs and old-fashioned classes, and it has never been released on PyPI, I
recommend against its use.
Cleartext on the Network
There are several security problems that TLS is designed to solve. They are best understood by
considering the dangers of sending your network data as “cleartext” over a plain old socket, which copies
your data byte-for-byte into the packets that get sent over the network.
Imagine that you run a typical web service consisting of front-end machines that serve HTML to
customers and a back-end database that powers your service, and that all communication over your
network is cleartext. What attacks are possible?
First, consider an adversary who can observe your packets as they travel across the network. This
activity is called “network sniffing,” and is quite legitimate when performed by network administrators
trying to fix problems on their own hardware. The traditional program tcpdump and the more sleek and
modern wireshark are both good tools if you want to try observing some network packets yourself.
Perhaps the adversary is sitting in a coffee shop, and he has a wireless card that is collecting your
traffic as you debug one of the servers, and he keeps it for later analysis. Or maybe he has offered a bribe
to a machine-room operator (or has gotten himself hired as a new operator!) and has attached a passive
monitor to one of your network cables where it passes under the floor. But through whatever means, he
can now observe, capture, and analyze your data at his leisure. What are the consequences?
• Obviously, he can see all of the data that passes over that segment of the network.
The fraction of your data that he can capture depends on how much of it passes
over that particular link. If he is watching conversations between your web front
end and the database behind it, and only 1% of your customers log in every day to
check their balances, then it will take him weeks to reconstruct a large fraction of
your entire database. If, on the other hand, he can see the network segment that
carries each night's disk backup to your mass storage unit, then in just a few hours
he will learn the entire contents of your database.
90