Re: Unorthodox SSL Questions

[Jeffrey Altman]

Marton Anka wrote:

The client cannot trust the host because the client is not verifying

the Host's certificate.

The client has no way of knowing whether or not the proxy server has

been compromised. Therefore it is not acceptable

to trust the proxy to decrypt and reencrypt the data. You have now

introduced a man in the middle.

I think there's an error in your logic. First you state that the Client
cannot trust the Host because it hasn't verified its certificate, then
you go on to say that it is because it has no way of knowing whether
Proxy has been compromised or not.

I do not believe there is an error in my logic.
You are using the client's trust of the Proxy
to bootstrap whether or not the client trusts
the Host with whom it is attempting to communicate
securely.

If the Proxy server becomes compromised, the Proxy
will continue to be trusted by the clients even
though all of the data exchanged between the Client
and the Host will now be visible to an attacker. Or
worse the proxy can redirect to a host which is not
even yours.

In my mind, the Client should not care one bit
about the identity of the Proxy, the Proxy should
simply being acting as a packet forwarder through
which the SSL/TLS session between the Client and
the Host is negotiated.  Now what I see as your
problem is that the Client (being a standard browser)
is not going to trust the certificates which you
are using for Host identification.

I think this is two separate
problems:

1. Verifying identities based on a trust chain.

2. Trusting or not trusting someone or someone's judgement by
determining if they'd been compromised or not.

I think 1) is solved by this process. I also think that 2) will dever be
solved by anyone.

Think about it this way: if Client were to connect to Host directly, it
would still have no way of knowing if Host itself had been compromised
or not.

Of course not.  However, I would hope that the
security of your hosts (not being visible to the
outside world) is going to be significantly better
than the security of your external proxy.

It all depends upon your threat model of course.  SSL/TLS
does not protect against host compromises.  What it does
protect against is the visibility and integrity of the
data stream between a client and an authenticated server.
If you are going to use SSL/TLS in such a way as to
significantly reduce the strength of that functionality,
you probably should use something other than SSL/TLS
to protect your data.

The first question is, is this cryptographically sound if we assume

that Proxy has not fallen into the wrong hands?

No. It is not a sound security process.

Even if we "assume that Proxy has not fallen into the wrong hands"? Can
you elaborate?

There is nothing wrong with your model assuming that
the client is willing to trust the proxy to protect
the rest of the food chain.  What you have to realize
is that by making that assumption the Client really
does not have any ability to trust that the data it
sends really is received by the appropriate destination.

Assuming that the Proxy has not fallen into the wrong
hands is like assuming you will never be attacked.  The
point of security analysis of protocols is to determine
where the weak points are and how those weak points
could result in data compromise if they were to fail.

Jeffrey Altman

smime.p7s

Description: S/MIME Cryptographic Signature