Looks interesting, but it looks complex and sounds like I'd need more of a router than I have to do it.
From: "Craddock, Tommy" <Tommy.Craddock@xxxxxxxxxxxxxx>
To: "squid-users@xxxxxxxxxxxxxxxxxxxxx" <squid-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 3, 2017 2:04 PM
Subject: Re: HTTPS support
Hello,
Is this more in line with what your trying to do:
Tommy
From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx]
On Behalf Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: HTTPS support
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: HTTPS support
In any case, I'm finding SSH through proxy is undesirable or not possible. I'm thinking shellinabox, which is insecure but run over
a secure proxy link, is my best bet.
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
To: j m <acctforjunk@xxxxxxxxx>; "squid-users@xxxxxxxxxxxxxxxxxxxxx" <squid-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: HTTPS support
To: j m <acctforjunk@xxxxxxxxx>; "squid-users@xxxxxxxxxxxxxxxxxxxxx" <squid-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: HTTPS support
On 05/03/2017 11:37 AM, j m wrote:
> the plan was to use SSH through the proxy.
If your SSH clients support SSH through an HTTP proxy, then do not
authenticate them in Squid. Just do not let them go anywhere but the SSH
server. It would be like running an exposed-to-the-world SSH server, no
worse. Squid will still know nothing about SSH. Squid will just tunnel
opaque bytes from your SSH clients to your SSH server. You will use an
HTTP (not HTTPS) Squid port for this traffic because your SSH clients
are unlikely to support HTTPS to the proxy.
Your browsers will still use HTTPS to the proxy (and get authenticated).
Thus, you will have two different http_ports, one for HTTP
(unauthenticated SSH clients) and one for HTTPS (authenticated browsers).
If SSH blocking is not based on _protocol_ but on port, then follow
Antony Stone advice and change the SSH server port instead of
HTTP-proxying SSH connections.
Alex.
> the plan was to use SSH through the proxy.
If your SSH clients support SSH through an HTTP proxy, then do not
authenticate them in Squid. Just do not let them go anywhere but the SSH
server. It would be like running an exposed-to-the-world SSH server, no
worse. Squid will still know nothing about SSH. Squid will just tunnel
opaque bytes from your SSH clients to your SSH server. You will use an
HTTP (not HTTPS) Squid port for this traffic because your SSH clients
are unlikely to support HTTPS to the proxy.
Your browsers will still use HTTPS to the proxy (and get authenticated).
Thus, you will have two different http_ports, one for HTTP
(unauthenticated SSH clients) and one for HTTPS (authenticated browsers).
If SSH blocking is not based on _protocol_ but on port, then follow
Antony Stone advice and change the SSH server port instead of
HTTP-proxying SSH connections.
Alex.
> ------------------------------------------------------------------------
> *From:* Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
> *To:* "squid-users@xxxxxxxxxxxxxxxxxxxxx"
> <squid-users@xxxxxxxxxxxxxxxxxxxxx>
> *Cc:* j m <acctforjunk@xxxxxxxxx>
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: HTTPS support
>
> On 05/03/2017 10:57 AM, j m wrote:
>> I wanted to set up a proxy on my home server for use from remote
>> locations to use as a web proxy (of course) and also to run SSH over.
>
> The "ssh" part is unrelated to Squid. Secure ssh separately from Squid.
>
>
>> This means that basic auth is undesirable due to the login being sent
>> in clear text. So, someone suggested digest auth, and I was happy.
>> But, now I'm finding that PuTTY and WinSCP do not support digest auth.
>> And consequently, I haven't found any other SSH clients that support
>> digest. (sigh)
>
> These problems will go away if you stop mixing Squid and ssh. Squid is
> HTTP while PuTTY/WinSCP is SSH. You gain very little by trying to use
> the same authentication mechanism for both protocols in your use case.
>
>
>> So, I'm back to plan b, and that is to have a secure proxy connection so
>> all browser-to-server communication is encrypted.
>
> That is a good idea if all of your browsers support it. Popular browsers
> support HTTPS-to-proxy on desktop, but I am not sure about their mobile
> versions. You may have to jump through some hoops.
>
>
>
>> So the question is, does
>> anyone know if squid 3.5 on Ubuntu 16.04 supports secure connections?
>
>
> Squid v3.5 supports secure connections to the proxy. See "TLS / SSL
> Options" for the http_port directive (not the https_port directive!).
>
> You can install Squid v3.5 on Ubuntu. I do not know whether the official
> Ubuntu Squid package is built with the required support.
>
>
> HTH,
>
> Alex.
>
>
>
>
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
