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:[email protected]> [email protected]
_______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
