Secure Transport Layer

In the early days of the Internet, networks were small and all of the routers were in secure locations. As long as each computer connected to the Internet protected itself from unwanted incoming connections, it was felt that there was no need to protect data from prying eyes while it was crossing the network.

So the Link, Internetwork, and Transport layers were focused on the efficient movement of data and solving the problems of a large-scale shared distributed network without worrying about the privacy of that data.

But as the use of the Internet grew rapidly in the late 1980s and literally exploded when the Web became mainstream in 1994, security and privacy of network traffic became very important problems to solve. When we began using the Internet to conduct commerce and credit cards and bank account numbers were being routinely sent across the network, securing data became essential. And when we started using wireless technologies like WiFi, security became necessary for even the simplest uses of the Internet.

There are two general approaches to securing network activity. The first makes sure that all of the network hardware (routers and links) is in physically secure locations so it is not possible for someone to sneak in and monitor traffic while it is crossing the Internet. This approach is not practical for hundreds of thousands of network routers owned and operated by many different organizations. While you might be able to ensure that some of the router operators adhered to strict security procedures and policies, sooner or later a mistake will be made. And once WiFi was added to the mix and your packets went over radio waves, a network attacker could just sit in a coffee shop and intercept packets as they passed through the air.

Under these conditions, the only reasonable solution is to encrypt data in your computer before it is sent across its first physical link, and then decrypt the data in the destination computer after it arrives. Using this approach, we assume that an attacker can see all of the packets that you send, but they cannot decrypt the data that they have captured. The encryption also guarantees that there is no way to alter your data while it is crossing the Internet.

Encrypting and Decrypting Data

The concept of protecting information so it cannot be read while it is being transported over an insecure medium is thousands of years old. The leaders in Roman armies sent coded messages to each other using a code called the “Caesar Cipher”. The simplest version of this approach is to take each of the characters of the actual message (we call this “plain text”) and shift each character a fixed distance down the alphabet to produce the scrambled message or “ciphertext”.

Then we send the ciphertext via the courier or other insecure transport to the other person. The courier cannot read the message because it appears to be random characters unless you know the technique used to encode the message.

As long as the person receiving the message knew the number used to shift the message, they could unshift the characters in the encoded message to reproduce the original message.

Here is a simple example of plain text and ciphertext using a shift of one:

Plain text:  Go to the river
Cipher text: Hp up uif sjwfs

We use the word “encrypt” to describe transforming the plain text to the ciphertext and “decrypt” to describe the reverse process.

The Caesar Cipher is very simple to defeat, but it was used to protect important messages until about 150 years ago. Modern encryption techniques are far more sophisticated than a simple character shift, but all encryption systems depend on some kind of a secret key that both parties are aware of so they can decrypt received data.

Two Kinds of Secrets

The traditional way to encrypt transmissions is using a shared secret (a password, a sentence, a number) that only the sending and receiving parties know. With the secret, it is easy to decrypt the received data, but if you received the data without possessing the secret, it would be effectively impossible to decrypt the message.

In the early days of the Internet, two people could send encrypted email to each other by one person first calling the other person on the phone and giving them the decryption secret. This worked well when there were only a few users on the network, but could not scale to situations where a company might have millions of customers and could not afford to make a phone call to each customer to establish a shared secret before they could make a purchase.

It might seem like a good idea to distribute the shared secrets over the Internet, but if we assume that the attackers are monitoring and capturing all network traffic, they could also capture the unencrypted message that contained the shared secret. At that point it would be trivial for the attacker to use the shared secret to decrypt a message. And even worse, the attacker could intercept a message, delay it, then decrypt it, change and re-encrypt it, and send the modified message back on its way. The receiving computer would decrypt the message and never know that it had been modified by an attacker while in transit.

So shared secrets clearly would not work to solve the problem of securing network traffic between trillions of pairs of networked computers.

The solution to this problem came in the 1970s when the concept of asymmetric key encryption was developed. The idea of asymmetric key encryption is that one key is used to encrypt the message and another key is used to decrypt it. The computer that will be receiving the encrypted data chooses both the encryption key and decryption key. Then the encryption key is sent to the computer that will be sending the data. The sending computer encrypts the data and sends it across the network. The receiving computer uses the decryption key to decrypt the data.

We call the encryption key the “public” key because it can be widely shared. We call the decryption key the “private” key because it never leaves the computer where it was created. Another name for asymmetric keys is public/private keys.

The whole process is designed so that if an attacker has the public key (which was sent unencrypted) and the encrypted text, it is virtually impossible to decrypt the encrypted data. There is a lot of math with large prime numbers that makes it hard to guess the private key from the public key and encrypted data.

