Thank you, Amos, In scenario that Shekhar described it is acceptable to have unsecure clinet<->squid communication. There would be actually only one client and and the difficulty we are facing is that our websocket client implementation is unable to interact with specific certificates using openssl. Ultimate goal is that client (via squid) should represent to server certificates that openssl have access. Thus, we are considering squid. Based on your answer I assume it is not possible to configure squid in such a way, please correct me if I'm wrong. Seems our scenario is similar to the option #3 described here: http://lists.squid-cache.org/pipermail/squid-users/2017-January/013953.html Thanks, Roman On 6/18/19, 11:31 PM, "squid-users on behalf of Amos Jeffries" <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx on behalf of squid3@xxxxxxxxxxxxx> wrote: On 19/06/19 4:13 pm, Satyanarayana, Shekhar wrote: > Hi Squid Community, > > I am relatively new to Squid and I am facing the following issue, would > truly appreciate if you could help. > > Squid4.6 is used as a forward proxy to convert all traffic to secure > traffic. > > The configuration of squid is very simple, it allows all traffic and > uses urlrewrite.pl to replace "http" to "https". What you are doing is actually the opposite to secure. Letting the server think the traffic is secure so it passes on confidential or privacy sensitive information - then exposing all that within clear-text HTTP and again within the client itself. > > Question: > > 1.Is there any way to upgrade a websocket connection to secure websocket > using squid4.6? > No. Squid does not support WebSockets natively. > 2.Or say I use wss-client (without certificate) and a wss-server(with > certificates), is there a way to inform squid to use its own > certificates even mentioned in "tls_outgoing_options" to establish the > connection? > What Squid does is enact the CONNECT or GET request of the HTTP messages you see with wireshark - excluding the Upgrade HTTP feature you may see being attempted. For the CONNECT WebSockets happens inside the tunnel. With no interference by Squid. For the GET either the server accepts the fallback to HTTP response. Or rejects it and the client is expected to fallback itself to another method of communication. eg WebSockets native port or a CONNECT tunnel. You cannot simply turn a GET request onto a bi-directional binary tunnel. Nor a bi-directional tunnel into a GET response. They are entirely different syntax and incompatible concepts / semantics. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.squid-2Dcache.org_listinfo_squid-2Dusers&d=DwIGaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=3q1cou6mQpySVdgvrT4UXuR-8zDVO5Th0-ypQm3MaSE&m=DXanVFfv4gim1_IFY24RenJExFIumvXojFN06ovaVpA&s=53LUnq1oGInZT4hR-9DXBQYqjI_OSYRktzTEhBOzQ1U&e=
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
