[squid-users] Can I use squid to reverse proxy https (without making it a man-in-the-middle)?

[Stefan Blachmann]

I am using squid 3.5.23 for no-caching reverse proxying http to
backend web servers.
I want to do the same with https.

If I try to make cache_peer, acl, http_access and cache_peer_access
for port 443 in addition to port 80, the connection attempt fails with
browser complaining about error code: SSL_ERROR_RX_RECORD_TOO_LONG. In
squid access log then there is a complaint about "invalid request".

Is there a way to configure squid to just pass through https traffic
to https backends? Just like it does with http?
That is, _without_ needing to give squid access to the certificates and keys?

(I ask because all instructions I found in the web are
privacy-breaking decrypting Mitm interception instructions. And I do
_not_ want to do it this way!)
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid dead error with 3.5.23

[Nil Nik]

Hi,


Using Squid 3.5.23, After some time found squid dead with below errors. Even i 
restart it doesn't start for some time (5-10 minutes).


Apr 28 16:16:18 mysystem (squid-1): Ipc::Mem::Segment::open failed to 
shm_open(/squid-ssl_session_cache.shm): (2) No such file or directory
Apr 28 16:16:18 mysystem squid[30477]: Squid Parent: (squid-1) process 30490 
exited with status 1
Apr 28 16:16:21 mysystem squid[30477]: Squid Parent: (squid-1) process 30495 
started
Apr 28 16:16:21 mysystem (squid-1): Ipc::Mem::Segment::open failed to 
shm_open(/squid-ssl_session_cache.shm): (2) No such file or directory
Apr 28 16:16:21 mysystem squid[30477]: Squid Parent: (squid-1) process 30495 
exited with status 1
Apr 28 16:16:24 mysystem squid[30477]: Squid Parent: (squid-1) process 30500 
started
Apr 28 16:16:24 mysystem (squid-1): Ipc::Mem::Segment::open failed to 
shm_open(/squid-ssl_session_cache.shm): (2) No such file or directory
Apr 28 16:16:24 mysystem squid[30477]: Squid Parent: (squid-1) process 30500 
exited with status 1
Apr 28 16:16:24 mysystem squid[30477]: Squid Parent: (squid-1) process 30500 
will not be restarted due to repeated, frequent failures
Apr 28 16:16:24 mysystem squid[30477]: Exiting due to repeated, frequent 
failures

I was using squid 3.3.9 never observed such kind of issue.
Please help.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Huge memory required for squid 3.5

[Nil Nik]

Hi,


Can we cleanup 'Cache' using -

SSL_flush_sessions(ctx, time(NULL));  or
SSL_flush_sessions(ctx,0);

Periodically or on reconfigure?

Nil


From: squid-users  on behalf of Nil 
Nik 
Sent: Wednesday, May 3, 2017 11:54 AM
To: Alex Rousskov; squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Huge memory required for squid 3.5

Hi,


NO_DEFAULT_CA doesn't help. Still goes in GB. Can anyone tell me area so that i 
can work on?


Regards,

Nil



From: squid-users  on behalf of Alex 
Rousskov 
Sent: Wednesday, April 26, 2017 7:37 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Huge memory required for squid 3.5

On 04/26/2017 09:35 AM, Yuri Voinov wrote:

> This is openssl issue or squid's?

