[Security] TLS Certificates Verification (summary)
Johansson Olle E
oej at edvina.net
Wed Aug 20 07:14:00 CDT 2008
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
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
present a different set of keys.
More information about the Security