On 25/02/2015 9:29 a.m., Tsantilas Christos wrote: > Hi all, > > > This patch adds server_name ACL matching server name(s) obtained from > various sources such as CONNECT request URI, client SNI, and SSL server > certificate CN. > > During each SslBump step, Squid improves its understanding of a "true > server name", with a bias towards server-provided (and Squid-validated) > information. > > The server-provided server names are retrieved from the server > certificate CN and Subject Alternate Names. The new server_name ACL > matches any of alternate names and CN. If the CN or an alternate name is > a wildcard, then the new ACL matches any domain that matches the domain > with the wildcard.
The principle for ACLs is to test specific things about the transaction. Having tests like this server_name that tests generic name (which can vary wildly across the transaction processing) is not a good idea. It dilutes the certainty about what is being tested and what will match for any given circumstances. I think we should be adding two ACLs here, one for the SNI and one for the cert field value, unless they are guaranteed to be the same and we reject traffic where they differ (like Host header validation ensures dstdomain is the/a domain for the server contacted). Mentioning which - the CONNECT request URI hostname and client SNI values need to be validated against each other, or the CVE-2009-0801 type of issue is opened all over again for HTTPS. I'm also a bit worried that server_name will be confusing for newcomers who may think its meaning more like that actually filled by dstdomain. "sni" should be sufficient since the term is more commonly known by the acronym. Also note that bumping is not the only source of SNI information. * In reverse-proxy HTTPS connections there is SNI containing the virtual hosted domain name. * In TLS connections to an explict proxy there is SNI for the proxy name the client knows about. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