AFAIK, the underlying issue (i.e., bug #4005) is mostly a Squid problem:
Squid is caching SSL contexts (instead of certificates) and does a poor
job maintaining that cache.

Earlier OpenSSL versions (that had to be used when the original code was
written) complicated solving this problem. OpenSSL v1.0.1+ added APIs
that simplify some aspects of the anticipated fix. Certain OpenSSL
aspects will continue to hurt Squid, even with OpenSSL v1.0.1, but if
you want to blame a single project (instead of both), blame Squid.


> Why sessions can't share CA's data cached in memory? shared_ptr invented
> already.

OpenSSL knew how to share things well before std::shared_ptr became
available. However, it is the responsibility of the application to tell
OpenSSL what to create from scratch and what to share. A part of the
problem is that Squid tells OpenSSL to create many large things from
scratch and then caches those large things while underestimating their
size by several(?) orders of magnitude (and probably also missing many
cache hits).

More details, including the difference between problems associated with
from-client and to-server connections, are documented in the "Memory
Usage" section of http://wiki.squid-cache.org/Features/SslBump
Features/SslBump - Squid Web Proxy 
Wiki
wiki.squid-cache.org
Squid-in-the-middle decryption and encryption of straight CONNECT and 
transparently redirected SSL traffic, using configurable CA certificates.



FWIW, we have spent a lot of resources on triaging this problem and
drafting possible solutions (in various overlapping areas), but there is
currently no sponsor to finalize and implement any of the fixes. AFAIK,
bug #4005 is stuck.

I am glad that NO_DEFAULT_CA helps mitigate some of the problems in some
environments.


HTH,

Alex.


> 26.04.2017 9:08, Amos Jeffries пишет:
>> On 26/04/17 10:53, Yuri Voinov wrote:
>>> Ok, but how NO_DEFAULT_CA should help with this?
>>
>> It prevents OpenSSL copying that 1MB into each incoming client
>> connections memory. The CAs are only useful there when you have some
>> of the global CAs as root for client certificates - in which case you
>> still only want to trust the roots you paid for service and not all of
>> them.
>>
>> Just something to try if there are huge memory issues with TLS/SSL
>> proxying. The default behaviour is fixed for Squid-4 with the config
>> options changes. But due to being a major surprise for anyone already
>> relying on global roots for client certs it remains a problem in 3.5.
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid proxy without name resolution for internet adresses behind parent proxy

[Amos Jeffries]

On 04/05/17 06:45, mbaltruschat wrote:

Hello Amos,

many thanks, i think i got it, it was a Problem with my "never_direct"
rules, i already got them in the conf, but the dont worked, so after your
tips,  i wrote the conf from scratch in Notepad++ and now it works - i guess
it was a Problem with charset while saving.

again, many thanks, can i donate something for squid development? Paypal?


Donations to Squid project:
 

or, Donations to me for time doing Squid related stuff:
 

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid as Proxy/Web Filer only

[Amos Jeffries]

On 04/05/17 06:54, Skyvolt Zoltar wrote:

Hi, I am completely new to Squid.

I would like to know if it is possible to configure squid within my 
network as a web filter only.


The scenario would be like this.

User's browser has proxy configuration > forwards all the browsers 
request to Squid > squid does an analysis > squid forward to the 
default gateway of my network.


But all that within the same IP address range. I have a router already 
doing the routing from my internal to external network.


Or I cannot? Will Squid only work between two different network, with 
different IP address (one IP for an internal interface and other for 
external interface)?


Sure can. Squid works between any HTTP client(s) and server(s).

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Passing Windows username to parent proxy

[Amos Jeffries]

On 04/05/17 02:19, BurningSky wrote:

Hi Amos,

Thanks for the reply. Sorry, what I meant by that was that I was logged into 
the Squid Windows server using remote desktop so that I could edit the 
configuration so that is separate from the machine trying to use Squid a a 
proxy.

So it would seem like the issue is with the firewall from what you're saying? 
Using the most basic Squid config pointing it at the firewall as a parent 
should be all I need to do for the Windows username to be passed through to the 
firewall?


If I'm remembering it correctly yes.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[j m]

I forgot: I know VPN doesn't work from there, but it's on the standard port, so 
I could investigate that.  However the issue is then everything else running 
will want to run over the VPN, e.g. email, IM, various IT services I don't know 
about.

  From: Daniel Greenwald 
 To: "Craddock, Tommy"  
Cc: "squid-users@lists.squid-cache.org" 
 Sent: Wednesday, May 3, 2017 3:23 PM
 Subject: Re: [squid-users] HTTPS support
   
Seems to me you are overthinking this. What you're up against is blocked 
outbound ports. Simply run openvpn at your home over one of the allowed 
outbound ports eg 80 443 or possibly 3128/8080 according to your environment 
and call it a day. You won't need proxy authentication or haproxy etc..

On Wed, May 3, 2017 at 3:35 PM, Craddock, Tommy  
wrote:

Hello, Yeah, that guide is for PFsense in particular, but you could run HAProxy 
by itself (say in a VM) and get the same result.  Just fwd those ports from 
your router to the HAProxy box. 
Thanks!  From: squid-users [mailto:squid-users-bounces@ 
lists.squid-cache.org]On Behalf Of j m
Sent: Wednesday, May 03, 2017 3:14 PM
To: squid-users@lists.squid-cache. org
Subject: Re: [squid-users] HTTPS support 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" 
To: "squid-users@lists.squid- cache.org" 
Sent: Wednesday, May 3, 2017 2:04 PM
Subject: Re: [squid-users] HTTPS support Hello, Is this more in line with what 
your trying to do: http://loredo.me/post/ 116633549315/geeking-out-with- 
haproxy-on-pfsense-the- ultimate Tommy From: squid-users 
[mailto:squid-users-bounces@ lists.squid-cache.org]On Behalf Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@lists.squid-cache. org
Subject: Re: [squid-users] 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 

To: j m ; "squid-users@lists.squid- cache.org" 

Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: [squid-users] 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.



> -- -- 
> *From:* Alex Rousskov 
> *To:* "squid-users@lists.squid- cache.org"
> 
> *Cc:* j m 
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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

Re: [squid-users] HTTPS support

[j m]

I don't believe blocked outbound ports is the problem.  I can for example 
connect to several ports in the 8090 - 8100 range using services other than 
SSH.  I've also tried moving the SSH server to 443 and one of these 
aforementioned ports, but no go.

  From: Daniel Greenwald 
 To: "Craddock, Tommy"  
Cc: "squid-users@lists.squid-cache.org" 
 Sent: Wednesday, May 3, 2017 3:23 PM
 Subject: Re: [squid-users] HTTPS support
   
Seems to me you are overthinking this. What you're up against is blocked 
outbound ports. Simply run openvpn at your home over one of the allowed 
outbound ports eg 80 443 or possibly 3128/8080 according to your environment 
and call it a day. You won't need proxy authentication or haproxy etc..

On Wed, May 3, 2017 at 3:35 PM, Craddock, Tommy  
wrote:

Hello, Yeah, that guide is for PFsense in particular, but you could run HAProxy 
by itself (say in a VM) and get the same result.  Just fwd those ports from 
your router to the HAProxy box. 
Thanks!  From: squid-users [mailto:squid-users-bounces@ 
lists.squid-cache.org]On Behalf Of j m
Sent: Wednesday, May 03, 2017 3:14 PM
To: squid-users@lists.squid-cache. org
Subject: Re: [squid-users] HTTPS support 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" 
To: "squid-users@lists.squid- cache.org" 
Sent: Wednesday, May 3, 2017 2:04 PM
Subject: Re: [squid-users] HTTPS support Hello, Is this more in line with what 
your trying to do: http://loredo.me/post/ 116633549315/geeking-out-with- 
haproxy-on-pfsense-the- ultimate Tommy From: squid-users 
[mailto:squid-users-bounces@ lists.squid-cache.org]On Behalf Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@lists.squid-cache. org
Subject: Re: [squid-users] 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 

To: j m ; "squid-users@lists.squid- cache.org" 

Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: [squid-users] 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.



> -- -- 
> *From:* Alex Rousskov 
> *To:* "squid-users@lists.squid- cache.org"
> 
> *Cc:* j m 
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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 Securit

Re: [squid-users] HTTPS support

[Daniel Greenwald]

Seems to me you are overthinking this. What you're up against is blocked
outbound ports. Simply run openvpn at your home over one of the allowed
outbound ports eg 80 443 or possibly 3128/8080 according to your
environment and call it a day. You won't need proxy authentication or
haproxy etc..

On Wed, May 3, 2017 at 3:35 PM, Craddock, Tommy <
tommy.cradd...@bicgraphic.com> wrote:

> Hello,
>
>
>
> Yeah, that guide is for PFsense in particular, but you could run HAProxy
> by itself (say in a VM) and get the same result.  Just fwd those ports from
> your router to the HAProxy box.
>
>
> Thanks!
>
>
>
>
>
> *From:* squid-users [mailto:squid-users-boun...@lists.squid-cache.org] *On
> Behalf Of *j m
> *Sent:* Wednesday, May 03, 2017 3:14 PM
>
> *To:* squid-users@lists.squid-cache.org
> *Subject:* Re: [squid-users] HTTPS support
>
>
>
> 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" 
> *To:* "squid-users@lists.squid-cache.org"  cache.org>
> *Sent:* Wednesday, May 3, 2017 2:04 PM
> *Subject:* Re: [squid-users] HTTPS support
>
>
>
> Hello,
>
>
>
> Is this more in line with what your trying to do:
>
>
>
> http://loredo.me/post/116633549315/geeking-out-with-
> haproxy-on-pfsense-the-ultimate
>
>
>
> Tommy
>
>
>
> *From:* squid-users [mailto:squid-users-boun...@lists.squid-cache.org
> ] *On Behalf Of *j m
> *Sent:* Wednesday, May 03, 2017 2:44 PM
> *To:* squid-users@lists.squid-cache.org
> *Subject:* Re: [squid-users] 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 
> *To:* j m ; "squid-users@lists.squid-cache.org" <
> squid-users@lists.squid-cache.org>
> *Sent:* Wednesday, May 3, 2017 1:19 PM
> *Subject:* Re: [squid-users] 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.
>
>
>
>
>
> > 
> > *From:* Alex Rousskov 
> > *To:* "squid-users@lists.squid-cache.org"
> > 
> > *Cc:* j m 
> > *Sent:* Wednesday, May 3, 2017 12:22 PM
> > *Subject:* Re: [squid-users] 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 Sec

Re: [squid-users] HTTPS support

[Craddock, Tommy]

Hello,

Yeah, that guide is for PFsense in particular, but you could run HAProxy by 
itself (say in a VM) and get the same result.  Just fwd those ports from your 
router to the HAProxy box.

Thanks!


From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of j m
Sent: Wednesday, May 03, 2017 3:14 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] HTTPS support

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" 
mailto:tommy.cradd...@bicgraphic.com>>
To: 
"squid-users@lists.squid-cache.org" 
mailto:squid-users@lists.squid-cache.org>>
Sent: Wednesday, May 3, 2017 2:04 PM
Subject: Re: [squid-users] HTTPS support

Hello,

Is this more in line with what your trying to do:

http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate

Tommy

From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] 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 
mailto:rouss...@measurement-factory.com>>
To: j m mailto:acctforj...@yahoo.com>>; 
"squid-users@lists.squid-cache.org" 
mailto:squid-users@lists.squid-cache.org>>
Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: [squid-users] 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.




> 
> *From:* Alex Rousskov 
> mailto:rouss...@measurement-factory.com>>
> *To:* 
> "squid-users@lists.squid-cache.org"
> mailto:squid-users@lists.squid-cache.org>>
> *Cc:* j m mailto:acctforj...@yahoo.com>>
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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 ema

Re: [squid-users] HTTPS support

[j m]

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" 
 To: "squid-users@lists.squid-cache.org"  
 Sent: Wednesday, May 3, 2017 2:04 PM
 Subject: Re: [squid-users] HTTPS support
   
#yiv0837668946 #yiv0837668946 -- _filtered #yiv0837668946 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0837668946 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0837668946 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0837668946 
#yiv0837668946 p.yiv0837668946MsoNormal, #yiv0837668946 
li.yiv0837668946MsoNormal, #yiv0837668946 div.yiv0837668946MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0837668946 a:link, 
#yiv0837668946 span.yiv0837668946MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv0837668946 a:visited, #yiv0837668946 
span.yiv0837668946MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv0837668946 
span.yiv0837668946EmailStyle17 {color:#1F497D;}#yiv0837668946 
.yiv0837668946MsoChpDefault {font-size:10.0pt;} _filtered #yiv0837668946 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv0837668946 div.yiv0837668946WordSection1 
{}#yiv0837668946 Hello,    Is this more in line with what your trying to do:    
http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate
    Tommy    From: squid-users 
[mailto:squid-users-boun...@lists.squid-cache.org]On Behalf Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] 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 
To: j m ; "squid-users@lists.squid-cache.org" 

Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: [squid-users] 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. 



> 
> *From:* Alex Rousskov 
> *To:* "squid-users@lists.squid-cache.org"
> 
> *Cc:* j m 
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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 bee

Re: [squid-users] Squid proxy without name resolution for internet adresses behind parent proxy

