On 30/05/2016 11:03 p.m., Erik Seres wrote:
> Hi Willy and Amos,
> 
> I think I am confused by what information is expected to go into the
>  PP2_TYPE_AUTHORITY field and how it would be a suitable substitute 
> for what SNI represents.

PP2 is generic and needs to relay multiple protocols.

Authority is a frequently used and generic thing holding a host:port or
IP:port value representing the server for the protocol being relayed.

SNI breakes the normal pattern used by other protocols and restricts its
value to only being an FQDN. No port or raw-IP representation of the
server permitted.


The mapping is generic and works for any wrapper protocol TLS is
transmitted over:

When generating the authority from an SNI;
 * copy the SNI value into authority as-is, and
 * append the server port being contacted.


When generating an SNI from an authority:
* drop the port, and
* if the remainder is a raw-IP, there is no SNI
* else, the remainder is the SNI value.


> 
> Where would that information (server name?) come from outside the
> TLS handshake?

>From the authority field of whatever transfer protocol the TLS is being
wrapped by / relayed over.

PP2 in this case. But it could also be HTTP (CONNECT message) or SMTP
(Start-TLS).


> 
> And why is HTTP CONNECT mentioned at all in this discussion?

Two reasons:

1) Because HAProxy and Squid which implement relay and gateway for PP2
protocol are HTTP proxies.

2) Because there is a pile of trouble and security issues that exist as
a direct result of the HTTP authority being represented mutiple times in
different ways in a single CONNECT message.

  It is a good example of why we should not have several
not-quite-identical representations in a PP2 message (PP2_TYPE_AUTHORITY
and PP2_TYPE_SSL_SNI).


>
> Again, excuse my ignorance but I just can’t seem to put two and two together.
> 

Amos


Reply via email to