So with the advent of public/private key technology, the only question left was how to apply it in our network model.

Secure Sockets Layer (SSL)

Since network engineers decided to add security nearly 20 years after the Internet protocols were developed, it was important not to break any existing Internet protocols or architecture. Their solution was to add an optional partial layer between the Transport layer and the Application layer. They called this partial layer the Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

When an application requested that the Transport layer make a connection to a remote host, it could request that the connection either be encrypted or unencrypted. If an encrypted connection was requested, the Transport layer encrypted the data before breaking the stream into packets. This meant that the Transport layer, Internetwork layer, and physical (link) layers could still perform exactly the same way whether the packets were encrypted or non-encrypted. The applications making the connections were also spared the details of how encryption and decryption worked.

Since encryption was a simple and transparent addition to the Transport layer, there was no need to change the routers that operate at the Internetwork and Link layers. There was no need to change any Link layer hardware to make encryption work. And applications did not need to be modified except to request that a connection be encrypted when appropriate.

Encrypting Web Browser Traffic

Since web browsers and web servers operate at the application layer, we barely notice whether we are using encrypted or unencrypted connections. Web browsers use the URL convention of replacing “http:” with “https:” to indicate that the browser is to communicate with the web server using the Secure Transport Layer instead of the unencrypted Transport layer. Your browser will usually show a “lock” icon in the address bar to let you know that you are communicating with a secure web site.

There is a small overhead in setting up the https connections and a small cost to encrypt and decrypt the data that is being sent. Since https was slightly more costly, for a while it was used only for pages that contained passwords, bank account numbers, or other sensitive data.

But over time as networks have become faster and the https implementations have gotten much more efficient, there is a trend toward encrypting all web server interactions whenever you are interacting with a web server where you have an account. The current trend is towards using https for all web traffic.

Certificates and Certificate Authorities

While public/private key encryption works to allow the distribution of encryption keys across insecure networks and the use of those keys to encrypt transmissions, there is still a problem of knowing if the public key that you have received when you connected to a server is really from the organization it claims to be from.

Perhaps you think you are connecting to www.amazon.com but a rogue computer intercepts your traffic, claiming to be www.amazon.com and giving you a public key to use for encryption. If your web browser trusts the key, it will use the rogue computer’s public key to encrypt your banking information and send it to the rogue computer. Since the rogue computer gave you the public key, it also has the corresponding private key and is able to decrypt and abscond with your banking information.

So your computer needs to know who the key is actually coming from. This is achieved by sending you a public key that is digitally signed by a Certificate Authority (CA). When your computer or browser is initially installed, it knows about a number of well-known certificate authorities. If your browser is given a public key that is signed by one of the well-known certificate authorities, it trusts the key and uses it to encrypt and send your data. If your computer receives a public key that is not signed by one of its trusted certificate authorities, it will warn you before sending your data using the key.

If you see a warning message about an untrusted certificate, you should probably say “no” and figure out why your network traffic is not being routed to the server that you think it is going to before sending any sensitive data.

Summary

Since the Internet was nearly 20 years old before we needed broadly deployed security, we had to find a way to add security to the already existing four-layer model. The perfect place to add security was as an option in the Transport layer. This is why we call secure connections on the Internet “Secure Sockets Layer” (SSL) or “Transport Layer Security” (TLS). There are subtle differences between SSL and TLS but they both encrypt data at the Transport layer.

The invention of public/private key encryption was well timed in that it solved the key distribution problem of shared-secret encryption approaches. With public/private keys, the public encryption key can be routinely shared across insecure media. This means we can use an unencrypted connection to exchange data and upgrade the connection to a secure connection.

By inserting the secure layer at the top of the Transport layer, we were able to avoid changing the Application, Internetwork, and Link layers while still easily securing any Transport layer connection. This approach ensures that all data being sent across a connection is encrypted before it leaves your computer. Given that many of us use wireless connections like WiFi, which are easily monitored by attackers, it is a good idea to encrypt data before it is sent across WiFi.

Browsers support secure connections by changing the prefix on the URL from “http:” to “https:”. By keeping an eye on the URL, end users can make sure they never send sensitive data across insecure connections. A series of trusted Certificate Authorities will sign public keys to give you an assurance that the key you received is indeed from the organization you expect it to be.

The design of the Secure Transport Layer provides a secure and yet easy-to-use mechanism for secure communications across the Internet at a scale of trillions of pairs of interacting computers.