[Alex Rousskov]

On 05/03/2017 12:45 PM, mbaltruschat wrote:

> can i donate something for squid development? Paypal?

If you would like to donate to the Squid Project, please see the URL
below but note that Amos, personally, will not receive your donation
because Squid Foundation directors are unpaid volunteers. If you want to
reward Amos, please contact him (off-list) for details. Either way, you
will be helping the Squid Project, and we thank you!

http://www.squid-cache.org/Foundation/donate.html

Cheers,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[Craddock, Tommy]

Hello,

Is this more in line with what your trying to do:

http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate

Tommy

From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of j m
Sent: Wednesday, May 03, 2017 2:44 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] 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 
mailto:rouss...@measurement-factory.com>>
To: j m mailto:acctforj...@yahoo.com>>; 
"squid-users@lists.squid-cache.org" 
mailto:squid-users@lists.squid-cache.org>>
Sent: Wednesday, May 3, 2017 1:19 PM
Subject: Re: [squid-users] 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.




> 
> *From:* Alex Rousskov 
> mailto:rouss...@measurement-factory.com>>
> *To:* 
> "squid-users@lists.squid-cache.org"
> mailto:squid-users@lists.squid-cache.org>>
> *Cc:* j m mailto:acctforj...@yahoo.com>>
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid proxy without name resolution for internet adresses behind parent proxy

[mbaltruschat]

Hello Amos,

many thanks, i think i got it, it was a Problem with my "never_direct"
rules, i already got them in the conf, but the dont worked, so after your
tips,  i wrote the conf from scratch in Notepad++ and now it works - i guess
it was a Problem with charset while saving.

again, many thanks, can i donate something for squid development? Paypal?

Regards
Marcel



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-proxy-without-name-resolution-for-internet-adresses-behind-parent-proxy-tp4682225p4682289.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid as Proxy/Web Filer only

[Skyvolt Zoltar]

Hi, I am completely new to Squid.

I would like to know if it is possible to configure squid within my network
as a web filter only.

The scenario would be like this.

User's browser has proxy configuration > forwards all the browsers request
to Squid > squid does an analysis > squid forward to the default gateway of
my network.

But all that within the same IP address range. I have a router already
doing the routing from my internal to external network.

Or I cannot? Will Squid only work between two different network, with
different IP address (one IP for an internal interface and other for
external interface)?

Thank you.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[j m]

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 
 To: j m ; "squid-users@lists.squid-cache.org" 
 
 Sent: Wednesday, May 3, 2017 1:19 PM
 Subject: Re: [squid-users] 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.



> 
> *From:* Alex Rousskov 
> *To:* "squid-users@lists.squid-cache.org"
> 
> *Cc:* j m 
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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.
> 
> 
> 
> 



   ___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[j m]

>So, redirect *external* connections to port 3128 to localhost 22, and then SSH 
>to your home server on port 3128?

I think what you're saying is it's a port number issue, that certain ports are 
problematic.  But that doesn't seem to be the case.  I already run SSH on a 
non-standard port, and have tried moving SSH to squid's port after moving 
moving squid elsewhere; it still doesn't work.  In addition, I'm able to 
connect to an entirely different service I run on the same server.  So it seems 
SSH is being filtered
>Squid is an HTTP (and partly FTP) proxy, not a general-purpose TCP proxy.
This is the first I've been told this.  I personally don't know since I'm very 
proxy-illiterate. 

  From: Antony Stone 
 To: squid-users@lists.squid-cache.org 
 Sent: Wednesday, May 3, 2017 12:48 PM
 Subject: Re: [squid-users] HTTPS support
   
On Wednesday 03 May 2017 at 18:37:36, j m wrote:

> I cannot SSH into my home server from an organization that is apparently
> blocking SSH connections, for whatever reason, intentional or not.  I am,
> however, able to use a squid proxy that I run from my home server.

So, redirect *external* connections to port 3128 to localhost 22, and then SSH 
to your home server on port 3128?

> So the plan was to use SSH through the proxy.

Squid is an HTTP (and partly FTP) proxy, not a general-purpose TCP proxy.


Antony.

-- 
"In fact I wanted to be John Cleese and it took me some time to realise that 
the job was already taken."

 - Douglas Adams

                                                  Please reply to the list;
                                                        please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


   ___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[Alex Rousskov]

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.



> 
> *From:* Alex Rousskov 
> *To:* "squid-users@lists.squid-cache.org"
> 
> *Cc:* j m 
> *Sent:* Wednesday, May 3, 2017 12:22 PM
> *Subject:* Re: [squid-users] 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.
> 
> 
> 
> 

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[Antony Stone]

On Wednesday 03 May 2017 at 18:37:36, j m wrote:

> I cannot SSH into my home server from an organization that is apparently
> blocking SSH connections, for whatever reason, intentional or not.  I am,
> however, able to use a squid proxy that I run from my home server.

So, redirect *external* connections to port 3128 to localhost 22, and then SSH 
to your home server on port 3128?

> So the plan was to use SSH through the proxy.

Squid is an HTTP (and partly FTP) proxy, not a general-purpose TCP proxy.


Antony.

-- 
"In fact I wanted to be John Cleese and it took me some time to realise that 
the job was already taken."

 - Douglas Adams

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[j m]

I should clarify things a bit.  I do realize SSH and squid are separate, but 
the problem I'm having is I cannot SSH into my home server from an organization 
that is apparently blocking SSH connections, for whatever reason, intentional 
or not.  I am, however, able to use a squid proxy that I run from my home 
server.  So the plan was to use SSH through the proxy.  VPNs are out of the 
question as this does not work.
I would only need to use my proxy from the desktop, so mobile is not required.  

>Squid v3.5 supports secure connections to the proxy. See "TLS / SSL
>Options" for the http_port directive (not the https_port directive!).

This is helpful since I was trying to use https_port.
  From: Alex Rousskov 
 To: "squid-users@lists.squid-cache.org"  
Cc: j m 
 Sent: Wednesday, May 3, 2017 12:22 PM
 Subject: Re: [squid-users] 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.



   ___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] HTTPS support

[Alex Rousskov]

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.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] HTTPS support

[j m]

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.  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)
So, I'm back to plan b, and that is to have a secure proxy connection so all 
browser-to-server communication is encrypted.  Since SSH over proxy might not 
be feasible because I don't want to use basic auth, I could use shellinabox if 
the proxy link is secure.  So the question is, does anyone know if squid 3.5 on 
Ubuntu 16.04 supports secure connections?  From what I've found it does not, 
although nothing has definitively said one way or another.  Is there a way to 
tell?  I've tried configuring for it and it didn't work, but I have little 
confidence in my config file for this.___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Huge memory required for squid 3.5

[Yuri Voinov]

You sure?


http://wiki.squid-cache.org/SquidFaq/SquidMemory


