Re: Insecure IKE Implementations Clarification

From: Florian Weimer (fw_at_deneb.enyo.de)
Date: 12/12/03

  • Next message: Thor Lancelot Simon: "Re: Insecure IKE Implementations Clarification" 
    Date: Fri, 12 Dec 2003 23:25:55 +0100
To: Thor Lancelot Simon <tls@rek.tjls.com>

    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.

  • Next message: Thor Lancelot Simon: "Re: Insecure IKE Implementations Clarification"

    Relevant Pages

    • Re: PKI: the end
      ... that one of the keys is consistently kept private and the other ... How does PKI infer 3-factor? ... What's with the "business process" terminology? ... > case of domain name SSL certificates, ...
      (sci.crypt)
    • Re: Effect of changing passwords
      ... Does it mean it deletes any cookies they have? ... which only the truly paranoid will even consider, nobody on the planet knows how to get at those certificates without your password. ... That means not even the people who wrote Windows. ... those keys aren't really yours; ...
      (microsoft.public.windowsxp.newusers)
    • Re: trust issues associated with Public Key Infrastructure?
      ... how can you trust, that the public key you have really ... CAs could issue certificates without checking owner identity ... Private keys could be disclosed by accident or on purpose ... False certificates could be inserted into browsers ...
      (comp.security.misc)
    • Re: EFS decryption problem solved!! FYI stuff inside.
      ... I'm suspecting that somewhere along the way new certificates (and keys) were ... domain recovery agent policy does not show up using the certificates mmc ... > encryption keys from the domain controller. ...
      (microsoft.public.security)
    • Re: Keyboard shortcuts and WebBrowser control
      ... See if it helps you - it didn't seem to work for keys for me, ... >>I have a form that includes, among other things, a web browser control. ... >>When the web browser control has focus, I find that the keyboard shortcuts ...
      (microsoft.public.vb.general.discussion)
    • Quantcast