Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Building And Integrating Virtual Private Networks With Openswan (2006).pdf
Скачиваний:
73
Добавлен:
17.08.2013
Размер:
4.74 Mб
Скачать

Opportunistic Encryption

However, this does not protect all the other traffic. More wrappers have been added. Secure POP and IMAP, secure webmail, STARTTLS for SMTP servers, and right now security is being applied to the various Instant Messaging (IM) protocols. And people only started using them when faced with the reality that anyone anywhere could read, or even manipulate their packets, thanks to the success of wireless networks. GSM, UMTS, and GPRS were still too expensive for the average person to eavesdrop on; it requires serious money to obtain the right GSM equipment and it is usually illegal to operate without a license. But WiFi (802.11) finally killed the illusion of trusting the airwaves. The wireless industry's attempts at securing the WiFi protocols have failed again and again. WEP was hacked, WPA was hacked for most common keys, LEAP was broken. Tomorrow there will be another standard, but how long will that one last?

Instead of scrambling to secure all the different network protocols, there is another choice. Secure the IP layer. And why not use IPsec? After all, it is proven to be very secure and we already have all the software on our servers and clients to deploy it. We just need to find a way to set up an IPsec connection without prior arrangement. That method is called Opportunistic Encryption.

History of Opportunistic Encryption

Opportunistic Encryption (OE) was the primary motivation for the original FreeS/WAN project, all the way back in 1996. OE's goal was to use upcoming IPsec protocols to secure not just a few important links (aka VPNs), but each and every computer on the Internet. Unfortunately, the market was moving in different ways. There was money to be made on domain registrations, domain security, security software, and digital certificates for each and every user and application. Big corporations like Network Solutions and Verisign and Thawte provided the X.509 Certificate frameworks, and the big software vendors like IBM and Microsoft provided expensive groupware suites to authenticate these users, based on big corporate user hierarchies. Of course, this is not what the Internet is good at. The Internet's strength is not its few big players, but its decentralized way of handling everything. Even though the FreeS/WAN project pushed various technologies to the IETF, that process was very slow. The consequences of that slow process are still visible, as workarounds have had to be deployed to kickstart the entire acceptance and usability of OE. Most importantly, changes in the DNS have taken almost ten years to complete. Finally, there is now an official method for storing public IPsec keys in DNS. It is described in RFC 4025.

Trusting Third Parties

Let us move back to our original dilemma though. How do we encrypt communications between all hosts on the Internet? Securing two hosts is easy. A dozen is doable, but how are we going to secure millions of hosts? Of course, if we are talking about millions of hosts, we cannot use anything based on shared secrets, as the whole world would need to know this secret and it would not be a secret anymore. We have to use public key cryptography, such as RSA or DSA, and clearly we cannot call up all the system administrators and ask for their public keys. We need a place to store and retrieve these public keys dynamically.

This problem is not as new as it looks. It is very similar to the problem of finding a website, or sending email to a particular domain. These tasks are done with the largest distributed database

132