IDS mailing list archives

Previous By Date Next
Previous By Thread Next

Re: SSL and IPS (was RE: ssh and ids)

From: "Michael H. Warfield" <mhw () wittsend com>
Date: Thu, 1 Jul 2004 14:38:55 -0400
On Thu, Jul 01, 2004 at 07:58:55PM +0200, Wouter Clarie wrote:

On Wed, 30 Jun 2004, Michael H. Warfield wrote:



    The files are ready.

    You can let me know what the URL was that was requested.  You can
readily extract the server name from the cert.  The rest will come from
the decrypted session.



[snip]



    You now have everything you claim to need.  Send me back the URL
and the html text of the page.  I want to see this.  I'll be truely
impressed if you can do what you claim to do.



I think you made a mistake. This session does not use DH, it uses
TLS_RSA_WITH_RC4_128_MD5, so you don't even need the certificate.


        Yup...  Saw that afterwards.  And now I see where the confusion is
and (more important to me) where my error has been.  I've been assuming (I
know - my bad) that, since SSL3 / TLS1 supports Diffie-Hellman, that they
were using Diffie-Hellman to negotiate the session keys.  Turns out that
it uses Diffie-Hellman by default only on anonymous SSL connections (no
authentication either direction).  This creates the very interesting
situation that, yes, the default authenticated session can be passively
sniffed and decrypted as described, but the unauthenticated SSL connections
can not (because of Diffie-Hellman).

        That also means that the security of a session depends on the
future security of the server key as well.  If the session is captured
and the key is ever compromised at some time in the future, the entire
contents of the session can be decrypted.  Since most server keys are
not password protected, that can be very bad if someone finds some file
disclosure exploits (as has happened in the past).  That's as bad (or worse)
as IPsec/IKE using shared secret keys and no perfect forward secrecy.  It's
perfectly secure as long as nobody uncovers that secret.  Fortunately
SSH and IPSec/IKE with PFS are not vulnerable to that kind of attack
(I'm in the process of converting all my SSL based VPNs over to ssh
or IPSec now).  Neither SSH nor IPSec/IKE combine the session key
negotiation in with the server authentication (separate phases) so
I feel much more comfortable with them, at this point.

        Got a few other things I'm playing with as well to try and get
that session to use Diffie-Hellman and see what a difference that makes.

        Sooo...  As I said, I don't mind a little egg on my face.  I owe
everybody a round of apologies (and maybe a beer or two if you catch me
at a show).

        Later!

        Regards,
        Mike


This was the request:

    GET /kudzu/ HTTP/1.1
    Host: www.cryptolinux.org
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
    Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive

Reply:

    <HTML><HEAD>
    <TITLE>CyrptoLinux - LinuxCryto - Cryptography on Linux</TITLE>
    <META name="description" content="Welcome to CryptoLinux.  This is a resource
    site for all thing cryptographic on Linux.">
    <META name="keywords" content="Linux, Cryptography, Cryptographic, Linux OS,
    Linux operation system">
    </HEAD>
    <BODY BACKGROUND=/backgrounds/paper/blue_paper.gif BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" 
ALINK="#FF0000" VLINK="#551A8B">
    <img src="/crypto_tux_l.gif" align=left>
    <img src="/crypto_tux_r.gif" align=right>
    <Center>

Etc...

Regards,

Wouter Clarie


-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw () WittsEnd com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Attachment: _bin
Description:

Previous By Date Next
Previous By Thread Next

Current thread: