[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
trust?

>>> 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.


Dirk

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


More information about the Security mailing list