[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Tue Aug 19 23:13:57 CDT 2008


Thanks for the helpful summary. I think we might want to have separate 
threads about each of these topics, but for now I will reply inline 
about everything.

Florian Zeitz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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)

Those seem like good goals.

> 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

I agree with you that each of these may be appropriate in different 
contexts.

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

This is really a question about properly designing the cert generation 
process. First of all it is difficult to spoof packets in XMPP (it's 
easy for a rogue server, but if your account is hosted on server with 
evil admins then you have bigger problems). Second, the process might 
involve two different media (e.g., you send a message to the CA via 
XMPP, receive a link, click the link to visit a website, fill out a 
form, receive a second XMPP message with a request code, paste that 
request code into the web form, the CA generates your cert and presents 
it to you via the web, and you paste that into your Jabber client). Or 
your client could do all that automagically using x:data forms.

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

We don't all need to use a single CA. We might begin by using xmpp.net 
but then encourage other CAs to get involved.

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

Doesn't that introduce a single point of failure? ;-)

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

Yes, that is a challenge.

> One solution would be to store the certificate on the
> server (doesn't really sound like a good idea). 

I'm curious to see how that would really work.

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

Agreed.

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

I have slowly come to that conclusion, too.

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

I'm neutral about deniability as a requirement.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080819/e0e1e5a5/attachment-0001.bin 


More information about the Security mailing list