[Security] TLS Certificates Verification (summary)

[Johansson Olle E]

20 aug 2008 kl. 12.50 skrev Dave Cridland:

> On Wed Aug 20 11:24:54 2008, Johansson Olle E wrote:
>> 20 aug 2008 kl. 12.08 skrev Dave Cridland:
>>> On Wed Aug 20 07:37:32 2008, Johansson Olle E wrote:
>>>> 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.
> For the record, I'm saying that we, here, don't need to care at all  
> about NAT traversal because this problem is either solved, or else  
> needs to be solved by Jingle and not by us  and not here.
>
Well, if you want end to end TLS, there's some architecture examples  
that will be affected by a middle man. Take the example of the OTR  
"proxy" :-)  I mentioned earlier. No one really
bother to check the OTR fingerprints, so they would not discover the  
proxy, unless the client reacted the way my ssh client reacts to a new  
key fingerprint.

You need to be aware of this when designing a solution. Requiring TLS  
encryption of the stream after connection setup won't really be  
affected as much as using the TLS connection certificate/keys, where a  
middleman can
present a different set of keys.

/O