Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

On 5/20/20 6:02 AM, Matus UHLAR - fantomas wrote:
>> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
>>> David, note that requiring browsers to connect to your proxy over
>>> encrypted (https) connection, and then decrypting tunnels to real server 
>>> will
>>> lower the clients' security

> On 19.05.20 10:46, Alex Rousskov wrote:
>> A proper SslBump implementation for HTTPS proxy will not be "decrypting
>> tunnels to real server". The security of such an implementation will be
>> the same as of SslBump supported today (plus the additional protections
>> offered by securing the browser-proxy communication).

> If David wants to ssl-bump the traffic inside the HTTPS tunel, it means that 
> the
> communication between browser and server has to be decrypted on squid,
> squid will talk to server using HTTPS

You are right. Due to insufficient shared terminology, we are simply
talking about two different things:

* I am talking about Squid (in a bumping HTTPS proxy role) sending
bumped requests to plain servers, exposing previously encrypted traffic.
While that is technically possible to support (in some cases) and even
occasionally explicitly requested (in a peering environment), that
should _not_ happen if the existing SslBump support is added to the
existing HTTPS proxy mode.

* You are talking about Squid (in a bumping HTTPS proxy role) inspecting
TLS traffic that the client meant for to origin servers eyes only. That
will happen, of course. This is what SslBump is about.


> My point is that David wants to provide "secure" proxy which may compromise
> the security instead by bumping connections.

Right. And my point is that adding SslBump support to HTTPS proxy does
not make things _worse_ as far as "security" and "privacy" are
concerned. Compared to using SslBump in an HTTP proxy, adding SslBump
support to HTTPS proxy may make things better. How much better depends
on your threat model, of course.

No sane person would argue that bumping is a good solution. My point was
that if you have to bump, then using an HTTPS proxy is not going to make
things worse.

It would be better if popular browsers would send plain https://... URLs
to an HTTPS proxy they trust, but they refuse to support that "GET
https" mode.


Cheers,

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

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

On 5/20/20 3:51 AM, David Touzeau wrote:

> How to be a sponsor?

There are many ways, including these two:

1. You privately find a developer (a person or an organization) and pay
them for implementing the changes you need.

2. You post an RFQ to squid-dev and solicit quotes/bids from developers.

If substantial changes you sponsored are officially accepted, you can
request to be officially listed in SPONSORS. Needless to say, you can
pull resources with other co-sponsors.

For a complex feature like TLS-inside-TLS bumping, please make sure that

a) The required architectural changes are deemed acceptable to the Squid
Project before the development starts. Otherwise, you may end up with a
large piece of code that you would have to pay somebody to maintain
forever. Such preliminary acceptance can be secured via discussions on
squid-dev. Such discussions should be initiated by (the developer)
posting a Request For Comments outlining major anticipated changes.

b) The developer will support the changes throughout Squid Project
review and initial deployment. It is very likely that the initial
version of the "working" code will need to be adjusted (for many reasons).

The following FAQ may be useful in this context:
https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


> ( cost ) of such feature

That would be determined by the developer, subject to the usual business
negotiations (warranties, deadlines, backporting support, payment terms,
etc.). The most common pitfalls here are underestimating the complexity
of the changes, the overheads related to getting the changes officially
accepted, and medium-term support costs. FWIW, if I were to get a quote
that equates this project with a week worth of work, I would laugh at it.

Please note that the Squid Project itself does not do Squid development
and does not receive any money for Squid development. Some developers
contribute back to the Project (in various ways), but there is no
requirement to do so. This is typical for many open source projects, of
course.


> Could you think it can be planned for 5.x ?

IMO, no. The change is too big to qualify for any reasonable v5 freeze
exception. Squid v6 is your best bet right now. If the developer knows
what they are doing, there are ways to mitigate associated risks.


HTH,

Alex.


> Le 19/05/2020 à 16:46, Alex Rousskov a écrit :
 On 18/05/20 10:15 am, David Touzeau wrote:
> Hi we want to use squid as * * * Secure Proxy * * * using https_port
> We have tested major browsers and it seems working good.
>
> To make it work, we need to deploy the proxy certificate on all browsers
> to make the secure connection running.
>> I hope that deployment is not necessary -- an HTTPS proxy should be
>> using a certificate issued for its domain name and signed by a
>> well-known CA already trusted by browsers. An HTTPS proxy is not faking
>> anything. If browsers do require CA certificate import in this
>> environment, it is their limitation.
>>
>>
>> On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
>>> David, note that requiring browsers to connect to your proxy over encrypted
>>> (https) connection, and then decrypting tunnels to real server will lower
>>> the clients' security
>> A proper SslBump implementation for HTTPS proxy will not be "decrypting
>> tunnels to real server". The security of such an implementation will be
>> the same as of SslBump supported today (plus the additional protections
>> offered by securing the browser-proxy communication).
>>
>> Cheers,
>>
>> Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Matus UHLAR - fantomas]

On 18/05/20 10:15 am, David Touzeau wrote:

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers
to make the secure connection running.


On 19.05.20 10:46, Alex Rousskov wrote:

I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


That means, SSL connection from brower to the proxy will be encrypted and
signed by certificate installed on the proxy, which may be signed by public
authority, provided the proxy has public DNS name 
(public authorities only sign public domains)


the traffic inside of the SSL tunnel will be standard proxy communication -
GET, POST, CONNECT requests.

CONNECT requests will ask the proxy to build tunnel to destination server,
which will usually contain encrypted HTTPS communication between browser and
final server.  So, CONNECT will create HTTPS connection (browser-server)
inside of HTTPS connection (browser-proxy)


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:

David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security


A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).


If David wants to ssl-bump the traffic inside the HTTPS tunel (and I from
Davis's request I believe he wants to do that), it means that the
communication between browser and server has to be decrypted on squid, squid
will talk to server using HTTPS and create HTTPS endpoint to the client that
provides data, which means:

- squid will see the communication between browser and server
 (which is what HTTPS is designed to avoid)
- squid will need to dynamically creste certificated for sites it bumps
 using local CA
- clients will need to install the CA as trusted.

This is exactly what SSL Bump is about. 


My point is that David wants to provide "secure" proxy which may compromise
the security instead by bumping connections.

I am not objecting against doing it, but I want to note that whole point of
HTTPS (where the "S" means secure) is that noone in the middle sees what is
the content of communication between client and server.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
On the other hand, you have different fingers.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[David Touzeau]

Thanks for the answer details

How to be a sponsor ? ( cost ) of such feature
Could you think it can be planned for 5.x ?
I think it should be a "future" "standard" in the same way of DNS over SSL

Le 19/05/2020 à 16:46, Alex Rousskov a écrit :

On 18/05/20 10:15 am, David Touzeau wrote:

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers
to make the secure connection running.

I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:

David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security

A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).

Cheers,

Alex.
___
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] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

>> On 18/05/20 10:15 am, David Touzeau wrote:
>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>>> We have tested major browsers and it seems working good.
>>>
>>> To make it work, we need to deploy the proxy certificate on all browsers
>>> to make the secure connection running.

I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
> David, note that requiring browsers to connect to your proxy over encrypted
> (https) connection, and then decrypting tunnels to real server will lower
> the clients' security

A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).

Cheers,

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

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

On 5/19/20 7:15 AM, Amos Jeffries wrote:
> On 18/05/20 10:15 am, David Touzeau wrote:
>>   
>>
>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>> We have tested major browsers and it seems working good.
>>
>> To make it work, we need to deploy the proxy certificate on all browsers
>> to make the secure connection running.
>>
>> In this case, squid forward requests without decrypting them.because
>> ssl-bump is not added.
>>
>> But Adding the ssl-bump in https_port is not permitted :
>>
>> "sl-bump on https_port requires tproxy/intercept which is missing"
>>
>> why bumping is not allowed ?
>>
> 
> Because origin server and explicit proxy traffic are mutually exclusive
> syntax at the HTTP level, and use different types of SSL certificate at
> the TLS level.
> 
> A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
> traffic gets decrypted normally on receipt by the https_port, using a
> proxy server certificate.
> 
> SSL-Bump auto-generates a server certificate to decrypt with, and
> expects origin form HTTP syntax once decrypted.
> 
> 
> HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
> sent to a secure proxy. In which case there are two layers of encryption
> nested inside each other. Decrypting the interior layer of at is not yet
> supported by Squid.


David,

Just to avoid misunderstanding: The answer to your question is in
the last sentence of the last paragraph by Amos -- Squid lacks the code
that is necessary to do what you want. There are no fundamental reasons
it cannot be done. There have been a few requests for TLS-inside-TLS
support, but I am not aware of any actual sponsors or features on the
road map. It is a complicated project, even though each of its two
components already works today.


Cheers,

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

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Matus UHLAR - fantomas]

On 18/05/20 10:15 am, David Touzeau wrote:

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers
to make the secure connection running.

In this case, squid forward requests without decrypting them.because
ssl-bump is not added.

But Adding the ssl-bump in https_port is not permitted :

"sl-bump on https_port requires tproxy/intercept which is missing"

why bumping is not allowed ?


On 19.05.20 23:15, Amos Jeffries wrote:

Because origin server and explicit proxy traffic are mutually exclusive
syntax at the HTTP level, and use different types of SSL certificate at
the TLS level.

A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
traffic gets decrypted normally on receipt by the https_port, using a
proxy server certificate.

SSL-Bump auto-generates a server certificate to decrypt with, and
expects origin form HTTP syntax once decrypted.


David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security:
Clients will talk HTTPS to proxy, but proxy to server connection might be as
well unencrypted (or, decrypted by proxy).
This makes thinge like SSL authentication impossible.
I understand that you might scan connections for viruses or disabled
content, but the security will be harmed.


HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
sent to a secure proxy. In which case there are two layers of encryption
nested inside each other. Decrypting the interior layer of at is not yet
supported by Squid.


so, this is the real problem :-)


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Amos Jeffries]

On 18/05/20 10:15 am, David Touzeau wrote:
>   
> 
> Hi we want to use squid as * * * Secure Proxy * * * using https_port
> We have tested major browsers and it seems working good.
> 
> To make it work, we need to deploy the proxy certificate on all browsers
> to make the secure connection running.
> 
> In this case, squid forward requests without decrypting them.because
> ssl-bump is not added.
> 
> But Adding the ssl-bump in https_port is not permitted :
> 
> "sl-bump on https_port requires tproxy/intercept which is missing"
> 
> why bumping is not allowed ?
> 

Because origin server and explicit proxy traffic are mutually exclusive
syntax at the HTTP level, and use different types of SSL certificate at
the TLS level.

A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
traffic gets decrypted normally on receipt by the https_port, using a
proxy server certificate.

SSL-Bump auto-generates a server certificate to decrypt with, and
expects origin form HTTP syntax once decrypted.


HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
sent to a secure proxy. In which case there are two layers of encryption
nested inside each other. Decrypting the interior layer of at is not yet
supported by Squid.


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

[squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[David Touzeau]

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers 
to make the secure connection running.


In this case, squid forward requests without decrypting them.because 
ssl-bump is not added.


But Adding the ssl-bump in https_port is not permitted :

"sl-bump on https_port requires tproxy/intercept which is missing"

why bumping is not allowed ?

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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

Right. that works now.

thanks.
- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 12/12/19 11:38 am, GeorgeShen wrote:
> 
> did a 'openssl dhparam -out dhparams.pem 4096' to generate the dhparams.pem
> file, and added those into the squid.conf:
> 
> http_port 3129 ssl-bump cert=/usr/local/squid/etc/ssl_cert/myCA.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> *options=SINGLE_DH_USE:SINGLE_ECDH_USE
> tls-dh=/usr/local/squid/etc/dhparams.pem*
> 
> when the client software include the ciphersuites of the above mentioned,
> still fail the TLS negotiation. Do I configured this incorrectly?

What you have so far enables the DH ciphers and algorithms, but not yet
the curve parts. For that you need to add the curve name to tls-dh option.



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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

did a 'openssl dhparam -out dhparams.pem 4096' to generate the dhparams.pem
file, and added those into the squid.conf:

http_port 3129 ssl-bump cert=/usr/local/squid/etc/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
*options=SINGLE_DH_USE:SINGLE_ECDH_USE
tls-dh=/usr/local/squid/etc/dhparams.pem*

when the client software include the ciphersuites of the above mentioned,
still fail the TLS negotiation. Do I configured this incorrectly?

thanks.
- George




--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 11/12/19 4:00 pm, GeorgeShen wrote:
> I'm running the squid latest from download site. 4.9
> Ok, i suspect that was related to my ^C running the process in foreground,
> but I also see before that there are warning messages in the log:
> 2019/12/09 19:23:12.116 kid1| WARNING:
> /usr/local/squid/libexec/security_file_certgen -s
> /usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr5 exited
> 2019/12/09 19:23:12.118 kid1| WARNING:
> /usr/local/squid/libexec/security_file_certgen -s
> /usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr1 exited
> 2019/12/09 19:23:12.123 kid1| WARNING:
> /usr/local/squid/libexec/security_file_certgen -s
> /usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr3 exited
> 
> it could be related also to my ^C, but not sure.
> 
> the other program, I have found it is related to my golang program set the
> ciphersuite to some more secured cipher algorithm:
> tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, and
> tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. After removed those cipher
> restrictions, the ssl-bump does work.

That implies that your proxy is configured in such a way that these
ciphers are not usable - and/or that the origin servers being contacted
cannot handle them.

You may want to fix that for at least Squid. To do so set the tls-dh=
option with a preference EC curve name and DHE parameters file.


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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

I'm running the squid latest from download site. 4.9
Ok, i suspect that was related to my ^C running the process in foreground,
but I also see before that there are warning messages in the log:
2019/12/09 19:23:12.116 kid1| WARNING:
/usr/local/squid/libexec/security_file_certgen -s
/usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr5 exited
2019/12/09 19:23:12.118 kid1| WARNING:
/usr/local/squid/libexec/security_file_certgen -s
/usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr1 exited
2019/12/09 19:23:12.123 kid1| WARNING:
/usr/local/squid/libexec/security_file_certgen -s
/usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr3 exited

it could be related also to my ^C, but not sure.

the other program, I have found it is related to my golang program set the
ciphersuite to some more secured cipher algorithm:
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, and
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. After removed those cipher
restrictions, the ssl-bump does work.

thanks.
- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Alex Rousskov]

On 12/9/19 12:56 PM, GeorgeShen wrote:

> and at the end, it is also saying security_file_certgen crashes rapidly!!!

I would ignore anything that happens _after_ you press ^C (i.e. send
Squid a shutdown signal). While a shutdown should not "crash" any
helpers, that is not the problem you are currently trying to solve.

As for your primary problem, I see nothing interesting in the provided
logs (which does not necessarily mean there is nothing there). As Amos
has said, when dealing with SslBump problems, please make sure you are
running Squid v4.9 (or even master).


> ^C2019/12/09 09:39:33.337| 1,2| main.cc(1788) masterShutdownStart: received
> shutdown command

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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 10/12/19 6:46 pm, GeorgeShen wrote:
> 
> I'm wondering if this issue reported last year is fixed:
> http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-4-security-file-certgen-helpers-crashing-td4687098.html
> 

That question implies that you are not using the latest Squid release,
or you already have the answer. When using SSL-Bump features (cert
generation being one) it is best to follow the updates.


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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

I'm wondering if this issue reported last year is fixed:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-4-4-security-file-certgen-helpers-crashing-td4687098.html

or is there a work around.
thanks.

- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

Hi Alex,

this time I tried, a little different, this is the log from got the server
certs to colose the
SSL with error, and at the end, it is also saying security_file_certgen
crashes rapidly!!!

below the output of log
thanks.
- George


geyBC5spVGniTZ9g4/4EALHmrmP0d4vcbw0FJugljU7jWmdiUQEpoZZCovZY+lyX
IGRmShEZ6Enq77nr6xgMpW080lJojSBBE0bG7tJj8sUeU03xVyHJZJ4cNX7VD/Dn
g0KNg0PA4UvJLMoKal8UqHzxNXjZZ778O7mOOyvdHfkHgUsFdp9a25/nzduUFQ4R
8faCm0U26P8C
-END CERTIFICATE-

2019/12/09 09:39:32.243 kid1| 83,5| helper.cc(136) Submit: request from
0x256a4a8 as crtGenRq12500/1
2019/12/09 09:39:32.243 kid1| 84,5| helper.cc(1247) GetFirstAvailable:
GetFirstAvailable: Running servers 5
2019/12/09 09:39:32.243 kid1| 5,5| AsyncCall.cc(26) AsyncCall: The AsyncCall
helperDispatchWriteDone constructed, this=0x2557fe0 [call2906]
2019/12/09 09:39:32.243 kid1| 5,5| Write.cc(35) Write: local=[::]
remote=[::] FD 10 flags=1: sz 5266: asynCall 0x2557fe0*1
2019/12/09 09:39:32.243 kid1| 5,5| ModEpoll.cc(117) SetSelect: FD 10,
type=2, handler=1, client_data=0x2091e30, timeout=0
2019/12/09 09:39:32.243 kid1| 84,5| helper.cc(1379) helperDispatch:
helperDispatch: Request sent to
/usr/local/squid/libexec/security_file_certgen -s
/usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr1, 5266 bytes
2019/12/09 09:39:32.243 kid1| 17,4| AsyncJob.cc(154) callEnd: Http1::Server
status out: [ job203]
2019/12/09 09:39:32.243 kid1| 17,4| AsyncCallQueue.cc(57) fireNext: leaving
ConnStateData::ConnStateData::httpsPeeked(local=192.168.1.35:46896
remote=X.Y.82.162:443 FD 15 flags=1, request=0x20fb630*3)
2019/12/09 09:39:32.243 kid1| 93,5| AsyncCallQueue.cc(55) fireNext: entering
Initiate::noteInitiatorAborted()
2019/12/09 09:39:32.243 kid1| 93,5| AsyncCall.cc(38) make: make call
Initiate::noteInitiatorAborted [call2905]
2019/12/09 09:39:32.243 kid1| 93,5| AsyncCall.cc(56) cancel: will not call
Initiate::noteInitiatorAborted [call2905] because job gone
2019/12/09 09:39:32.243 kid1| 93,5| AsyncCall.cc(48) make: will not call
Initiate::noteInitiatorAborted [call2905] because of job gone
2019/12/09 09:39:32.243 kid1| 93,5| AsyncCallQueue.cc(57) fireNext: leaving
Initiate::noteInitiatorAborted()
2019/12/09 09:39:32.243 kid1| 50,3| ModDaemon.cc(110) logfileHandleWrite:
daemon:/usr/local/squid/var/logs/access.log: write returned 106
2019/12/09 09:39:32.243 kid1| 5,5| Write.cc(66) HandleWrite: local=[::]
remote=[::] FD 10 flags=1: off 0, sz 5266.
2019/12/09 09:39:32.243 kid1| 5,5| Write.cc(108) HandleWrite: write()
returns 5266
2019/12/09 09:39:32.243 kid1| 5,3| IoCallback.cc(116) finish: called for
local=[::] remote=[::] FD 10 flags=1 (0, 0)
2019/12/09 09:39:32.243 kid1| 5,5| AsyncCall.cc(93) ScheduleCall:
IoCallback.cc(135) will call helperDispatchWriteDone(local=[::] remote=[::]
FD 10 flags=1, data=0x20b4b18, size=5266, buf=0x20ea960) [call2906]
2019/12/09 09:39:32.243 kid1| 5,5| AsyncCallQueue.cc(55) fireNext: entering
helperDispatchWriteDone(local=[::] remote=[::] FD 10 flags=1,
data=0x20b4b18, size=5266, buf=0x20ea960)
2019/12/09 09:39:32.243 kid1| 5,5| AsyncCall.cc(38) make: make call
helperDispatchWriteDone [call2906]
2019/12/09 09:39:32.243 kid1| 5,5| AsyncCallQueue.cc(57) fireNext: leaving
helperDispatchWriteDone(local=[::] remote=[::] FD 10 flags=1,
data=0x20b4b18, size=5266, buf=0x20ea960)
2019/12/09 09:39:32.243 kid1| 5,5| ModEpoll.cc(117) SetSelect: FD 20,
type=2, handler=0, client_data=0, timeout=0
2019/12/09 09:39:32.243 kid1| 5,5| ModEpoll.cc(117) SetSelect: FD 10,
type=2, handler=0, client_data=0, timeout=0
2019/12/09 09:39:32.244 kid1| 5,3| Read.cc(145) HandleRead: FD 10, size
32767, retval 3401, errno 0
2019/12/09 09:39:32.244 kid1| 5,3| IoCallback.cc(116) finish: called for
local=[::] remote=[::] FD 10 flags=1 (0, 0)
2019/12/09 09:39:32.244 kid1| 5,4| AsyncCall.cc(93) ScheduleCall:
IoCallback.cc(135) will call helperHandleRead(local=[::] remote=[::] FD 10
flags=1, data=0x20b4b18, size=3401, buf=0x20b4d40) [call2841]
2019/12/09 09:39:32.244 kid1| 5,4| AsyncCallQueue.cc(55) fireNext: entering
helperHandleRead(local=[::] remote=[::] FD 10 flags=1, data=0x20b4b18,
size=3401, buf=0x20b4d40)
2019/12/09 09:39:32.244 kid1| 5,4| AsyncCall.cc(38) make: make call
helperHandleRead [call2841]
2019/12/09 09:39:32.244 kid1| 84,5| helper.cc(963) helperHandleRead:
helperHandleRead: 3401 bytes from
/usr/local/squid/libexec/security_file_certgen -s
/usr/local/squid/var/logs/ssl_db -M 4MB #Hlpr1
2019/12/09 09:39:32.244 kid1| 84,3| helper.cc(991) helperHandleRead:
helperHandleRead: end of reply found
2019/12/09 09:39:32.244 kid1| 84,3| Reply.cc(41) finalize: Parsing helper
buffer
2019/12/09 09:39:32.244 kid1| 84,3| Reply.cc(59) finalize: Buff length is
larger than 2
2019/12/09 09:39:32.244 kid1| 84,3| Reply.cc(63) finalize: helper Result =
OK
2019/12/09 09:39:32.244 kid1| 83,5| helper.cc(158) HandleGeneratorReply: to
0x256a4a8 in crtGenRq12500/1
2019/12/09 09:39:32.244 kid1| 33,5| client_side.cc(2870) sslCrtdHandleReply:
Certificate for X.Y.82.162 was successfully 

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Alex Rousskov]