03.05.2017 21:44, Nil Nik пишет:
>
> Hi,
>
>
> Its not disk cache, its due to in memory SSL context.
>
>
> Nil
>
>
> *From:* squid-users  on
> behalf of Yuri 
> *Sent:* Wednesday, May 3, 2017 11:55 AM
> *To:* squid-users@lists.squid-cache.org
> *Subject:* Re: [squid-users] Huge memory required for squid 3.5
>  
>
> How big disk cache(s) and how it full?
>
>
> 03.05.2017 17:54, Nil Nik пишет:
>> Hi,
>>
>>
>> NO_DEFAULT_CA doesn't help. Still goes in GB. Can anyone tell me area
>> so that i can work on?
>>
>>
>> Regards,
>>
>> Nil
>>
>>
>> 
>> *From:* squid-users  on
>> behalf of Alex Rousskov 
>> *Sent:* Wednesday, April 26, 2017 7:37 PM
>> *To:* squid-users@lists.squid-cache.org
>> *Subject:* Re: [squid-users] Huge memory required for squid 3.5
>>  
>> On 04/26/2017 09:35 AM, Yuri Voinov wrote:
>>
>> > This is openssl issue or squid's?
>>
>> AFAIK, the underlying issue (i.e., bug #4005) is mostly a Squid problem:
>> Squid is caching SSL contexts (instead of certificates) and does a poor
>> job maintaining that cache.
>>
>> Earlier OpenSSL versions (that had to be used when the original code was
>> written) complicated solving this problem. OpenSSL v1.0.1+ added APIs
>> that simplify some aspects of the anticipated fix. Certain OpenSSL
>> aspects will continue to hurt Squid, even with OpenSSL v1.0.1, but if
>> you want to blame a single project (instead of both), blame Squid.
>>
>>
>> > Why sessions can't share CA's data cached in memory? shared_ptr
>> invented
>> > already.
>>
>> OpenSSL knew how to share things well before std::shared_ptr became
>> available. However, it is the responsibility of the application to tell
>> OpenSSL what to create from scratch and what to share. A part of the
>> problem is that Squid tells OpenSSL to create many large things from
>> scratch and then caches those large things while underestimating their
>> size by several(?) orders of magnitude (and probably also missing many
>> cache hits).
>>
>> More details, including the difference between problems associated with
>> from-client and to-server connections, are documented in the "Memory
>> Usage" section of http://wiki.squid-cache.org/Features/SslBump
>> 
>> Features/SslBump - Squid Web Proxy Wiki
>> 
>> wiki.squid-cache.org
>> Squid-in-the-middle decryption and encryption of straight CONNECT and
>> transparently redirected SSL traffic, using configurable CA certificates.
>>
>>
>>
>> FWIW, we have spent a lot of resources on triaging this problem and
>> drafting possible solutions (in various overlapping areas), but there is
>> currently no sponsor to finalize and implement any of the fixes. AFAIK,
>> bug #4005 is stuck.
>>
>> I am glad that NO_DEFAULT_CA helps mitigate some of the problems in some
>> environments.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>> > 26.04.2017 9:08, Amos Jeffries пишет:
>> >> On 26/04/17 10:53, Yuri Voinov wrote:
>> >>> Ok, but how NO_DEFAULT_CA should help with this?
>> >>
>> >> It prevents OpenSSL copying that 1MB into each incoming client
>> >> connections memory. The CAs are only useful there when you have some
>> >> of the global CAs as root for client certificates - in which case you
>> >> still only want to trust the roots you paid for service and not all of
>> >> them.
>> >>
>> >> Just something to try if there are huge memory issues with TLS/SSL
>> >> proxying. The default behaviour is fixed for Squid-4 with the config
>> >> options changes. But due to being a major surprise for anyone already
>> >> relying on global roots for client certs it remains a problem in 3.5.
>> >>
>> >> Amos
>> >>
>> >> ___
>> >> squid-users mailing list
>> >> squid-users@lists.squid-cache.org
>> >> http://lists.squid-cache.org/listinfo/squid-users
>> squid-users Info Page 
>> lists.squid-cache.org
>> squid-users -- General discussion relating to Squid. The membership
>> of this list is thousands of Squid users from around the world About
>> squid-users
>>
>>
>> >
>> >
>> >
>> > ___
>> > squid-users mailing list
>> > squid-users@lists.squid-cache.org
>> > http://lists.squid-cache.org/listinfo/squid-users
>> squid-users Info Page 
>> lists.squid-cache.org
>> squid-users -- General discussion relating to Squid. The membership
>> of this list is thousands of Squid users from around the world About
>> squid-users
>>
>>
>> >
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>> squid-users Info Page 
>> lists.squid-cache.org
>> squid-users -- Gene

Re: [squid-users] Huge memory required for squid 3.5

[Nil Nik]

Hi,


Its not disk cache, its due to in memory SSL context.


Nil

From: squid-users  on behalf of Yuri 

Sent: Wednesday, May 3, 2017 11:55 AM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Huge memory required for squid 3.5


How big disk cache(s) and how it full?

03.05.2017 17:54, Nil Nik пишет:
Hi,


NO_DEFAULT_CA doesn't help. Still goes in GB. Can anyone tell me area so that i 
can work on?


Regards,

Nil



From: squid-users 

 on behalf of Alex Rousskov 

Sent: Wednesday, April 26, 2017 7:37 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Huge memory required for squid 3.5

On 04/26/2017 09:35 AM, Yuri Voinov wrote:

> This is openssl issue or squid's?

AFAIK, the underlying issue (i.e., bug #4005) is mostly a Squid problem:
Squid is caching SSL contexts (instead of certificates) and does a poor
job maintaining that cache.

Earlier OpenSSL versions (that had to be used when the original code was
written) complicated solving this problem. OpenSSL v1.0.1+ added APIs
that simplify some aspects of the anticipated fix. Certain OpenSSL
aspects will continue to hurt Squid, even with OpenSSL v1.0.1, but if
you want to blame a single project (instead of both), blame Squid.


> Why sessions can't share CA's data cached in memory? shared_ptr invented
> already.

OpenSSL knew how to share things well before std::shared_ptr became
available. However, it is the responsibility of the application to tell
OpenSSL what to create from scratch and what to share. A part of the
problem is that Squid tells OpenSSL to create many large things from
scratch and then caches those large things while underestimating their
size by several(?) orders of magnitude (and probably also missing many
cache hits).

More details, including the difference between problems associated with
from-client and to-server connections, are documented in the "Memory
Usage" section of http://wiki.squid-cache.org/Features/SslBump
Features/SslBump - Squid Web Proxy 
Wiki
wiki.squid-cache.org
Squid-in-the-middle decryption and encryption of straight CONNECT and 
transparently redirected SSL traffic, using configurable CA certificates.



FWIW, we have spent a lot of resources on triaging this problem and
drafting possible solutions (in various overlapping areas), but there is
currently no sponsor to finalize and implement any of the fixes. AFAIK,
bug #4005 is stuck.

I am glad that NO_DEFAULT_CA helps mitigate some of the problems in some
environments.


HTH,

Alex.


> 26.04.2017 9:08, Amos Jeffries пишет:
>> On 26/04/17 10:53, Yuri Voinov wrote:
>>> Ok, but how NO_DEFAULT_CA should help with this?
>>
>> It prevents OpenSSL copying that 1MB into each incoming client
>> connections memory. The CAs are only useful there when you have some
>> of the global CAs as root for client certificates - in which case you
>> still only want to trust the roots you paid for service and not all of
>> them.
>>
>> Just something to try if there are huge memory issues with TLS/SSL
>> proxying. The default behaviour is fixed for Squid-4 with the config
>> options changes. But due to being a major surprise for anyone already
>> relying on global roots for client certs it remains a problem in 3.5.
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users





___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org

Re: [squid-users] Passing Windows username to parent proxy

[BurningSky]

Hi Amos,

Thanks for the reply. Sorry, what I meant by that was that I was logged into 
the Squid Windows server using remote desktop so that I could edit the 
configuration so that is separate from the machine trying to use Squid a a 
proxy.

So it would seem like the issue is with the firewall from what you're saying? 
Using the most basic Squid config pointing it at the firewall as a parent 
should be all I need to do for the Windows username to be passed through to the 
firewall?

Thanks,
Sam 

> On 3 May 2017, at 14:43, Amos Jeffries [via Squid Web Proxy Cache] 
>  wrote:
> 
> On 03/05/17 22:47, BurningSky wrote:
> 
> > Hi, 
> > 
> > I have been searching around the web for a while now to try and find a 
> > solution but having not had much luck I was wondering if someone on here 
> > could help. 
> > 
> > I have set up a Windows 2008 R2 server running the Diladele pre-complied 
> > Squid 3.5 proxy and am looking to make use of our firewall for URL 
> > filtering. Our firewall allows/denies access to certain web sites by using 
> > the AD group memberships of the Windows end user. 
> > 
> > I have managed to get a basic config up and running and am using the line 
> > below to forward the traffic via the proxy setup on our firewall. If I 
> > point 
> > the end user machine directly at the firewall then the filtering works but 
> > the firewall doesn't have caching, thus wanting to use Squid. 
> > cache_peer whl-utm1.e2v.com parent 3128 0 no-query default login=PASSTHRU 
> > 
> > As I am new to Squid I thought, perhaps naively, that the end user domain 
> > username would automatically be forwarded on with the requests to the 
> > parent 
> > but in the parents log file I just seem to see the username of the account 
> > that I have RDPed to the server on, not of the end user machine that the 
> > request is coming from.
> 
> Not sure exactly what you mean by "RPDd", but you can only authenticate 
> one user at a time with connection based authentication. 
> 
> The login=PASSTHRU is correct for passing whatever the clients sends 
> through to the parent proxy and vice versa for the parents response auth 
> headers. Squid must not itself perform any type of authentication with 
> either client, or the parents cache_peer TCP connections. 
> 
> Amos 
> 
> ___ 
> squid-users mailing list 
> [hidden email] 
> http://lists.squid-cache.org/listinfo/squid-users
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Passing-Windows-username-to-parent-proxy-tp4682272p4682277.html
> To unsubscribe from Passing Windows username to parent proxy, click here.
> NAML




--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Passing-Windows-username-to-parent-proxy-tp4682272p4682278.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Passing Windows username to parent proxy

[Amos Jeffries]

On 03/05/17 22:47, BurningSky wrote:

Hi,

I have been searching around the web for a while now to try and find a
solution but having not had much luck I was wondering if someone on here
could help.

I have set up a Windows 2008 R2 server running the Diladele pre-complied
Squid 3.5 proxy and am looking to make use of our firewall for URL
filtering. Our firewall allows/denies access to certain web sites by using
the AD group memberships of the Windows end user.

I have managed to get a basic config up and running and am using the line
below to forward the traffic via the proxy setup on our firewall. If I point
the end user machine directly at the firewall then the filtering works but
the firewall doesn't have caching, thus wanting to use Squid.
cache_peer whl-utm1.e2v.com parent 3128 0 no-query default login=PASSTHRU

As I am new to Squid I thought, perhaps naively, that the end user domain
username would automatically be forwarded on with the requests to the parent
but in the parents log file I just seem to see the username of the account
that I have RDPed to the server on, not of the end user machine that the
request is coming from.


Not sure exactly what you mean by "RPDd", but you can only authenticate 
one user at a time with connection based authentication.


The login=PASSTHRU is correct for passing whatever the clients sends 
through to the parent proxy and vice versa for the parents response auth 
headers. Squid must not itself perform any type of authentication with 
either client, or the parents cache_peer TCP connections.


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Tutorial for better authentication than basic

[Amos Jeffries]

On 03/05/17 00:40, j m wrote:
Here's a question:  if I use SSL or TLS encryption between squid and 
browser, would even the basic auth login be encrypted?




All of the HTTP going to the proxy would be encrypted.


I'm thinking that instead of trying to use the proxy to SSH through, I 
could use something like shellinabox over the proxy if the link is 
encrypted.  This would be much easier and serve the purpose.


According to this link, it seems pretty straightforward to get Firefox 
or Chrome to do it: wiki.squid-cache.org/Features/HTTPS#Chrome 



Would the default config located at 
wiki.squid-cache.org/SquidFaq/ConfiguringSquid#Squid-3.5_default_config 
 
allow this?




The answer there depends on what the traffic is and what it needs from 
the proxy. Default config for Squid allows HTTP clients to use the 
proxy, that is all.


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] limit access with acl only based on source and destination domain

[Amos Jeffries]

On 03/05/17 12:40, Blaxton wrote:

Hi

I am trying to limit the out bound connection based on list of domain 
names defined

in srcdomain and dstdomain.

Here is acl :

acl From_Source_Domains srcdomain domain1 domain2 domain3
acl To_Destination_Domains dstdomain domain4 domain5 domain6

Now some web site says below considered OR and it is working for me:
http_access allow From_Source_Domains
http_access allow To_Destination_Domains

And some web sites saying below considered AND but it is not working 
for me:

http_access allow From_Source_Domains To_Destination_Domains

I am assuming since I have not allowed any port, then port should be 
disabled

but it is not, on OR of the src and dst domains.


No, ports are not part of that lines rule. There is no enable/disable - 
they are simply irrelevant when processing that line.


Traffic which gets filtered by that line coming from any client whose IP 
address rDNS matches one of the "From_Source_Domains" AND URL contains 
one of the "To_Destination_Domains" gets allowed into Squid.




If add
acl http_port 80
http_access allow http_port

Then it allow traffic from any source to any destination if port is 80.

Kind of confusing and need a bit of help.


The "how" is simple:

  http_access lines are processed from top to bottom, left to right. 
First fully matching line wins and its action (allow or deny) happens.






Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Huge memory required for squid 3.5

[Yuri]

How big disk cache(s) and how it full?


03.05.2017 17:54, Nil Nik пишет:

Hi,


NO_DEFAULT_CA doesn't help. Still goes in GB. Can anyone tell me area 
so that i can work on?



Regards,

Nil



*From:* squid-users  on 
behalf of Alex Rousskov 

*Sent:* Wednesday, April 26, 2017 7:37 PM
*To:* squid-users@lists.squid-cache.org
*Subject:* Re: [squid-users] Huge memory required for squid 3.5
On 04/26/2017 09:35 AM, Yuri Voinov wrote:

> This is openssl issue or squid's?

AFAIK, the underlying issue (i.e., bug #4005) is mostly a Squid problem:
Squid is caching SSL contexts (instead of certificates) and does a poor
job maintaining that cache.

Earlier OpenSSL versions (that had to be used when the original code was
written) complicated solving this problem. OpenSSL v1.0.1+ added APIs
that simplify some aspects of the anticipated fix. Certain OpenSSL
aspects will continue to hurt Squid, even with OpenSSL v1.0.1, but if
you want to blame a single project (instead of both), blame Squid.


> Why sessions can't share CA's data cached in memory? shared_ptr invented
> already.

OpenSSL knew how to share things well before std::shared_ptr became
available. However, it is the responsibility of the application to tell
OpenSSL what to create from scratch and what to share. A part of the
problem is that Squid tells OpenSSL to create many large things from
scratch and then caches those large things while underestimating their
size by several(?) orders of magnitude (and probably also missing many
cache hits).

More details, including the difference between problems associated with
from-client and to-server connections, are documented in the "Memory
Usage" section of http://wiki.squid-cache.org/Features/SslBump 

Features/SslBump - Squid Web Proxy Wiki 


wiki.squid-cache.org
Squid-in-the-middle decryption and encryption of straight CONNECT and 
transparently redirected SSL traffic, using configurable CA certificates.




FWIW, we have spent a lot of resources on triaging this problem and
drafting possible solutions (in various overlapping areas), but there is
currently no sponsor to finalize and implement any of the fixes. AFAIK,
bug #4005 is stuck.

I am glad that NO_DEFAULT_CA helps mitigate some of the problems in some
environments.


HTH,

Alex.


> 26.04.2017 9:08, Amos Jeffries пишет:
>> On 26/04/17 10:53, Yuri Voinov wrote:
>>> Ok, but how NO_DEFAULT_CA should help with this?
>>
>> It prevents OpenSSL copying that 1MB into each incoming client
>> connections memory. The CAs are only useful there when you have some
>> of the global CAs as root for client certificates - in which case you
>> still only want to trust the roots you paid for service and not all of
>> them.
>>
>> Just something to try if there are huge memory issues with TLS/SSL
>> proxying. The default behaviour is fixed for Squid-4 with the config
>> options changes. But due to being a major surprise for anyone already
>> relying on global roots for client certs it remains a problem in 3.5.
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users 


squid-users Info Page 
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of 
this list is thousands of Squid users from around the world About 
squid-users



>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users 


squid-users Info Page 
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of 
this list is thousands of Squid users from around the world About 
squid-users



>

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page 
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of 
this list is thousands of Squid users from around the world About 
squid-users





___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Huge memory required for squid 3.5

[Nil Nik]

Hi,


NO_DEFAULT_CA doesn't help. Still goes in GB. Can anyone tell me area so that i 
can work on?


Regards,

Nil



From: squid-users  on behalf of Alex 
Rousskov 
Sent: Wednesday, April 26, 2017 7:37 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Huge memory required for squid 3.5

On 04/26/2017 09:35 AM, Yuri Voinov wrote:

> This is openssl issue or squid's?

AFAIK, the underlying issue (i.e., bug #4005) is mostly a Squid problem:
Squid is caching SSL contexts (instead of certificates) and does a poor
job maintaining that cache.

Earlier OpenSSL versions (that had to be used when the original code was
written) complicated solving this problem. OpenSSL v1.0.1+ added APIs
that simplify some aspects of the anticipated fix. Certain OpenSSL
aspects will continue to hurt Squid, even with OpenSSL v1.0.1, but if
you want to blame a single project (instead of both), blame Squid.


> Why sessions can't share CA's data cached in memory? shared_ptr invented
> already.

OpenSSL knew how to share things well before std::shared_ptr became
available. However, it is the responsibility of the application to tell
OpenSSL what to create from scratch and what to share. A part of the
problem is that Squid tells OpenSSL to create many large things from
scratch and then caches those large things while underestimating their
size by several(?) orders of magnitude (and probably also missing many
cache hits).

More details, including the difference between problems associated with
from-client and to-server connections, are documented in the "Memory
Usage" section of http://wiki.squid-cache.org/Features/SslBump
Features/SslBump - Squid Web Proxy 
Wiki
wiki.squid-cache.org
Squid-in-the-middle decryption and encryption of straight CONNECT and 
transparently redirected SSL traffic, using configurable CA certificates.



FWIW, we have spent a lot of resources on triaging this problem and
drafting possible solutions (in various overlapping areas), but there is
currently no sponsor to finalize and implement any of the fixes. AFAIK,
bug #4005 is stuck.

I am glad that NO_DEFAULT_CA helps mitigate some of the problems in some
environments.


HTH,

Alex.


> 26.04.2017 9:08, Amos Jeffries пишет:
>> On 26/04/17 10:53, Yuri Voinov wrote:
>>> Ok, but how NO_DEFAULT_CA should help with this?
>>
>> It prevents OpenSSL copying that 1MB into each incoming client
>> connections memory. The CAs are only useful there when you have some
>> of the global CAs as root for client certificates - in which case you
>> still only want to trust the roots you paid for service and not all of
>> them.
>>
>> Just something to try if there are huge memory issues with TLS/SSL
>> proxying. The default behaviour is fixed for Squid-4 with the config
>> options changes. But due to being a major surprise for anyone already
>> relying on global roots for client certs it remains a problem in 3.5.
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


>

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
squid-users Info Page
lists.squid-cache.org
squid-users -- General discussion relating to Squid. The membership of this 
list is thousands of Squid users from around the world About squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Passing Windows username to parent proxy

[BurningSky]

Hi,

I have been searching around the web for a while now to try and find a
solution but having not had much luck I was wondering if someone on here
could help.

I have set up a Windows 2008 R2 server running the Diladele pre-complied
Squid 3.5 proxy and am looking to make use of our firewall for URL
filtering. Our firewall allows/denies access to certain web sites by using
the AD group memberships of the Windows end user.

I have managed to get a basic config up and running and am using the line
below to forward the traffic via the proxy setup on our firewall. If I point
the end user machine directly at the firewall then the filtering works but
the firewall doesn't have caching, thus wanting to use Squid.
cache_peer whl-utm1.e2v.com parent 3128 0 no-query default login=PASSTHRU

As I am new to Squid I thought, perhaps naively, that the end user domain
username would automatically be forwarded on with the requests to the parent
but in the parents log file I just seem to see the username of the account
that I have RDPed to the server on, not of the end user machine that the
request is coming from.

Do I need to enable some form of dummy authentication on the Squid proxy and
is this possible when running the Windows based version of the Squid proxy?

Any thoughts would be greatly appreciated!



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Passing-Windows-username-to-parent-proxy-tp4682272.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl bump and chrome 58

[Yuri]

Exactly.


03.05.2017 16:32, Rafael Akchurin пишет:

And on 3.5 too?

-Original Message-
From: Yuri [mailto:yvoi...@gmail.com]
Sent: Wednesday, May 3, 2017 12:30 PM
To: Rafael Akchurin ; Flashdown 

Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

Mountain brake, Raf :-)

Fixed yesterday, already running on productions (on my side) ;-)


03.05.2017 15:05, Rafael Akchurin пишет:

Sorry disregard - should practice my  google fu better - see
http://bugs.squid-cache.org/show_bug.cgi?id=4711

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org]
On Behalf Of Rafael Akchurin
Sent: Wednesday, May 3, 2017 10:48 AM
To: Flashdown ; Yuri Voinov

Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

