RE: Security of HTTPS

[Frank Knobbe <frank () knobbe us>]

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. 

(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 :)


What you described IS a classic MITM where the intercepting device
presents its own certificate.

Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part