On 07/07/2016 07:15 AM, Amos Jeffries wrote:
On 7/07/2016 1:55 p.m., Marcus Kool wrote:
On 07/06/2016 10:07 PM, Alex Rousskov wrote:
On 07/06/2016 05:01 PM, Marcus Kool wrote:
On 07/06/2016 11:36 AM, Steve Hill wrote:
I'm using a transparent proxy and SSL-peek and have hit a problem with
an iOS app which seems to be doing broken things with the SNI.
The app is making an HTTPS connection to a server and presenting an
SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if
this behaviour is actually illegal, but it certainly doesn't seem
to make a lot of sense to me.
[snip]
Q3. What should Squid do when receiving a wildcard SNI?
The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
about them forever. The last question is important, which brings us to:
Since Squid tries to mimic the behavior of the server and of the client,
it deserves a patch where instead of doing a DNS lookup and then doing a
connect (based on the result of the DNS lookup?),
Squid simply connects to the IP address that the client tries to
connect to
and does the TLS handshake with the SNI (that does not make sense).
This way it mimics the client a bit better.
I believe that is what Squid does already but please correct me if I am
wrong.
Steve said that Squid rejects the connection because of a failed DNS
lookup.
So what is Squid doing? Is it doing the following ?
- connect to the original IP
- use the presented SNI to the server
- do a DNS lookup and reject
No it is doing Host: header verification on the faked CONNECT request
which uses the SNI in the Host: header value. This is not strictly
required for CONNECT messages, but does potentially prevent Squid using
other IPs than the original one the client was contacting.
Squid _has_ the original IP so why would Squid potentially connect to an
other IP ?
If the SNI is a valid domain name (ie resolves in DNS). Then Squid
should continue on past the check.
Does Squid do a DNS lookup or only check the value for "valid" characters?
When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.
It is interesting to know if an ICAP server or URL rewriter is called
and with which parameters when the ios app breaks.
Whether Squid should generate a fake CONNECT with a wildcard host name
is an interesting question:
1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).
2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.
3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.
#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).
I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
so the URL redirector receives both the original IP address and
the peeked SNI value to make its decisions.
I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
also get both the IP address and the SNI value.
That is a problem for the service. Squid can already send anything in:
<http://www.squid-cache.org/Doc/config/adaptation_meta/>.
Which problem are you referring to?
Maybe you have mistaken it for the inability of most ICAP services to
send things back to Squid in the same way.
The ICAP server needs both the IP and the SNI which Squid can be configured
to do. What do you suggest that an ICAP server needs to send back to Squid?
A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.
To support the weirdest apps Squid might have to simply copy all
unusual characters to present the same parameter values to the server.
It is being mapped into the HTTP equivalent value. Which are Host:
header and authority-URI. Only valid FQDN names can make it through the
mapping.
Here things get complicated.
It is correct that Squid enforces apps to follow standards or
should Squid try to proxy connections for apps when it can?
Marcus
But we do not want to break things... so which characters are
so unusual that Squid does not want to accept them?
In Steve's case the asterisk at the start of the domain name. The name
labels must each start with an alphabet character a-z or A-Z. That is a
fixed requirement. The other characters that follow are where things get
fuzzy depending on what RFCs you follow.
Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
