What real improvements in Internet security have we achieved? The Net certainly is not a safe place as long as there are phishing, DDoS attacks, and cross-site script HTML attacks. However, although those are serious problems, we should not ignore the ways in which we have been successful in making the Net a safer place, and we should try to take some lessons from those successes.
The Net Is a Dangerous Place, but We Can Do Things Safely
Twenty years ago, it was considered rude to connect a UNIX machine to the Net without offering a password-free account named guest so that any passerby could use it. When I tell this to people who have less than 10 years of experience working with the Internet, they don’t believe me.
Times have certainly changed. Today the Net is much less secure. In an environment where attacks are recurring events, where operating system and application vulnerabilities are discovered daily, and where bot-nets of 100,000 zombies attack, we still feel comfortable conducting financial and other private transactions worth billions of dollars on the Net.
How is this possible? It’s possible because we have deployed tools and protocols that enable secure transactions in an insecure world. This philosophy is similar to that which explains how we were able to build a reliable network from a set of unreliable components: circuits may fail and equipment may have errors, but the packets route around these problems.
So, what are the successful protocols and tools that have made the Net a safer place? Here are some of what I consider the most significant.
Secure Sockets Layer/Transport Layer Security (SSL/TLS)
One would not consider sending credit card or other personal information over an unencrypted link. Encrypted and authenticated browsing, using https as opposed to http, are the bases on which almost all Internet commerce is founded. Even when a transaction is not facilitated by a browser, TLS (Transport Layer Security) – the new name for SSL (so that the IETF could make a “contribution”) – is used underneath most client-server exchanges.
SSH (Secure Shell)
Can you imagine having to telnet to a remote system today? The exposure to attack, password interception, and other potential dangers have made telnet a thing of the distant past, along with rsh (remote shell) and rpc (remote procedure call), among others.
The SSH protocol and tool set – and SSHv2 in particular – now dominate this niche.
VPN technology allows safe business transactions among branch offices, trusted vendors, road warriors, and telecommuters. IP Security (IPsec) in particular offers more than just seemingly private channels; it encrypts the data flowing over those channels, which multiprotocol label switching (MPLS), asynchronous transfer mode (ATM), and others do not. Aside from being complex and fragile, circuit emulators such as MPLS and ATM are unencrypted and therefore vulnerable to tapping because they are virtual networks, not virtual private networks.
Russ Housley and members of the IESG at the IETF 70 plenary
Photo Credit: Peter Lötberg, with permission
Unfortunately, IPsec is only half a win. It is widely deployed in prepackaged and configured VPN devices, and it is usually managed by an ISP, security company, or local guru. It is the last that is the sore spot in IPsec. It requires a guru to configure. This is inexcusable and unnecessary, and until setup and maintenance become a lot easier, IPsec will remain a specialised corner and its promise will be only partially realised.
Pretty Good Privacy (PGP)
PGP allows us to exchange signed and strongly encrypted e-mail whose content cannot be repudiated; in other words, the sender cannot deny sending it. PGP can also be used to encrypt files on one’s hard drive. This free tool is so powerful that the U.S. government tried to suppress its export even harder than the efforts it usually makes.
It’s also worth noting that trust in PGP is nonhierarchic (meaning, there is no central authority). PGP entities attest to each other’s identities in a web of trust, as opposed to adhering to a particular hierarchy. Therefore, it is quite decentralised and immune to compromise of root trust anchors.
X.509 certificates and the public key infrastructure to support them are used in browser authentication. The problem here is that because they are totally hierarchic, they are only as reliable as the Certifying Authority (CA) that issues them; and the commercial CAs that issue certificates have little financial incentive to make the effort to truly validate identity. There have been notable compromises of the X.509 certificate hierarchy.
Use of X.509 certificates for attesting to IP address space ownership will be coming into use at the ARIN, APNIC, etc., and ISP levels in 2008.
There is a second, far less used, e-mail signing method that is used to some extent in the corporate world. Its function is similar to that of PGP, but it relies on an X.509 certificate hierarchy.
There are free, open-source tool kits for all of the tools and protocols described here, all of which are incorporated in browsers and e-mail packages.
This is not to say there are no longer security threats on the Internet. Certainly, spam, DDoS, the Estonian DDoS, and the root DNS attack of 7 February 2007 are all very real and serious problems, but thanks to the good folks who gave us the protocols and tools described here and the applications that use them, we can walk safely through a dangerous city.
Again, in the same way that we can build a reliable Internet out of unreliable components, we can build secure applications and services that work well in today’s highly insecure environment. This is a big win.