Glossary

asymmetric key: An approach to encryption where one (public) key is used to encrypt data prior to transmission and a different (private) key is used to decrypt data once it is received.

certificate authority: An organization that digitally signs public keys after verifying that the name listed in the public key is actually the person or organization in possession of the public key.

ciphertext: A scrambled version of a message that cannot be read without knowing the decryption key and technique.

decrypt: The act of transforming a ciphertext message to a plain text message using a secret or key.

encrypt: The act of transforming a plain text message to a ciphertext message using a secret or key.

plain text: A readable message that is about to be encrypted before being sent.

private key: The portion of a key pair that is used to decrypt transmissions.

public key: The portion of a key pair that is used to encrypt transmissions.

shared secret: An approach to encryption that uses the same key for encryption and decryption.

SSL: Secure Sockets Layer. An approach that allows an application to request that a Transport layer connection is to be encrypted as it crosses the network. Similar to Transport Layer Security (TLS).

TLS: Transport Layer Security. An approach that allows an application to request that a Transport layer connection is to be encrypted as it crosses the network. Similar to Secure Sockets Layer (SSL).

Questions

1. How do we indicate that we want a secure connection when using a web browser?
   • a)Use https:// in the URL
   • b)Use a secure web browser
   • c)Open an incognito window
   • d)Manually encode the address of the server using SHA1
2. Why is a shared-secret approach not suitable for use on the Internet?
   • a)Because people would lose or misplace the secret
   • b)It is difficult to distribute the secrets
   • c)Encryption and decryption with shared secrets are too easily broken
   • d)Encryption and decryption with shared secrets take too much compute power
3. What is the underlying mathematical concept that makes public/private key encryption secure?
   • a)Continuous functions
   • b)Taylor series
   • c)Karnaugh Maps
   • d)Prime numbers
4. Which of the keys can be sent across the Internet in plain text without compromising security?
   • a)Encryption key
   • b)Decryption Key
   • c)Shared Secret
   • d)Univerally Safe Key (USK)
5. Where does the Secure Sockets Layer (SSL) fit in the four-layer Internet architecture?
   • a)Below the Link layer
   • b)Between the Link and Internetworking layers
   • c)Between the Internetworking and Transport layers
   • d)Between the Transport and Application layers
6. If you were properly using https in a browser over WiFi in a cafe, which of the following is the greatest risk to your losing credit card information when making an online purchase?
   • a)Someone captured the packets that were sent across the WiFi
   • b)Someone captured the packets in the gateway router
   • c)Someone captured the packets as they passed through a core Intenet router
   • d)You have a virus on your computer that is capturing keystrokes
7. With the Secure Sockets Layer, where are packets encrypted and decrypted?
   • a)They are encrypted and decrypted as they pass through the router
   • b)Each physical link has its own separate encryption
   • c)They are encrypted in your computer and decrypted in the server
   • d)They are encrypted in the WiFi gateway and decrypted in the last router before the destination computer
8. What changes to the IP layer were needed to make secure socket layer (SSL) work?
   • a)No changes were needed
   • b)We had to add support for Secure IP (IPSEC)
   • c)We needed to support longer packets in IP
   • d)The Time-To-Live (TTL) value needed to be encrypted
9. If a rogue element was able to monitor all packets going through an undersea cable and you were using public/private key encryption properly, which of the following would be the most difficult for them to obtain?
   • a)What servers you were communicating with
   • b)How often you used the servers
   • c)How much data you retrieved from the servers
   • d)Which documents you retrieved from the servers
10. What is the purpose of a Certificate Authority in public/private key encryption?
    • a)To make sure people do not forge badges for learning activities
    • b)To make sure packets get routed to the correct destination computer
    • c)To assure us that a public key comes from the organization it claims to be from
    • d)To choose when a particular country must switch from IPv4 to IPv6
11. The ARPANET network was in operation starting in the 1960s. Secure Sockets Layer (SSL) was not invented util the 1980s. How did the ARPANET insure the security of the data on its network?
    • a)By using public/private keys and encrypting all transmissions
    • b)By using encryption at the Link layer
    • c)By making sure no one could access the physical links
    • d)By only using secure WiFi routers
12. Which of these answers is “Security is fun” encrypted with a Caesar Cipher shift of 1.

• a)Ptsjduao rt dii
• b)Wentudhs di dju
• c)Tfdvsjuz jt gvo
• d)Asdfghjk qw zxc

1. What Caesar Cipher shift was used to encrypt “V yvxr frphevgl”?

• a)1
• b)6
• c)13
• d)24