SSL/TLS is the bedrock of modern security. Just about all security strategies involve it or chain back to it at some point. At its core, the contract is this: something encrypted with a user’s public key can only be decrypted by the corresponding private key, and something encrypted with the user’s private key can only be decrypted by the corresponding public key. From this we derive digital signatures, and communication that cannot be intercepted by a malicious third party who has tapped the line. But what does this mean? Rarely do we get a high-level understanding of the sorts of things criminals would actually do in order to get between the source of a digital communication and its destination.
Often, people think that “man-in-the-middle” refers to one very specific type of attack. This is not the case. It is a category of attack vectors that might occur at different points in the message’s transit. Let’s say you’re at your computer, and you’re logging into your credit union’s site. They notably don’t use any kind of multi-factor authentication. You enter your username and password, the only things preventing a bad actor from transferring all of your money to themselves. You enter the website into your browser. First, your machine checks its HOSTS file for an entry to resolve the domain name to an IP address. If it does not find it, your machine then queries its own DNS cache. If the information is not in its DNS cache, it queries the upstream DNS resolver configured either statically on its network adapter or served to it by a DHCP server on its layer 2 adjacent LAN (oftentimes for home users the router/modem combo from their ISP serves DHCP and DNS). Then, the computer knows what IP Address to send its HTTP request. It attempts to open a TCP socket to that IP address on port 443 in order to talk to that server and POST your login credentials to the endpoint specified in the HTML of your bank’s webform so that you can be granted a bearer token (like an encrypted cookie, or a SAML token) that will allow your bank to know that you are in fact you for the rest of the session. In order to open this TCP socket though, your computer needs to route traffic over the internet.
In order to traverse the internet, in a process that’s similar to DNS resolution, first checks if itself is the computer destined to receive the traffic. If so, the traffic never leaves the machine. Next, it consults its ARP cache, a scratchpad of sorts where it keeps track of its own layer 2 adjacent neighbors on its local LAN. Failing ARP lookup, it consults its own routing table to determine if it knows where to route traffic for the specific IP address it’s attempting to communicate with. Now is when the computer gears itself up to wrap its layer 2 frame in a layer 3 packet and send that communication to a router in order for it to be delivered. The communication may traverse tens or hundreds of routers in between known as “hops” before it makes it way to its destination. If the computer does not have a static entry consisting of the IP Address, or the range of IPs in which the destination address lives, it sends the traffic to its configured “default gateway” (or gateway of last resort) configured either statically on its own networking adapter or served by a neighbor DHCP server in its own LAN. Finally, once the traffic has left the local LAN, the router sends the traffic to the ISP’s router who is capable of speaking BGP.
The Border Gateway Protocol (en.wikipedia.org/wiki/Border_Gateway_Protocol) is how all of the many autonomous systems (AS’s) that make up the internet know about each other. They publish “BGP routes” so that at any given time there are anywhere from 2 to hundreds of possible routes traffic can take in order to get to its intended destination. All of this is to say, that there many, many moving parts, each of which can be manipulated by an attacker in control of that specific resource.
Let’s go back to the beginning. A bad actor who already has control of your computer via malware can modify your HOSTS files, your DNS cache, your DNS Server, your routing table, or your default gateway in order to reroute your traffic to themselves. A router who has a presence on your layer 2 LAN (such as at a coffee shop or at an airport) can inject their own entries into your ARP cache with malicious broadcast traffic (known as ARP poisoning), pretend to be the default gateway on the local LAN by issuing a Denial-Of-Service attack against the router and spoofing its MAC address, or even compromising a managed switch between you and the router and then mirroring all traffic to a port on the switch which the malicious actor has a different device attached.
Once the traffic leaves your network, an attacker could tap into a telephone pole between you and an ISP and install a fibre switch (much less difficult than you would think) to send all of your traffic to themselves, but also still send the original traffic to its destination so that you nor the ISP ever knew it was happening. An attacker could register their own AS and publish routes to other BGP enabled routers, issue strategic Denial-Of-Service attacks against AS’s that have nothing to do with you except for being nodes through which your traffic might pass, in order to make the shortest path between your traffic and its destination go through the attacker. Then, the attacker can run a modified BGP router to simply capture all traffic on its way to its destination for analysis later. All of these man-in-the-middle attacks are “slam dunks”. If your traffic is plain HTTP traffic, any of these attacks executed correctly will render your secrets to an attacker in the clear.
Circling back, HTTPS does two things, and it does them well. Firstly, Encryption allows us to send sensitive information across an insecure channel without worrying about interception in transit – without the private key, held by only the server on the other end, all the attacker can intercept is gibberish. Secondly, and most importantly, encryption doesn’t help you if you can’t trust that the site you’re visiting belongs to the entity you think it does. If a route poisoning attack takes you to malicious page pretending to be your bank’s web server (and they can trivially copy the look and feel of the page exactly), your browser will alert you that the connection is insecure, because the attacker doesn’t have the ability to present to your browser a certificate signed by a certificate authority verifying that that server is allowed to claim to be that domain on the internet at large. Certificate Authorities, such as Thawte, are a trusted third party who serve as unsung heroes of our time. Without the diligence of verifying (usually through DNS-based challenge response and a slew of other secondary methods) that only those who have authority over a given domain can issue certificates for it that browsers trust out-of-the-box, can we conduct our business safely.
Not all signed certificates offer the same level of protection. Domain Validated certificates (most certificates issued) only rely on the above, but a second type of certificate, Extended Validation certificates, insure secure commerce by forcing the entity to undergo more rigorous authentication schemes. (For example, maybe the CA will only issue an extended validation certificate after a conversation with the technical contact in the domain’s WHOIS at the phone number listed). If it weren’t for the human element, all certificate authorities would be the same. Because people can, and do make mistakes, organizations wanting the most assurance possible that their customers aren’t at risk, picking an industry leader such as Thaete which has real responsibilities to their shareholders can make you feel confident that all staff have been appropriately trained, and that things such as “separation of duties” are being carried out appropriately. Thawte also enforces rigorous standards for resellers that other authorities don’t necessarily enforce.