[squid-dev] Non TLS connections to HTTP and SSL_BUMP ports
Eliezer Croitor
ngtech1ltd at gmail.com
Sat Jul 4 21:33:44 UTC 2020
Hey Dev Team,
Long before SSL-BUMP got to what it is now I had a question in my mind:
What about connections on intercepted port which are either non TLS/SSL or
when squid had some server or client negotiation issues?
The first issue with TLS connections is that if for any reason the proxy
didn't managed to negotiate and establish a TLS connection with the server,
the client is STUCK.
I cannot touch TLS related code due to obviates reasons but I believe it's
trivial to have:
- Proxy side "retries" toward the TLS server
- A hook point for an ACL to decide what to do in such a scenario
ie in case of an error in the negotiation with the server
I have seen Golang code that does something about it and it works based on
the assumption that the client will always send something before the server.
The sketch of such a function can be like the PROXY protocol parsing(in a
way.).
- If TLS handshake exists, try to parse
- If parse is OK try to connect the remote server else throw the
connection into some ACL
- If the remote server responds well to a TLS handshare, bump else
spice
I understand that it overlaps some of the bump-first in a way.
With this issue the resolution for other scenarios: which a client really
doesn't speak RFC TLS or something similar, might be possible?
I have seen couple times a situation which port 443 is used for customized
protocols such as VPN and others.
The risk I can see is that the proxy admins (which we know that do weird
stuff when allowed) will allow any TLS error to be bypassed.
If we will leave the error logs into cache.log in debug level 1 like today
but still allow to bypass, would it change anything?
I will really appreciate feedback about this specific issue.
Eliezer
----
Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: <mailto:ngtech1ltd at gmail.com> ngtech1ltd at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20200705/7679b546/attachment.html>
More information about the squid-dev
mailing list