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