In an eavesdropping attack, a passive or active network attacker listens in on other users’ network traffic, such as DNS queries, HTTP requests, responses, etc. By eavesdropping on their network traffic, an attacker is not only able to learn sensitive, personal information, such as credit card info, financial means, usernames, passwords, contents of email messages, etc. but can also listen in on important Web metadata, such as session identifiers or supposedly secret cookies. Obtaining any of this information is not only directly harmful to the user but also enables the attacker to escalate the attack, for example through session hijacking.
Eavesdropping attacks are extremely relevant in the modern Web, especially because of the numerous wireless networks, to which users connect with their mobile devices or laptops. Many of these networks are unprotected or easily spoofed by an attacker. Additionally, with the revelations, it has become clear that state-sponsored eavesdropping occurs on a large scale, scooping up every piece of unencrypted information that is encountered.
The goal of an eavesdropping attack is to obtain traffic that is sent over the network. The way of executing an eavesdropping attack depends on the network under attack. For example, eavesdropping on airborne signals, such as wifi, radio, or cellular, only requires an antenna in the proximity of the network. Eavesdropping on a switch, the wired network requires some interference, for example by running an ARP spoofing attack. Eavesdropping can also occur at intermediaries within the network infrastructure, for example at an ISP, a proxy server, or a Tor exit node. Even higher up in the network, an attacker can eavesdrop on backbone traffic, with submarine taps on fiber-optic cables as an extreme example.
Technically, running an eavesdropping attack is fairly straightforward. As an illustration, the browser add-on Firesheep enables a user to eavesdrop on a wifi network, abusing obtained session identifiers to perform a session hijacking attack with one point-and-click operation. Alternatively, software tools such as Subterfuge and dedicated devices such as the Pineapple make collecting sensitive information a straightforward task. Eavesdropping on a wired, switched network is also possible with a wide variety of freely available tools, such as Ettercap or sniff. Essentially, eavesdropping attacks will always be possible, especially with the evolution of wireless networks. However, the real problem is the achievement of perfect forward secrecy (PFS), which guarantees that previously recorded TLS sessions cannot be deciphered by learning the server’s private key at a later point in time. While PFS has previously known a limited deployment due to an impact on performance and requiring less commonly used cipher suites, it has come into the spotlight again, due to private keys leaking out, for example, if someone hacks a Web server, or if server units are decommissioned inappropriately.
Finally, a large effort is being spent on the development of the successor to HTTP, HTTP/2.0 based on Google’s SPDY protocol. While initially SPDY was proposed to always run over TLS, that position was somewhat watered down in HTTP/2.0, mainly due to interference with middleboxes, such as Web caches or HTTP proxies that need to be able to see some HTTP metadata (e.g., headers) to function. Nonetheless, HTTP/2.0 will be far more likely to be deployed running over TLS, since the application layer protocol negotiation TLS extension offers the most efficient upgrade path, with the fewest additional network round trips. Additionally, discussions to allow clients and servers to make use of TLS even for HTTP (i.e. non-HTTPS) URIs when using HTTP/2.0, are ongoing.
While TLS effectively tackles network attacks, it is not yet widely deployed, although adoption is growing. As an indication of the current deployment state of TLS, a monitoring site reports that approximately 34% of the top 10-million Web sites are using TLS with certificates issued by a recognized CA. Recently, Google has announced an HTTPS Everywhere initiative, encouraging the deployment of TLS. As part of this initiative, Google is starting to use HTTPS as a signal in its ranking algorithm. Next to the limited adoption, older and less secure versions of TLS that are deployed, are rarely upgraded to the latest version, leaving a trail of inadequate legacy implementations across the Web. The SSL Pulse project reports that of the 152,733 surveyed TLS sites in July 2014, only 28.3% had a secure TLS deployment.
While the specific reasons for the slow adoption of TLS are hard to pinpoint, potential candidates are its (antiquated) reputation imputing significant performance impact, the difficulty of managing and deploying certificates, potential interference or incompatibility of the encrypted traffic with middleboxes, such as proxies and caches, and general ignorance from Web application operators. Additionally, TLS is often used incorrectly, which may be attributed to relatively hard-to-use APIs and incorrectly configured trust-roots.