Yes, all the compression/cipher spec are transmitted in clear 
during the handshake phase and that can give some information
to an attacker like the use of "fool" ciphers (40 bits).

It is also in that phase that the master key is secretely
negiotiated between the two parties (thanks to a 
key exchange private key like an RSA private key). So the
interception of the handshake packets and the possession of 
the private key would be sufficient to handle all the application
packets for that session. 

Not an easy task however and that will work only for servers that
we control. So why not just plug some code in them that send the
clear data (received or transmitted) to a sniffer server (maybe
on a TLS channel).



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bodo Moeller
> Sent: Tuesday, June 15, 1999 5:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: advice needed
> 
> 
> On Tue, Jun 15, 1999 at 04:54:40PM +0200, Pierre De Boeck wrote:
> 
> > 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.
> 
> Of course it's not trivial to read the encrypted payload data, but the
> algorithm identifiers are transmitted in clear; so the attacker can
> tell which connections use only 40-bit encryption keys, and -- if
> enough computing power can be put into this -- can do key-searches for
> those and then decrypt them.
> ______________________________________________________________________
> 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