dsniff and SSH : Reports of My Demise are Greatly Exaggerated
by Richard E. Silverman
On 17 December 2000, Dug Song released a new version of his well-known
package of network sniffing tools,
The new release includes a tool named "sshmitm," which performs a
man-in-the-middle attack (MITM) on the SSH-1 protocol.
The following day, Kurt Seifried wrote an article titled
The End of SSL and SSH?
The article has generated a fair amount of discussion and buzz, not least
because of its dire-sounding title. And there are certainly important
implications to the appearance of sshmitm. Seifried's piece, however,
contains several factual errors and misleading statements in discussing
the details of SSH (secure shell), SSL (secure sockets layer), and MITM.
This is unfortunate, since these shortcomings blur the
essential message, which is valid and important to get out. This article attempts
to correct some of those mistakes, and to clarify the issues involved.
The MITM is not a new idea; it is a well-known general method of attack
against authentication and key-exchange protocols. SSH includes mandatory
server authentication specifically to thwart MITM. Naturally, this relies
on the ability of the client to verify the claimed association between the
server's public key and the identity of the server host. In an SSH
session, the server hands the client a public key, then proceeds to prove
that it has access to the corresponding private key. All well and good,
but the server could have simply generated a brand-new key pair and done
the same thing. For this transaction to be meaningful, the client must
independently verify that this particular public key identifies the host
that the client originally intended to contact. Solving this
"key-distribution problem" is a necessary part of public-key
There are technologies available to address key distribution. One is
the X.509-based Public Key Infrastructure, or PKI. Another is DNSSEC, a
set of extensions to DNS for securing the Internet naming system, which
naturally allows for verifiable bindings between hostnames and keys. However, no
such systems are yet commonly deployed, so current SSH
implementations take a simple approach: a local database of key/hostname
associations, maintained by the sysadmin and/or individual users. SSH
clients may be configured to automatically accept and record host public
keys on first contact, thus allowing the user to build up the known-hosts
list naturally--but incurring the risk of MITM on the first connection
to any host. If this risk is unacceptable, the client may also be set to
require an existing correct host-key entry and reject connections that
fail this test. This protects against MITM in all cases, with the
attendant burden of requiring the user to manually add new host-keys as
needed. Of course, the point is that in doing so, the user should verify
through some other means that the key actually belongs to the host in
question--perhaps by getting it on a diskette from the sysadmin, or by
checking the key fingerprint against a posted list.
With these ideas in mind, let's examine some excerpts from Seifried's
> "The End of SSL and SSH?"
> By Kurt Seifried (email@example.com) for
> December 18, 2000 - Yesterday, dsniff 2.3 was released.
> Why is this important, you ask? dsniff 2.3 allows you to
> exploit several fundamental flaws in two extremely popular
> encryption protocols, SSL and SSH.
This is a misleading exaggeration. It becomes clear shortly that Seifried
is talking about MITM. The existence of MITM is not a flaw in either
protocol; in fact, both protocols include mechanisms to counter MITM.
What is true is that, in most implementations, users may choose to
override those mechanisms for the sake of convenience, forgoing MITM
protection. One might take issue with this decision, but it is an
implementation issue, not a protocol design flaw.
Now, the SSH protocol does specifically allow clients to omit the host-key
verification step, leaving the session open to MITM. Of course, it would
be impossible to enforce such a step through the protocol anyway, since it
is a one-sided policy issue, but the protocol could at least state the
requirement. This could be considered a flaw, but that's not a fair
assessment. The decision to sanction this behavior is a considered one,
balancing the security risk against the overall security benefits of
widespread SSH use. There is an entire section of the IETF
(Internet Engineering Task Force) draft on the
SSH-2 protocol architecture , which discusses this
very issue (section 3.1, "host-keys"). It explicitly acknowledges that for
a client to connect without verifying the server host-key is a
vulnerability, but weighs this against the fact that without any kind of
widespread PKI, SSH usage would be severely limited by demanding server
authentication in every instance. To quote:
... Implementations SHOULD NOT normally allow such
connections by default, as they pose a potential
security problem. However, as there is no widely
deployed key infrastructure available on the Internet
yet, this option makes the protocol much more usable
during the transition time until such an infrastructure
emerges, while still providing a much higher level of
security than that offered by older solutions (e.g.
telnet [RFC-854] and rlogin [RFC-1282])...
We believe that ease of use is critical to end-user
acceptance of security solutions, and no improvement
in security is gained if the new solutions are not used.
Thus, providing the option not to check the the server
host-key is believed to improve overall security of the
Internet, even though it reduces the security of the
protocol in configurations where it is allowed.
This argument is compelling and very practical: it will be better to have
a large amount of Internet traffic enjoy integrity and privacy protection
(though some small fraction of that traffic is missing MITM protection), rather than
see the deployment of any kind of protection stunted. SSH will not be
widely used if it is too difficult to do so. Moreover, absolutely requiring
preexisting known-hosts entries is simply too onerous in today's
> ... There is one fundamental problem with establishing
> a secure, encrypted connection over the Internet. No
> matter how you do it, at some point you must initiate
> the connection over a public and potentially hostile
> network. Ideally, when two hosts establish a connection,
> they exchange public keys using a variety of verification
> processes (Diffie-Hellman being an extremely popular one),
> and each host properly receives the other's key.
> Unfortunately, since this must take place over a public
> and usually insecure network, it is possible for an
> attacker to intercept the key exchange and subvert it.
This is confusing. The Diffie-Hellman key-exchange algorithm does not
exchange public keys; it allows two parties to agree on a single, secret
(symmetric) key. This is done in such a way that it is not feasible for
an observer to discover the shared key, even though the messages are
transmitted in the clear. The Diffie-Hellman method by itself is
vulnerable to MITM, however, which is why both the SSH and SSL protocols
require that server authentication guard against this. That step does involve
exchanging at least one public key--but that is a separate element of
> ... Since this problem is so fundamental to public
> key encryption, there have been many schemes to foil
> an attacker ... [description of server authentication
> using public-key certificates] ... Unfortunately, there
> is a missing part in this equation. While SSL requires that
> the server authenticate to the user, it is usually an
> option for the user to authenticate to the server. And
> since so very few users own personal certificates, it is
> exceedingly rare for a user to be able to prove their
> identity to the server in question--leaving the connection
> open to attack.
Seifried does not specify here exactly what "attack" he's talking about.
However, context implies that he means MITM. The claim here, then, is
that omitting client (user) authentication leaves the protocol vulnerable
to MITM. This is wrong. Client authentication takes place only after
successful server authentication--which will fail under MITM. A user
may override or omit the server authentication check, allowing MITM to
succeed, but this is completely independent of whether or not client
authentication is used later on.
Now, there is a related but different statement that is true: abstractly,
omitting client authentication may bypass a chance to detect MITM,
assuming that server authentication has already failed to do so (either
because the user defeated it, or because the attacker has stolen the
legitimate server's private host-key). This is because some client
authentication methods are also designed to resist MITM. SSH password
authentication, obviously, is not MITM-resistant; once you hand your
password over the trapped connection, all is lost. And the SSH-1
public-key user-authentication method is also vulnerable; the attacker may
use the signed authenticator from the client side to access the client's
account on the server. However, the SSH-2 public-key and host-based client
authentication methods are MITM-proof: the authenticators involved are
bound to session identifiers that are forced to be different on either
side of the attacker.
> The same general problems exist for SSH. Instead
> of certificates, however, SSH simply uses a secret
> and public key, and since they are generally not signed,
> it is trivial for an attacker to sit in the middle
> and intercept the connection. If this is the first
> time you are connecting to a host and you do not have
> the server's public key locally, you will be none the
The writing here is a bit confused. First, Seifried proceeds to talk
about the "same general problems for SSH." He does this even though he
has switched from
discussing user authentication to server authentication, which are
entirely different topics (and, in fact, in SSH-2, different protocol
Second, the claim about being "none the wiser" regarding the addition of a
new key is at best exaggerated. This is obviously an implementation
rather than a protocol question: when it encounters an unknown host-key,
what does the client do? Existing software varies, but OpenSSH, for
example, may be configured to:
- Add the key automatically and issue an advisory message;
- stop with a warning and ask whether to add the key and continue, or
abort the connection; or
- refuse to connect at all.
> If you do have the server's public key, you will
> generally receive a warning like "Warning: server's
> key has changed. Continue?" Most users will hit Yes.
Again, implementations vary, but the message issued in this circumstance
by all three common Unix SSH packages, is in fact quite a bit more
strenuous than this suggests:
@ WARNING: HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now
(man-in-the-middle attack)! It is also possible that
the host-key has just been changed. Please contact
your system administrator.
If you don't get the idea from this message that something might be wrong, then
all the cryptography in the world won't help you. And remember, this
message will only be followed by the option to continue if the
sysadmin has set it as the default. In a security-conscious
environment, strict host-key checking will be required, and the connection
will simply fail. The user could override that, but, at this point, she's
on her own. Including the ability to override allows for widespread
use of SSH, which is worth the risk of some users willfully ignoring their
local security policy. (Which they could always do simply by compiling
their own custom version of the software, anyway.)
> ... There are newer key exchange algorithms
> that claim to solve many of the problems inherent
> in these transactions, but most are aimed at services
> where the user is logging in to a server... Unfortunately,
> these protocols do not work so well for SSL transactions,
> which are used on a massive scale with end users that
> cannot prove their identity to the server.
Again, I read this as claiming user authentication is necessary for
MITM resistance. This is just not true.
> If you are on a hub or a switch, you can use arpspoof
> to hijack other machines' IP addresses. If the switch
> is secured and ignoring arp packets, you can use
> macof to flood it...
This is a side issue, not related directly to SSH or SSL--but it's an
error worth mentioning nonetheless, since it implies that switches can
somehow be configured to prevent ARP (Address Resolution Protocol) spoofing.
I have never heard of a
layer 2 switch listening to ARP traffic; it need only examine the source
and destination MAC addresses of passing Ethernet frames to do its job. A
spoofed ARP reply operates at a higher layer, poisoning the target host's
ARP cache and fooling its IP stack into transmitting some IP datagrams to
the attacker's MAC address in lieu of the legitimate host. The switch
continues to operate normally.
> With the latest version of dsniff you also gain
> the ability to intercept and monitor SSH (protocol
> version 1) and SSL connections using the vulnerabilities
> discussed above... Without major restructuring of the
> SSH and SSL protocols, there is very little that can be
> done to "fix" them.
Again, this happens only if server authentication has been
deliberately disabled, bypassed by client configuration, or if the client
host has been separately compromised and its known-hosts file or trusted
CA certificate cache poisoned. These are issues of implementation,
user-awareness, and local host security. They are important ones and
worth discussing, but they are not protocol "vulnerabilities" or "flaws,"
and there is nothing to "fix."
To sum up, then: The easy availability of dsniff/sshmitm drives home the
point that MITM is a real threat, not just a theoretical one. With the
dsniff tools, it took this author only a few minutes to spoof DNS replies
to a victim host, redirect an SSH connection to an intermediate system,
and conduct a successful MITM against it. The sshmitm program obligingly
printed out my username and password, and then echoed the contents of the
trapped SSH session as I typed. Scary stuff. It should serve to raise
user and sysadmin awareness of their responsibility to maintain the SSH
known-hosts lists, configure client behavior in accordance with a
considered security policy, and think carefully before overriding security
warnings about changed or missing host-keys. But there is no reason to
suppose that the appearance of dsniff 2.3 and sshmitm spells the "end of
SSH and SSL" in any way.