On 12/8/19 1:53 AM, George Sheng wrote:

> From the debug I can also see the proxy  connects towards the remote
> server, and proxy has negotiated fine with the server. the proxy
> receives 3 certificates from the server,
> and verification was fine to the server. But when the proxy trying to
> proceed with client negotiation, I got this error:

> 2019/12/07 20:48:59.761 kid1| 83,5| Session.cc(362)
> get_session_cb: Failed to retrieve SSL_SESSION from cache

As Amos has said, this failure to find a cached session is not an error
in itself. It is a cache miss. Look for problems after this log line.


> The alpine linux, using the wget https, got error message ssl_client:
> handshake failed: error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3
> alert handshake failure 

OK.


> (on the proxy log, it is the same thing, can not
> somehow retrieve the ssl session, probably due to some TLS mismatch)

What happens on Squid side _after_ the TLS session is not found in the
cache?

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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 9/12/19 10:41 am, GeorgeShen wrote:
> Hi Amos,
> 
> i downloaded the 4.9 latest, and compiled with "./configure
> --with-default-user=proxy --with-openssl --enable-ssl-crtd", not redo the
> openssl and proxy certificate part, start squid with 4.9, still seeing
> failure. Have not debugged in detail. 
> Quick question, when compile for the bump usage case, do i need to use the
> with-gnutls option also?

No, GnuTLS is just an alternative to OpenSSL for those where the OpenSSL
license vs GPL incompatibility matters (anyone distributing both OPenSSL
and Squid packages - eg Ubuntu itself).

It still lacks most of the the SSL-Bump features. So eventually you
might be able to choose between them, but right now OpenSSL is needed to
do interception of HTTPS.

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

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

the version 4.9 has the same behavior, can not finish negotiate with the
client.
I have setup two different client machines, one is macOS, the other alpine
linux.

I finally got the macOS wget https to work through the squid 4.9 proxy with
ssl-bump.
So the squid config is ok.

The alpine linux, using the wget https, got error message ssl_client:
handshake failed: error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3
alert handshake failure (on the proxy log, it is the same thing, can not
somehow retrieve the ssl session, probably due to some TLS mismatch)

I'm wondering if you know normally what kind of mismatch this is between the
client and proxy.
if i'm using wget https for testing, what kind of parameters I need to
change to match them.

thanks.
- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

Hi Amos,

i downloaded the 4.9 latest, and compiled with "./configure
--with-default-user=proxy --with-openssl --enable-ssl-crtd", not redo the
openssl and proxy certificate part, start squid with 4.9, still seeing
failure. Have not debugged in detail. 
Quick question, when compile for the bump usage case, do i need to use the
with-gnutls option also?
just wondering.

thanks.
- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[GeorgeShen]

Hi Amos,

thanks for the comments. I'll first try the later version as you pointed out
4.9 and see if I get the issues. Will report back.
thanks.

- George



--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[Amos Jeffries]

On 8/12/19 7:53 pm, George Sheng wrote:
> 
> Hi,
> 
> I’m new to this group. I just setup a squid ver 4.5 on my ubuntu

When using SSL-Bump one does need to use the latest release. Which is
4.9 now.

Since this is a custom build (4.5 has never been a release in Ubuntu)
you may find Squid-5 has even less issues for SSL-Bump.



...
> 2019/12/07 20:48:59.761 kid1| 83,5| Session.cc (347)
> get_session_cb: Request to search for SSL_SESSION of
> len: 321019023443:419801955
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc (156)
> openForReading: trying to open slot for
> key 5310BD3C63AB0519C4F984A35A8DC1AE for reading in map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc (177)
> openForReadingAt: trying to open slot at 18 for reading in
> map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc (169)
> openForReading: failed to open slot for
> key 5310BD3C63AB0519C4F984A35A8DC1AE for reading in map [tls_session_cache]
> 2019/12/07 20:48:59.761 kid1| 83,5| Session.cc (362)
> get_session_cb: Failed to retrieve SSL_SESSION from cache
> ***

This is talking about Squid's internal cache of TLS sessions that
clients have negotiated previously with this Squid. It means the client
is attempting to use/resume a TLS session ID that does not exist. There
is nothing anyone can do about that.


> 
> Here is my squid.conf:
> 
...
> https_port 3130 intercept ssl-bump
> cert=/usr/local/squid/etc/ssl_cert/myCA.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> key=/usr/local/
> squid/etc/ssl_cert/myCA.pem
> 

FYI: with cert= and key= pointing at the same file you do not need the
key= option.


> ##
> 
> I’m wondering if this problem is a bug, my proxy config issue, or the
> client does not send the correct TLS parameters.
> thanks for your help in advance.
> 

The problem is most likely the client.

If the session ID actually was negotiated previously with this Squid
there may be shared-memory issues on your machine. Even with only one
worker this cache uses SMP functionality

If you only just started this Squid, the session may have been
negotiated with the origin or previous Squid instance. In that case it
is normal to get at least a few of these until they timeout and/or get
renegotiated.


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

[squid-users] Squid Proxy SSL Bump can not retrieve SSL session back to the client?

[George Sheng]

Hi,

I’m new to this group. I just setup a squid ver 4.5 on my ubuntu machine. I 
configured this proxy to receive
https packets from another device on the same LAN, and modified the iptables to 
redirect the port 443 packets
to the squid proxy port 3130.

I can see the client https packet has been received and the proxy is ready to 
do the ‘bump’, the fd to the client
connection is 13:

**
2019/12/07 20:48:59.586 kid1| 85,4| 
client_side_request.cc(1510) processRequest: 
CONNECT x.y.43.31:443
2019/12/07 20:48:59.586 kid1| 85,5| 
client_side_request.cc(1597) sslBumpStart: 
Confirming peek-bumped CONNECT tunnel on FD local=x.y..31:443 
remote=192.168.1.25:39273 FD 13 flags=33
**


From the debug I can also see the proxy  connects towards the remote
server, and proxy has negotiated fine with the server. the proxy receives 3 
certificates from the server,
and verification was fine to the server. But when the proxy trying to proceed 
with client negotiation, I got this error:

***
2019/12/07 20:48:59.760 kid1| 33,5| client_side.cc(2859) 
sslCrtdHandleReply: Certificate for x.y.43.31 was successfully recieved from 
ssl_crtd
2019/12/07 20:48:59.760 kid1| 33,5| client_side.cc(3335) 
doPeekAndSpliceStep: PeekAndSplice mode, proceed with client negotiation. 
Currrent state:SSLv2/v3 read client hello A
2019/12/07 20:48:59.760 kid1| 5,5| ModEpoll.cc(117) 
SetSelect: FD 13, type=2, handler=1, client_data=0x15beef8, timeout=0
2019/12/07 20:48:59.760 kid1| 84,5| helper.cc(1247) 
GetFirstAvailable: GetFirstAvailable: Running servers 5
2019/12/07 20:48:59.760 kid1| 5,4| AsyncCall.cc(26) 
AsyncCall: The AsyncCall helperHandleRead constructed, this=0x1a37c50 [call827]
2019/12/07 20:48:59.760 kid1| 5,5| Read.cc(57) comm_read_base: 
comm_read, queueing read for local=[::] remote=[::] FD 10 flags=1; asynCall 
0x1a37c50*1
2019/12/07 20:48:59.760 kid1| 5,5| ModEpoll.cc(117) 
SetSelect: FD 10, type=1, handler=1, client_data=0x155cce8, timeout=0
2019/12/07 20:48:59.760 kid1| 5,4| 
AsyncCallQueue.cc(57) fireNext: leaving 
helperHandleRead(local=[::] remote=[::] FD 10 flags=1, data=0x157f9a8, 
size=3384, buf=0x157fbd0)
2019/12/07 20:48:59.760 kid1| 83,5| bio.cc(612) squid_bio_ctrl: 
0x1a5e140 6(0, 0x1a76c00)
2019/12/07 20:48:59.761 kid1| 83,5| Session.cc(347) 
get_session_cb: Request to search for SSL_SESSION of len: 321019023443:419801955
2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc(156) 
openForReading: trying to open slot for key 5310BD3C63AB0519C4F984A35A8DC1AE 
for reading in map [tls_session_cache]
2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc(177) 
openForReadingAt: trying to open slot at 18 for reading in map 
[tls_session_cache]
2019/12/07 20:48:59.761 kid1| 54,5| MemMap.cc(169) 
openForReading: failed to open slot for key 5310BD3C63AB0519C4F984A35A8DC1AE 
for reading in map [tls_session_cache]
2019/12/07 20:48:59.761 kid1| 83,5| Session.cc(362) 
get_session_cb: Failed to retrieve SSL_SESSION from cache
***

Here is my squid.conf:

#
acl localnet src 192.168.1.0/24
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1
ssl_bump stare step2
ssl_bump bump all

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 3128
http_port 3129 intercept
https_port 3130 intercept ssl-bump cert=/usr/local/squid/etc/ssl_cert/myCA.pem 
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB key=/usr/local/
squid/etc/ssl_cert/myCA.pem

sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s 
/usr/local/squid/var/logs/ssl_db -M 4MB
coredump_dir /usr/local/squid/var/cache/squid
cache_dir ufs /usr/local/squid/var/cache/squid 1000 16 256 # 1GB as Cache

##

I’m wondering if this problem is a bug, my proxy config issue, or the client 
does not send the correct TLS parameters.
thanks for your help in advance.

Cheers,
- George

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

Re: [squid-users] Squid 4.6 "SSL routines:tls_parse_stoc_sct:bad extension"

[Amos Jeffries]

On 16/04/19 10:34 pm, Christian Schnatz wrote:
> Hi Everyone,
> 
> we’ve just updated one of our machines to squid 4.6 with openssl 1.1.1 and 
> ran in some strange errors when accessing *.google.com and apple app/itunes 
> store domains. 
> Has anyone else encountered the follow errors and nows how to solve them? 
> Right now clients are unable to browse the apple app store and do get a squid 
> error page when accessing google.com.
> 
> Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 202: 
> error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback 
> (1/-1/0)

A 5min web search can be useful.

 




> Apr 16 12:17:05 squid[2201]: 1555409825.478327 172.20.233.28 NONE/200 0 
> CONNECT 104.31.75.217:443 - ORIGINAL_DST/104.31.75.217 -
> 
> Apr 16 12:17:05 squid[2203]: 1555409825.184  10099 172.20.228.187 
> NONE_ABORTED/200 0 CONNECT 213.180.141.156:443 - HIER_NONE/- -
> Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 873: 
> error:1423406E:SSL routines:tls_parse_stoc_sct:bad extension (1/-1/0)


Your OpenSSL library does not understand the TLS extension being
received from one endpoint. The client or server, depending on which
step the SSL-Bump process is up to and what your ssl_bump rules say to do.

It is possible that your OpenSSL installation is corrupted, that the
endpoint is using some mandatory avoid TLS/SSL extension that is no
longer supported, that the endpoint is not sending TLS/SSL at all, or a
number of other similar things.


> 
> We are running squid with the following config:
> 
> sslproxy_cert_error allow all
> https_port 3129 ssl-bump intercept connection-auth=off 
> tls-cert=/etc/squid/myCA.pem generate-host-certificates=on 
> dynamic_cert_mem_cache_size=12MB options=ALL
> tls_outgoing_options options=ALL

The above options enables (or disables) a lot of OpenSL features which
are set with default on/off for very good reasons. Usually because they
cause bad problems if used on general TLS traffic. Things like 0-bit
security keys, nul-ciphers, IE 3 compatibility ciphers, SSLv2 and so on.

If used at all the "ALL" shoudl be followed by a long list of things to
turn off again. Or prefixed with a '!' to disable everything, followed
by a long list of things to turn on. Just by itself is a bad idea.


> tls_outgoing_options flags=DONT_VERIFY_PEER

This is another even worse idea. It is hiding TLS problems from you.
Serious ones with the security keys and certs.


> tls_outgoing_options default-ca=off
> tls_outgoing_options min-version=1.0

TLS has no version older than 1.0. So the above line is pointless.

> 
> follow_x_forwarded_for allow all
> logfile_rotate 2
> access_log syslog:LOG_LOCAL0:EMERGENCY squid
> max_filedescriptors 65535
> 
> http_port 3131
> acl localnet src 10.0.0.0/8   # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12# RFC1918 possible internal network
> acl localnet src 192.168.0.0/16   # RFC1918 possible internal network
> 
> acl SSL_ports port 443
> acl Safe_ports port 80# http
> acl Safe_ports port 21# ftp
> acl Safe_ports port 443   # https
> acl Safe_ports port 70# gopher
> acl Safe_ports port 210   # wais
> acl Safe_ports port 1025-65535# unregistered ports
> acl Safe_ports port 280   # http-mgmt
> acl Safe_ports port 488   # gss-http
> acl Safe_ports port 591   # filemaker
> acl Safe_ports port 777   # multiling http
> acl CONNECT method CONNECT
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> http_access allow localnet
> http_access allow localhost
> http_access deny all
> http_port 3128 transparent

"transparent" is a long ago deprecated option. It was replaced by
"intercept" to avoid confusion with transparent proxy options that do
*actual* transparency.


> #debug_options ALL,9
> coredump_dir /var/spool/squid
> url_rewrite_program /usr/bin/cf_plugin
> url_rewrite_extras "%ssl::>sni %>a %et"
> 
> refresh_pattern ^ftp: 144020% 10080
> refresh_pattern ^gopher:  14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0   0%  0
> refresh_pattern (Release|Packages(.gz)*)$  0   20% 2880
> refresh_pattern . 0   20% 4320
> 
> cache deny all
> cache_log /dev/null

Another bad idea. This can lead to /dev/null being moved to /dev/null.0
and a file put at /dev/null . Imagine the machine disks over-filling
with infinite amounts of crap from every application and script ever
running.
 Use "debug_options ALL,0" to minimize cache.log output.


> logfile_rotate 0
> 
> sslproxy_session_cache_size 0 MB
> 
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> 
> external_acl_type bump_check 

[squid-users] Squid 4.6 "SSL routines:tls_parse_stoc_sct:bad extension"

[Christian Schnatz]

Hi Everyone,

we’ve just updated one of our machines to squid 4.6 with openssl 1.1.1 and ran 
in some strange errors when accessing *.google.com and apple app/itunes store 
domains. 
Has anyone else encountered the follow errors and nows how to solve them? Right 
now clients are unable to browse the apple app store and do get a squid error 
page when accessing google.com.

Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 202: 
error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback 
(1/-1/0)
Apr 16 12:17:05 squid[2201]: 1555409825.478327 172.20.233.28 NONE/200 0 
CONNECT 104.31.75.217:443 - ORIGINAL_DST/104.31.75.217 -

Apr 16 12:17:05 squid[2203]: 1555409825.184  10099 172.20.228.187 
NONE_ABORTED/200 0 CONNECT 213.180.141.156:443 - HIER_NONE/- -
Apr 16 12:17:05 squid[2201]: ERROR: negotiating TLS on FD 873: 
error:1423406E:SSL routines:tls_parse_stoc_sct:bad extension (1/-1/0)


We are running squid with the following config:

sslproxy_cert_error allow all
https_port 3129 ssl-bump intercept connection-auth=off 
tls-cert=/etc/squid/myCA.pem generate-host-certificates=on 
dynamic_cert_mem_cache_size=12MB options=ALL
tls_outgoing_options options=ALL
tls_outgoing_options flags=DONT_VERIFY_PEER
tls_outgoing_options default-ca=off
tls_outgoing_options min-version=1.0

follow_x_forwarded_for allow all
logfile_rotate 2
access_log syslog:LOG_LOCAL0:EMERGENCY squid
max_filedescriptors 65535

http_port 3131
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 3128 transparent
#debug_options ALL,9
coredump_dir /var/spool/squid
url_rewrite_program /usr/bin/cf_plugin
url_rewrite_extras "%ssl::>sni %>a %et"

refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern (Release|Packages(.gz)*)$  0   20% 2880
refresh_pattern .   0   20% 4320

cache deny all
cache_log /dev/null
logfile_rotate 0

sslproxy_session_cache_size 0 MB

acl ssl_step1 at_step SslBump1
acl ssl_step2 at_step SslBump2
acl ssl_step3 at_step SslBump3

external_acl_type bump_check children-max=10 %URI %ssl::>sni %>a %et 
/usr/bin/cf_plugin -b
acl cf_allows external bump_check

ssl_bump peek ssl_step1 all
always_direct allow all
ssl_bump peek ssl_step2 cf_allows
ssl_bump bump ssl_step3 all
ssl_bump stare ssl_step2 !cf_allows
ssl_bump splice ssl_step3 cf_allows
ssl_bump bump ssl_step3 !cf_allows

on_unsupported_protocol tunnel all
url_rewrite_children 10
shutdown_lifetime 5 seconds
memory_pools off
cache_mem 2 MB
workers 5
ipcache_size 10240
fqdncache_size 10240
httpd_suppress_version_string on


Our main usage is to extract the SNI or IP from the SSL Request, forward it to 
cf_plugin and do some magic to decide wether this request should be blocked or 
not.

Squid has been build with the follow options:

Squid Cache: Version 4.6
Service Name: squid
Ubuntu linux

This binary uses OpenSSL 1.1.1b  26 Feb 2019. For legal restrictions on 
distribution see https://www.openssl.org/source/license.html

configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--libexecdir=${prefix}/lib/squid' '--srcdir=.' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--disable-silent-rules' 'BUILDCXXFLAGS=-g -O2 
-fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed' '--enable-build-info=Ubuntu linux' 
'--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' 
'--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man' '--enable-inline' 
'--disable-arch-native' '--enable-async-io=8' 
'--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' 
'--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' 
'--enable-follow-x-forwarded-for' 
'--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' 
'--enable-auth-digest=file,LDAP' 

Re: [squid-users] squid 4.5 , ssl bump and c-icap on google sites

[Dmitry Melekhov]

Hello!

Problem  was on c-icap side, my build had no br support.

Thank you!

10.01.2019 14:44, Dmitry Melekhov пишет:


Hello!


We are testing ssl-bump with squid 4.5.

Also we run c-icap with squid.


What is strange here -  ssl-bump works for google domains if icap is 
disabled,


but if it is on, then we get an error from c-icap:


You tried to upload/download a file that contains the virus: 
*uncompress: Uncompression Failure *

The Http location is: *https://www.youtube.com/
*

*
*

Although it works on most other sites.


Could you tell me why it does not work and is it possible to fix it?


Thank you!



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

Re: [squid-users] squid 4.5 , ssl bump and c-icap on google sites

[Amos Jeffries]

On 10/01/19 11:44 pm, Dmitry Melekhov wrote:
> Hello!
> 
> 
> We are testing ssl-bump with squid 4.5.
> 

With what settings?

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

[squid-users] squid 4.5 , ssl bump and c-icap on google sites

[Dmitry Melekhov]

Hello!


We are testing ssl-bump with squid 4.5.

Also we run c-icap with squid.


What is strange here -  ssl-bump works for google domains if icap is 
disabled,


but if it is on, then we get an error from c-icap:


You tried to upload/download a file that contains the virus: 
*uncompress: Uncompression Failure *

The Http location is: *https://www.youtube.com/
*

*
*

Although it works on most other sites.


Could you tell me why it does not work and is it possible to fix it?


Thank you!

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

Re: [squid-users] Squid 4.4 + SSL bump: Squid is crashing completely opening https://www.drcleaner.com/de/dr-cleaner/

[info]

> Hi,
> 
> Works “well” on my squid v 4.4 (patched) “ debian 9.
> 
> Although the site does not load well, squid does not die:
> 
> (…)
> 
> TCP_MISS/502 1609 GET 
> https://cache.drcleaner.com/extend/home/js/jquery-2.0.0.min.js -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/403 684 GET
> https://s3-us-west-2.amazonaws.com/trustedsite-public/host/drcleaner.com/client.js
>  -
> ORIGINAL_DST/52.218.200.72 application/xml
> 
> TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/css/index.css -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET 
> https://cache.drcleaner.com/extend/home/css/bootstrap.min.css -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET 
> https://cache.drcleaner.com/extend/home/js/jquery-2.0.0.min.js -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET 
> https://cache.drcleaner.com/extend/home/js/jquery.screw.js -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/js/bg_pro.js -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/js/mobile.js -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET
> https://cache.drcleaner.com/wp-content/plugins/contact-form-7/includes/js/scripts.js?
>  -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> TCP_MISS/502 1609 GET 
> https://cache.drcleaner.com/wp-includes/js/comment-reply.min.js? -
> ORIGINAL_DST/99.84.27.102 text/html
> 
> And over..
> 
> Please, see https://bugs.squid-cache.org/show_bug.cgi?id=4896
> 
> If your case is similar, there is a patch as a workaround.
> 
> HTH
> 

