Re: [TLS] Impact of draft-ietf-mptcp-api on TLS

[Florian Weimer <[e-mail]>]

On 11/28/2012 08:52 PM, Geoffrey Keating wrote:

> Maybe a related example will help: suppose the user is trying to
> connect to https://198.51.100.3.  There is an HTTP proxy configured,
> so what the browser actually does is make a TCP connection to
> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
> SSL negotiation.  The certificate still has to mention 198.51.100.3,
> and doesn't have to mention 192.0.2.99.
>
> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
> whatever), then 198.51.100.3 is the address that has to appear in the
> certificate, even if the connection is redirected to some other
> endpoint, even if the redirection happens before any data is actually
> sent on the connection.

I suspect the confusion arises because if the interaction with 
198.51.100.3 causes another connection with a different IP address to be 
created, it hast to be verified against the IP address 198.51.100.3 as well.

This is different from HTML over HTTPS, where additional connections use 
the embedded addresses and names for endpoint verification.  This is 
possible because in the HTML/HTTPS case, these names and addresses are 
protected by the TLS channel, while in MPTCP, they are not.

-- 
Florian Weimer / Red Hat Product Security Team