I think your concept of SSL/TLS sniffer is not realistic
in a general way, for the following reasons:

        - the packets transmitted between a client and a server have submitted
          a set of "transformations" (fragmentation, compression(optional)+
          encryption(optional)+"MACed")
        - to recover the original payload, you must, among other things, know
                - the compression alg/param used if any
                - the cipher alg.param used (e.g. RC2-CBC-40 with a specific IV)+
                  the secret key

That information is shared by the two parties but obviously not transported
in the packets. So the knowledge of the private assymetric key of the server 
is neither sufficient nor needed to recover the original data. 

You could however immagine protocols that enable your sniffer to know
that information. For instance, before beginning a session, the two parties
"register" in a secure way (using TLS) their session secrets to the authenticated
sniffer.

  

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Martin Hallerdal
> Sent: Tuesday, June 15, 1999 1:43 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: advice needed
> 
> 
> Well we have the private key of the server of course, since it's 
> our server.
> If we didn't the efforts put into this project would be quite in vain :-)
> 
> > -----Original Message-----
> > From:       Erwann ABALEA [SMTP:[EMAIL PROTECTED]]
> > Sent:       Monday, June 14, 1999 3:50 PM
> > To: [EMAIL PROTECTED]
> > Subject:    Re: advice needed
> > 
> > On Mon, 14 Jun 1999, Martin Hallerdal wrote:
> > 
> > > We are developing a network sniffer that monitors IP traffic. If the
> > > "sniffed" packet is part of a https conversation it should be 
> decrypted.
> > Now
> > > of course this means that we have to monitor every session in order to
> > find
> > > out the session key, storing this information in a data structure of
> > some
> > > sort.
> > > 
> > > The whole concept is a bit tricky and we thought that by using OpenSSL
> > or
> > > SSLeay things could get a bit easier. But I have the impression that
> > these
> > > libraries were constructed for a client or server, not a network
> > sniffer. I
> > > would be grateful if someone could give us hints on how to use these
> > > libraries in our situation. NOTE, we are not involved in any cracking-
> > or
> > > illegal activity. 
> > 
> > Well..... Do you understand that if you can decrypt the packets only by
> > sniffing, then you completely break the SSL stuff, which was designed to
> > resist to such attacks?
> > 
> > In other words, you can't do that.... Sorry..... Unless you have the
> > private keys of the servers....
> > 
> > -- 
> > Erwann ABALEA
> > System and Development Engineer - Certplus SA
> > [EMAIL PROTECTED]
> > - RSA PGP Key ID: 0x2D0EABD5 -
> > 
> > ______________________________________________________________________
> > OpenSSL Project                                 http://www.openssl.org
> > Development Mailing List                       [EMAIL PROTECTED]
> > Automated List Manager                           [EMAIL PROTECTED]
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [EMAIL PROTECTED]
> Automated List Manager                           [EMAIL PROTECTED]
> 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to