Your Squid 4.4 is patched with 
https://bugs.squid-cache.org/show_bug.cgi?id=4896 > 
SQUID-385-Comm_MonitorsRead-assertion-t3.patch ?
It seems exactly the issue I experienced.

I did recompile a testenvironment Squid with that patch, now the mentioned site 
is not killing my Squid anymore with SSL bump enabled. I am going to rollout 
the patched version this evening for our 20+ testusers on a pre-prod proxy. If 
there is any further issue, I'll comment the bugreport directly.

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

Re: [squid-users] Squid 4.4 + SSL bump: Squid is crashing completely opening https://www.drcleaner.com/de/dr-cleaner/

[ziprasidone146939277]

Hi,

 

Works “well” on my squid v 4.4 (patched) “ debian 9.

 

Although the site does not load well, squid does not die:

 

(…)

 

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/extend/home/js/jquery-2.0.0.min.js - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/403 684 GET 
https://s3-us-west-2.amazonaws.com/trustedsite-public/host/drcleaner.com/client.js
 - ORIGINAL_DST/52.218.200.72 application/xml

TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/css/index.css - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/extend/home/css/bootstrap.min.css - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/extend/home/js/jquery-2.0.0.min.js - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/extend/home/js/jquery.screw.js - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/js/bg_pro.js - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET https://cache.drcleaner.com/extend/home/js/mobile.js - 
ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/wp-content/plugins/contact-form-7/includes/js/scripts.js?
 - ORIGINAL_DST/99.84.27.102 text/html

TCP_MISS/502 1609 GET 
https://cache.drcleaner.com/wp-includes/js/comment-reply.min.js? - 
ORIGINAL_DST/99.84.27.102 text/html

 

And over..

 

Please, see https://bugs.squid-cache.org/show_bug.cgi?id=4896

 

If your case is similar, there is a patch as a workaround.

 

HTH

 

 

De: squid-users  En nombre de 
i...@schroeffu.ch
Enviado el: martes, 4 de diciembre de 2018 13:11
Para: squid-users@lists.squid-cache.org
Asunto: [squid-users] Squid 4.4 + SSL bump: Squid is crashing completely 
opening https://www.drcleaner.com/de/dr-cleaner/

 

Hi all,

my Squid 4.4 with SSL bump is crashing while trying to open this website: 
https://www.drcleaner.com/de/dr-cleaner/
So, after trying open this site with SSL bump enabled, no Squid process is 
running anymore. Just. Dead.

What can I do for debug that properly better to report properly an issue?

SSL bump config:

http_port proxy02bs:8080 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/xx.pem 
key=/etc/squid/certs/xx.pem
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB
always_direct allow all
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all !domains_dont_sslbump


Latest words 'till the dead:

Dec 4 16:47:19 proxy02bs squid[1001]: assertion failed: http.cc:1530: 
"!Comm::MonitorsRead(serverConnection->fd)"
Dec 4 16:47:19 proxy02bs squid[604]: Squid Parent: squid-1 process 1001 exited 
due to signal 6 with status 0
Dec 4 16:47:19 proxy02bs squid[604]: Squid Parent: squid-1 process 1001 will 
not be restarted for 3600 seconds due to repeated, frequent failures
Dec 4 16:47:19 proxy02bs squid[604]: Exiting due to repeated, frequent failures
Dec 4 16:47:19 proxy02bs squid[604]: Removing PID file (/var/run/squid.pid)
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Main process exited, 
code=exited, status=1/FAILURE
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 666 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 786 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 855 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 923 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 995 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1004 
(security_file_c) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1007 
(ufdbgclient) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1008 
(ufdbgclient) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1065 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Failed with result 
'exit-code'.


Full syslog: https://pastebin.com/i9itZcZa
Full access.log: https://pastebin.com/Vc0A5sSG
Full cache.log: https://pastebin.com/xdi3RHqs

Thanks for any help in advance
Schroeffu 

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

[squid-users] Squid 4.4 + SSL bump: Squid is crashing completely opening https://www.drcleaner.com/de/dr-cleaner/

[info]

Hi all,

my Squid 4.4 with SSL bump is crashing while trying to open this website: 
https://www.drcleaner.com/de/dr-cleaner/ 
(https://www.drcleaner.com/de/dr-cleaner/)
So, after trying open this site with SSL bump enabled, no Squid process is 
running anymore. Just. Dead.

What can I do for debug that properly better to report properly an issue?

SSL bump config:

http_port proxy02bs:8080 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/xx.pem 
key=/etc/squid/certs/xx.pem
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB
always_direct allow all
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all !domains_dont_sslbump
Latest words 'till the dead:

Dec 4 16:47:19 proxy02bs squid[1001]: assertion failed: http.cc:1530: 
"!Comm::MonitorsRead(serverConnection->fd)"
Dec 4 16:47:19 proxy02bs squid[604]: Squid Parent: squid-1 process 1001 exited 
due to signal 6 with status 0
Dec 4 16:47:19 proxy02bs squid[604]: Squid Parent: squid-1 process 1001 will 
not be restarted for 3600 seconds due to repeated, frequent failures
Dec 4 16:47:19 proxy02bs squid[604]: Exiting due to repeated, frequent failures
Dec 4 16:47:19 proxy02bs squid[604]: Removing PID file (/var/run/squid.pid)
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Main process exited, 
code=exited, status=1/FAILURE
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 666 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 786 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 855 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 923 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 995 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1004 
(security_file_c) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1007 
(ufdbgclient) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1008 
(ufdbgclient) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Killing process 1065 
(pinger) with signal SIGKILL.
Dec 4 16:47:19 proxy02bs systemd[1]: squid.service: Failed with result 
'exit-code'.
Full syslog: https://pastebin.com/i9itZcZa (https://pastebin.com/i9itZcZa)
Full access.log: https://pastebin.com/Vc0A5sSG (https://pastebin.com/Vc0A5sSG)
Full cache.log: https://pastebin.com/xdi3RHqs (https://pastebin.com/xdi3RHqs)

Thanks for any help in advance
Schroeffu
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.4: SSL/certification error messages not displayed with non-english error_directory

[Amos Jeffries]

On 15/11/18 10:50 PM, i...@schroeffu.ch wrote:
> 
> Changing the error_directory to non-english like german or italian, the
> ssl bump error messages like "expired certificate" or "self signed
> certificated" are not showing anymore. Browser is just displaying an
> ugly error 503. But, other error messages like "access denied" are
> displayed properly, also tested with German and Italian.
> 
> #error_directory /usr/share/squid/errors/German
> #error_directory /usr/share/squid/errors/Italian
> 
> How do I debug that properly to raise a bugeport if required?
> 

It is a known bug. The langpack contained empty files for some
templates. You can workaround the issue by replacing the 0-sized file(s)
with the one(s) from errors/templates/.
 A new langpack will be coming out as soon as we get the source of the
problem fixed.

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

[squid-users] Squid 4.4: SSL/certification error messages not displayed with non-english error_directory

[info]

Changing the error_directory to non-english like german or italian, the ssl 
bump error messages like "expired certificate" or "self signed certificated" 
are not showing anymore. Browser is just displaying an ugly error 503. But, 
other error messages like "access denied" are displayed properly, also tested 
with German and Italian.

#error_directory /usr/share/squid/errors/German
#error_directory /usr/share/squid/errors/Italian

How do I debug that properly to raise a bugeport if required?

Squid Version: 4.4-1 (from Debian unstable on Ubuntu 18.04 Server, recompiled 
with openssl)
Squid Langpack Version: Version: 20170901-1 (from Debian unstable on Ubuntu 
18.04 Server)
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Alex Rousskov]

On 11/2/18 3:47 AM, Sid wrote:

> tls_outgoing_options \
>default-ca=off \
>cafile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
>options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE \

> Only issue is Squid sends:
> http://squid-web-proxy-cache.1019090.n4.nabble.com/file/t377591/2018-11-02_151705.jpg

> How to make Squid send certificate in it?

I believe I have answered that question in my previous email[1]. Your
current tls_outgoing_options appear to ignore my answer.

Please note that I have not tested whether tls_outgoing_options cert=...
key= mentioned in [1] works as it should in your environment, but
Squid documentation implies that it works. If it does not work, you may
want to file a bug report.

Alex.
[1]
http://lists.squid-cache.org/pipermail/squid-users/2018-November/019613.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Sid]

Thank you Amos and Alex for great help & support so far.

As per suggestions I have added lot more parameters in squid.conf for both
"http" & "tls_outgoing_options" directives:

http_port 3128 ssl-bump \
  tls-cert=/usr/local/squid/etc/ssl_cert/myCA.pem \
 
cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!DH:!ADH
\
  options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB \
  tls-cafile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
  tls-dh=prime256v1:/usr/local/squid/etc/dhparam.pem \
  tls-dh=secp384r1:/usr/local/squid/etc/dhparam.pem

tls_outgoing_options \
   default-ca=off \
   cafile=/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
   options=NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE \
  
cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!DH:!ADH
\
   flags=DONT_VERIFY_DOMAIN \
   flags=DONT_VERIFY_PEERi \
   min-version=1.2

Now, when I look into wireshark between Server <--> Squid; I no longer see
error: 61 Alert (Level: Fatal, Description: Internal Error) sent by Squid

Only issue is Squid sends:
2018-11-02_151705.jpg

  

How to make Squid send certificate in it?






--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Alex Rousskov]

On 10/31/18 10:55 PM, Sid wrote:

> Actually in my case Server is looking for a certificate to be sent by
> client; How to configure Squid to get
> this certificate from client for mutual authentication?

It is technically impossible to meaningfully forward a client
certificate to the origin server when _bumping_ connections, and, hence,
Squid cannot support such forwarding. You should be able to configure a
bumping Squid to send its own client certificate to the origin server
though; see tls_outgoing_options cert=... key=

The question is, can you give Squid the same client certificate as used
by your client?

* If that client certificate is the same for all from-Squid traffic, you
have access to the client certificate key, and you can store that key
securely on the Squid server, then the answer is probably "yes". It
would not be true "forwarding", but the origin server will get the
certificate it expects, and Squid will be able to send the right TLS
CertificateVerify message to prove that Squid has the private key.

* Otherwise, the answer is probably "no", and you cannot use client
certificate-based authentication with the origin server while bumping
connections. Whether it is possible to support that by enhancing Squid
would depend on which precondition(s) in the first bullet are not
satisfied. For example, it is possible to enhance Squid to select from a
list of client certificates when bumping a server connection.


HTH,

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

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Amos Jeffries]

On 1/11/18 5:55 PM, Sid wrote:
> Thank you Alex.
> 
>> Sounds good. Does the generated fake certificate contain the right origin
> server name? 
> Sid: Yes, It does contain correct IP Address in Server name sent by client.
>  

Alex asked about *name*. IP address is not part of the considerations
because using a raw-IP is not valid for SNI. Even though having one in
the cert "name" is valid it is not supposed to happen either.

Also by "right" he means that Squid is passing on either the *same* name
value from the client SNI (bumping at step 2) or from the real server
provided certificate (bumping at step 3).


> 
>> Why do you expect the client to send a client certificate to Squid? In most
> deployments, TLS servers do not request client certificates and, hence, TLS
> clients do not send client certificates. IIRC, you did not configure your
> Squid to request a client certificate from the client? 
> 
>> Or is there a terminology problem where "client certificate sent to 
> Squid" means something other than "an x509 certificate requested by a 
> TLS server and sent to that server by a TLS client during TLS 
> handshake"? Please note that Squid is a TLS server in this context. 
> 
> Sid: Actually in my case Server is looking for a certificate to be sent by
> client; it isn't a Web Server but SBC looking for a certificate sent by
> a client to grant further voice & video call. How to configure Squid to get
> this certificate from client for mutual authentication?


Configure clientca= on the http(s)_port directive.
see 

IIRC that should work when SSL-Bump functionality re-purposes the
cafile= option which was supposed to be the CA for client certificates.


> 
>> Perhaps the alert may not be related to certificate validation. If you want
> to verify whether UCAppsCA.pem is enough to trust the origin server, you can
> use "curl" or "openssl s_client" tools for a test. They should fail to
> validate the server when not configured to use UCAppsCA.pem and they should
> succeed otherwise. 
> 
> Sid: I have tried following which shows "Verify return code: 0 (ok)":
> openssl s_client -connect :443 -CAfile
> /usr/local/squid/etc/UCAppsCA.pem
> 



Amos

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

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Sid]

Thank you Alex.

>Sounds good. Does the generated fake certificate contain the right origin
server name? 
Sid: Yes, It does contain correct IP Address in Server name sent by client.
 

>Why do you expect the client to send a client certificate to Squid? In most
deployments, TLS servers do not request client certificates and, hence, TLS
clients do not send client certificates. IIRC, you did not configure your
Squid to request a client certificate from the client? 

>Or is there a terminology problem where "client certificate sent to 
Squid" means something other than "an x509 certificate requested by a 
TLS server and sent to that server by a TLS client during TLS 
handshake"? Please note that Squid is a TLS server in this context. 

Sid: Actually in my case Server is looking for a certificate to be sent by
client; it isn't a Web Server but SBC looking for a certificate sent by
a client to grant further voice & video call. How to configure Squid to get
this certificate from client for mutual authentication?

>Perhaps the alert may not be related to certificate validation. If you want
to verify whether UCAppsCA.pem is enough to trust the origin server, you can
use "curl" or "openssl s_client" tools for a test. They should fail to
validate the server when not configured to use UCAppsCA.pem and they should
succeed otherwise. 

Sid: I have tried following which shows "Verify return code: 0 (ok)":
openssl s_client -connect :443 -CAfile
/usr/local/squid/etc/UCAppsCA.pem






--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Alex Rousskov]

On 10/30/18 10:59 PM, Sid wrote:

> Sid: I took wireshark on Squid server (centOS 7); I took 2 wiresharks
> between Client & Squid and then between Squid & Server. I can see client
> being sent fake cert generated by Squid & client responds with "Client key
> Exchange", "Change cipher spec", "Encrypted Handshake Message". 

Sounds good. Does the generated fake certificate contain the right
origin server name?


> But I can't see actual client certificate sent to Squid.

Why do you expect the client to send a client certificate to Squid? In
most deployments, TLS servers do not request client certificates and,
hence, TLS clients do not send client certificates. IIRC, you did not
configure your Squid to request a client certificate from the client?

Or is there a terminology problem where "client certificate sent to
Squid" means something other than "an x509 certificate requested by a
TLS server and sent to that server by a TLS client during TLS
handshake"? Please note that Squid is a TLS server in this context.


> Is there a way to decypt in Wireshark. 

Yes, there are several ways, including giving Wireshark your Squid's
private certificate key. Sorry, I do not have detailed instructions.
Please note that the encrypted part probably does not matter -- in most
cases prior to TLS v1.3, it is the plain text Hellos that are important
when it comes to bumping the connection.


> In Wireshark between Squid & Server I can see Squid responding
> with "61 Alert (Level: Fatal, Description: Internal Error)".

> Alex: Is your Squid configured to trust those internal CAs? If not, Squid
> would not be able to validate the server certificate. 

> Sid: I have added those chained certificates as following in squid.conf
> tls_outgoing_options cafile=/usr/local/squid/etc/UCAppsCA.pem
> sslproxy_foreign_intermediate_certs /usr/local/squid/etc/UCAppsCA.pem

Perhaps the alert may not be related to certificate validation. If you
want to verify whether UCAppsCA.pem is enough to trust the origin
server, you can use "curl" or "openssl s_client" tools for a test. They
should fail to validate the server when not configured to use
UCAppsCA.pem and they should succeed otherwise.


HTH,

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

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Sid]

Thank you Alex for the reply.
 
Alex: 1. Servers never send SNI. Clients usually send SNI. Squid should
forward SNI it received from the client to the server, provided the client
actually sent SNI. Did your client send SNI? 

Sid: I can see in Client Hello IP Address being sent by Client; so there is
no SNI from client itself.

Alex: 2. Bugs notwithstanding, the implied order of events is not what
actually happens: Squid, as configured, does _not_ forward anything from the
server certificate to the client. Squid, as configured, generates a
certificate based on client-supplied information (not server-supplied
information). After sending that generated certificate to the client, Squid
establishes a TLS connection with the server. 

Sid: Thank you for explanation.

Alex: For an accurate picture, in addition to Squid-server and server-Squid
traffic, look at what Squid has received from the client and what Squid sent
to the client, all in actual order.

Sid: I took wireshark on Squid server (centOS 7); I took 2 wiresharks
between Client & Squid and then between Squid & Server. I can see client
being sent fake cert generated by Squid & client responds with "Client key
Exchange", "Change cipher spec", "Encrypted Handshake Message". But I can't
see actual client certificate sent to Squid. Is there a way to decypt in
Wireshark. In Wireshark between Squid & Server I can see Squid responding
with "61 Alert (Level: Fatal, Description: Internal Error)".

Alex: Is your Squid configured to trust those internal CAs? If not, Squid
would not be able to validate the server certificate. 

Sid: I have added those chained certificates as following in squid.conf
tls_outgoing_options cafile=/usr/local/squid/etc/UCAppsCA.pem
sslproxy_foreign_intermediate_certs /usr/local/squid/etc/UCAppsCA.pem




--
Sent from: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Alex Rousskov]

On 10/30/18 2:36 AM, Sid wrote:

> http_port 3128 ssl-bump \ 
>   cert=/usr/local/squid/etc/ssl_cert/myCA.pem \ 
>   generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 

> ssl_bump peek step1 
> ssl_bump bump all 

> Browser & HTTP UA Client connections are working with SSL bump properly; but
> except for one connection. 

> Server sends certificate with SNI; but squid forwards it as IP Address to
> client

Two problems with that statement:

1. Servers never send SNI. Clients usually send SNI. Squid should
forward SNI it received from the client to the server, provided the
client actually sent SNI. Did your client send SNI?

2. Bugs notwithstanding, the implied order of events is not what
actually happens: Squid, as configured, does _not_ forward anything from
the server certificate to the client. Squid, as configured, generates a
certificate based on client-supplied information (not server-supplied
information). After sending that generated certificate to the client,
Squid establishes a TLS connection with the server.


> When I took wireshark on Squid; I can see Squid sends: 

For an accurate picture, in addition to Squid-server and server-Squid
traffic, look at what Squid has received from the client and what Squid
sent to the client, all in actual order.


> 61 Alert (Level: Fatal, Description: Internal Error) to certificate sent by
> Server 
> 
> cache.log: 
> 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21:
> error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify
> failed (1/-1/0) 
> 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21:
> error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify
> failed (1/-1/0) 
> 
> This is an internal server with its own CA certs. 

Is your Squid configured to trust those internal CAs? If not, Squid
would not be able to validate the server certificate.


HTH,

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

[squid-users] Squid 4.3: SSL Bump fails to send client certificate

[Sid]

Hi, 

I have following Squid version installed on CentOS 7: 
[root@localhost ~]# squid -v 
Squid Cache: Version 4.3 
Service Name: squid 

This binary uses OpenSSL 1.0.2k-fips  26 Jan 2017. For legal restrictions on
distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/usr' '--includedir=/usr/include'
'--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid'
'--localstatedir=/var' '--sysconfdir=/etc/squid' '--with-openssl'
'--enable-ssl-crtd' 

Squid.conf: 
# Recommended minimum configuration: 
# 

# Example rule allowing access from your local networks. 
# Adapt to list your (internal) IP networks from where browsing 
# should be allowed 
#acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) 
#acl localnet src 10.0.0.0/8# RFC 1918 local private network
(LAN) 
#acl localnet src 100.64.0.0/10 # RFC 6598 shared address space
(CGN) 
#acl localnet src 169.254.0.0/16# RFC 3927 link-local (directly
plugged) machines 
#acl localnet src 172.16.0.0/12 # RFC 1918 local private network
(LAN) 
#acl localnet src 10.133.64.0/22# RFC 1918 local private
network (LAN) 
acl localnet src 20.20.64.0/24 
acl localnet src 192.168.1.0/24 
#acl localnet src 10.133.65.0/22 
#acl localnet src 10.133.66.0/22 
#acl localnet src 10.133.67.0/22 
#acl localnet src fc00::/7  # RFC 4193 local private network
range 
#acl localnet src fe80::/10 # RFC 4291 link-local (directly
plugged) machines 

acl SSL_ports port 443 
acl SSL_ports port 8443 
acl Safe_ports port 80  # http 
acl Safe_ports port 21  # ftp 
acl Safe_ports port 443 # https 
acl Safe_ports port 8443 # https 
acl Safe_ports port 70  # gopher 
acl Safe_ports port 210 # wais 
acl Safe_ports port 1025-65535  # unregistered ports 
acl Safe_ports port 280 # http-mgmt 
acl Safe_ports port 488 # gss-http 
acl Safe_ports port 591 # filemaker 
acl Safe_ports port 777 # multiling http 
acl CONNECT method CONNECT 