[This sender failed our fraud detection checks and may not be who they
appear to be. Learn about spoofing at
http://aka.ms/LearnAboutSpoofing]

Hello all,

The following steps give in Chrome 58 the "Your connection is not private" error with 
"NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error:

(peek-an-splice bumping squid 3.5.23_1 as in
https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html)

1. Open Chrome 58+
2. Type some non existing domain name like "https://www.asdlajsdfl.com"; (note 
the httpS:// schema) 3. See the missing_subjectAltName error.

Correct behavior would be Squid generating faked certificate for the domain name 
"www.asdlajsdfl.com" *with* subjectAltName extension set to 
"www.asdlajsdfl.com".

So question is - does anyone know if this is already existing bug or shall I 
file one?
May be it is a feature?

Best regards,
Rafael


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org]
On Behalf Of Flashdown
Sent: Thursday, April 27, 2017 6:42 PM
To: Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

I've tested the registry setting and it worked out. You can copy the below 
lines in a .reg file and execute it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:0001


Best regards,
Flashdown

Am 2017-04-27 18:34, schrieb Flashdown:

Hello together,

here is a workaround that you could use in the meanwhile.

https://www.chromium.org/administrators/policy-list-3#EnableCommonNam
e
FallbackForLocalAnchors

Source:
https://www.chromium.org/administrators/policy-list-3#EnableCommonNam
e
FallbackForLocalAnchors

BEGIN

EnableCommonNameFallbackForLocalAnchors
Whether to allow certificates issued by local trust anchors that are
missing the subjectAlternativeName extension

Data type:
  Boolean [Windows:REG_DWORD]
Windows registry location:

Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAncho
r
s
Mac/Linux preference name:
  EnableCommonNameFallbackForLocalAnchors
Android restriction name:
  EnableCommonNameFallbackForLocalAnchors
Supported on:

  Google Chrome (Linux, Mac, Windows) since version 58 until
version 65
  Google Chrome OS (Google Chrome OS) since version 58 until
version 65
  Google Chrome (Android) since version 58 until version 65

Supported features:
  Dynamic Policy Refresh: Yes, Per Profile: No
Description:

  When this setting is enabled, Google Chrome will use the
commonName of a server certificate to match a hostname if the
certificate is missing a subjectAlternativeName extension, as long as
it successfully validates and chains to a locally-installed CA
certificates.

  Note that this is not recommended, as this may allow bypassing
the nameConstraints extension that restricts the hostnames that a
given certificate can be authorized for.

  If this policy is not set, or is set to false, server
certificates that lack a subjectAlternativeName extension containing
either a DNS name or IP address will not be trusted.
Example value:
  0x (Windows), false (Linux), false (Android), 
(Mac)
 END



Am 2017-04-27 18:16, schrieb Flashdown:

Hello together,

Suddenly I am facing the same issue when users Chrome has been
updated to V58. I am running Squid 3.5.23.

This is the reason:
https://www.thesslstore.com/blog/security-changes-in-chrome-58/
Short: Common Name Support Removed in Chrome 58 and Squid does not
create certs with DNS-Alternatives names in it. Because of that it
fails.

Chrome says:
1. Subject Alternative Name Missing - The certificate for this site
does not contain a Subject Alternative Name extension containing a
domain name or IP address.
2. Certificate Error - There are issues with the site's certificate
chain (net::ERR_CERT_COMMON_NAME_INVALID).

Can we get Squid to add the DNS-Alternative Name to the generated
certs? Since this is what I believe is now required in Chrome 58+

Best regards,
Enrico


Am 2017-04-21 15:35, schrieb Yuri Voinov:

I see no problem w

Re: [squid-users] ssl bump and chrome 58

[Rafael Akchurin]

And on 3.5 too?

-Original Message-
From: Yuri [mailto:yvoi...@gmail.com] 
Sent: Wednesday, May 3, 2017 12:30 PM
To: Rafael Akchurin ; Flashdown 

Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

Mountain brake, Raf :-)

