[Security] TLS Certificates Verification

Dirk Meyer dmeyer at tzi.de
Tue Aug 19 14:58:54 CDT 2008


"Eric Rescorla" wrote:
> 1. A PAKE mode (SRP)[0]
> 2. Session resumption.

After some searching I found only a draft about SRP and TLS, but
openssl seems to support it which is a good sign. I want to avoid
using something libraries do not support.

> SRP allows the client and server to establish an authenticated connection
> based purely on a short password. The only restriction is that they need
> to share a known DH group, but that's easy to profile.

What is a DH group?

> If you're not willing to have long-term secret storage (though why you would
> be willing to have long-term public storage but not secret storage would
> need some explaining) you can do TLS-SRP and then rehandshake on the
> same TLS channel, this time using self-signed certs, and then the peers can
> simply remember each others certs.

Let me try some scenarios here and you tell me if I missed
something. Let us asume a client may have a client certificate that is
different from the user certificate. But we have a pubsub entry with a
list of all client certificates for a user signed by that user
certificate about X.509 (setting up a CA is very complicated).

Now Alice connects to a client of Bob. They look up if they know each
other and they don't. So they choose SRP. I window will pop up asking
for a password. Both user enter the password, TLS works and after that
we do a rehandshake based on the certificates. Now both have the
client certificate of the other. Using XMPP we can exchange the user
certificate. Works!

Now Alice and Bob connect again with different clients. They have the
user certificate and use "normal" TLS handshakes. They receive a
certificate they do not know. They look up the pubsub items and find
the key they got and vertify the signature of that key using the
others user certificate. Works!

I start a client (e.g. set-top box). It generates a self-signed
certificate and searches for a client of mine with the users secret
key. This is doable in XMPP somehow. Let's call such a client master
now. The new client connects to my master and chooses SRP. I either
enter a password on both sides or the new one may have a static
printed somewhere. After that we rehandshake, the client has the
master public key and the master has the client certificate to sign
and put on the XMPP server. Works!

The XMPP server is used to store user certificates of friends signed
by any client key or user key. It is also used to hold a list of
client certificates and to revoke client certificates.

The only thing that that not work if Alice wants to connect to a dump
set-top box of Bob and never connected with Bob before. But IMHO this
is a good sign. You should always start with connected to a client
controlled by the user and not the bot.

How does this sound?


Dirk

-- 
When nothing can possibly go wrong, it will.


More information about the Security mailing list