# 
# Recommended minimum Access Permission configuration: 
# 
# Deny requests to certain unsafe ports 
http_access deny !Safe_ports 

# Deny CONNECT to other than secure SSL ports 
# Deny CONNECT to other than secure SSL ports 
http_access deny CONNECT !SSL_ports 

# Only allow cachemgr access from localhost 
http_access allow localhost manager 
http_access deny manager 

# We strongly recommend the following be uncommented to protect innocent 
# web applications running on the proxy server who think the only 
# one who can access services on "localhost" is a local user 
#http_access deny to_localhost 

# 
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS 
# 

# Example rule allowing access from your local networks. 
# Adapt localnet in the ACL section to list your (internal) IP networks 
# from where browsing should be allowed 
http_access allow localnet 
http_access allow localhost 

# And finally deny all other access to this proxy 
http_access deny all 

# Squid normally listens to port 3128 
#http_port 3128 

http_port 3128 ssl-bump \ 
  cert=/usr/local/squid/etc/ssl_cert/myCA.pem \ 
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 

# For squid 3.5.x 
#sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB 

# For squid 4.x 
sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s
/var/lib/ssl_db -M 4MB 

acl step1 at_step SslBump1 

ssl_bump peek step1 
ssl_bump bump all 

tls_outgoing_options cafile=/usr/local/squid/etc/UCAppsCA.pem 
sslproxy_foreign_intermediate_certs /usr/local/squid/etc/UCAppsCA.pem 

# Uncomment and adjust the following to add a disk cache directory. 
cache_effective_user squid 
cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256 

# Leave coredumps in the first cache dir 
coredump_dir /usr/local/squid/var/cache/squid 

# 
# Add any of your own refresh_pattern entries above these. 
# 
refresh_pattern ^ftp:   144020% 10080 
refresh_pattern ^gopher:14400%  1440 
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0 
refresh_pattern .   0   20% 4320 
xx
Browser & HTTP UA Client connections are working with SSL bump properly; but
except for one connection. 

Server sends certificate with SNI; but squid forwards it as IP Address to
client 
1540529604.672 49 20.20.64.91 NONE/200 0 CONNECT 20.20.64.56:443 -
HIER_DIRECT/20.20.64.56 - 

When I took wireshark on Squid; I can see Squid sends: 

61 Alert (Level: Fatal, Description: Internal Error) to certificate sent by
Server 

cache.log: 
2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify
failed (1/-1/0) 
2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21:
error:14090086:SSL 

Re: [squid-users] SQUID Proxy - SSL Certificate error

[Amos Jeffries]

On 18/10/18 3:49 PM, Amos Jeffries wrote:
> On 18/10/18 2:31 AM, Vayalpadu, Vedavyas wrote:
>> Hi All,
>>
>> We have an existing SSL certificate for a WebShop URL. It has an
>> external IP Natted to a Load Balancer and has 2 reverse-squid proxies
>> configured for load balancing.
>>
>>  
>>
>> Now we need to on-board a new URL with same external IP, Same Load
>> Balancers and r-Squid proxy servers ? Is it possible.
>>
>>  
>>
>> I have uploaded the new URL certificate and restarted the squid proxy
>> services, when I try to access the URL iam getting below error, and
>> Certificate error as below.
>>
>>  
>>
>> Can anyone help me on this ?
>>
> 
> OpenSSL builds of Squid do not support multiple certificates per
> listening port.
> 
> Squid-4 does support multiple certificates when built with GnuTLS
> instead of OpenSSL. This is still an experimental feature though, so YMMV.
> 

FYI: I have now added a config example to the wiki documenting this
GnuTLS feature at
.

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

Re: [squid-users] SQUID Proxy - SSL Certificate error

[Amos Jeffries]

On 18/10/18 2:31 AM, Vayalpadu, Vedavyas wrote:
> Hi All,
> 
> We have an existing SSL certificate for a WebShop URL. It has an
> external IP Natted to a Load Balancer and has 2 reverse-squid proxies
> configured for load balancing.
> 
>  
> 
> Now we need to on-board a new URL with same external IP, Same Load
> Balancers and r-Squid proxy servers ? Is it possible.
> 
>  
> 
> I have uploaded the new URL certificate and restarted the squid proxy
> services, when I try to access the URL iam getting below error, and
> Certificate error as below.
> 
>  
> 
> Can anyone help me on this ?
> 

OpenSSL builds of Squid do not support multiple certificates per
listening port.

Squid-4 does support multiple certificates when built with GnuTLS
instead of OpenSSL. This is still an experimental feature though, so YMMV.

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

[squid-users] SQUID Proxy - SSL Certificate error

[Vayalpadu, Vedavyas]

Hi All,

We have an existing SSL certificate for a WebShop URL. It has an external IP 
Natted to a Load Balancer and has 2 reverse-squid proxies configured for load 
balancing.

Now we need to on-board a new URL with same external IP, Same Load Balancers 
and r-Squid proxy servers ? Is it possible.

I have uploaded the new URL certificate and restarted the squid proxy services, 
when I try to access the URL iam getting below error, and Certificate error as 
below.

Can anyone help me on this ?


The hostname in the website's security certificate differs from the website you 
are trying to visit.
Error Code: DLG_FLAGS_SEC_CERT_CN_INVALID


Certificate error:

[cid:image003.png@01D4664B.C79973D0]


Please let me know if there are more questions, or call me over skype.

VYAS  (Vedavyas Vayalpadu)
IBM-AIX-UNIX Support
vedavyas.vayalp...@accenture.com





This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise confidential information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy. Your privacy is important to us. Accenture uses your personal data only 
in compliance with data protection laws. For further information on how 
Accenture processes your personal data, please see our privacy statement at 
https://www.accenture.com/us-en/privacy-policy.
__

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

Re: [squid-users] Squid and SSL Bump

[Amos Jeffries]

On 13/01/18 02:00, Yoinier Hernandez Nieves wrote:


The user ynieves is member of ad groups “internet”, “socialNetwork”, “youtube” and 
“moderadoresSocNet"



So most of your http_access lines end with group checks. That could be a 
problem later. Right now its not clear which would be rejecting with 
that auth message, and the status being 403 indicates a hard failure 
rather than re-auth.



I suggest doing the usual thing of placing a single "http_access deny 
!users" line first, then appending " all" to the lines that normally end 
with a group check.


Like:

  http_access deny !users

  http_access allow cubaDomains cubaPC all
  http_access allow cubaDomains national all
  http_access allow cubaDomains internet all
  http_access deny SQUISHED1 all

  http_access allow socialDomains moderadoresSocNet all
  http_access allow socialTime socialDomains socialNetwork all
  http_access allow socialTime youtubeDomains youtuber all


For the delay pools there is no need to re-authenticate at all. Use the 
"note" ACL type to check that a username exists. Like so:


  acl loggedIn note user .

  delay_access 2 allow loggedIn workTime \
!extDownloads !extDocuments !delaysFree


Also, the pool using only "-1/-1" as its paremeters should be removed. 
Squid links multiple pools to a transaction, so it is not doing what you 
think it does. To make certain transactions unlimited simply deny them 
being added to the other pools. That will also make your existing rules 
much simpler:


  denya_access 2 deny delaysFree
  delay_access 2 allow loggedIn workTime !extDownloads !extDocuments !
  delay_access 2 deny all


Also, your media and mediapr checks are slow regex tests. They should be 
placed after the default security checks.



If the problem remains after all the above changes are made you will 
need to track down what is generating the error page using cache.log 
trace with "debug_options ALL,5".


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

Re: [squid-users] Squid and SSL Bump

[Yoinier Hernandez Nieves]

squid.conf
Description: Binary data

The user ynieves is member of ad groups “internet”, “socialNetwork”, “youtube” 
and “moderadoresSocNet"

Thanks.

Yoinier Hernandez Nieves.

> El 11/01/2018, a las 10:47 a.m., Amos Jeffries  
> escribió:
> 
> On 12/01/18 03:24, Yoinier Hernandez Nieves wrote:
>>> El 11/01/2018, a las 12:46 a.m., Amos Jeffries escribió:
>>> 
>>> On 11/01/18 09:33, Yoinier Hernandez Nieves wrote:
 I try connect direct to the proxy, and this is the result
 1515616366.189   1359 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT 
 www.ssllabs.com:443  ynieves 
 HIER_DIRECT/64.41.200.100 -
 1515616366.207  0 aaa.aaa.aaa.aaa TCP_DENIED/403 4419 GET 
 https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- 
 text/html
 1515616366.244  0 aaa.aaa.aaa.aaa TAG_NONE/503 4914 GET 
 http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png 
 ynieves HIER_DIRECT/64.41.200.100 text/html
 How I can fix this.??
>>> 
>>> 
>>> What exactly do you think needs "fixing” ?
>> I need fix the problem with the auth failure.
>> Hi say:
>> Sorry, you are not currently allowed to request 
>> https://www.google.com/search? from this cache until you have authenticated 
>> yourself.
>> But I stay authenticated, see the log, user, ynieves.
> 
> Then something in your squid.conf is forbidding username ynieves access to 
> use the proxy and defining that other username might be allowed. But it 
> provides that info far too late to re-authenticate the already finished 
> CONNECT message with usable credentials.
> 
> Please post *all* of your squid.conf settings so we can look in places you 
> might not have expected to find auth relationships. Just exclude empty lines 
> and # comments.
> 
> 
> Amos
> ___
> 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] Squid and SSL Bump

[Amos Jeffries]

On 12/01/18 03:24, Yoinier Hernandez Nieves wrote:



El 11/01/2018, a las 12:46 a.m., Amos Jeffries escribió:

On 11/01/18 09:33, Yoinier Hernandez Nieves wrote:

I try connect direct to the proxy, and this is the result
1515616366.189   1359 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT www.ssllabs.com:443 
 ynieves HIER_DIRECT/64.41.200.100 -
1515616366.207  0 aaa.aaa.aaa.aaa TCP_DENIED/403 4419 GET 
https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- text/html
1515616366.244  0 aaa.aaa.aaa.aaa TAG_NONE/503 4914 GET 
http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png ynieves 
HIER_DIRECT/64.41.200.100 text/html
How I can fix this.??



What exactly do you think needs "fixing” ?


I need fix the problem with the auth failure.

Hi say:

Sorry, you are not currently allowed to request https://www.google.com/search? 
from this cache until you have authenticated yourself.

But I stay authenticated, see the log, user, ynieves.



Then something in your squid.conf is forbidding username ynieves access 
to use the proxy and defining that other username might be allowed. But 
it provides that info far too late to re-authenticate the already 
finished CONNECT message with usable credentials.


Please post *all* of your squid.conf settings so we can look in places 
you might not have expected to find auth relationships. Just exclude 
empty lines and # comments.



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

Re: [squid-users] Squid and SSL Bump

[Yoinier Hernandez Nieves]

> El 11/01/2018, a las 12:46 a.m., Amos Jeffries  
> escribió:
> 
> On 11/01/18 09:33, Yoinier Hernandez Nieves wrote:
>> I try connect direct to the proxy, and this is the result
>> 1515616366.189   1359 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT 
>> www.ssllabs.com:443  ynieves 
>> HIER_DIRECT/64.41.200.100 -
>> 1515616366.207  0 aaa.aaa.aaa.aaa TCP_DENIED/403 4419 GET 
>> https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- 
>> text/html
>> 1515616366.244  0 aaa.aaa.aaa.aaa TAG_NONE/503 4914 GET 
>> http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png 
>> ynieves HIER_DIRECT/64.41.200.100 text/html
>> How I can fix this.??
> 
> 
> What exactly do you think needs "fixing” ?

I need fix the problem with the auth failure.

Hi say:

Sorry, you are not currently allowed to request https://www.google.com/search? 
from this cache until you have authenticated yourself.

But I stay authenticated, see the log, user, ynieves.

Thanks

Yoinier Hernandez Nieves

> 
> 
> Amos
> ___
> 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] Squid and SSL Bump

[Amos Jeffries]

On 11/01/18 09:33, Yoinier Hernandez Nieves wrote:


I try connect direct to the proxy, and this is the result

1515616366.189   1359 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT 
www.ssllabs.com:443  ynieves 
HIER_DIRECT/64.41.200.100 -
1515616366.207      0 aaa.aaa.aaa.aaa TCP_DENIED/403 4419 GET 
https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- 
text/html
1515616366.244      0 aaa.aaa.aaa.aaa TAG_NONE/503 4914 GET 
http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png 
ynieves HIER_DIRECT/64.41.200.100 text/html


How I can fix this.??



What exactly do you think needs "fixing" ?


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

Re: [squid-users] Squid and SSL Bump

[Yoinier Hernandez Nieves]

> El 10/01/2018, a las 8:47 a.m., Amos Jeffries  escribió:
> 
> On 10/01/18 10:56, Yoinier Hernandez Nieves wrote:
>> I answer interline.
>>> El 9/01/2018, a las 4:27 p.m., Antony Stone escribió:
>>> 
>>> On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:
>>> 
 I try configure squid 3.5 on CentOS 7 with sslBump.
 
 But I have some problems, the first:
 
 Some HTTPs sites can access, because squid say what I am are not
 authenticated. And other sites, yes I can access.
>>> 
>>> Please give us information:
>>> 
>>> 1. An example of sites can you access.
>> not https
>>> 2. An example of sites can you not access.
>> https://www.ssllabs.com/ssltest/viewMyClient.html
>> https://outlook.co.il/
>> https://www.facebook.com
>>> 3. For problems, show us error messages - quote us what the remote sites 
>>> tell
>>> you.
>> Se encontró el siguiente error al intentar recuperar la dirección URL: 
>> https://outlook.co.il/
>>*Acceso Denegado a la Caché*
>> Lo lamento, tu no estás autorizado a solicitar https://outlook.co.il/ de 
>> este caché hasta que te hayas autenticado.
>> Please contact the cache administrator 
>> 
>>  if you have difficulties authenticating yourself.
>>> 
>>> 4. Please rephrase "squid say what I am are not authenticated" - this is not
>>> clear - what do you mean?
>>> 
 I am authenticated.
>>> 
>>> To what?  Squid, or the remote site?
>> Squid, see message in Spanish for point 3.
> 
> Your Squid log snippets you presented below say that the client which 
> delivered a CONNECT message to Squid was authenticated. Things inside the 
> tunnel encryption *cannot* be authenticated as separate things. Squid 
> associates the credentials from the CONNECT tunnel for each request inside 
> that tunnel.
> 
> That means that if you have any auth related config settings to the https:// 
> request(s) which cause those credentials to need to be re-checked, to 
> timeout, or any of a multitude of other situations that normally occur with 
> auth - then the bumped traffic in that bump'd tunnel from that point onward 
> cannot be serviced and you will start to have errors. The only viable 
> solution is to avoid authentication checks on the decrypted / MITM'd / 
> SSL-Bump'd traffic.
> 
> 
> 
>> Other error is that
>> https://www.kiosco.bandec.cu/kiosco
>> Error negotiating SSL on FD 16: error:14090086:SSL 
>> routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
>> The following error was encountered while trying to retrieve the URL: 
>> https://www.kiosco.bandec.cu/*
>>*Failed to establish a secure connection to 190.6.64.132*
>> The system returned:
>>(71) Protocol error (TLS code: 
>> X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)
>>SSL Certficate error: certificate issuer (CA) not known:
>>/CN=CX6.bandec.cu
>> This proxy and the remote host failed to negotiate a mutually acceptable 
>> security settings for handling your request. It is possible that the remote 
>> host does not support secure connections, or the proxy is not satisfied with 
>> the host security credentials.
> 
> Please read the above error message carefully. It explains exactly what is 
> going wrong, and from that you should be able to find the MANY discussion 
> threads that exact same error message has had in here and elsewhere over the 
> past few years.
> 
> Your options are to:
> 
> * configure 
>  
> (may require a Squid-3.5 upgrade), or
> 
> * upgrade to Squid-4 which auto-downloads these things.
> 
> 
>>> 
>>> How do you know you are authenticated - what confirmation do you have?
>>> 
 Fragment of my squid.conf.
 
 http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
 generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
 options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
 /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
 NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
 acl step1 at_step SslBump1
 acl step2 at_step SslBump2
 acl step3 at_step SslBump3
 ssl_bump peek step1
 ssl_bump 

Re: [squid-users] Squid and SSL Bump

[Amos Jeffries]

On 10/01/18 10:56, Yoinier Hernandez Nieves wrote:

I answer interline.


El 9/01/2018, a las 4:27 p.m., Antony Stone escribió:

On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:


I try configure squid 3.5 on CentOS 7 with sslBump.

But I have some problems, the first:

Some HTTPs sites can access, because squid say what I am are not
authenticated. And other sites, yes I can access.


Please give us information:

1. An example of sites can you access.

not https


2. An example of sites can you not access.

https://www.ssllabs.com/ssltest/viewMyClient.html
https://outlook.co.il/
https://www.facebook.com

3. For problems, show us error messages - quote us what the remote 
sites tell

you.


Se encontró el siguiente error al intentar recuperar la dirección URL: 
https://outlook.co.il/


*Acceso Denegado a la Caché*

Lo lamento, tu no estás autorizado a solicitar https://outlook.co.il/ de 
este caché hasta que te hayas autenticado.


Please contact the cache administrator 
 
if you have difficulties authenticating yourself.




4. Please rephrase "squid say what I am are not authenticated" - this 
is not

clear - what do you mean?


I am authenticated.


To what?  Squid, or the remote site?

Squid, see message in Spanish for point 3.



Your Squid log snippets you presented below say that the client which 
delivered a CONNECT message to Squid was authenticated. Things inside 
the tunnel encryption *cannot* be authenticated as separate things. 
Squid associates the credentials from the CONNECT tunnel for each 
request inside that tunnel.


That means that if you have any auth related config settings to the 
https:// request(s) which cause those credentials to need to be 
re-checked, to timeout, or any of a multitude of other situations that 
normally occur with auth - then the bumped traffic in that bump'd tunnel 
from that point onward cannot be serviced and you will start to have 
errors. The only viable solution is to avoid authentication checks on 
the decrypted / MITM'd / SSL-Bump'd traffic.





Other error is that
https://www.kiosco.bandec.cu/kiosco
Error negotiating SSL on FD 16: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)


The following error was encountered while trying to retrieve the URL: 
https://www.kiosco.bandec.cu/*


*Failed to establish a secure connection to 190.6.64.132*

The system returned:

(71) Protocol error (TLS code: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)

SSL Certficate error: certificate issuer (CA) not known:
/CN=CX6.bandec.cu

This proxy and the remote host failed to negotiate a mutually acceptable 
security settings for handling your request. It is possible that the 
remote host does not support secure connections, or the proxy is not 
satisfied with the host security credentials.




Please read the above error message carefully. It explains exactly what 
is going wrong, and from that you should be able to find the MANY 
discussion threads that exact same error message has had in here and 
elsewhere over the past few years.


Your options are to:

* configure 
 
(may require a Squid-3.5 upgrade), or


* upgrade to Squid-4 which auto-downloads these things.




How do you know you are authenticated - what confirmation do you have?


Fragment of my squid.conf.

http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
/usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1
ssl_bump bump all
authenticate_ip_ttl 60 seconds


That looks a bit strange (and a bit incomplete) to me, but since I'm 
no expert

on SSL interception, I'll let someone else step in here.



The authenticate_ip_ttl is irrelevant except that if the auth system 
obeys it, the result will be all persistent connections producing errors 
60 seconds after they become 

Re: [squid-users] Squid and SSL Bump

[Yoinier Hernandez Nieves]

I answer interline.

> El 9/01/2018, a las 4:27 p.m., Antony Stone 
>  escribió:
> 
> On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:
> 
>> I try configure squid 3.5 on CentOS 7 with sslBump.
>> 
>> But I have some problems, the first:
>> 
>> Some HTTPs sites can access, because squid say what I am are not
>> authenticated. And other sites, yes I can access.
> 
> Please give us information:
> 
> 1. An example of sites can you access.
not https

> 2. An example of sites can you not access.
https://www.ssllabs.com/ssltest/viewMyClient.html 

https://outlook.co.il/ 
https://www.facebook.com 

> 3. For problems, show us error messages - quote us what the remote sites tell 
> you.
Se encontró el siguiente error al intentar recuperar la dirección URL: 
https://outlook.co.il/ 
Acceso Denegado a la Caché

Lo lamento, tu no estás autorizado a solicitar https://outlook.co.il/ de este 
caché hasta que te hayas autenticado.

Please contact the cache administrator 

 if you have difficulties authenticating yourself.

> 
> 4. Please rephrase "squid say what I am are not authenticated" - this is not 
> clear - what do you mean?
> 
>> I am authenticated.
> 
> To what?  Squid, or the remote site?
Squid, see message in Spanish for point 3.

Other error is that
https://www.kiosco.bandec.cu/kiosco 
Error negotiating SSL on FD 16: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
The following error was encountered while trying to retrieve the URL: 
https://www.kiosco.bandec.cu/* 
Failed to establish a secure connection to 190.6.64.132

The system returned:

(71) Protocol error (TLS code: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)
SSL Certficate error: certificate issuer (CA) not known: /CN=CX6.bandec.cu