Fixed yesterday, already running on productions (on my side) ;-)


03.05.2017 15:05, Rafael Akchurin пишет:
> Sorry disregard - should practice my  google fu better - see 
> http://bugs.squid-cache.org/show_bug.cgi?id=4711
>
> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
> On Behalf Of Rafael Akchurin
> Sent: Wednesday, May 3, 2017 10:48 AM
> To: Flashdown ; Yuri Voinov 
> 
> Cc: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] ssl bump and chrome 58
>
> [This sender failed our fraud detection checks and may not be who they 
> appear to be. Learn about spoofing at 
> http://aka.ms/LearnAboutSpoofing]
>
> Hello all,
>
> The following steps give in Chrome 58 the "Your connection is not private" 
> error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" 
> error:
>
> (peek-an-splice bumping squid 3.5.23_1 as in 
> https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html)
>
> 1. Open Chrome 58+
> 2. Type some non existing domain name like "https://www.asdlajsdfl.com"; (note 
> the httpS:// schema) 3. See the missing_subjectAltName error.
>
> Correct behavior would be Squid generating faked certificate for the domain 
> name "www.asdlajsdfl.com" *with* subjectAltName extension set to 
> "www.asdlajsdfl.com".
>
> So question is - does anyone know if this is already existing bug or shall I 
> file one?
> May be it is a feature?
>
> Best regards,
> Rafael
>
>
> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
> On Behalf Of Flashdown
> Sent: Thursday, April 27, 2017 6:42 PM
> To: Yuri Voinov 
> Cc: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] ssl bump and chrome 58
>
> I've tested the registry setting and it worked out. You can copy the below 
> lines in a .reg file and execute it.
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
> "EnableCommonNameFallbackForLocalAnchors"=dword:0001
>
>
> Best regards,
> Flashdown
>
> Am 2017-04-27 18:34, schrieb Flashdown:
>> Hello together,
>>
>> here is a workaround that you could use in the meanwhile.
>>
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNam
>> e
>> FallbackForLocalAnchors
>>
>> Source:
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNam
>> e
>> FallbackForLocalAnchors
>>> BEGIN
>> EnableCommonNameFallbackForLocalAnchors
>> Whether to allow certificates issued by local trust anchors that are 
>> missing the subjectAlternativeName extension
>>
>> Data type:
>>  Boolean [Windows:REG_DWORD]
>> Windows registry location:
>>
>> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAncho
>> r
>> s
>> Mac/Linux preference name:
>>  EnableCommonNameFallbackForLocalAnchors
>> Android restriction name:
>>  EnableCommonNameFallbackForLocalAnchors
>> Supported on:
>>
>>  Google Chrome (Linux, Mac, Windows) since version 58 until 
>> version 65
>>  Google Chrome OS (Google Chrome OS) since version 58 until 
>> version 65
>>  Google Chrome (Android) since version 58 until version 65
>>
>> Supported features:
>>  Dynamic Policy Refresh: Yes, Per Profile: No
>> Description:
>>
>>  When this setting is enabled, Google Chrome will use the 
>> commonName of a server certificate to match a hostname if the 
>> certificate is missing a subjectAlternativeName extension, as long as 
>> it successfully validates and chains to a locally-installed CA 
>> certificates.
>>
>>  Note that this is not recommended, as this may allow bypassing 
>> the nameConstraints extension that restricts the hostnames that a 
>> given certificate can be authorized for.
>>
>>  If this policy is not set, or is set to false, server 
>> certificates that lack a subjectAlternativeName extension containing 
>> either a DNS name or IP address will not be trusted.
>> Example value:
>>  0x (Windows), false (Linux), false (Android), 
>> (Mac)
>>  END
>>
>>
>>
>> Am 2017-04-27 18:16, schrieb Flashdown:
>>> Hello together,
>>>
>>> Suddenly I am facing the same issue when users Chrome has been 
>>> updated to V58. I am running Squid 3.5.23.
>>>
>>> This is the reason:
>>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>>> Short: Common Name Support Removed in Chrome 58 and Squid does not 
>>> create certs with DNS-Alternatives names in it. Because of that it 
>>> fails.
>>>
>>> Chrome says:
>>> 1. Subject Alternative Name Missing - The certificate for this site 
>>> does not contain a Subject Alternative Name extension containing a 
>>> domain name or IP address.
>>> 2. Certificate Error - There ar

Re: [squid-users] ssl bump and chrome 58

[Yuri]

Mountain brake, Raf :-)

