[Security] TLS Certificates Verification

Dirk Meyer dmeyer at tzi.de
Mon Aug 18 14:22:48 CDT 2008

"Eric Rescorla" wrote:
> On Mon, Aug 18, 2008 at 7:20 AM, Jonathan Schleifer
> <js-xmpp-security at webkeks.org> wrote:
>> Am 18.08.2008 um 13:39 schrieb Dirk Meyer:
>>> Yes, that is solution 1 for this problem. Each user can get a
>>> certificate signed by the XMPP CA. But is that practical. I have not
>>> tried to get a signature for my XMPP server yet, but how hard is it?
>>> Every person who can use an IM client and register for an account
>>> should be able to get a signed certificate. IMHO usability is the main
>>> problem we have to keep in mind when trying to solve this.
>> It's impossible for the average user to get a certificate. Only geeks will
>> use encryption then. I still think we should pay the money needed for a
>> cryptanalysis for ESessions and use that - that's crypto even my grandmother
>> can use! All that hacky TLS for end-to-end stuff is more than
>> userunfriendly.
> The method you use for establishing trust in credentials is largely
> orthogonal to the protocol you're using. In particular, TLS is quite compatible
> with leap-of-faith type mechanisms. That's just not what's the standard
> end-user clients use. It's true that TLS doesn't currently support an SAS,
> but it wouldn't be that hard to add if it were determined that that's what
> people wanted, and that's probably more efficient in the long run than
> having an entirely separate security protocol for jabber alone.

Yes. TLS provides two things: a certificate chain to validate a
certificate and a way to encrypt a session based on public and private
keys. The later is something we need and it is well understood. So
IMHO we should use it. The first one is crap: like Jonathan wrote:
only geeks will send the key to a CA.

So what we can do very easy is generate self signed certificates to
use with TLS. Now we have encryption. We have one question left: does
this self signed certificate belong to the person I want to talk
to. Since we have no CA we need to find other ways.

> Instead of talking about specific technologies, I would recommend
> trying to figure out what interaction model you want to have. I.e.,
> what do you want people to do to determine that the person on the
> other end of the line is the correct one?

Right. After the TLS handshake I know the public key and the
fingerprint of my peer. I also have my own key pair. How can we use
that to verify the peer.

First idea: send fingerprint over a different transport, e.g. mail.
That sucks because fingerprints are not very userfriendly. So maybe a
password (shared secret) to verify this? Maybe some sort of web of

>>> Yes, a key-pair and self-sign to make any TLS library happy. After
>>> that we can create a web of trust outside the ssl library. I don't
>>> know if this will work, but it could.
>> Signing keys is nothing the average user will do. Never.
> They will if the software just does it.

Right. One openssl command will generate a self-signed certificate.
Simple and TLS is happy.

> I must say, I find SAS fairly user unfriendly as well. At least with
> a fingerprint type mechanism I can go out of band to someone's web
> site and check the fingerprint. With SAS, I have to actually call
> them on the phone.

That is not an option for me. I want bots to talk to each other. They
can not use the phone.


"The early worm gets eaten by the bird, so sleep late."

More information about the Security mailing list