This proxy and the remote host failed to negotiate a mutually acceptable 
security settings for handling your request. It is possible that the remote 
host does not support secure connections, or the proxy is not satisfied with 
the host security credentials.

> 
> How do you know you are authenticated - what confirmation do you have?
> 
>> Fragment of my squid.conf.
>> 
>> http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
>> options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
>> /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
>> NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
>> ssl_bump peek step1
>> ssl_bump bump all
>> authenticate_ip_ttl 60 seconds
> 
> That looks a bit strange (and a bit incomplete) to me, but since I'm no 
> expert 
> on SSL interception, I'll let someone else step in here.
> 
> If you can provide more information in the meantime (eg: enough to help 
> someone else replicate your problem) that would be good.
> 
I use too dansguardians before the squid proxy.

See the logs for one petition

1515534858.355   3720 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT 
www.ssllabs.com:443 ynieves HIER_DIRECT/64.41.200.100 -
1515534858.375  0 bbb.bbb.bbb.bbb TCP_DENIED/403 4457 GET 
https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- text/html
1515534858.407  0 bbb.bbb.bbb.bbb TAG_NONE/503 4952 GET 
http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png ynieves 
HIER_DIRECT/64.41.200.100 text/html

aaa.aaa.aaa.aaa is my pc.
bbb.bbb.bbb.bbb is the dansguardians

> 
> Antony.
> 
> -- 
> Wanted: telepath.   You know where to apply.
> 
>   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 

Re: [squid-users] Squid and SSL Bump

[Antony Stone]

On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:

> I try configure squid 3.5 on CentOS 7 with sslBump.
> 
> But I have some problems, the first:
> 
> Some HTTPs sites can access, because squid say what I am are not
> authenticated. And other sites, yes I can access.

Please give us information:

1. An example of sites can you access.

2. An example of sites can you not access.

3. For problems, show us error messages - quote us what the remote sites tell 
you.

4. Please rephrase "squid say what I am are not authenticated" - this is not 
clear - what do you mean?

> I am authenticated.

To what?  Squid, or the remote site?

How do you know you are authenticated - what confirmation do you have?

> Fragment of my squid.conf.
> 
> http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
> options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
> /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
> NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1
> ssl_bump bump all
> authenticate_ip_ttl 60 seconds

That looks a bit strange (and a bit incomplete) to me, but since I'm no expert 
on SSL interception, I'll let someone else step in here.

If you can provide more information in the meantime (eg: enough to help 
someone else replicate your problem) that would be good.


Antony.

-- 
Wanted: telepath.   You know where to apply.

   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] Squid and SSL Bumb

[Yoinier Hernandez Nieves]

I try configure squid 3.5 on CentOS 7 with sslBump.

But I have some problems, the first:

Some HTTPs sites can access, because squid say what I am are not authenticated. 
And other sites, yes I can access.

I am authenticated.

Thanks.

Yoinier.

Fragment of my squid.conf.

http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem 
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB# options=NO_SSLv3 
dhparams=/etc/squid/ssl_cert/dhparam.pem
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1
ssl_bump bump all
authenticate_ip_ttl 60 seconds


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

Re: [squid-users] squid 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Jason Chiu]

I reconfigured  add " --with-nat-devpf " (squid-3.5.24 on FreeBSD 9.1)

This issue *has been resolved*
thanks to Amos Jeffries

The follow is my squid version and configure.

Squid Cache: Version 3.5.24-20170331-r14150
Service Name: squid
configure options:  '--prefix=/usr/local/squid' '--sysconfdir=/etc/squid'
'--localstatedir=/var/squid' '--datadir=/usr/share/squid'
'--enable-icap-client' '--enable-ssl' '--with-pthreads'
'--enable-pf-transparent' '--with-nat-devpf' '--enable-ssl-crtd'
'--enable-ecap' '--with-openssl' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
--enable-ltdl-convenience






--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-5-ssl-bump-intercept-TCP-DENIED-200-on-bridge-mode-tp4682712p4682748.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] squid 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Jason Chiu]

test case 1 : 
-
I changed my squid setting (don't use intercept mode)

http_port 3129 ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

thab client Web Browser set proxy to 192.168.95.81:3129

squid ssl-bump * OK *
squid access.log has the client access log.

test case 2:
-
but I want use transparent mode (intercept with PF rdr).
intercept mode add the following acl rule :

acl bumpedPorts myportname 3129
http_access allow CONNECT bumpedPorts
.
https_port 3129 intercept ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 

access.log no appear TCP_DENIED/200 0 CONNECT 127.0.0.1:3129 
but client web browser has been waiting and no response.





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-5-ssl-bump-intercept-TCP-DENIED-200-on-bridge-mode-tp4682712p4682735.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] squid 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Jason Chiu]

I also tested the following cases 
test case 1: 

add the following settings in squid.conf 

acl bumpedPorts myportname 3129 
http_access allow CONNECT bumpedPorts 

test results:  ssl bump is failed 
1. access.log no record 
2. web browser has been waiting , no response 

-- 

test case 2: 
1. squid.conf  use  http_port 3129 ssl-bump
cert=/usr/local/squid/ssl_cert/myCA.pem generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB 
2. web browser use proxy server x.x.x.x 3129 

test result :  ssl bump is OK



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-5-ssl-bump-intercept-TCP-DENIED-200-on-bridge-mode-tp4682712p4682734.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] squid 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Alex Rousskov]

On 06/07/2017 03:37 AM, Jason Chiu wrote:

> 1495699856.074  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129

> *Need to adjust which part of the settings?*

If that connection is really trying to connect to 127.0.0.1:3129 from
Squid point of view, then your interception setup is probably deficient.
Intercepted to-port 443 connections should be seen by Squid as going to
port 443 (while being received at Squid port 3129). Interception is not
(or should not be) just port redirection. This has nothing to do with
Squid configuration though.

Once you fix interception (or if you refuse to fix it), if Squid is
denying access, then you should adjust your http_access rules. Your
rules must allow fake CONNECT request that represent intercepted HTTPS
connections. For example, the above TCP_DENIED line is probably logged
because your current interception setup triggers this (correct) rule:

> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports


And yes, it might have "worked" in the past because earlier Squids were
doing fewer checks that they should be doing.

Alex.


> #
> # Recommended minimum Access Permission configuration:
> #
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
> 
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
> 
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
> 
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
> 
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
> 
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow localnet
> http_access allow localhost
> 
> # And finally deny all other access to this proxy
> http_access deny all
> 
> # Squid normally listens to port 3128
> http_port 3128
> 
> # Uncomment and adjust the following to add a disk cache directory.
> #cache_dir ufs /var/squid/cache/squid 100 16 256
> 
> # Leave coredumps in the first cache dir
> coredump_dir /var/squid/cache/squid
> 
> #
> # Add any of your own refresh_pattern entries above these.
> #
> refresh_pattern ^ftp:   144020% 10080
> refresh_pattern ^gopher:14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> refresh_pattern .   0   20% 4320
> 
> #http_port 3129 ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> https_port 3129 intercept ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1 all
> ssl_bump bump all
> 
> # sslcrtd
> sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/squid/ssl_db -M
> 10MB
> sslcrtd_children 5
> 
> # sslproxy setting
> sslproxy_capath /var/squid/ssl_db/certs
> sslproxy_options NO_SSLv2,NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
> #sslproxy_cipher
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
> sslproxy_cert_error allow all
> sslproxy_cert_adapt setValidAfter all
> 
> sslproxy_flags DONT_VERIFY_PEER
> 
> 
> pf.conf
> ---
> #internal interface
> int_if = '{em1}'
> 
> # Normalization: reassemble fragments resolve or reduce traffic ambiguities.
> scrub in all
> set skip on lo0
> 
> #sslTP rdr setting
> rdr_from = 'any'
> rdr_to = 'any;
> rdr on $int_if inet proto tcp from $rdr_from to $rdr_to port 443 ->
> 127.0.0.1 port 3129
> pass in all no state
> pass out all no state
> pass in quick on $int_if route-to lo0 inet proto tcp from $rdr_from to any
> keep state
> 
> 
> 
> --
> View this message in context: 
> http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-5-ssl-bump-intercept-TCP-DENIED-200-on-bridge-mode-tp4682712.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 mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Jason Chiu]

I also tested the following cases 
test case 1: 

add the following settings in squid.conf 

acl bumpedPorts myportname 3129 
http_access allow CONNECT bumpedPorts 

test results:  ssl bump is failed
1. access.log no record 
2. web browser has been waiting , no response 

-- 

test case 2: 
1. squid.conf  use  http_port 3129 ssl-bump
cert=/usr/local/squid/ssl_cert/myCA.pem generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB 
2. web browser use proxy server x.x.x.x 3129 

test result :  ssl bump is OK 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-5-ssl-bump-intercept-TCP-DENIED-200-on-bridge-mode-tp4682712p4682713.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 3.5 ssl-bump intercept TCP_DENIED/200 on bridge mode

[Jason Chiu]

I had a FreeBSD 9.1 bridge (em0, em1) environment,
Use "pf rdr to" redirect HTTPS (port 443) packets to squid (squid 127.0.0.1:
3129)

Squid *3.3.11* ssl bump is OK.


The following is the setting of squid 3.3.11

Squid Cache: Version 3.3.11-20140220-r12672
Configure options: '--prefix = / usr / local / squid' '--sysconfdir = / etc
/ squid' '--localstatedir = / var / squid' '--datadir = / usr / share /
squid' Enable-icap-client '' --enable-ssl '' --with-pthreads ''
--enable-pf-transparent '' --enable-ssl-crtd '' --enable-ecap ''
PKG_CONFIG_PATH = / usr / Local / lib / pkgconfig '--enable-ltdl-convenience


Recently in order to allow squid can signing generated sha256 certificates 
, 
upgrade squid to 3.5.24 version.


But ssl bump * is not OK *

Access.log always appears the following message:
1495699856.074  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -
1495699857.720  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -
1495701676.054  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -
1495701676.717  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -
1495701677.060  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -
1495701677.354  0 192.168.95.81 TCP_DENIED/200 0 CONNECT 127.0.0.1:3129
- HIER_NONE/- -

*Need to adjust which part of the settings?*



The following is my settings: 

Squid Cache: Version 3.5.24-20170331-r14150
Service Name: squid
configure options:  '--prefix=/usr/local/squid' '--sysconfdir=/etc/squid'
'--localstatedir=/var/squid' '--datadir=/usr/share/squid'
'--enable-icap-client' '--enable-ssl' '--with-pthreads'
'--enable-pf-transparent' '--enable-ssl-crtd' '--enable-ecap'
'--with-openssl' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
--enable-ltdl-convenience


squid.conf

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged)
machines

acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/squid/cache/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/squid/cache/squid

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320

#http_port 3129 ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
https_port 3129 intercept ssl-bump cert=/usr/local/squid/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump bump all

# sslcrtd
sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/squid/ssl_db -M
10MB
sslcrtd_children 5

# sslproxy setting
sslproxy_capath /var/squid/ssl_db/certs
sslproxy_options NO_SSLv2,NO_SSLv3,NO_TLSv1,SINGLE_DH_USE,SINGLE_ECDH_USE
#sslproxy_cipher

Re: [squid-users] Squid with SSL-Bump on Debian testing: SSL_ERROR_RX_RECORD_TOO_LONG

[C. L. Martinez]

On Sat, Mar 04, 2017 at 04:21:19AM +0600, Yuri Voinov wrote:
> 
> 
> 04.03.2017 3:29, C. L. Martinez пишет:
> > Hi all,
> >
> >  After installing Squid 3.5.24 in my Debian testing (many thanks Amos for 
> > your help), I am trying to configure Squid as https intercept proxy. My 
> > config actually is:
> >
> > http_port 127.0.0.1:8080
> > http_port 127.0.0.1:8081 intercept
> > http_port 127.0.0.1:8082 ssl-bump cert=/opt/squid/etc/certs/myCA.pem 
> > generate-host-certificates=on \
> > dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
> > https_port 127.0.0.1:8083 ssl-bump intercept 
> > cert=/opt/squid/etc/certs/myCA.pem generate-host-certificates=on \
> > dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
> > sslcrtd_program /opt/squid/libexec/ssl_crtd -s /var/squid/ssldb -M 4MB
> >
> > # SSL-Bump
> > acl step1 at_step SslBump1
> > acl step2 at_step SslBump2
> > acl step3 at_step SslBump3
> > ssl_bump splice localhost
> > acl exclude_sites ssl::server_name_regex -i 
> > "/usr/local/etc/squid/doms.nobump"
> > ssl_bump peek step1 all
> > ssl_bump splice exclude_sites
> > ssl_bump stare step2 all
> > ssl_bump bump all
> >
> >  Content of "/usr/local/etc/squid/doms.nobump" is:
> >
> > update\.microsoft\.com$
> > update\.microsoft\.com\.akadns\.net$
> >
> >  But every time I have receiving Error code: SSL_ERROR_RX_RECORD_TOO_LONG 
> > in Firefox's browsers when I visit any web using https like 
> > https://www.debian.org, https://www.redhat.com, etc.. Some time ago, I have 
> > setup same config under OpenBSD and all works ok.
> >
> >  Where am I doing the mistake?
> Hardly this is mistake. Most probably this is platform-specific
> non-squid bug.
> -- 
> Bugs to the Future

Uhmm ... You are right Yuri. There is some problem with LibreSSL :( ... 
Generating certificate with Debian's openssl package works ok.

Many thanks Yuri.

-- 
Greetings,
C. L. Martinez
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid with SSL-Bump on Debian testing: SSL_ERROR_RX_RECORD_TOO_LONG

[Yuri Voinov]

04.03.2017 3:29, C. L. Martinez пишет:
> Hi all,
>
>  After installing Squid 3.5.24 in my Debian testing (many thanks Amos for 
> your help), I am trying to configure Squid as https intercept proxy. My 
> config actually is:
>
> http_port 127.0.0.1:8080
> http_port 127.0.0.1:8081 intercept
> http_port 127.0.0.1:8082 ssl-bump cert=/opt/squid/etc/certs/myCA.pem 
> generate-host-certificates=on \
>   dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
> https_port 127.0.0.1:8083 ssl-bump intercept 
> cert=/opt/squid/etc/certs/myCA.pem generate-host-certificates=on \
>   dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
> sslcrtd_program /opt/squid/libexec/ssl_crtd -s /var/squid/ssldb -M 4MB
>
> # SSL-Bump
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump splice localhost
> acl exclude_sites ssl::server_name_regex -i "/usr/local/etc/squid/doms.nobump"
> ssl_bump peek step1 all
> ssl_bump splice exclude_sites
> ssl_bump stare step2 all
> ssl_bump bump all
>
>  Content of "/usr/local/etc/squid/doms.nobump" is:
>
> update\.microsoft\.com$
> update\.microsoft\.com\.akadns\.net$
>
>  But every time I have receiving Error code: SSL_ERROR_RX_RECORD_TOO_LONG in 
> Firefox's browsers when I visit any web using https like 
> https://www.debian.org, https://www.redhat.com, etc.. Some time ago, I have 
> setup same config under OpenBSD and all works ok.
>
>  Where am I doing the mistake?
Hardly this is mistake. Most probably this is platform-specific
non-squid bug.
-- 
Bugs to the Future


0x613DEC46.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid with SSL-Bump on Debian testing: SSL_ERROR_RX_RECORD_TOO_LONG

[C. L. Martinez]

Hi all,

 After installing Squid 3.5.24 in my Debian testing (many thanks Amos for your 
help), I am trying to configure Squid as https intercept proxy. My config 
actually is:

http_port 127.0.0.1:8080
http_port 127.0.0.1:8081 intercept
http_port 127.0.0.1:8082 ssl-bump cert=/opt/squid/etc/certs/myCA.pem 
generate-host-certificates=on \
dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
https_port 127.0.0.1:8083 ssl-bump intercept cert=/opt/squid/etc/certs/myCA.pem 
generate-host-certificates=on \
dynamic_cert_mem_cache_size=4MB tls-dh=/opt/squid/etc/certs/dhparam.pem
sslcrtd_program /opt/squid/libexec/ssl_crtd -s /var/squid/ssldb -M 4MB

# SSL-Bump
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump splice localhost
acl exclude_sites ssl::server_name_regex -i "/usr/local/etc/squid/doms.nobump"
ssl_bump peek step1 all
ssl_bump splice exclude_sites
ssl_bump stare step2 all
ssl_bump bump all

 Content of "/usr/local/etc/squid/doms.nobump" is:

update\.microsoft\.com$
update\.microsoft\.com\.akadns\.net$

 But every time I have receiving Error code: SSL_ERROR_RX_RECORD_TOO_LONG in 
Firefox's browsers when I visit any web using https like 
https://www.debian.org, https://www.redhat.com, etc.. Some time ago, I have 
setup same config under OpenBSD and all works ok.

 Where am I doing the mistake?
-- 
Greetings,
C. L. Martinez
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid 3.5.24 - Ssl Bump tlsv1 alert unknown ca

[Test1964]

HI,

when using squid in transparent mode and try to access 
https://www.facebook.com from computer all working very well,
but when I try to use Facebook app (on Iphone for example), I'm getting 
this error in cache.log:


Error negotiating SSl connection on FD XX: error:14094418:SSL 
routines:SSL3_READ_BYTES:tlsv1 alert unknown ca (1/0)


and Facebook not working.

I run on Centos 7:

* run update-ca-trust
* yum update ca-certificates
* create the certificate like this:
openssl req -newkey rsa:4096 -sha512 -days 365 -nodes -x509 -keyout 
myCA.pem -out myCA.pem


Do I need to create the certificate for smartphones  different way?
Do I need to install more ca bundle in Centos?
How to fix this problem without white list this site from ssl bump


Thanks Dan

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

Re: [squid-users] Squid 3.5.21 ssl bump and x-forward

[FredB]

If really needed, there is a patch here 
http://bugs.squid-cache.org/show_bug.cgi?id=3792
But as Amos said this patch is incomplete the CONNECT XFF header contents 
should also be added to the bumped request

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

Re: [squid-users] Squid 3.5.21 ssl bump and x-forward

[FredB]

> 
> I have the same issue and racked my brain trying to find a solution.
> Now, I
> see there is no solution for this yet.
> 
> I would appreciate so much if this feature were made available in the
> future.
> 
> Eduardo Carneiro
> 
> 

Yes http://bugs.squid-cache.org/show_bug.cgi?id=4607
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.21 ssl bump and x-forward

[Eduardo Carneiro]

Amos Jeffries wrote
>>>
>> 
>> 
>> Ok thank you, there is a plan to add this ? Without identification we are
>> in the fog all bumped requests are only recorded with 127.0.0.1
>> 
> 
> Eventually, yes. I'm not aware of anyone actually working on it at
> present though.
> 
> Amos
> 
> ___
> squid-users mailing list

> squid-users@.squid-cache

> http://lists.squid-cache.org/listinfo/squid-users

I have the same issue and racked my brain trying to find a solution. Now, I
see there is no solution for this yet. 

I would appreciate so much if this feature were made available in the
future. 

Eduardo Carneiro




--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-3-5-21-ssl-bump-and-x-forward-tp4679521p4680697.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] Squid 3.5.21 ssl bump and x-forward

[Amos Jeffries]

On 15/09/2016 10:54 p.m., FredB wrote:
> 
>>
>> Above are bumped requests sent inside the tunnel. Proxy #1 did not
>> interact with them, so it has no way to add XFF headers.
>>
>> The SSL-Bump logic does not yet store some things like indirect
>> client
>> IP and associate them with the bumped requests.
>>
>> Amos
>>
> 
> 
> Ok thank you, there is a plan to add this ? Without identification we are in 
> the fog all bumped requests are only recorded with 127.0.0.1
> 

Eventually, yes. I'm not aware of anyone actually working on it at
present though.

Amos

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

Re: [squid-users] Squid 3.5.21 ssl bump and x-forward

[FredB]

> 
> Above are bumped requests sent inside the tunnel. Proxy #1 did not
> interact with them, so it has no way to add XFF headers.
> 
> The SSL-Bump logic does not yet store some things like indirect
> client
> IP and associate them with the bumped requests.
> 
> Amos
> 


Ok thank you, there is a plan to add this ? Without identification we are in 
the fog all bumped requests are only recorded with 127.0.0.1

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

Re: [squid-users] Squid 3.5.21 ssl bump and x-forward

[Amos Jeffries]