Fixed yesterday, already running on productions (on my side) ;-)


03.05.2017 15:05, Rafael Akchurin пишет:

Sorry disregard - should practice my  google fu better - see 
http://bugs.squid-cache.org/show_bug.cgi?id=4711

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Rafael Akchurin
Sent: Wednesday, May 3, 2017 10:48 AM
To: Flashdown ; Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Hello all,

The following steps give in Chrome 58 the "Your connection is not private" error with 
"NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error:

(peek-an-splice bumping squid 3.5.23_1 as in 
https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html)

1. Open Chrome 58+
2. Type some non existing domain name like "https://www.asdlajsdfl.com"; (note 
the httpS:// schema) 3. See the missing_subjectAltName error.

Correct behavior would be Squid generating faked certificate for the domain name 
"www.asdlajsdfl.com" *with* subjectAltName extension set to 
"www.asdlajsdfl.com".

So question is - does anyone know if this is already existing bug or shall I 
file one?
May be it is a feature?

Best regards,
Rafael


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Flashdown
Sent: Thursday, April 27, 2017 6:42 PM
To: Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

I've tested the registry setting and it worked out. You can copy the below 
lines in a .reg file and execute it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:0001


Best regards,
Flashdown

Am 2017-04-27 18:34, schrieb Flashdown:

Hello together,

here is a workaround that you could use in the meanwhile.

https://www.chromium.org/administrators/policy-list-3#EnableCommonName
FallbackForLocalAnchors

Source:
https://www.chromium.org/administrators/policy-list-3#EnableCommonName
FallbackForLocalAnchors

BEGIN

EnableCommonNameFallbackForLocalAnchors
Whether to allow certificates issued by local trust anchors that are
missing the subjectAlternativeName extension

Data type:
 Boolean [Windows:REG_DWORD]
Windows registry location:

Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor
s
Mac/Linux preference name:
 EnableCommonNameFallbackForLocalAnchors
Android restriction name:
 EnableCommonNameFallbackForLocalAnchors
Supported on:

 Google Chrome (Linux, Mac, Windows) since version 58 until
version 65
 Google Chrome OS (Google Chrome OS) since version 58 until
version 65
 Google Chrome (Android) since version 58 until version 65

Supported features:
 Dynamic Policy Refresh: Yes, Per Profile: No
Description:

 When this setting is enabled, Google Chrome will use the
commonName of a server certificate to match a hostname if the
certificate is missing a subjectAlternativeName extension, as long as
it successfully validates and chains to a locally-installed CA
certificates.

 Note that this is not recommended, as this may allow bypassing the
nameConstraints extension that restricts the hostnames that a given
certificate can be authorized for.

 If this policy is not set, or is set to false, server certificates
that lack a subjectAlternativeName extension containing either a DNS
name or IP address will not be trusted.
Example value:
 0x (Windows), false (Linux), false (Android), 
(Mac)
 END



Am 2017-04-27 18:16, schrieb Flashdown:

Hello together,

Suddenly I am facing the same issue when users Chrome has been
updated to V58. I am running Squid 3.5.23.

This is the reason:
https://www.thesslstore.com/blog/security-changes-in-chrome-58/
Short: Common Name Support Removed in Chrome 58 and Squid does not
create certs with DNS-Alternatives names in it. Because of that it
fails.

Chrome says:
1. Subject Alternative Name Missing - The certificate for this site
does not contain a Subject Alternative Name extension containing a
domain name or IP address.
2. Certificate Error - There are issues with the site's certificate
chain (net::ERR_CERT_COMMON_NAME_INVALID).

Can we get Squid to add the DNS-Alternative Name to the generated
certs? Since this is what I believe is now required in Chrome 58+

Best regards,
Enrico


Am 2017-04-21 15:35, schrieb Yuri Voinov:

I see no problem with it on all five SSL Bump-aware servers with new
Chrome. So fare so good.


21.04.2017 18:29, Marko Cupać пишет:

Hi,

I have squid setup with ssl bump which worked fine, but since I
updated chrome to 58 it won't display any https sites, throwing
NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work

Re: [squid-users] ssl bump and chrome 58

[Rafael Akchurin]

Sorry disregard - should practice my  google fu better - see 
http://bugs.squid-cache.org/show_bug.cgi?id=4711

-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Rafael Akchurin
Sent: Wednesday, May 3, 2017 10:48 AM
To: Flashdown ; Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Hello all,

The following steps give in Chrome 58 the "Your connection is not private" 
error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" 
error:

(peek-an-splice bumping squid 3.5.23_1 as in 
https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html)

1. Open Chrome 58+
2. Type some non existing domain name like "https://www.asdlajsdfl.com"; (note 
the httpS:// schema) 3. See the missing_subjectAltName error.

Correct behavior would be Squid generating faked certificate for the domain 
name "www.asdlajsdfl.com" *with* subjectAltName extension set to 
"www.asdlajsdfl.com".

So question is - does anyone know if this is already existing bug or shall I 
file one?
May be it is a feature?

Best regards,
Rafael


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Flashdown
Sent: Thursday, April 27, 2017 6:42 PM
To: Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

I've tested the registry setting and it worked out. You can copy the below 
lines in a .reg file and execute it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:0001


Best regards,
Flashdown

Am 2017-04-27 18:34, schrieb Flashdown:
> Hello together,
>
> here is a workaround that you could use in the meanwhile.
>
> https://www.chromium.org/administrators/policy-list-3#EnableCommonName
> FallbackForLocalAnchors
>
> Source:
> https://www.chromium.org/administrators/policy-list-3#EnableCommonName
> FallbackForLocalAnchors
>> BEGIN
> EnableCommonNameFallbackForLocalAnchors
> Whether to allow certificates issued by local trust anchors that are 
> missing the subjectAlternativeName extension
>
> Data type:
> Boolean [Windows:REG_DWORD]
> Windows registry location:
>
> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor
> s
> Mac/Linux preference name:
> EnableCommonNameFallbackForLocalAnchors
> Android restriction name:
> EnableCommonNameFallbackForLocalAnchors
> Supported on:
>
> Google Chrome (Linux, Mac, Windows) since version 58 until 
> version 65
> Google Chrome OS (Google Chrome OS) since version 58 until 
> version 65
> Google Chrome (Android) since version 58 until version 65
>
> Supported features:
> Dynamic Policy Refresh: Yes, Per Profile: No
> Description:
>
> When this setting is enabled, Google Chrome will use the 
> commonName of a server certificate to match a hostname if the 
> certificate is missing a subjectAlternativeName extension, as long as 
> it successfully validates and chains to a locally-installed CA 
> certificates.
>
> Note that this is not recommended, as this may allow bypassing the 
> nameConstraints extension that restricts the hostnames that a given 
> certificate can be authorized for.
>
> If this policy is not set, or is set to false, server certificates 
> that lack a subjectAlternativeName extension containing either a DNS 
> name or IP address will not be trusted.
> Example value:
> 0x (Windows), false (Linux), false (Android), 
> (Mac)
>  END
>
>
>
> Am 2017-04-27 18:16, schrieb Flashdown:
>> Hello together,
>>
>> Suddenly I am facing the same issue when users Chrome has been 
>> updated to V58. I am running Squid 3.5.23.
>>
>> This is the reason:
>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>> Short: Common Name Support Removed in Chrome 58 and Squid does not 
>> create certs with DNS-Alternatives names in it. Because of that it 
>> fails.
>>
>> Chrome says:
>> 1. Subject Alternative Name Missing - The certificate for this site 
>> does not contain a Subject Alternative Name extension containing a 
>> domain name or IP address.
>> 2. Certificate Error - There are issues with the site's certificate 
>> chain (net::ERR_CERT_COMMON_NAME_INVALID).
>>
>> Can we get Squid to add the DNS-Alternative Name to the generated 
>> certs? Since this is what I believe is now required in Chrome 58+
>>
>> Best regards,
>> Enrico
>>
>>
>> Am 2017-04-21 15:35, schrieb Yuri Voinov:
>>> I see no problem with it on all five SSL Bump-aware servers with new 
>>> Chrome. So fare so good.
>>>
>>>
>>> 21.04.2017 18:29, Marko Cupać пишет:
 Hi,

 I have squid setup with ssl bump which worked fine, but since I 
 updated chrome to 58 it won't displ

Re: [squid-users] ssl bump and chrome 58

[Rafael Akchurin]

Hello all,

The following steps give in Chrome 58 the "Your connection is not private" 
error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" 
error:

(peek-an-splice bumping squid 3.5.23_1 as in 
https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html)

1. Open Chrome 58+
2. Type some non existing domain name like "https://www.asdlajsdfl.com"; (note 
the httpS:// schema)
3. See the missing_subjectAltName error.

Correct behavior would be Squid generating faked certificate for the domain 
name "www.asdlajsdfl.com" *with* subjectAltName extension set to 
"www.asdlajsdfl.com".

So question is - does anyone know if this is already existing bug or shall I 
file one?
May be it is a feature?

Best regards,
Rafael


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Flashdown
Sent: Thursday, April 27, 2017 6:42 PM
To: Yuri Voinov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] ssl bump and chrome 58

I've tested the registry setting and it worked out. You can copy the below 
lines in a .reg file and execute it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:0001


Best regards,
Flashdown

Am 2017-04-27 18:34, schrieb Flashdown:
> Hello together,
> 
> here is a workaround that you could use in the meanwhile.
> 
> https://www.chromium.org/administrators/policy-list-3#EnableCommonName
> FallbackForLocalAnchors
> 
> Source:
> https://www.chromium.org/administrators/policy-list-3#EnableCommonName
> FallbackForLocalAnchors
>> BEGIN
> EnableCommonNameFallbackForLocalAnchors
> Whether to allow certificates issued by local trust anchors that are 
> missing the subjectAlternativeName extension
> 
> Data type:
> Boolean [Windows:REG_DWORD]
> Windows registry location:
> 
> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor
> s
> Mac/Linux preference name:
> EnableCommonNameFallbackForLocalAnchors
> Android restriction name:
> EnableCommonNameFallbackForLocalAnchors
> Supported on:
> 
> Google Chrome (Linux, Mac, Windows) since version 58 until 
> version 65
> Google Chrome OS (Google Chrome OS) since version 58 until 
> version 65
> Google Chrome (Android) since version 58 until version 65
> 
> Supported features:
> Dynamic Policy Refresh: Yes, Per Profile: No
> Description:
> 
> When this setting is enabled, Google Chrome will use the 
> commonName of a server certificate to match a hostname if the 
> certificate is missing a subjectAlternativeName extension, as long as 
> it successfully validates and chains to a locally-installed CA 
> certificates.
> 
> Note that this is not recommended, as this may allow bypassing the 
> nameConstraints extension that restricts the hostnames that a given 
> certificate can be authorized for.
> 
> If this policy is not set, or is set to false, server certificates 
> that lack a subjectAlternativeName extension containing either a DNS 
> name or IP address will not be trusted.
> Example value:
> 0x (Windows), false (Linux), false (Android), 
> (Mac)
>  END
> 
> 
> 
> Am 2017-04-27 18:16, schrieb Flashdown:
>> Hello together,
>> 
>> Suddenly I am facing the same issue when users Chrome has been 
>> updated to V58. I am running Squid 3.5.23.
>> 
>> This is the reason:
>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>> Short: Common Name Support Removed in Chrome 58 and Squid does not 
>> create certs with DNS-Alternatives names in it. Because of that it 
>> fails.
>> 
>> Chrome says:
>> 1. Subject Alternative Name Missing - The certificate for this site 
>> does not contain a Subject Alternative Name extension containing a 
>> domain name or IP address.
>> 2. Certificate Error - There are issues with the site's certificate 
>> chain (net::ERR_CERT_COMMON_NAME_INVALID).
>> 
>> Can we get Squid to add the DNS-Alternative Name to the generated 
>> certs? Since this is what I believe is now required in Chrome 58+
>> 
>> Best regards,
>> Enrico
>> 
>> 
>> Am 2017-04-21 15:35, schrieb Yuri Voinov:
>>> I see no problem with it on all five SSL Bump-aware servers with new 
>>> Chrome. So fare so good.
>>> 
>>> 
>>> 21.04.2017 18:29, Marko Cupać пишет:
 Hi,
 
 I have squid setup with ssl bump which worked fine, but since I 
 updated chrome to 58 it won't display any https sites, throwing 
 NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in 
 previous chrome version, as well as in IE.
 
 Anything I can do in squid config to get ssl-bumped sites in chrome 
 again?
 
 Thank you in advance,
>>> 
>>> ___
>>> squid-users mailing list
>>> squid-users@lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>> ___
>> squid-users