[Security] TLS Certificates Verification

Florian Zeitz florian.zeitz at gmx.de
Tue Aug 19 19:10:05 CDT 2008

Hash: SHA1

So this is my take on summing up the problems and some thoughts about them:
First up, what do we want? (Often been asked never really answered in
this thread IMHO)
I personally think we want something with similar (in user experience)
properties to ESession (Jargon free encryption):
* Encryption should be straightforward to set up/enable (just a click of
a button, or automagically when support has been determined over disco)
* Identity should be easy to verify
* Encryption and Identity Verification should be separate things (i.e.
You can talk over an encrypted connection with someone, while you don't
know who he is)

Next up problems arising from this when using TLS:
The main problem is verifying certificates (which is what this thread
should be about).
As far as I can see there are mainly two ways this could be done:
1. Make it possible to use a SAS/shared secret that can be compared to
verify the certs
2. A CA

A CA seems to have many problems. It would need to certify that a JID
belongs to a certain certificate. This needs to be verified in a
reliable way. psa suggested to do that automatically. Now I may be
wrong, but I'm under the impression that if somebody can pretend to be
sending a message to you from a certain JID he should also be able to do
that to a certification service too.

Another problem I see when using a CA (and doing it in an automated
fashion) attacks a basic aspect of XMPP: decentralization. Such a CA
would have to be central and therefore is a single point of failure.

Using SAS OTOH doesn't seem to be a good method if you want to have bots
or other services communicate over an encrypted session.

Probably the best idea is using each when applicable.
For normal user-to-user communication SAS are probably the best method.
While some have argued that having to talk to somebody out-of-band is
sometimes not possible, or to hard I personally consider it the only
possibility if you don't have a third trusted party. As for the argument
Peter brought in that he doesn't have the information to contact
somebody out-of-band I'd personally argue that if you don't have that
information you can never be sure who the person you're talking to
really is. You may or may not always talk to a MITM or a real person you
just can't tell.

If you have non-human entities (set-top boxes etc.) you might want to
use a CA and have that CAs certificate on each system that needs to
verify an identity of an entity in your infrastructure. I'd consider
this he easiest and most practicable solution. (Note that it might be
worthwhile to issue xmpp.net certificates for this purpose so that there
is one CA whose certificate all clients have).

Another issue with certificates in general (that Justin Karneges already
brought up) is that there should be only one certificate per JID. That
means you have to get this certificate to all machines you use that
account with. One solution would be to store the certificate on the
server (doesn't really sound like a good idea). The other would be to
leave it to the user to transfer the certificate from machine to
machine, which probably falls in to the "to hard" category.

Finally some words on the ESession debate:
ESession is very nice to use as end-user and the protocol seems nice
too. It's a shame that so many work writing the XEP and implementing it
has went into it, when it should have been obvious from the start that
it would not be considered secure basically due to the fact that it is
new. OTOH it really is just that, not proven to be secure. XTLS would be
relatively straight forward to define and implement because it is
heavily based on technologies already, or soon to be in use. So XTLS
sounds like the better option for now.

And some very last words on deniabillity:
While I like Peter Saint-Andre think that courts just wont care (after
all it seems to be enough if some copyright enforcement people claim a
certain IP has downloaded copyrighted material (where I personally would
argue that logs of that could be easily forged)) I still think it is
nice to have. After all the alternative is that it is completely
verifiable that it was you that made a certain statement, which is
something you definitely don't want.
Version: GnuPG v1.4.6 (GNU/Linux)


More information about the Security mailing list