On 15/09/2016 8:53 p.m., FredB wrote:
> Hello,
> 
> I'm testing SSlBump and it works good, however I'm seeing something strange 
> with two proxies and x-forwarded enabled to the first, some requests are 
> wrote with the first proxy address. 
> 
> user -> squid (fowarded_for on) -> squid (follow_x_forwarded_for allow all) 
> -> Net 
> 
> Here log from the second squids, on same server, (same result when there are 
> separate 127.0.0.1 = IP FIRST SQUID) 
> 
> 10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "CONNECT 
> www.google.fr:443 HTTP/1.0" 200 0 440 TAG_NONE:HIER_NONE "Mozilla/5.0 
> (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0" 
> 10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "GET 
> http://www.google.fr/ HTTP/1.0" 302 643 1575 TCP_MISS:HIER_DIRECT 
> "Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0" 
> 10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "CONNECT 
> www.google.fr:443 HTTP/1.0" 200 0 440 TAG_NONE:HIER_NONE "Mozilla/5.0 
> (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0" 

Above are HTTP requests sent from proxy #1 to proxy #2.

> 127.0.0.1 - myaccount [15/Sep/2016:09:40:07 +0200] "POST 
> https://www.google.fr/gen_204?atyp=i=slh==EVDaV-rAOcS7adLmucAF=3=2=0.19272099408438004=4:1473925301533,e,U=1473925301536
>  HTTP/1.1" 204 401 1571 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
> rv:48.0) Gecko/20100101 Firefox/48.0" 
> 127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
> https://www.google.fr/?gws_rd=ssl HTTP/1.1" 200 61953 1387 
> TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 
> Firefox/48.0" 
> 127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "POST 
> https://www.google.fr/gen_204?atyp=i=slh==EVDaV-rAOcS7adLmucAF=4=2=0.19272099408438004=5:1473925302218,e,H=1473925302220
>  HTTP/1.1" 204 401 1571 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
> rv:48.0) Gecko/20100101 Firefox/48.0" 
> 127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
> https://www.google.fr/complete/search?sclient=psy-ab==hp==_l==1=on.2,or.r_cp.=1=995=554=1.25=p_rn=64_ri=psy-ab=yZHeL-_L5Be_JazeSm0Mtg=0_id=0=t=1=1=tVDaV7_DMsXqauCygeAF.1473925302436.1
>  HTTP/1.1" 200 913 1618 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
> rv:48.0) Gecko/20100101 Firefox/48.0" 
> 127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
> https://www.google.fr/gen_204?v=3=webhp=csi=tVDaV7_DMsXqauCygeAF=2=2=0==init.26.20.sb.18.p.3.jsa.1.abd.1.foot.1=0=xjsls.21,prt.41,iml.41,dcl.82,xjses.124,jraids.149,jraide.153,xjsee.185,xjs.185,ol.217,aft.41,wsrt.748,cst.1,dnst.0,rqst.522,rspt.533,rqstt.161,unt.143,cstt.144,dit.816
>  HTTP/1.1" 204 401 1616 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
> rv:48.0) Gecko/20100101 Firefox/48.0" 

Above are bumped requests sent inside the tunnel. Proxy #1 did not
interact with them, so it has no way to add XFF headers.

The SSL-Bump logic does not yet store some things like indirect client
IP and associate them with the bumped requests.

Amos

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

[squid-users] Squid 3.5.21 ssl bump and x-forward

[FredB]

Hello,

I'm testing SSlBump and it works good, however I'm seeing something strange 
with two proxies and x-forwarded enabled to the first, some requests are wrote 
with the first proxy address. 

user -> squid (fowarded_for on) -> squid (follow_x_forwarded_for allow all) -> 
Net 

Here log from the second squids, on same server, (same result when there are 
separate 127.0.0.1 = IP FIRST SQUID) 

10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "CONNECT www.google.fr:443 
HTTP/1.0" 200 0 440 TAG_NONE:HIER_NONE "Mozilla/5.0 (Windows NT 6.1; rv:48.0) 
Gecko/20100101 Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "GET http://www.google.fr/ 
HTTP/1.0" 302 643 1575 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:07 +0200] "CONNECT www.google.fr:443 
HTTP/1.0" 200 0 440 TAG_NONE:HIER_NONE "Mozilla/5.0 (Windows NT 6.1; rv:48.0) 
Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:07 +0200] "POST 
https://www.google.fr/gen_204?atyp=i=slh==EVDaV-rAOcS7adLmucAF=3=2=0.19272099408438004=4:1473925301533,e,U=1473925301536
 HTTP/1.1" 204 401 1571 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
https://www.google.fr/?gws_rd=ssl HTTP/1.1" 200 61953 1387 TCP_MISS:HIER_DIRECT 
"Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "POST 
https://www.google.fr/gen_204?atyp=i=slh==EVDaV-rAOcS7adLmucAF=4=2=0.19272099408438004=5:1473925302218,e,H=1473925302220
 HTTP/1.1" 204 401 1571 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
https://www.google.fr/complete/search?sclient=psy-ab==hp==_l==1=on.2,or.r_cp.=1=995=554=1.25=p_rn=64_ri=psy-ab=yZHeL-_L5Be_JazeSm0Mtg=0_id=0=t=1=1=tVDaV7_DMsXqauCygeAF.1473925302436.1
 HTTP/1.1" 200 913 1618 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "GET 
https://www.google.fr/gen_204?v=3=webhp=csi=tVDaV7_DMsXqauCygeAF=2=2=0==init.26.20.sb.18.p.3.jsa.1.abd.1.foot.1=0=xjsls.21,prt.41,iml.41,dcl.82,xjses.124,jraids.149,jraide.153,xjsee.185,xjs.185,ol.217,aft.41,wsrt.748,cst.1,dnst.0,rqst.522,rspt.533,rqstt.161,unt.143,cstt.144,dit.816
 HTTP/1.1" 204 401 1616 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:08 +0200] "CONNECT 
plus.google.com:443 HTTP/1.0" 200 0 446 TAG_NONE:HIER_NONE "Mozilla/5.0 
(Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:08 +0200] "POST 
https://plus.google.com/u/0/_/n/gcosuc HTTP/1.1" 200 862 1388 
TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 
Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:18 +0200] "CONNECT 
p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-i1-v6exp3-v4.metric.gstatic.com:443 
HTTP/1.0" 200 0 617 TAG_NONE:HIER_NONE "Mozilla/5.0 (Windows NT 6.1; rv:48.0) 
Gecko/20100101 Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:18 +0200] "CONNECT 
p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-i2-v6exp3-ds.metric.gstatic.com:443 
HTTP/1.0" 200 0 617 TAG_NONE:HIER_NONE "Mozilla/5.0 (Windows NT 6.1; rv:48.0) 
Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:18 +0200] "GET 
https://p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-i2-v6exp3-ds.metric.gstatic.com/v6exp3/6.gif
 HTTP/1.1" 200 1214 702 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:18 +0200] "GET 
https://p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-i1-v6exp3-v4.metric.gstatic.com/v6exp3/6.gif
 HTTP/1.1" 200 1214 702 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 
10.x.x.x.x - myaccount [15/Sep/2016:09:40:48 +0200] "CONNECT 
p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-s1-v6exp3-v4.metric.gstatic.com:443 
HTTP/1.0" 200 0 617 TAG_NONE:HIER_NONE "Mozilla/5.0 (Windows NT 6.1; rv:48.0) 
Gecko/20100101 Firefox/48.0" 
127.0.0.1 - myaccount [15/Sep/2016:09:40:48 +0200] "GET 
https://p5-d67enuz43bu7a-hck6hyjacaic2rnf-280807-s1-v6exp3-v4.metric.gstatic.com/gen_204?ipv6exp=3=1_img_dt=270_img_dt=253
 HTTP/1.1" 204 1393 601 TCP_MISS:HIER_DIRECT "Mozilla/5.0 (Windows NT 6.1; 
rv:48.0) Gecko/20100101 Firefox/48.0" 

Fred

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

Re: [squid-users] Squid Proxy SSL Bump Certificates

[Antony Stone]

On Thursday 30 June 2016 at 10:53:57, i...@comunicacionesman.com wrote:

> What I'm trying to do now is to use an external certificate from a
> trusted certificate authority (in this case I'm using a free SSL
> certificate from comodo), but I can't see my certificate in the
> certificates list when enabling SSL Man in the middle. I can only see
> CA's, which are certificate authorities, but when I upload comodo's Root
> CA certificate and select it, service does not start. Throws this error:
> 
> Jun 30 08:52:40   squid   No valid signing SSL certificate 
> configured
> for HTTP_port 192.168.1.1:3128
> 
> Does Squid not accept a SSL Certificate from external authorities or am
> I missing something?

Squid would be quite happy to accept a certificate from external authorities, 
but you will never get one.

You're missing the significance of the word "signing" in that error message.

What you have from Comodo is a signED certificate (and you also have the CA 
certificate to prove that they signed it).

What you do not have is a signING certificate (together with the accompanying 
private key) to be able to create and sign certificates on the fly, which is 
what Squid does for SSL MITM interception.

You will never get an appropriate key and certificate for this purpose from an 
external CA, because if they gave you those, you could forge certificates for 
any website on the Internet and their trust model would collapse.

SSL MITM has to be done with a self-signed certificate, and a self-generated CA 
certificate on the clients.


Antony.

-- 
Python is executable pseudocode.
Perl is executable line noise.

   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] Squid Proxy SSL Bump Certificates

[info]

Hi.

I've configured a firewall in our company with pfSense using Squid as 
proxy server. I made it work combined with Diladele to show graphs, 
filter logs, configure blocked sites, etc.


What I'm trying to do now is to use an external certificate from a 
trusted certificate authority (in this case I'm using a free SSL 
certificate from comodo), but I can't see my certificate in the 
certificates list when enabling SSL Man in the middle. I can only see 
CA's, which are certificate authorities, but when I upload comodo's Root 
CA certificate and select it, service does not start. Throws this error:


Jun 30 08:52:40	squid		No valid signing SSL certificate configured for 
HTTP_port 192.168.1.1:3128


Does Squid not accept a SSL Certificate from external authorities or am 
I missing something?


Thanks in advance.

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

Re: [squid-users] Squid 3.5.17 SSL-Bump Step1

[admin]

Thanks for answer, Alex! 

Alex Rousskov писал 2016-05-17 00:24:

> When access is prohibited via http_access deny, Squid needs to send an
> "Access Denied" error response to the user (this is how http_access
> works). To send that error to the user, Squid needs to establish a
> secure connection with the user (this is how HTTPS works). To do that,
> Squid has to use its own SSL certificate (this is how SSL works).
> 
> If you want to use a splice-or-terminate design, do not deny access via
> http_access. Limit yourself to "ssl_bump terminate" rules.

Is feature planned to squid gave when ERR_ACCESS_DENIED then terminate?

What are some other ways to deny HTTPS in intercept mode?___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.17 SSL-Bump Step1

[Alex Rousskov]

On 05/16/2016 04:47 AM, admin wrote:
>>> acl blocked_https ssl::server_name  "/etc/squid/urls/block-url"
>>> https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2
>>> connection-auth=off cert=/etc/squid/squidCA.pem
>>> acl step1 at_step SslBump1
>>> ssl_bump peek step1
>>> ssl_bump terminate blocked_https
>>>
>>> It works.

>> Obviously not. There is no instruction what to do other than terminate.
>> Squid is left to other circumstances to decide what is needed...

> it works! :) if you have the opportunity to check on the virtual machine

Your configuration works by accident. You should not expect it to work
across Squid upgrades, for example. It may continue to work or may stop
working. To fix the problem, be explicit regarding what to do when the
terminate rule does not match:

  ssl_bump peek step1
  ssl_bump terminate blocked_https
  ssl_bump splice all



> http_access deny users_no_inet

> Why, if access is
> allowed everything works, and if the ban on access to HTTP, you must
> first see a message stating that my certificate has not been able to
> match, and then later ERR_ACCESS_DENIED.


When access is allowed, Squid works as a TCP relay. Client bytes are
sent to the origin server. Server bytes are sent to the client. No
errors or certificates to worry about.

When access is prohibited via http_access deny, Squid needs to send an
"Access Denied" error response to the user (this is how http_access
works). To send that error to the user, Squid needs to establish a
secure connection with the user (this is how HTTPS works). To do that,
Squid has to use its own SSL certificate (this is how SSL works).


If you want to use a splice-or-terminate design, do not deny access via
http_access. Limit yourself to "ssl_bump terminate" rules.


HTH,

Alex.



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

Re: [squid-users] Squid 3.5.17 SSL-Bump Step1

[admin]

Amos Jeffries писал 2016-05-16 13:34:

> Please upgrade to 3.5.19.

Upgrade to 3.5.19

>> acl blocked_https ssl::server_name  "/etc/squid/urls/block-url"
>> https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2
>> connection-auth=off cert=/etc/squid/squidCA.pem
>> acl step1 at_step SslBump1
>> ssl_bump peek step1
>> ssl_bump terminate blocked_https
>> 
>> It works.
> 
> Obviously not. There is no instruction what to do other than terminate.
> Squid is left to other circumstances to decide what is needed...

it works! :) if you have the opportunity to check on the virtual machine

>> But if I use
>> 
>> acl users_no_inet src "/etc/squid/ip-groups/no-inet"
>> http_access deny users_no_inet
> 
> ... you force bumping to happen in order to deliver the HTTP error message.
> 
> Try adding this rule above the peek (and the ACL line too):
> ssl_bump terminate users_no_inet

trying, no success :(

I just do not understand the reason for such behavior. Why, if access is
allowed everything works, and if the ban on access to HTTP, you must
first see a message stating that my certificate has not been able to
match, and then later ERR_ACCESS_DENIED. Sorry for my English___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.17 SSL-Bump Step1

[Amos Jeffries]

On 16/05/2016 5:48 p.m., admin wrote:
> Hi!
> 
> Squid 3.5.17 with SSL, intercept.

Please upgrade to 3.5.19.

> 
> I use SSL-Bump only step1 that get SNI and terminate HTTPS sites by
> domain name. The certificate's is not replaced !

The certificate is never replaced. Though if you dont know how TLS works
and look at it only from the client perspective it can appear to be so.
The reality is you either have one TLS connection or two with different
certificates on each.

> 
> acl blocked_https ssl::server_name  "/etc/squid/urls/block-url"
> https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2
> connection-auth=off cert=/etc/squid/squidCA.pem
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump terminate blocked_https
> 
> It works.

Obviously not. There is no instruction what to do other than terminate.
Squid is left to other circumstances to decide what is needed...

> 
> But if I use
> 
> acl users_no_inet src "/etc/squid/ip-groups/no-inet"
> http_access deny users_no_inet

... you force bumping to happen in order to deliver the HTTP error message.

Try adding this rule above the peek (and the ACL line too):
  ssl_bump terminate users_no_inet


> 
> I see NET::ERR_CERT_AUTHORITY_INVALID in browser. I import my squid
> cert, but I see NET::ERR_CERT_COMMON_NAME_INVALID
> 
> Why in this case, the squid trying to replace the certificate?

There is no server connection or certificate in existence. So nothing
exists to be replaced.

What you are seeing is Squid using its own certificate to get a TLS
connection it can deliver the HTTP error message through.


Amos

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

[squid-users] Squid 3.5.17 SSL-Bump Step1

[admin]

Hi!

Squid 3.5.17 with SSL, intercept.

I use SSL-Bump only step1 that get SNI and terminate HTTPS sites by 
domain name. The certificate's is not replaced !


acl blocked_https ssl::server_name  "/etc/squid/urls/block-url"
https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 
connection-auth=off cert=/etc/squid/squidCA.pem

acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate blocked_https

It works.

But if I use

acl users_no_inet src "/etc/squid/ip-groups/no-inet"
http_access deny users_no_inet

I see NET::ERR_CERT_AUTHORITY_INVALID in browser. I import my squid 
cert, but I see NET::ERR_CERT_COMMON_NAME_INVALID


Why in this case, the squid trying to replace the certificate?

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

[squid-users] squid 3.4.8 ssl-bump resolve ip in access.log

[LANGLOIS Nicolas]

Hi,  i'm trying to set up squid 3.4.8 on debian , i want a full transparent 
proxy, no conf on client side .
it's working actually but i 'm ask to report websites access but for https 
actually i just get  this kind of line in my access.log :
< TCP_MISS/200 288 CONNECT 64.233.184.106:443 - ORIGINAL_DST/64.233.184.106 <

Is there a way to have dns resolution  and log the website visited  for https ?

Here is a part of my squid.conf :

http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem
http_port 192.168.1.1:3129 intercept
https_port 192.168.1.1:3130 intercept ssl-bump  generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem

ssl_bump none all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
always_direct allow all

or is there a magical solution for transparent proxy  with no client-side 
(certs or proxy conf) config working actually with https ?

Regards

Nicolas

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

Re: [squid-users] squid 3.4.8 ssl-bump resolve ip in access.log

[Amos Jeffries]

On 2/12/2015 12:40 a.m., LANGLOIS Nicolas wrote:
> Hi,  i'm trying to set up squid 3.4.8 on debian , i want a full transparent 
> proxy, no conf on client side .

That is not what "fully transparent" means.

The best form of transparent proxy is when clients are auto-configured
with explicit-proxy settings.


Also be aware that the Debian versions which are shipping Squid-3.4.8
have some mystery issue in their kernels that nobody has yet been able
to track down that prevents the TPROXY feature from operating properly.
You will have to stick with NAT or upgrade to one of the Debian versions
shipping Squid-3.5, their kernels seem to work better.


> it's working actually but i 'm ask to report websites access but for https 
> actually i just get  this kind of line in my access.log :
> < TCP_MISS/200 288 CONNECT 64.233.184.106:443 - ORIGINAL_DST/64.233.184.106 <
> 
> Is there a way to have dns resolution  and log the website visited  for https 
> ?

What for? all it does is reduce accuracy of the log.
You can end up with situations where the log says:
 "CONNECT 64.233.184.106:443 - ORIGINAL_DST/example.com"

But when log analysis runs example.com has moved its IP, or just DNS has
cycled on to another one of the set. So analysis then reports the client
requested URL "64.233.184.106:443" when connecting to a server whose IP
is now 192.0.2.1. Which is plain wrong.


> 
> Here is a part of my squid.conf :
> 
> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem
> http_port 192.168.1.1:3129 intercept
> https_port 192.168.1.1:3130 intercept ssl-bump  generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem
> 
> ssl_bump none all
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER
> always_direct allow all

So basically; Intercept TLS (supposed to be secure). Ignore all possible
errors, malicious attacks, diversions or hijacking that might be done by
anyone else on the way to the real server. BUT tell the client
everything is safe to send or fetch that sensitive data they needed TLS for?

You are SO lucky you started that "ssl_bump none all" actually means
dont perform SSL-bump interception. It is preventing a world of FAIL
from landing on your head.

The other three lines should be erased immediately.

> 
> or is there a magical solution for transparent proxy  with no client-side 
> (certs or proxy conf) config working actually with https ?

Firstly, Be aware that SSL-Bump is involved in an arms race. If you are
doing bumping always use the latest Squid. The 3.4 series is outdated by
a year. Things have already moved on well past its capabilities.


Secondly, after upgrade to Squid-3.5 use "splice all" where you have
placed "none all" right now and what you request will 'just work'. You
can then peek/stare at unencrypted the SNI and cert details to log where
clients are going and/or block certain servers being contacted.

The assumption with SSL-Bump is that you are doing so in order to
actually bump at least some of the traffic. There is very little point
in diverting port 443 to Squid only to do nothing at all with it. All
that does is slow the already heavyweight HTTPS protocol down. It is the
bumping action that requires the client setup.

Amos

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

Re: [squid-users] squid 3.4.8 ssl-bump resolve ip in access.log

[LANGLOIS Nicolas]

Thanks Amos for the quick reply,  
I 'm making lot of mistake around  ssl with squid, i 'm following your advice 
and try to setup with with last squid 3.5 version using tproxy  will let you 
know . 

Have a good day 

Nicolas

-Message d'origine-
De : squid-users [mailto:squid-users-boun...@lists.squid-cache.org] De la part 
de Amos Jeffries
Envoyé : mardi 1 décembre 2015 13:18
À : squid-users@lists.squid-cache.org
Objet : Re: [squid-users] squid 3.4.8 ssl-bump resolve ip in access.log

On 2/12/2015 12:40 a.m., LANGLOIS Nicolas wrote:
> Hi,  i'm trying to set up squid 3.4.8 on debian , i want a full transparent 
> proxy, no conf on client side .

That is not what "fully transparent" means.

The best form of transparent proxy is when clients are auto-configured with 
explicit-proxy settings.


Also be aware that the Debian versions which are shipping Squid-3.4.8 have some 
mystery issue in their kernels that nobody has yet been able to track down that 
prevents the TPROXY feature from operating properly.
You will have to stick with NAT or upgrade to one of the Debian versions 
shipping Squid-3.5, their kernels seem to work better.


> it's working actually but i 'm ask to report websites access but for https 
> actually i just get  this kind of line in my access.log :
> < TCP_MISS/200 288 CONNECT 64.233.184.106:443 - 
> ORIGINAL_DST/64.233.184.106 <
> 
> Is there a way to have dns resolution  and log the website visited  for https 
> ?

What for? all it does is reduce accuracy of the log.
You can end up with situations where the log says:
 "CONNECT 64.233.184.106:443 - ORIGINAL_DST/example.com"

But when log analysis runs example.com has moved its IP, or just DNS has cycled 
on to another one of the set. So analysis then reports the client requested URL 
"64.233.184.106:443" when connecting to a server whose IP is now 192.0.2.1. 
Which is plain wrong.


> 
> Here is a part of my squid.conf :
> 
> http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem
> http_port 192.168.1.1:3129 intercept
> https_port 192.168.1.1:3130 intercept ssl-bump  
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
> cert=/etc/squid3/ssl_cert/squid.pem
> 
> ssl_bump none all
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER
> always_direct allow all

So basically; Intercept TLS (supposed to be secure). Ignore all possible 
errors, malicious attacks, diversions or hijacking that might be done by anyone 
else on the way to the real server. BUT tell the client everything is safe to 
send or fetch that sensitive data they needed TLS for?

You are SO lucky you started that "ssl_bump none all" actually means dont 
perform SSL-bump interception. It is preventing a world of FAIL from landing on 
your head.

The other three lines should be erased immediately.

> 
> or is there a magical solution for transparent proxy  with no client-side 
> (certs or proxy conf) config working actually with https ?

Firstly, Be aware that SSL-Bump is involved in an arms race. If you are doing 
bumping always use the latest Squid. The 3.4 series is outdated by a year. 
Things have already moved on well past its capabilities.


Secondly, after upgrade to Squid-3.5 use "splice all" where you have placed 
"none all" right now and what you request will 'just work'. You can then 
peek/stare at unencrypted the SNI and cert details to log where clients are 
going and/or block certain servers being contacted.

The assumption with SSL-Bump is that you are doing so in order to actually bump 
at least some of the traffic. There is very little point in diverting port 443 
to Squid only to do nothing at all with it. All that does is slow the already 
heavyweight HTTPS protocol down. It is the bumping action that requires the 
client setup.

Amos

___
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] Squid 3.5.10 SSL Bump whitelist domains issue

