Re: Security of HTTPS

[Ng Pheng Siong <ngps () netmemetic com>]

On Fri, Nov 26, 2004 at 06:58:44PM -0600, Frank Knobbe wrote:
> On Tue, 2004-11-23 at 10:00, lordchariot () earthlink net wrote:
> > I wouldn't necessarily call it a MITM attack, but there are some products
> > out there that intentionally decrypt an SSL connection. These type of
> > products will take an SSL certificate as presented from the web site, and
> > re-create a new one on-the-fly to present to the client browser. If the
> > product's CA cert is loaded into the client, there aren't any certificate
> > warnings. If not, then most people click through the cert warning anyway
> > because they don't know any better.
>
> Yuck... that's too complicated. All such a product needs are the public
> and private keys from the server. At run-time, it can sniff the public
> key of the visiting client, and that's all that's required to follow an
> SSL session up to and including the exchange of the session keys (after
> which point the device can decrypt and monitor the full SSL session).
> This is caused by an (I guess intentional) weakness in the SSL
> handshaking. 

You're thinking of a device near the server. lordchariot is talking about a
device near the client which doesn't have admin access to the server. He
gave the example of virus/adware scanning, which is aimed at protecting the
client.

> (If I remember right, the skinny is that the client encrypts the
> pre-master key and sends it to the server. The server [and client] then
> generate the master key which is used to generate the session key. The
> "weakness" imho is that there is no transfer of encrypted key material
> from the server to the client, which would require the clients secret
> key to decrypt. Thus, by having the clients public key, and the servers
> public and private key, an observer can follow the negotiation and
> arrive with the same session key materials as the server. Or perhaps
> that is a feature :)

In SSL/TLS, the client certificate request is optional, and its typical
use, HTTPS, does not require client certificates, so there is no client
public/private key here that can be used to "transfer encrypted key
material". 

Cheers.

-- 
Ng Pheng Siong <ngps () netmemetic com> 

http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards