bugtraq - Re: Insecure IKE Implementations Clarification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20031212222555.GA19095@deneb.enyo.de>
Date: Fri, 12 Dec 2003 23:25:55 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Thor Lancelot Simon <tls@....tjls.com>
Cc: aadams@...urityfocus.com, bugtraq@...urityfocus.com
Subject: Re: Insecure IKE Implementations Clarification

Thor Lancelot Simon wrote:

> Yes and no.  SSH is not, by itself, a network-layer encryption solution,
> and there are many applications where that's really desirable.  The other
> issue is, of course, that SSH's model for authenticating host identities
> is, itself, a mess: in this day and age, it is not acceptable to just
> punt on the problem of first contact and pretend that users will reasonably
> exchange key fingerprints offline.

You don't exchange fingerprints, you just store them.  Previously, I
thought that to be risky, but after having seen too many failed PKIs
implemented according to the text books, I'm no longer sure if the SSH
approach is so ugly.

FWIW, I have removed all CA certificates from my web browser and store
all web site certificates permanently.  According to my threat model
(which involves greedy CAs issuing certificates after superficial
checks), this will catch a few attacks.

> The widespread success of sniffing and MITM attacks on the SSH
> protocol -- all due to users not doing what the protocol, by omitting
> any means of using a hierarchy or web to validate host keys, requires
> them to do -- should be proof enough of this.

There are very few such attacks in the wild.  Most machines which do not
already have the keys I need and which are in an environment especially
prone to MITM attacks are not exactly trustworthy, either, so I don't
lose much.  In fact, there is not much choice because it's impossible to
roll out root CA keys for SSH server authentication.  There's no widely
used proprietary implementation that could essentially control the root
CA set (as it happened with the web browser PKI).

However, in the Cisco VPN case, the issue is moot.  You can easily
distribute the concentrator certificate or fingerprint along the client
software and configuration.  You already need a secure channel for that
anyway.