We discussed DNS (the domain name service), an important application-layer protocol for converting human-readable domain names (such as cs.cornell.edu) to IP addresses. Domain names are hierarchical: the cs.cornell.edu domain is contained in the cornell.edu domain which is in turn a part of the .edu domain.
To resolve a domain name (e.g. www.cs.cornell.edu), you first query your local caching name server. In principle, your name server will first query one of the (small number of well-known) root name servers to find the .edu authoritative name server. This is the server that is responsible for storing the IP addresses of all name servers of subdomains of the .edu domain.
The .edu nameserver will respond with the IP address of the cornell.edu authoritative nameserver. In turn, this will respond with the IP address of the cs.cornell.edu nameserver. Finally, your caching nameserver will query the cs.cornell.edu nameserver to find the IP of the www host.
The caching nameserver may cache any of the addresses that it learns as part of this process. Once it has resolved the name, the address will be returned to the requesting application.
Thus far, we have seen many layers at which network traffic can be intercepted, modified, or fabricated.
Transport layer security (TLS) is a session-layer protocol for providing secure channels (encrypted and signed). Applications using TLS establish a connection that behaves like a TCP connection, but the traffic is first encrypted and signed before it is actually transmitted over the underlying TCP connection.
In this lecture, we will go over some of the basic protocols used by TLS. Note that TLS used to be (and commonly is still) referred to as the secure sockets layer (SSL).
Encryption is the process of taking a message (sometimes called the plaintext), and mathematically manipulating it so that an observer cannot distinguish it from random noise. The manipulated message is referred to as the cyphertext. The intended recipient (who has some additional knowlege) should be able to decrypt the message.
With Symmetric encryption (also called shared-key or secret-key encryption), the sender and recipient have a secret key that they both know but that no other party does.
The encryption algorithm E takes the plaintext p and the key k as input and produce the cypher text; the decryption algorithm D takes the cyphertext and the key as input and reproduces the plaintext:
D(E(p, k), k) = pA simple example is a substitution cypher. Here the key is a table mapping each character to a different character. The sender replaces each character in the message using the table; the decryptor looks up each character in the cyphertext to find the original character of plaintext.
With asymmetric encryption (also called public key encryption), the recipient generates a public/private key pair (usually we use K to denote the public key and k to denote the private key). The keys K and k satisfy the following property:
D(E(p, K), k) = pThe public key can be freely disemminated, because it gives no information about the private key. The sender uses the recipient's public key to encrypt the message, but the private key must be used to decrypt.
Cryptography can also be used to ensure that messages are not tampered with. A signer can generate an unforgeable signature for a message; the recipient can then verify the signature to determine whether the message was corrupted or forged.
As with encryption, signatures can be symmetric or asymmetric. For symmetric signatures (also called message authentication codes), the sender and recipient share a secret which is used to generate the signature. The signature and verification algorithms satisfy the following property:
V(m, S(m, k), k) = "yes", and V(m, anything else, k) = "no"An example signature algorithm would be to hash the message and the key together, which could be verified by rehashing the message and key and checking that they match. Any sender without the key would be unable to produce the correct hash.
Asymmetric signatures require the use of a public/private key pair. Here the signer uses the private key to sign the message; anyone with the public key can verify the signature:
V(m, S(m,k), K) = "yes"If A wishes to communicate with B over a network controlled by E, E can perform a "man-in-the-middle attack": it can fool A into believing that it is B, and it can fool B into believing that it is A.
This can only be thwarted by using an out-of-band mechanism; some method of communication that E does not control. For example, A and B could establish a shared key using postal mail or telephone, or by physically meeting.
Out-of-band communication is expensive; it is certainly impractical to send a letter to facebook requesting a key whenever you want to log into their website. Digital Certificates provide a mechanism that minimizes the overhead of out-of-band communication.
A Certificate Authority is a company or organization whose role is to vouch for the integrity of other parties. Every party wishing to establish a secure TLS connection to some party contains a list of the public keys of certificate authorities that they trust. You can find out which certificate authorities your web browser trusts (and thus you also) by examining the security settings of your web browser.
You can think of the process of obtaining this list as the out-of-band communication that the CA performs with you.
The party wishing to verify their identity (such as trustedbank.com) communicates with the certificate authority using a secure out-of-band channel. The certificate authority gives mybank.com a statement that says "mybank.com's public key is Kbank", signed with kCA.
At this point, the CA's work is done. When You want to communicate with Bank.com, you first connect to bank.com and request their public key and certificate. They respond, and you are able to verify that the certificate has been signed by a CA you trust.
Once you have verified the certificate, you can use asymmetric encryption using the bank's public key to establish a shared secret (also called a session key); you can then use symmetric encryption with this key to encrypt and sign the remainder of the data to be transmitted.
Just as with DNS, there are a small number of trusted "root" CAs. They are able to delegate their signing authority to other CAs. For example, Cornell may have its own CA, which has its own public/private key pair (say kCornell and KCornell). A root CA has given the Cornell CA a certificate that says "Cornell is allowed to sign certificates in the .cornell.edu domain, and its public key is KCornell". A host wishing to obtain a cornell.edu certificate can then communicate (out-of-band) with Cornell, to obtain a certificate chain:
Anyone who trusts the CA will be willing to verify the first certificate; this then allows them to verify the second certificate.