[Amos Jeffries]

On 22/10/2015 7:31 a.m., luizcasey wrote:
> 
> 
> Hello, So what I am trying to accomplish here is to basically have a
> whitelist of domains that is allowed via http/https.

What you have actually configured is a whitelist with MUCH narrower
criteria than that.


> If the UID is
> squid,apache, or root then basically you will bypass squid and anything
> is allowed.

Ok. That is iptables/ip6tables. Not Squid related.

> This was working well on 3.4.2 however once I moved to
> 3.5.10 it no longer works properly. I also noticed that there are “new”
> features peek,slice etc which is probably my issue since I was not using
> it. I have tried several combination and have only gotten it to work for
> http traffic. All https traffic is currently being blocked by the
> configuration. Below are my configurations. I don’t need to "inspect"
> any of the traffic just want to have a whitelist of allowed domains if
> you are not UID squid,apache, or root via http/https. Any help would be
> appreciated !!

I'm not sure how you define "inspect" exactly. But the config implies
that your Squid actually does need to do TLS inspection.


> # IPTABLES
> $iptables -L -t nat
> Chain PREROUTING (policy ACCEPT)
> target prot opt source   destination
> 
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source   destination
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> natoutlogaccept  tcp  --  anywhere anywheremultiport 
> dports http,https owner UID match squid
> natoutlogaccept  tcp  --  anywhere anywheremultiport 
> dports http,https owner UID match apache
> natoutlogaccept  tcp  --  anywhere anywheremultiport 
> dports http,https owner UID match root
> REDIRECT   tcp  --  anywhere anywheretcp dpt:http 
> redir ports 3401

Note that 3401 is the SNMP protocol port.

> REDIRECT   tcp  --  anywhere anywheretcp dpt:https 
> redir ports 4827
> 
> Chain natoutlogaccept (3 references)
> target prot opt source   destination
> LOGall  --  anywhere anywhereLOG level debug 
> prefix `nat out iptables accept '
> ACCEPT all  --  anywhere anywhere
> 
> 
> # Squid.conf
> 
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER

Like Yuri said the above line(s) are bad. Very bad.
They are instructing Squid not to verify the TLS to upstream servers are
secure. That allows any MITM upstream to be done on them without any
type of warning or alerts. Not only that but Squid will relay valid TLS
security to the clients, so they believe everything is just fine when in
fact they could be badly hijacked.


> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
> sslcrtd_children 50
> 
> https_port 4827 intercept ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.aarp.org.crt 
> key=/etc/squid/certs/squid.key
> # HTTPS forward port
> https_port 127.0.0.1:6887 cert=/etc/squid/certs/squid.crt 
> key=/etc/squid/certs/squid.key
> 
> http_port 3401 transparent
> # HTTP forward port
> http_port 127.0.0.1:6886
> 
> logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs % access_log /var/log/squid/access.log squid
> 
> always_direct allow all

The always_direct hack from Squid-3.1 bumping is no longer useful.

> cache deny all
> cache_dir ufs /home/squid/cache 100 16 256
> 
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> acl nobumpSites ssl::server_name "/etc/squid/allowed_domains/allowed_domains"
> 
> ssl_bump peek step1 all
> ssl_bump splice nobumpSites
> ssl_bump bump
> 
> acl http proto http
> acl https proto https
> 
> acl port_80 port 80
> acl port_443 port 443
> 
> http_access allow http port_80 nobumpSites
> http_access allow https port_443 nobumpSites

I think the problem here is that you are requiring the "http://; and
"https://; scheme be part of the URLs.

Your description of the whitelist did not mention any such criteria.

Squid-3.5 uses CONNECT requests (where the URL has *no* scheme segment)
to represent the initial TCP SYN connection happening before the HTTPS
stream starts. Your whitelist rules here will reject those because they
lack the https:// scheme portion. And thus reject all HTTPS traffic.


> 
> http_access deny all
> 
> # allowed_domains
> .cnn.com 
> .google.com 
> .facebook.com 
> ….etc 
> 
>  squid log
> TAG_NONE/403 350 HEAD https://www.facebook.com/  - 
> HIER_NONE/- text/html
> TCP_MISS/200 593 GET http://www.cnn.com/ 

I'm not sure why you are displaying these log lines. Everything appears
to be fine for them.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
BTW - you omit many important settings from squid.conf.default. You
configuration is so dangerous.

22.10.15 20:01, luizca...@gmail.com пишет:
> Here is the config I am currently using based on your suggestion earlier. 
> However it does not
start. I have also added some questions to each for verification
purposes to make sure I am understanding what is actually going on.
>
> https_port 4827 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.crt
key=/etc/squid/certs/squid.key
> http_port 3401 intercept
>
> logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs % access_log /var/log/squid/access.log squid
>
> cache deny all < — No caching.
>
> acl step1 at_step SslBump1 <— What is this doing ??
> acl whitelist_ssl ssl::server_name
"/etc/squid/git_allowed_domains/allowed_domains” <— Create whitelist for
SSL
>
> ssl_bump peek step1   <— Try to find server_name ?
> ssl_bump splice whitelist_ssl <— Ignore whitlist_ssl domains and let
it through
> ssl_bump bump net_bump <— ??? This I don’t get since there is no
net_bump acl ? Should this just be all ?
> ssl_bump splice all <— Splice everything else that couldn’t be bumped ??
>
> acl http proto http  <— Allow http photo
> acl whitelist dstdomain
"/etc/squid/git_allowed_domains/allowed_domains” <— Create whitelist for
http
>
> acl https proto https  <— Allow https
> acl port_80 port 80  <— Allow port 80. Is this redundant ??
> acl port_443 port 443 < — Allow port 443. Is this redundant ??
>
> http_access allow http port_80 whitelist<— Allow whitelisted
domains on port 80
> http_access allow https port_443 whitelist_ssl <— Allow whitelisted
domains on 443
>
> http_access deny al <— Deny all
>
>
> ###LOGS
>
> 2015/10/22 09:41:10| Processing: access_log /var/log/squid/access.log
squid
> 2015/10/22 09:41:10| Processing: cache deny all
> 2015/10/22 09:41:10| Processing: acl step1 at_step SslBump1
> 2015/10/22 09:41:10| Processing: acl whitelist_ssl ssl::server_name
"/etc/squid/git_allowed_domains/allowed_domains"
> 2015/10/22 09:41:10| Processing: ssl_bump peek step1
> 2015/10/22 09:41:10| Processing: ssl_bump splice whitelist_ssl
> 2015/10/22 09:41:10| Processing: ssl_bump bump net_bump <——— I
assume again this is because no all for net_bump.
> 2015/10/22 09:41:10| ACL not found: net_bump
> FATAL: Bungled /etc/squid/squid.conf line 22: ssl_bump bump net_bump
> Squid Cache (Version 3.5.10): Terminated abnormally.
> CPU Usage: 0.012 seconds = 0.003 user + 0.009 sys
> Maximum Resident Size: 26208 KB
> Page faults with physical i/o: 0
>
>
> If I change "ssl_bump bump net_bump" to "ssl_bump bump all” It starts
up but it still fails to allow any https through even those on the
whitelist_ssl file but allows http to those domains. Not sure what I am
doing wrong here.
>
>
>> On Oct 21, 2015, at 8:16 PM, luizca...@gmail.com wrote:
>>
>> Alex,
>> So what do you recommend to do here ? I just need a simple whitelist
file for both http/https. I have a config that works on 3.4 but would
like to upgrade to 3.5 and the current config we have won't cut it. Just
need a simple if you are in this list allow if not deny. No need for any
ssl validation or anything.
>>
>>> On Oct 21, 2015, at 6:49 PM, Alex Rousskov
 wrote:
>>>
 On 10/21/2015 02:49 PM, Yuri Voinov wrote:

 Working config snippet for 3.5.x looks like this:

 ssl_bump peek get_sni_at_step1
 ssl_bump splice spliced_hosts
 ssl_bump bump net_bump
>>>
>>>
>>> The above config leaves the following question unanswered:
>>>
>>> Q: What happens if neither spliced_hosts nor net_bump match at bumping
>>> step #2?
>>>
>>>
>>> Leaving questions unanswered is a bad idea for ssl_bump rules because
>>> defaults are complex (and used to be broken). To answer that question
>>> (instead of forcing Squid to guess the answer), add a forth catch-all
>>> rule. For example, this is how the latest Squids would guess:
>>>
>>> ssl_bump peek step1
>>> ssl_bump splice spliced_hosts
>>> ssl_bump bump net_bump
>>> ssl_bump splice all
>>>
>>>
>>> If spliced_hosts ACL negation works reliably, then the above is
>>> equivalent to:
>>>
>>> ssl_bump peek step1
>>> ssl_bump bump !spliced_hosts net_bump
>>> ssl_bump splice all
>>>
>>> but I recommend avoiding ACL negation in the actual rules.
>>>
>>>
>>> Finally, please make sure your http_access rules correctly handle
>>> CONNECT requests (real for forwarded connections and fake ones for
>>> intercepted connections). This may be difficult to do right now due to
>>> bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340
>>>
>>>
>>> HTH,
>>>
>>> Alex.
>>> P.S. I renamed get_sni_at_step1 to step1 in the above examples because
>>> that ACL itself does not know anything about SNI and does not force
>>> Squid to get SNI.
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> 

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Amos Jeffries]

On 23/10/2015 3:01 a.m., luizca...@gmail.com wrote:
> Here is the config I am currently using based on your suggestion earlier. 
> However it does not start. I have also added some questions to each for 
> verification purposes to make sure I am understanding what is actually going 
> on.
> 
> https_port 4827 intercept ssl-bump generate-host-certificates=on 
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.crt 
> key=/etc/squid/certs/squid.key
> http_port 3401 intercept
> 
> logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs % access_log /var/log/squid/access.log squid
> 
> cache deny all < — No caching.

Prevent things being stored in Squid's cache is what that does, yes.

> 
> acl step1 at_step SslBump1 <— What is this doing ??

Creating an ACL which will only match during SSL-Bump operations at step 1.

> acl whitelist_ssl ssl::server_name 
> "/etc/squid/git_allowed_domains/allowed_domains” <— Create whitelist for SSL 

Sort of yes, sort of no.

This is creating an ACL which will match if some domain name(s) are used
in CONNECT authority-URI (at SSL-Bump step 1 or 2), TLS SNI values (at
SSL-Bump step 2), or X.509 certificate SubjectAltName field (at SSL-Bump
step 3).


> 
> ssl_bump peek step1   <— Try to find server_name ?

Try to find client handshake details. One of those is the SNI which is
often the best available datum on what domain the client is trying to
connect to.

This will always match at step 1. So peek is aways done to find SNI,
NPN, ALPN etc.


> ssl_bump splice whitelist_ssl <— Ignore whitlist_ssl domains and let it 
> through

At step 2 attempt to match the whitelist ACL against the details we have
for server domain names. SNI if known, otherwise the CONNECT requests
authority-URI.

At step 3 (because this is checked at both step 2 and 3). Attempt to
match the whitelist ACL against the X.509 certificate SubjectAltName
details.


> ssl_bump bump net_bump <— ??? This I don’t get since there is no net_bump acl 
> ? Should this just be all ?
> ssl_bump splice all <— Splice everything else that couldn’t be bumped ??
> 

What is supposed to happen if the whitelist does not match ?
Take your policy requirement and make Squid do it.



> acl http proto http  <— Allow http photo

No. Create an ACL which matches when URL scheme is "http://;


> acl whitelist dstdomain "/etc/squid/git_allowed_domains/allowed_domains” <— 
> Create whitelist for http

Yes.


> 
> acl https proto https  <— Allow https 

No. Create an ACL which matches when URL scheme is "https://;


> acl port_80 port 80  <— Allow port 80. Is this redundant ??

No. Create an ACL which matches when URL port is 80.


> acl port_443 port 443 < — Allow port 443. Is this redundant ??

No. Create an ACL which matches when URL port is 443.


> 
> http_access allow http port_80 whitelist<— Allow whitelisted domains on 
> port 80 

No. Allows requests where there is a URL scheme http:// AND going to
port 80 AND on the whitelist.

> http_access allow https port_443 whitelist_ssl <— Allow whitelisted domains 
> on 443
> 

No. Allows requests where there is a URL scheme https:// AND going to
port 443 AND on the whitelist.

NP: HTTPS requests arrive as CONNECT mesage to URL with no scheme, and
going to port 443. May be a hostname not on the whitelist. For
intercepted traffic this request message will always have a raw-IP
instead of a hostname or domain name.


> http_access deny al <— Deny all 

No. deny whatever "al" matches.

Then the default action of allowing everything else.

> 
> 
> ###LOGS
> 
> 2015/10/22 09:41:10| Processing: access_log /var/log/squid/access.log squid
> 2015/10/22 09:41:10| Processing: cache deny all
> 2015/10/22 09:41:10| Processing: acl step1 at_step SslBump1
> 2015/10/22 09:41:10| Processing: acl whitelist_ssl ssl::server_name 
> "/etc/squid/git_allowed_domains/allowed_domains"
> 2015/10/22 09:41:10| Processing: ssl_bump peek step1
> 2015/10/22 09:41:10| Processing: ssl_bump splice whitelist_ssl
> 2015/10/22 09:41:10| Processing: ssl_bump bump net_bump <——— I assume 
> again this is because no all for net_bump.

Don't assume. Squid tells you what is wrong:

> 2015/10/22 09:41:10| ACL not found: net_bump
> FATAL: Bungled /etc/squid/squid.conf line 22: ssl_bump bump net_bump

... and what is being done about it:

> Squid Cache (Version 3.5.10): Terminated abnormally.
> CPU Usage: 0.012 seconds = 0.003 user + 0.009 sys
> Maximum Resident Size: 26208 KB
> Page faults with physical i/o: 0
> 
> 
> If I change "ssl_bump bump net_bump" to "ssl_bump bump all” It starts up but 
> it still fails to allow any https through even those on the whitelist_ssl 
> file but allows http to those domains. Not sure what I am doing wrong here.
> 

That is because the traffic is mostly intercepted and those
fake/synthetic CONNECT requests have "CONNECT IP:port HTTP/1.1".

raw-IPs are not in your whitelist. Your http_access rules do not permit
non-whitelisted URI to be serviced. Thus they are rejected before
bumping even 

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[luizcasey]

Here is the config I am currently using based on your suggestion earlier. 
However it does not start. I have also added some questions to each for 
verification purposes to make sure I am understanding what is actually going on.

https_port 4827 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.crt 
key=/etc/squid/certs/squid.key
http_port 3401 intercept

logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs % On Oct 21, 2015, at 8:16 PM, luizca...@gmail.com wrote:
> 
> Alex,
> So what do you recommend to do here ? I just need a simple whitelist file for 
> both http/https. I have a config that works on 3.4 but would like to upgrade 
> to 3.5 and the current config we have won't cut it. Just need a simple if you 
> are in this list allow if not deny. No need for any ssl validation or 
> anything.
> 
>> On Oct 21, 2015, at 6:49 PM, Alex Rousskov 
>>  wrote:
>> 
>>> On 10/21/2015 02:49 PM, Yuri Voinov wrote:
>>> 
>>> Working config snippet for 3.5.x looks like this:
>>> 
>>> ssl_bump peek get_sni_at_step1
>>> ssl_bump splice spliced_hosts
>>> ssl_bump bump net_bump
>> 
>> 
>> The above config leaves the following question unanswered:
>> 
>> Q: What happens if neither spliced_hosts nor net_bump match at bumping
>> step #2?
>> 
>> 
>> Leaving questions unanswered is a bad idea for ssl_bump rules because
>> defaults are complex (and used to be broken). To answer that question
>> (instead of forcing Squid to guess the answer), add a forth catch-all
>> rule. For example, this is how the latest Squids would guess:
>> 
>> ssl_bump peek step1
>> ssl_bump splice spliced_hosts
>> ssl_bump bump net_bump
>> ssl_bump splice all
>> 
>> 
>> If spliced_hosts ACL negation works reliably, then the above is
>> equivalent to:
>> 
>> ssl_bump peek step1
>> ssl_bump bump !spliced_hosts net_bump
>> ssl_bump splice all
>> 
>> but I recommend avoiding ACL negation in the actual rules.
>> 
>> 
>> Finally, please make sure your http_access rules correctly handle
>> CONNECT requests (real for forwarded connections and fake ones for
>> intercepted connections). This may be difficult to do right now due to
>> bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340
>> 
>> 
>> HTH,
>> 
>> Alex.
>> P.S. I renamed get_sni_at_step1 to step1 in the above examples because
>> that ACL itself does not know anything about SNI and does not force
>> Squid to get SNI.

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains issue

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
First, you should put in order configurations.

22.10.15 0:31, luizca...@gmail.com пишет:
> Hello, 
> So what I am trying to accomplish here is to basically have a
whitelist of domains that is allowed via http/https. If the UID is
squid,apache, or root then basically you will bypass squid and anything
is allowed. This was working well on 3.4.2 however once I moved to
3.5.10 it no longer works properly. I also noticed that there are “new”
features peek,slice etc which is probably my issue since I was not using
it. I have tried several combination and have only gotten it to work for
http traffic. All https traffic is currently being blocked by the
configuration. Below are my configurations.  I don’t need to "inspect"
any of the traffic just want to have a whitelist of allowed domains if
you are not UID squid,apache, or root via http/https. Any help would be
appreciated !!
>
>
> # Squid.conf
>
> sslproxy_cert_error allow all
This setting is DANGER. Don't use it in production. Completely.
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
>
> sslproxy_flags DONT_VERIFY_PEER
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
> sslcrtd_children 50
>
> https_port 4827 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.aarp.org.crt
key=/etc/squid/certs/squid.key
> # HTTPS forward port
> https_port 127.0.0.1:6887 cert=/etc/squid/certs/squid.crt
key=/etc/squid/certs/squid.key
HTTPS forward port: this is SSL Bumped port, or what? Where, in this
case, ssl-bump directive? On the other hand, you don't need use cert/key
for tunneling connections. This is enabled by default long, long time.
>
>
> http_port 3401 transparent
Here must be "intercept" against transparent.
>
>
> always_direct allow all
^^It's too much.
>
> cache deny all
You really sure you want completely disable all caching?
>
> cache_dir ufs /home/squid/cache 100 16 256
Why, in this case, you define on-disk cache?
>
>
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
This is completely unnecessary. You don't use it below.
>
>
> acl http proto http
> acl https proto https
Why is it here?
>
>
> acl port_80 port 80
> acl port_443 port 443
Why is it here?
>
>
> http_access allow http port_80 nobumpSites
> http_access allow https port_443 nobumpSites
Why is it here?
>
>
> http_access deny all
>
> # allowed_domains
> .cnn.com 
> .google.com 
> .facebook.com 
> ….etc
ACL and, more, access rules order is important. As by as in firewalls.
What do you mean with "allowed_domains" and why it here?
>
>
>  squid log
> TAG_NONE/403 350 HEAD https://www.facebook.com/
 - HIER_NONE/- text/html
> TCP_MISS/200 593 GET http://www.cnn.com/ 
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJWJ+CYAAoJENNXIZxhPexGZFEIAMBVhb1S3qScrRDYobIF3F85
qwslUiWPNW+D6KB3nqPmI7/mcBttn0Oi3kEJhymXPVIU/uBy6JkubT/HvfGL/w5U
BU6aA/6B+vm3HZ2PQ8jU7pZ5SwoswUkWXCZsapMypCEtUKswS7ohboBo0Rfga3Gg
ABg34HuGoCHVjoKCfFQwz1lmKY64VcCbjuMY+CpzGcR5bmyRuaWhAIcQLePsQFbV
MR4KfHP/5aSaDBR8zbsm74+RG4wyodA4WGQfNlBTY/bcH3RKeIX7e3b5oZeBRYhL
67NYBSFXtqaJsNZfUJwcWl6ZsnqQRtk/US2iO7DOCLVm1kXTjaaJWTB659xv+8M=
=Q/qX
-END PGP SIGNATURE-

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Show as access.log/cache.log for denied HTTPS sites.

All others confir quirks will remain onto your responsibility - Amos
come and explain when I/you wrong. ;)

22.10.15 1:52, luizca...@gmail.com пишет:
> I answered your questions below. However https traffic is still always being 
> denied even though
the site is on the allowed_list via nobumpSites.
> I want to control http/https traffic using the “allowed_domains” list.
This current configuration works for HTTP but not HTTPS traffic.
>
> If there is an easier way to do this I am open for suggestion. This
configuration minus the peek/splice part works fine in 3.4.2. Not sure
what changed in
> 3.5 that causes this to fail.
>
>
>> Date: Thu, 22 Oct 2015 00:59:36 +0600
>> From: Yuri Voinov <yvoi...@gmail.com>
>> To: squid-users@lists.squid-cache.org
>> Subject: Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains
>> issue
>> Message-ID: <5627e098.1000...@gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
> First, you should put in order configurations.
>
> 22.10.15 0:31, luizca...@gmail.com пишет:
> >>> Hello,
> >>> So what I am trying to accomplish here is to basically have a
> whitelist of domains that is allowed via http/https. If the UID is
> squid,apache, or root then basically you will bypass squid and anything
> is allowed. This was working well on 3.4.2 however once I moved to
> 3.5.10 it no longer works properly. I also noticed that there are “new”
> features peek,slice etc which is probably my issue since I was not using
> it. I have tried several combination and have only gotten it to work for
> http traffic. All https traffic is currently being blocked by the
> configuration. Below are my configurations.  I don’t need to "inspect"
> any of the traffic just want to have a whitelist of allowed domains if
> you are not UID squid,apache, or root via http/https. Any help would be
> appreciated !!
> >>>
> >>>
> >>> # Squid.conf
> >>>
> >>> sslproxy_cert_error allow all
> This setting is DANGER. Don't use it in production. Completely.
> http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
> >>>
> >>> sslproxy_flags DONT_VERIFY_PEER
> >>> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
> >>> sslcrtd_children 50
> >>>
> >>> https_port 4827 intercept ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.aarp.org.crt
> key=/etc/squid/certs/squid.key
> >>> # HTTPS forward port
> >>> https_port 127.0.0.1:6887 cert=/etc/squid/certs/squid.crt
> key=/etc/squid/certs/squid.key
> HTTPS forward port: this is SSL Bumped port, or what? Where, in this
> case, ssl-bump directive? On the other hand, you don't need use cert/key
> for tunneling connections. This is enabled by default long, long time.
> >>>
> >>>
> >>> http_port 3401 transparent
> Here must be "intercept" against transparent.
> >>>
> >>>
> >>> always_direct allow all
> ^^It's too much.
> >>>
> >>> cache deny all
> You really sure you want completely disable all caching?
> >>>
> >>> cache_dir ufs /home/squid/cache 100 16 256
> Why, in this case, you define on-disk cache?
> > Removed
> >>>
> >>>
> >>> acl step2 at_step SslBump2
> >>> acl step3 at_step SslBump3
> This is completely unnecessary. You don't use it below.
> > Removed
> >>>
> >>>
> >>> acl http proto http
> >>> acl https proto https
> Why is it here?
> > To only allow http and https proto
> >>>
> >>>
> >>> acl port_80 port 80
> >>> acl port_443 port 443
> Why is it here?
> > To only allow port 80 and 443
> >>>
> >>>
> >>> http_access allow http port_80 nobumpSites
> >>> http_access allow https port_443 nobumpSites
> Why is it here?
> > To only allow access to nobumpSites on port 80 and 443
> >>>
> >>>
> >>> http_access deny all
> >>>
> >>> # allowed_domains
> >>> .cnn.com <http://cnn.com/>
> >>> .google.com <http://google.com/>
> >>> .facebook.com <http://facebook.com/>
> >>> ….etc
> ACL and, more, access rules order is important. As by as in firewalls.
> What do you mean with "allowed_

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Show piece of

allowed_domains

file.

22.10.15 2:29, luizca...@gmail.com пишет:
> Could you suggest a configuration that you think should be working ? I would 
> like both
HTTP/HTTPS domains whitelisted via file all other domains blocked. What
am I missing ? My assumption here is the acl nobumpSites
ssl::server_name "/etc/squid/git_allowed_domains/allowed_domains” part
is not working for https but does work for http.
>
>  LOG
> 21/Oct/2015:16:24:45 -0400.062 28 X.X.X.X TCP_MISS/200 907 HEAD
http://www.cnn.com/ - ORIGINAL_DST/23.235.39.73 text/html
> 21/Oct/2015:16:25:12 -0400.515  0 X.X.X.X TAG_NONE/403 350 HEAD
https://www.facebook.com/ - HIER_NONE/- text/html
>
>  etc/squid/git_allowed_domains/allowed_domains"
> .facebook.com
> .cnn.com
>
>  Squid.con
> sslproxy_flags DONT_VERIFY_PEER
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
> sslcrtd_children 50
>
> https_port 4827 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.crt
key=/etc/squid/certs/squid.key
> http_port 3401 intercept
>
> logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs % access_log /var/log/squid/access.log squid
>
> cache deny all
>
> acl step1 at_step SslBump1
> acl nobumpSites ssl::server_name
"/etc/squid/git_allowed_domains/allowed_domains”
> # I even tried the follow just for https test and it still failed
> # acl nobumpSites ssl::server_name  .facebook.com
> # 21/Oct/2015:16:27:45 -0400.733  0 10.159.3.194 TAG_NONE/403 350
HEAD https://www.facebook.com/ - HIER_NONE/- text/html
>
> ssl_bump peek step1 all
> ssl_bump splice nobumpSites
> ssl_bump bump
>
> acl http proto http
> acl https proto https
> acl port_80 port 80
> acl port_443 port 443
>
> http_access allow http port_80 nobumpSites
> http_access allow https port_443 nobumpSites
>
> http_access deny all
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJWJ/ZVAAoJENNXIZxhPexGI/8H/0vLr5F4ejnNmJ55oUeGb2wv
YIs/gIW73DEdcTidPYSPWnfz25VQ5rStfejrkWWoPDdHTQNwUWi8vd45TptxFXtK
3r6xnL9+f+2JLMXjrRB8buQW7i3B8xmvWHniMzMh9EWwicGJIPRzowz8ijaIyoYx
ZpEh00NBLlHBJhu9EP81TVJauwqexbeRjjOmR8VLp7rEoeuWYXvR7D7Pcs5eNrKT
XnzwNKI6ZWRYSq9rfRObMRL5EIkbXqAcvh6+2KaYYUFVy87zm5bojrJqgbM6NGXS
7AwydX4ef5jRsvmt9lgYZJ/fjdggRxUsN+EvdccvhYQrD/6Coec/H1L84MKLfqY=
=2y9A
-END PGP SIGNATURE-

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[luizcasey]

I answered your questions below. However https traffic is still always being 
denied even though the site is on the allowed_list via nobumpSites.
I want to control http/https traffic using the “allowed_domains” list. This 
current configuration works for HTTP but not HTTPS traffic.

If there is an easier way to do this I am open for suggestion. This 
configuration minus the peek/splice part works fine in 3.4.2. Not sure what 
changed in
3.5 that causes this to fail.


> Date: Thu, 22 Oct 2015 00:59:36 +0600
> From: Yuri Voinov <yvoi...@gmail.com>
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains
>   issue
> Message-ID: <5627e098.1000...@gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> First, you should put in order configurations.
> 
> 22.10.15 0:31, luizca...@gmail.com пишет:
>> Hello, 
>> So what I am trying to accomplish here is to basically have a
> whitelist of domains that is allowed via http/https. If the UID is
> squid,apache, or root then basically you will bypass squid and anything
> is allowed. This was working well on 3.4.2 however once I moved to
> 3.5.10 it no longer works properly. I also noticed that there are “new”
> features peek,slice etc which is probably my issue since I was not using
> it. I have tried several combination and have only gotten it to work for
> http traffic. All https traffic is currently being blocked by the
> configuration. Below are my configurations.  I don’t need to "inspect"
> any of the traffic just want to have a whitelist of allowed domains if
> you are not UID squid,apache, or root via http/https. Any help would be
> appreciated !!
>> 
>> 
>> # Squid.conf
>> 
>> sslproxy_cert_error allow all
> This setting is DANGER. Don't use it in production. Completely.
> http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
>> 
>> sslproxy_flags DONT_VERIFY_PEER
>> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
>> sslcrtd_children 50
>> 
>> https_port 4827 intercept ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.aarp.org.crt
> key=/etc/squid/certs/squid.key
>> # HTTPS forward port
>> https_port 127.0.0.1:6887 cert=/etc/squid/certs/squid.crt
> key=/etc/squid/certs/squid.key
> HTTPS forward port: this is SSL Bumped port, or what? Where, in this
> case, ssl-bump directive? On the other hand, you don't need use cert/key
> for tunneling connections. This is enabled by default long, long time.
>> 
>> 
>> http_port 3401 transparent
> Here must be "intercept" against transparent.
>> 
>> 
>> always_direct allow all
> ^^It's too much.
>> 
>> cache deny all
> You really sure you want completely disable all caching?
>> 
>> cache_dir ufs /home/squid/cache 100 16 256
> Why, in this case, you define on-disk cache?
Removed
>> 
>> 
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
> This is completely unnecessary. You don't use it below.
Removed
>> 
>> 
>> acl http proto http
>> acl https proto https
> Why is it here?
To only allow http and https proto 
>> 
>> 
>> acl port_80 port 80
>> acl port_443 port 443
> Why is it here?
To only allow port 80 and 443 
>> 
>> 
>> http_access allow http port_80 nobumpSites
>> http_access allow https port_443 nobumpSites
> Why is it here?
To only allow access to nobumpSites on port 80 and 443 
>> 
>> 
>> http_access deny all
>> 
>> # allowed_domains
>> .cnn.com <http://cnn.com/>
>> .google.com <http://google.com/>
>> .facebook.com <http://facebook.com/>
>> ….etc
> ACL and, more, access rules order is important. As by as in firewalls.
> What do you mean with "allowed_domains" and why it here?
>> 
>> 
>>  squid log
>> TAG_NONE/403 350 HEAD https://www.facebook.com/
> <https://www.facebook.com/> - HIER_NONE/- text/html
>> TCP_MISS/200 593 GET http://www.cnn.com/ <http://www.cnn.com/>
>> 
>> 
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJWJ+CYAAoJENNXIZxhPexGZFEIAMBVhb1S3qScrRDYobIF3F85
> qwslUiWPNW+D6KB3nqPmI7/mcBttn0Oi3kEJhymXPVIU/uBy6JkubT/HvfGL/w5U
> BU6aA/6B+vm3HZ2PQ8jU7pZ5SwoswUkWXCZsapMypCEtUKswS7ohboBo0Rfga3Gg
> ABg34HuGoCHVjoKCfFQwz1lmKY64VcCbjuMY+CpzGcR5bmyRuaWhAIcQLePsQFbV
> MR4KfHP/5aSaDBR8zbsm74+RG4wyodA4WGQfNlBTY/bcH3RKeIX7e3b5oZeBRYhL
> 67NYBSFXtqaJsNZfUJwcWl6ZsnqQRtk/US2iO7DOCLVm1kXTjaaJWTB659xv+8M=
> =Q/qX
> -END PGP SIGNATURE-

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[luizcasey]

Could you suggest a configuration that you think should be working ? I would 
like both HTTP/HTTPS domains whitelisted via file all other domains blocked. 
What am I missing ? My assumption here is the acl nobumpSites ssl::server_name 
"/etc/squid/git_allowed_domains/allowed_domains” part is not working for https 
but does work for http.

 LOG
21/Oct/2015:16:24:45 -0400.062 28 X.X.X.X TCP_MISS/200 907 HEAD 
http://www.cnn.com/ - ORIGINAL_DST/23.235.39.73 text/html
21/Oct/2015:16:25:12 -0400.515  0 X.X.X.X TAG_NONE/403 350 HEAD 
https://www.facebook.com/ - HIER_NONE/- text/html

 etc/squid/git_allowed_domains/allowed_domains"
.facebook.com
.cnn.com

 Squid.con
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
sslcrtd_children 50

https_port 4827 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.crt 
key=/etc/squid/certs/squid.key
http_port 3401 intercept

logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs %https://www.facebook.com/ - HIER_NONE/- text/html

ssl_bump peek step1 all
ssl_bump splice nobumpSites
ssl_bump bump

acl http proto http
acl https proto https
acl port_80 port 80
acl port_443 port 443

http_access allow http port_80 nobumpSites
http_access allow https port_443 nobumpSites

http_access deny all

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[luizcasey]

There really isn’t anything in there right now since I am testing.

 /etc/squid/git_allowed_domains/allowed_domains"
.facebook.com
.cnn.com
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Working config snippet for 3.5.x looks like this:

acl get_sni_at_step1 at_step SslBump1
ssl_bump peek get_sni_at_step1
acl spliced_hosts ssl::server_name_regex -i
"/usr/local/squid/etc/url.nobump"
ssl_bump splice spliced_hosts
ssl_bump bump net_bump

and url.nobump contains:

# Mozilla services
services\.mozilla\.com

etc.


22.10.15 2:45, luizca...@gmail.com пишет:
> There really isn’t anything in there right now since I am testing.
>
>  /etc/squid/git_allowed_domains/allowed_domains"
> .facebook.com
> .cnn.com
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJWJ/pIAAoJENNXIZxhPexGknYH/2n7kI2rzHZraQ37nHxToAtE
ErNF5PIQv+zCifDcwZDx65uNMqBPDLdZLNsu4N39e5MR1M1Lqfc57akq1WCJbCSA
i1OGb58sI0g2E8lJhqvEIoyyl9KMGIuYzQBr21q7s7Kvs+uAC51OPmowFZt60LJ6
FnmYAfCqdwb95q+rMkcVIDVN0wo5aCO7ZE31ePu3PbpL5JqV1Zx3kjDG57E+H+HT
wRBZyNrRl8Vw8fbGrfm6kKccdy5hlHEcr7VQaOsi4vy6rDJdLTW55yynMHou3KNX
GM7Lm97NMR8+zJZRAXaeR5Nu9Mvzyr64IxER5x9Ozkzk8hHo4ULkki03FA69OJI=
=DcQ4
-END PGP SIGNATURE-

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

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[Alex Rousskov]

On 10/21/2015 02:49 PM, Yuri Voinov wrote:

> Working config snippet for 3.5.x looks like this:
> 
> ssl_bump peek get_sni_at_step1
> ssl_bump splice spliced_hosts
> ssl_bump bump net_bump


The above config leaves the following question unanswered:

Q: What happens if neither spliced_hosts nor net_bump match at bumping
step #2?


Leaving questions unanswered is a bad idea for ssl_bump rules because
defaults are complex (and used to be broken). To answer that question
(instead of forcing Squid to guess the answer), add a forth catch-all
rule. For example, this is how the latest Squids would guess:

  ssl_bump peek step1
  ssl_bump splice spliced_hosts
  ssl_bump bump net_bump
  ssl_bump splice all


If spliced_hosts ACL negation works reliably, then the above is
equivalent to:

  ssl_bump peek step1
  ssl_bump bump !spliced_hosts net_bump
  ssl_bump splice all

but I recommend avoiding ACL negation in the actual rules.


Finally, please make sure your http_access rules correctly handle
CONNECT requests (real for forwarded connections and fake ones for
intercepted connections). This may be difficult to do right now due to
bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340


HTH,

Alex.
P.S. I renamed get_sni_at_step1 to step1 in the above examples because
that ACL itself does not know anything about SNI and does not force
Squid to get SNI.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid 3.5.10 SSL Bump whitelist domains issue

[luizcasey]

Hello, 
So what I am trying to accomplish here is to basically have a whitelist of 
domains that is allowed via http/https. If the UID is squid,apache, or root 
then basically you will bypass squid and anything is allowed. This was working 
well on 3.4.2 however once I moved to 3.5.10 it no longer works properly. I 
also noticed that there are “new” features peek,slice etc which is probably my 
issue since I was not using it. I have tried several combination and have only 
gotten it to work for http traffic. All https traffic is currently being 
blocked by the configuration. Below are my configurations.  I don’t need to 
"inspect" any of the traffic just want to have a whitelist of allowed domains 
if you are not UID squid,apache, or root via http/https. Any help would be 
appreciated !!


# IPTABLES
$iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
natoutlogaccept  tcp  --  anywhere anywheremultiport 
dports http,https owner UID match squid
natoutlogaccept  tcp  --  anywhere anywheremultiport 
dports http,https owner UID match apache
natoutlogaccept  tcp  --  anywhere anywheremultiport 
dports http,https owner UID match root
REDIRECT   tcp  --  anywhere anywheretcp dpt:http redir 
ports 3401
REDIRECT   tcp  --  anywhere anywheretcp dpt:https 
redir ports 4827

Chain natoutlogaccept (3 references)
target prot opt source   destination
LOGall  --  anywhere anywhereLOG level debug 
prefix `nat out iptables accept '
ACCEPT all  --  anywhere anywhere


