Erle Robotics Python Networking Gitbook Free

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.

What are the consequences of someone who can now observe, capture, and analyze your data at his leisure?

  • 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.
  • He will see any usernames and passwords that your clients use to connect to the servers behind them.
  • Log messages can also be intercepted, if they are being sent to a central location and happen to travel over a compromised IP segment or device. This could be very useful if the observer wants to probe for vulnerabilities in your software.
  • If your database server is not picky about who connects, aside from caring that the web front end sends a password, then the attacker can now launch a “replay attack,” in which he makes his own connection to your database and downloads all of the data that a front-end server is normally allowed to access.

Imagine an attacker who cannot yet alter traffic on your network itself, but who can compromise one of the services around the edges that help your servers find each other. Specifically, what if she can compromise the DNS service that lets your web front ends find your db.example.com server.Then some interesting tricks might become possible:

  • When your front ends ask for the hostname db.example.com, she could answer with the IP address of her own server, located anywhere in the world, instead.
  • The fake database server will be at a loss to answer requests with any real data that the intruder has not already copied down off the network.
  • If your database is not carefully locked down and so is not picky about which servers connect, then the attacker can do something more interesting: as requests start arriving at her fake database server, he can have it turn around and forward those requests to the real database server. This is called a “man-in-the-middle” attack: he will be in fairly complete control of your application.
  • While proxying the client requests through to the database, the attacker will probably also have the option of inserting queries of her own into the request stream. This could let her download entire tables of data and delete or change whatever data the front-end services are typically allowed to modify.