[Security] TLS Certificates Verification (summary)

Johansson Olle E oej at edvina.net
Wed Aug 20 05:24:54 CDT 2008

20 aug 2008 kl. 12.08 skrev Dave Cridland:

> On Wed Aug 20 07:37:32 2008, Johansson Olle E wrote:
>> 1) XMPP often uses (and the XMPP foundation strongly recommends)  
>> TLS  between client and server. Within server, the messages are in  
>> the  clear. Thus, it gives no secure channel between two end  
>> points. Also,  between two endpoints connecting to servers with  
>> TLS, there could be a  non-TLS connection server-to-server (S2S).  
>> So even with a TLS  connection between a client and a server, we  
>> can't assume that we have  security end-to-end. We need to set that  
>> up. This discussion is about  how to set up confidential and  
>> authenticated client-to-client  sessions, based on the this scenario.
> Right, good summary.
>> 3) Clients may be behind NAT, so even a client-to-client direct   
>> session may need help from a server (proxy). This will have to be   
>> considered.
> This is a non-issue - we have Jingle, so we have the ability to  
> negotiate various channels, at least one of which (IBB) will work  
> through any amount of NATs and firewalling, albeit at a cost of  
> efficiency and ugliness. Really, this whole debate about IBB vs NATs  
> vs whatever is immaterial; we have Jingle specifically to solve all  
> these problems, and it passes the buck to ICE-TCP et al to solve the  
> tricky cases.
After spending many years with SIP and NAT traversal, I know that we  
will still need NAT traversal proxys, ICE/STUN is just a discovery  
service. And considering a possible future with IPv4 and IPv6, there  
will be proxys there too. Any solution has to work with an unknown or  
wellidentified point in the middle.

>> 5) Not all clients are human. We need solutions, but maybe not one   
>> solution, for
>>    - human clients on some sort of computer
>>    - bots with a delegation from a human (set-top-boxes)
>>    - applications (XMPP is used as middleware)
> For reasons concerning the retention of my santity, at least, I'd  
> prefer these to be as common as possible.

Me too!

I think we have to separate the technichal solution from implementor's  
guidelines. The guidelines could talk about using USB sticks, propose  
user interaction and other things that help those who write the  
interface in the server and the client. We need to make sure that all  
clients and servers share the same terminology. For instance -  
ejabberd docs talk about a "certificate" when they mean a file  
consisting of "private key in PEM encoding and CA certificate in PEM  
encoding" - which is confusing. And PSI always complain over my CAcert  
certificate, but doesn't propose a solution if I really want to keep  
using this certificate, like SSH. All of the little tings need to  
improve in order for users and admins to get going in the same  
direction - a more secure XMPP network :-)


More information about the Security mailing list