# Squid.conf

sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /home/squid/ssl_db -M 4MB
sslcrtd_children 50

https_port 4827 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/certs/squid.aarp.org.crt 
key=/etc/squid/certs/squid.key
# HTTPS forward port
https_port 127.0.0.1:6887 cert=/etc/squid/certs/squid.crt 
key=/etc/squid/certs/squid.key

http_port 3401 transparent
# HTTP forward port
http_port 127.0.0.1:6886

logformat squid %tl.%03tu %6tr %>a %Ss/%03Hs %http://cnn.com/>
.google.com 
.facebook.com 
….etc 

 squid log
TAG_NONE/403 350 HEAD https://www.facebook.com/  - 
HIER_NONE/- text/html
TCP_MISS/200 593 GET http://www.cnn.com/ ___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.10 SSL Bump whitelist domains

[luizcasey]

Alex,
So what do you recommend to do here ? I just need a simple whitelist file for 
both http/https. I have a config that works on 3.4 but would like to upgrade to 
3.5 and the current config we have won't cut it. Just need a simple if you are 
in this list allow if not deny. No need for any ssl validation or anything.

> On Oct 21, 2015, at 6:49 PM, Alex Rousskov  
> wrote:
> 
>> On 10/21/2015 02:49 PM, Yuri Voinov wrote:
>> 
>> Working config snippet for 3.5.x looks like this:
>> 
>> ssl_bump peek get_sni_at_step1
>> ssl_bump splice spliced_hosts
>> ssl_bump bump net_bump
> 
> 
> The above config leaves the following question unanswered:
> 
> Q: What happens if neither spliced_hosts nor net_bump match at bumping
> step #2?
> 
> 
> Leaving questions unanswered is a bad idea for ssl_bump rules because
> defaults are complex (and used to be broken). To answer that question
> (instead of forcing Squid to guess the answer), add a forth catch-all
> rule. For example, this is how the latest Squids would guess:
> 
>  ssl_bump peek step1
>  ssl_bump splice spliced_hosts
>  ssl_bump bump net_bump
>  ssl_bump splice all
> 
> 
> If spliced_hosts ACL negation works reliably, then the above is
> equivalent to:
> 
>  ssl_bump peek step1
>  ssl_bump bump !spliced_hosts net_bump
>  ssl_bump splice all
> 
> but I recommend avoiding ACL negation in the actual rules.
> 
> 
> Finally, please make sure your http_access rules correctly handle
> CONNECT requests (real for forwarded connections and fake ones for
> intercepted connections). This may be difficult to do right now due to
> bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340
> 
> 
> HTH,
> 
> Alex.
> P.S. I renamed get_sni_at_step1 to step1 in the above examples because
> that ACL itself does not know anything about SNI and does not force
> Squid to get SNI.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3 SSL bump: Google drive application could not connect

[Chris Bennett]

Hi Jason,

 If you think the external acl method is too expensive to run, how do you
 expect to feed this NIDS data back into squid? I think you'd find you'd
 need an external acl check to do that bit anyway :-)

I should have been clearer - my use of the term feedback loop was
meant to imply that this was an out-of-band method of populating a
cache of valid HTTPS IP addresses (as well as the any SNI and even
'Application name') for HTTPS, and observed non-HTTPS traffic over 443
and any other ports.  This may compliment any active external acl
style checking.

Was just thinking out loud - probably a crazy idea if every seriously
considered :)

Regards,

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

Re: [squid-users] Squid 3 SSL bump: Google drive application could not connect

[Jason Haar]

On 08/01/15 18:41, Chris Bennett wrote:
 Interesting thread so far.  Has anyone thought of using Bro-IDS as a
 feedback loop for some of this advanced logic for bypassing bumping?

The external acl method mentioned earlier probably out-does using some
NIDS feedback loop. In my testing it causes squid to block that new
connection until it returns, and that means your external acl script can
simply attempt a SSL transaction against the end-server and in realtime
figure out that it's SSL or not. And then cache it, blah, blah blah.

The advantage is that it will do a lookup on new HTTPS sessions and
potentially have the answer immediately (ie it can bump on first
attempt), whereas a NIDS would only find out the answer after squid has
defaulted to passthrough/splice mode, so it would only work properly on
future connections to that site.

 I like the active external acl solution since it meets a need, but
 there is overhead.  I'm not quite sure what Bro logs for non-HTTPS
 443 traffic, but I thought I'd chime in with the above idea if anyone
 wants to expand on it further :)

If you think the external acl method is too expensive to run, how do you
expect to feed this NIDS data back into squid? I think you'd find you'd
need an external acl check to do that bit anyway :-)

-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

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