Working peek/splice no longer functioning on some sites

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Working peek/splice no longer functioning on some sites

James Lay
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup:

acl localnet src 192.168.1.0/24
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt"

http_access deny !Safe_ports
http_access deny CONNECT !SSL_Ports
http_access allow SSL_ports
http_access allow allowed_http_sites
http_access deny all


ssl_bump peek all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

sslproxy_cert_error allow all
sslproxy_capath /etc/ssl/certs
sslproxy_flags DONT_VERIFY_PEER 
#sslproxy_options ALL

sslcrtd_program /opt/libexec/ssl_crtd -s /opt/var/ssl_db -M 4MB
sslcrtd_children 5

http_port 3128 intercept
https_port 3129 intercept ssl-bump cert=/opt/etc/squid/certs/sslsplit_ca_cert.pem cafile=/opt/etc/squid/certs/sslsplit_ca_cert.pem key=/opt/etc/squid/certs/sslsplit_ca_key.pem  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB sslflags=NO_SESSION_REUSE


logformat mine %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %ssl::>sni %ssl::>cert_subject %>Hs %<st %Ss:%Sh 

access_log syslog:daemon.info mine 

refresh_pattern -i (cgi-bin|\?) 0 0% 0
refresh_pattern . 0 20% 4320

coredump_dir /opt/var 

For example, the file http_url.txt contains:

account\.elderscrollsonline\.com
\.elderscrollsonline\.com
elderscrollsonline\.com


After doing some reading it looks like this is http2 traffic:  https://wiki.squid-cache.org/Features/HTTP2.

Is there anything I can do to continue using squid with more and more sites using http2?  Pcap enclosed..thank you.

James

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

error.pcap (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

James Lay
I should add this is squid-3.5.27.  Thank you.

On Fri, 2017-11-24 at 12:30 -0700, James wrote:
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup:

acl localnet src 192.168.1.0/24
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt"

http_access deny !Safe_ports
http_access deny CONNECT !SSL_Ports
http_access allow SSL_ports
http_access allow allowed_http_sites
http_access deny all


ssl_bump peek all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

sslproxy_cert_error allow all
sslproxy_capath /etc/ssl/certs
sslproxy_flags DONT_VERIFY_PEER 
#sslproxy_options ALL

sslcrtd_program /opt/libexec/ssl_crtd -s /opt/var/ssl_db -M 4MB
sslcrtd_children 5

http_port 3128 intercept
https_port 3129 intercept ssl-bump cert=/opt/etc/squid/certs/sslsplit_ca_cert.pem cafile=/opt/etc/squid/certs/sslsplit_ca_cert.pem key=/opt/etc/squid/certs/sslsplit_ca_key.pem  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB sslflags=NO_SESSION_REUSE


logformat mine %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %ssl::>sni %ssl::>cert_subject %>Hs %<st %Ss:%Sh 

access_log syslog:daemon.info mine 

refresh_pattern -i (cgi-bin|\?) 0 0% 0
refresh_pattern . 0 20% 4320

coredump_dir /opt/var 

For example, the file http_url.txt contains:

account\.elderscrollsonline\.com
\.elderscrollsonline\.com
elderscrollsonline\.com


After doing some reading it looks like this is http2 traffic:  https://wiki.squid-cache.org/Features/HTTP2.

Is there anything I can do to continue using squid with more and more sites using http2?  Pcap enclosed..thank you.

James
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Amos Jeffries
Administrator
In reply to this post by James Lay
On 25/11/17 08:30, James Lay wrote:

> Topic says it...this setup has been working well for a long time, but
> now there are some sites that are failing the TLS handshake.  Here's my
> setup:
>
> acl localnet src 192.168.1.0/24
> acl SSL_ports port 443
> acl Safe_ports port 80
> acl Safe_ports port 443
> acl CONNECT method CONNECT
> acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt"
>
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_Ports
> http_access allow SSL_ports
> http_access allow allowed_http_sites
> http_access deny all
>
>
> ssl_bump peek all
> acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
> ssl_bump splice allowed_https_sites
> ssl_bump terminate all


Because you have "peek all" being performed the transaction MUST pass
your regex patterns with both TLS SNI from the client *and* the server
certificate SubjectName values. Either one not matching will perform
that "terminate all" on the TLS handshake.


>
> sslproxy_cert_error allow all
> sslproxy_capath /etc/ssl/certs
> sslproxy_flags DONT_VERIFY_PEER
> #sslproxy_options ALL


Also, please remove these "*_error allow all" and DONT_VERIFY_PEER lines
from your config. They are actively harmful.

>
> sslcrtd_program /opt/libexec/ssl_crtd -s /opt/var/ssl_db -M 4MB
> sslcrtd_children 5
>
> http_port 3128 intercept
> https_port 3129 intercept ssl-bump
> cert=/opt/etc/squid/certs/sslsplit_ca_cert.pem
> cafile=/opt/etc/squid/certs/sslsplit_ca_cert.pem
> key=/opt/etc/squid/certs/sslsplit_ca_key.pem

NP: when cert= and key= are in the same file you do not need to specify
key=.

> generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB sslflags=NO_SESSION_REUSE
>

It is also best to add "sslflags=NO_DEFAULT_CA" to these ports for
Squid-3. That will save a lot of useless memory overheads.


>
> logformat mine %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %ssl::>sni
> %ssl::>cert_subject %>Hs %<st %Ss:%Sh
>
...

> For example, the file http_url.txt contains:
>
> account\.elderscrollsonline\.com
> \.elderscrollsonline\.com
> elderscrollsonline\.com
>
>
> After doing some reading it looks like this is http2 traffic:
> https://wiki.squid-cache.org/Features/HTTP2.
>

There is no sign of HTTP/2 in that PCAP trace. There is SPDY/3 and
HTTP/1.1 being offered by the client.


If that is from the client to Squid, then please check the matching
Squid->server for what is going on there.



If the problem remains please try Squid-4. It has more advanced TLS
capabilities than Squid-3.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

James Lay
On Sat, 2017-11-25 at 23:48 +1300, Amos Jeffries wrote:
On 25/11/17 08:30, James Lay wrote:
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup: acl localnet src 192.168.1.0/24 acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt" http_access deny !Safe_ports http_access deny CONNECT !SSL_Ports http_access allow SSL_ports http_access allow allowed_http_sites http_access deny all ssl_bump peek all acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt" ssl_bump splice allowed_https_sites ssl_bump terminate all
Because you have "peek all" being performed the transaction MUST pass your regex patterns with both TLS SNI from the client *and* the server certificate SubjectName values. Either one not matching will perform that "terminate all" on the TLS handshake.

Thanks Amos...do you have a suggestion for changing this to match one or the other instead of both?

James

sslproxy_cert_error allow all sslproxy_capath /etc/ssl/certs sslproxy_flags DONT_VERIFY_PEER #sslproxy_options ALL
Also, please remove these "*_error allow all" and DONT_VERIFY_PEER lines from your config. They are actively harmful.
sslcrtd_program /opt/libexec/ssl_crtd -s /opt/var/ssl_db -M 4MB sslcrtd_children 5 http_port 3128 intercept https_port 3129 intercept ssl-bump cert=/opt/etc/squid/certs/sslsplit_ca_cert.pem cafile=/opt/etc/squid/certs/sslsplit_ca_cert.pem key=/opt/etc/squid/certs/sslsplit_ca_key.pem
NP: when cert= and key= are in the same file you do not need to specify key=.
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB sslflags=NO_SESSION_REUSE
It is also best to add "sslflags=NO_DEFAULT_CA" to these ports for Squid-3. That will save a lot of useless memory overheads.
logformat mine %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %ssl::>sni %ssl::>cert_subject %>Hs %<st %Ss:%Sh
...
For example, the file http_url.txt contains: account\.elderscrollsonline\.com \.elderscrollsonline\.com elderscrollsonline\.com After doing some reading it looks like this is http2 traffic: https://wiki.squid-cache.org/Features/HTTP2.
There is no sign of HTTP/2 in that PCAP trace. There is SPDY/3 and HTTP/1.1 being offered by the client. If that is from the client to Squid, then please check the matching Squid->server for what is going on there. If the problem remains please try Squid-4. It has more advanced TLS capabilities than Squid-3. Amos _______________________________________________ squid-users mailing list [hidden email] http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Amos Jeffries
Administrator
On 26/11/17 00:52, James Lay wrote:

> On Sat, 2017-11-25 at 23:48 +1300, Amos Jeffries wrote:
>> On 25/11/17 08:30, James Lay wrote:
>>> Topic says it...this setup has been working well for a long time, but
>>> now there are some sites that are failing the TLS handshake.  Here's
>>> my setup: acl localnet src 192.168.1.0/24 acl SSL_ports port 443 acl
>>> Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT
>>> acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt"
>>> http_access deny !Safe_ports http_access deny CONNECT !SSL_Ports
>>> http_access allow SSL_ports http_access allow allowed_http_sites
>>> http_access deny all ssl_bump peek all acl allowed_https_sites
>>> ssl::server_name_regex "/opt/etc/squid/http_url.txt" ssl_bump splice
>>> allowed_https_sites ssl_bump terminate all
>>
>>
>>
>> Because you have "peek all" being performed the transaction MUST pass
>> your regex patterns with both TLS SNI from the client *and* the server
>> certificate SubjectName values. Either one not matching will perform
>> that "terminate all" on the TLS handshake.
>>
>
> Thanks Amos...do you have a suggestion for changing this to match one or
> the other instead of both?

Doing the splice check before the peek should do that. First one of the
server_names data sources to match will then splice and non-matches fall
through to either peek or terminate if no more peeking possible.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

James Lay
On Sun, 2017-11-26 at 01:33 +1300, Amos Jeffries wrote:
On 26/11/17 00:52, James Lay wrote:
On Sat, 2017-11-25 at 23:48 +1300, Amos Jeffries wrote:
On 25/11/17 08:30, James Lay wrote:
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup: acl localnet src 192.168.1.0/24 acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt" http_access deny !Safe_ports http_access deny CONNECT !SSL_Ports http_access allow SSL_ports http_access allow allowed_http_sites http_access deny all ssl_bump peek all acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt" ssl_bump splice allowed_https_sites ssl_bump terminate all
Because you have "peek all" being performed the transaction MUST pass your regex patterns with both TLS SNI from the client *and* the server certificate SubjectName values. Either one not matching will perform that "terminate all" on the TLS handshake.
Thanks Amos...do you have a suggestion for changing this to match one or the other instead of both?
Doing the splice check before the peek should do that. First one of the server_names data sources to match will then splice and non-matches fall through to either peek or terminate if no more peeking possible. Amos

Perfect..I've modded my lines with:

acl broken_https_sites ssl::server_name_regex "/opt/etc/squid/broken_url.txt"
ssl_bump splice broken_https_sites
ssl_bump peek all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

Hopefully that fixes these up.  Another site besides the the one this thread is fbcdn.net.  Again, these DID work, but something within the last month has changed...guessing Facebook and Elder Scrolls Online have added additional TLS security.  Thanks as always Amos.

James

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Alex K
Perhaps an alternative is to peek only on step1:

acl step1 at_step SslBump1

ssl_bump peek step1
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

On Nov 25, 2017 14:46, "James Lay" <[hidden email]> wrote:
On Sun, 2017-11-26 at 01:33 +1300, Amos Jeffries wrote:
On 26/11/17 00:52, James Lay wrote:
On Sat, 2017-11-25 at 23:48 +1300, Amos Jeffries wrote:
On 25/11/17 08:30, James Lay wrote:
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup: acl localnet src 192.168.1.0/24 acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt" http_access deny !Safe_ports http_access deny CONNECT !SSL_Ports http_access allow SSL_ports http_access allow allowed_http_sites http_access deny all ssl_bump peek all acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt" ssl_bump splice allowed_https_sites ssl_bump terminate all
Because you have "peek all" being performed the transaction MUST pass your regex patterns with both TLS SNI from the client *and* the server certificate SubjectName values. Either one not matching will perform that "terminate all" on the TLS handshake.
Thanks Amos...do you have a suggestion for changing this to match one or the other instead of both?
Doing the splice check before the peek should do that. First one of the server_names data sources to match will then splice and non-matches fall through to either peek or terminate if no more peeking possible. Amos

Perfect..I've modded my lines with:

acl broken_https_sites ssl::server_name_regex "/opt/etc/squid/broken_url.txt"
ssl_bump splice broken_https_sites
ssl_bump peek all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

Hopefully that fixes these up.  Another site besides the the one this thread is fbcdn.net.  Again, these DID work, but something within the last month has changed...guessing Facebook and Elder Scrolls Online have added additional TLS security.  Thanks as always Amos.

James

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

James Lay
On Sun, 2017-11-26 at 09:50 +0200, Alex K wrote:
Perhaps an alternative is to peek only on step1:

acl step1 at_step SslBump1

ssl_bump peek step1
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

Hrmm...wouldn't that negate the ability to read the cert on step2?

In layman's terms I'm thinking:
"peek at step1"
"splice acl allow matched sni's"
"peek at step2"
"splice acl allow'd matched certs"
"terminate the rest"

Would that work Amos?


On Nov 25, 2017 14:46,
"James Lay" <[hidden email]> wrote:
On Sun, 2017-11-26 at 01:33 +1300, Amos Jeffries wrote:
On 26/11/17 00:52, James Lay wrote:
On Sat, 2017-11-25 at 23:48 +1300, Amos Jeffries wrote:
On 25/11/17 08:30, James Lay wrote:
Topic says it...this setup has been working well for a long time, but now there are some sites that are failing the TLS handshake.  Here's my setup: acl localnet src 192.168.1.0/24 acl SSL_ports port 443 acl Safe_ports port 80 acl Safe_ports port 443 acl CONNECT method CONNECT acl allowed_http_sites url_regex "/opt/etc/squid/http_url.txt" http_access deny !Safe_ports http_access deny CONNECT !SSL_Ports http_access allow SSL_ports http_access allow allowed_http_sites http_access deny all ssl_bump peek all acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt" ssl_bump splice allowed_https_sites ssl_bump terminate all
Because you have "peek all" being performed the transaction MUST pass your regex patterns with both TLS SNI from the client *and* the server certificate SubjectName values. Either one not matching will perform that "terminate all" on the TLS handshake.
Thanks Amos...do you have a suggestion for changing this to match one or the other instead of both?
Doing the splice check before the peek should do that. First one of the server_names data sources to match will then splice and non-matches fall through to either peek or terminate if no more peeking possible. Amos

Perfect..I've modded my lines with:

acl broken_https_sites ssl::server_name_regex "/opt/etc/squid/broken_url.txt"
ssl_bump splice broken_https_sites
ssl_bump peek all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

Hopefully that fixes these up.  Another site besides the the one this thread is fbcdn.net.  Again, these DID work, but something within the last month has changed...guessing Facebook and Elder Scrolls Online have added additional TLS security.  Thanks as always Amos.

James

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Amos Jeffries
Administrator
On 28/11/17 03:50, James Lay wrote:

> On Sun, 2017-11-26 at 09:50 +0200, Alex K wrote:
>> Perhaps an alternative is to peek only on step1:
>>
>> acl step1 at_step SslBump1
>>
>> ssl_bump peek step1
>> acl allowed_https_sites ssl::server_name_regex
>> "/opt/etc/squid/http_url.txt"
>> ssl_bump splice allowed_https_sites
>> ssl_bump terminate all
>
> Hrmm...wouldn't that negate the ability to read the cert on step2?
>

Yes it would.

> In layman's terms I'm thinking:
> "peek at step1"
> "splice acl allow matched sni's"
> "peek at step2"
> "splice acl allow'd matched certs"
> "terminate the rest"
>
> Would that work Amos?
>

This is essentially what I suggested at the beginning.

Placing splice action and your ACLs on the first ssl_bump line ensures
that at each step if enough details are known to splice it will happen.

The second line being "peek all" make peek happen at every step for
which it is possible (step 1 and step 2 - not step 3).

"terminate all" being last makes it happen for "all the rest", aka step
3 if Squid gets that far without splicing.


The only difference is that my suggested way would also allow splicing
the CONNECT if it happens to be presented with a host name in the
authority-URI. Which cannot happen on your proxy unless your port 3128
happens to be intercepting traffic between clients and another proxy.


BTW please do not use port 3128 for intercept. It is officially
registered for HTTP proxy traffic and so qualifies as "well known".

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

James Lay
On 2017-11-29 07:29, Amos Jeffries wrote:

> On 28/11/17 03:50, James Lay wrote:
>> On Sun, 2017-11-26 at 09:50 +0200, Alex K wrote:
>>> Perhaps an alternative is to peek only on step1:
>>>
>>> acl step1 at_step SslBump1
>>>
>>> ssl_bump peek step1
>>> acl allowed_https_sites ssl::server_name_regex
>>> "/opt/etc/squid/http_url.txt"
>>> ssl_bump splice allowed_https_sites
>>> ssl_bump terminate all
>>
>> Hrmm...wouldn't that negate the ability to read the cert on step2?
>>
>
> Yes it would.
>
>> In layman's terms I'm thinking:
>> "peek at step1"
>> "splice acl allow matched sni's"
>> "peek at step2"
>> "splice acl allow'd matched certs"
>> "terminate the rest"
>>
>> Would that work Amos?
>>
>
> This is essentially what I suggested at the beginning.
>
> Placing splice action and your ACLs on the first ssl_bump line ensures
> that at each step if enough details are known to splice it will
> happen.
>
> The second line being "peek all" make peek happen at every step for
> which it is possible (step 1 and step 2 - not step 3).
>
> "terminate all" being last makes it happen for "all the rest", aka
> step 3 if Squid gets that far without splicing.
>
>
> The only difference is that my suggested way would also allow splicing
> the CONNECT if it happens to be presented with a host name in the
> authority-URI. Which cannot happen on your proxy unless your port 3128
> happens to be intercepting traffic between clients and another proxy.

Ah...ok so this is my lack of understanding then of peek/splice.  Sounds
like this is what I can try:

ssl_bump splice all
acl allowed_https_sites ssl::server_name_regex
"/opt/etc/squid/http_url.txt"
ssl_bump splice allowed_https_sites
ssl_bump terminate all

Is that what you're meaning Amos?  Thanks again.

James

>
>
> BTW please do not use port 3128 for intercept. It is officially
> registered for HTTP proxy traffic and so qualifies as "well known".
>
> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Amos Jeffries
Administrator
On 02/12/17 07:05, James Lay wrote:

> On 2017-11-29 07:29, Amos Jeffries wrote:
>> On 28/11/17 03:50, James Lay wrote:
>>> On Sun, 2017-11-26 at 09:50 +0200, Alex K wrote:
>>>> Perhaps an alternative is to peek only on step1:
>>>>
>>>> acl step1 at_step SslBump1
>>>>
>>>> ssl_bump peek step1
>>>> acl allowed_https_sites ssl::server_name_regex
>>>> "/opt/etc/squid/http_url.txt"
>>>> ssl_bump splice allowed_https_sites
>>>> ssl_bump terminate all
>>>
>>> Hrmm...wouldn't that negate the ability to read the cert on step2?
>>>
>>
>> Yes it would.
>>
>>> In layman's terms I'm thinking:
>>> "peek at step1"
>>> "splice acl allow matched sni's"
>>> "peek at step2"
>>> "splice acl allow'd matched certs"
>>> "terminate the rest"
>>>
>>> Would that work Amos?
>>>
>>
>> This is essentially what I suggested at the beginning.
>>
>> Placing splice action and your ACLs on the first ssl_bump line ensures
>> that at each step if enough details are known to splice it will
>> happen.
>>
>> The second line being "peek all" make peek happen at every step for
>> which it is possible (step 1 and step 2 - not step 3).
>>
>> "terminate all" being last makes it happen for "all the rest", aka
>> step 3 if Squid gets that far without splicing.
>>
>>
>> The only difference is that my suggested way would also allow splicing
>> the CONNECT if it happens to be presented with a host name in the
>> authority-URI. Which cannot happen on your proxy unless your port 3128
>> happens to be intercepting traffic between clients and another proxy.
>
> Ah...ok so this is my lack of understanding then of peek/splice.  Sounds
> like this is what I can try:
>
> ssl_bump splice all

ITYM 'peek all' there.

> acl allowed_https_sites ssl::server_name_regex
> "/opt/etc/squid/http_url.txt"
> ssl_bump splice allowed_https_sites
> ssl_bump terminate all
>
> Is that what you're meaning Amos?  Thanks again.
>
> James
>

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

torson
For me it works with "ssl_bump peek step1", not with "ssl_bump peek all".

My working config using Squid 4.8:
---
visible_hostname squid
debug_options ALL,1
positive_dns_ttl 0
negative_dns_ttl 0
client_persistent_connections off
http_port 3128
http_port 3129 intercept
acl allowed_http_sites dstdom_regex "/etc/squid/allow_list.conf"
http_access allow allowed_http_sites
https_port 3130 intercept ssl-bump \
  tls-cert=/etc/squid/ssl/squid-ca-cert-key.pem \
  options=SINGLE_DH_USE,SINGLE_ECDH_USE,NO_SSLv2,NO_SSLv3 \
  tls-dh=/etc/squid/ssl/dhparam.pem
acl SSL_port port 443
http_access allow SSL_port
acl allowed_https_sites ssl::server_name_regex "/etc/squid/allow_list.conf"
tls_outgoing_options cafile=/etc/ssl/certs/ca-certificates.crt
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump splice allowed_https_sites
ssl_bump terminate all
http_access deny all
logformat general      %tl %6tr %>a %Ss/%03>Hs %<st %rm %ssl::bump_mode %ru
%ssl::>sni
access_log daemon:/var/log/squid/access.log general
---

One thing to note are the "positive_dns_ttl 0" and "negative_dns_ttl 0"
directives ; my findings are that DNS caching needs to be set to zero in
cases where DNS records get changed every minute due to roundrobin combined
with hosting in environments where record changes faster than TTL - on AWS
where you're hitting different DNS servers with each having a different TTL.
I was getting a lot of host forgery errors before setting those to 0.
This is in addition to all the servers using the same DNS address.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Working peek/splice no longer functioning on some sites

Amos Jeffries
Administrator
On 2/09/19 8:44 am, torson wrote:
> For me it works with "ssl_bump peek step1", not with "ssl_bump peek all".
>

That tells me that your clients are lying to your proxy.

"peek step1" means only the client-provided detail is available. eg the
client says it is going to example.net (a domain which you allow) but
actually goes to othersite.example.com.

"peek all" means Squid also checks at step 2 against the server
certificate. eg Squid now sees the "othersite.example.com" detail and
rejects/terminates the bad client.



> My working config using Squid 4.8:
> ---
> visible_hostname squid
> debug_options ALL,1
> positive_dns_ttl 0
> negative_dns_ttl 0

Minimum value for negative_dns_ttl is 1. positive_dns_ttl must be
*greater* than negative_dns_ttl.

> client_persistent_connections off
> http_port 3128
> http_port 3129 intercept

You are missing the basic DoS and cross-protocol smuggling protections
provided in the default squid.conf.

Without those default rules your proxy is far more vulnerable to DoS
attack than it needs to be. This setup it will perform the complex and
slow regex ACL checking for each DoS request arriving. The defaults are
very fast port/method matches.

I suggest you extend the logformat to record the %ssl::<cert_subject
details from server certificate. Then decide whether (and how) to adjust
the server_name ACL rules.

You may want to use %ssl::<cert_errors as well if the problem is due to
server validation errors.



> acl allowed_http_sites dstdom_regex "/etc/squid/allow_list.conf"
> http_access allow allowed_http_sites
> https_port 3130 intercept ssl-bump \
>   tls-cert=/etc/squid/ssl/squid-ca-cert-key.pem \
>   options=SINGLE_DH_USE,SINGLE_ECDH_USE,NO_SSLv2,NO_SSLv3 \

SSLv2 related settings are obsolete in Squid-4. Even ones disabling it.

>   tls-dh=/etc/squid/ssl/dhparam.pem
> acl SSL_port port 443
> http_access allow SSL_port
> acl allowed_https_sites ssl::server_name_regex "/etc/squid/allow_list.conf"
> tls_outgoing_options cafile=/etc/ssl/certs/ca-certificates.crt
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump splice allowed_https_sites
> ssl_bump terminate all
> http_access deny all
> logformat general      %tl %6tr %>a %Ss/%03>Hs %<st %rm %ssl::bump_mode %ru
> %ssl::>sni
> access_log daemon:/var/log/squid/access.log general
> ---
>
> One thing to note are the "positive_dns_ttl 0" and "negative_dns_ttl 0"
> directives ; my findings are that DNS caching needs to be set to zero in
> cases where DNS records get changed every minute due to roundrobin combined
> with hosting in environments where record changes faster than TTL - on AWS
> where you're hitting different DNS servers with each having a different TTL.
> I was getting a lot of host forgery errors before setting those to 0.
> This is in addition to all the servers using the same DNS address.
>

IMO you are misunderstanding what the problem is and causing yourself
potentially worse problems in the long run.

FYI: Round-robin DNS has almost nothing to do with this issue. Under
round-robin the IPs Squid is checking for are still present, just not
first in the set. So the Host verify passes.
 The only part it might have is when the IP address set is too big for
the DNS packets your network (and your upstreams) allow. EDNS and
Jumbogram support resolves these issues entirely.


 The problem is that the DNS responses from the providers are *entirely*
different from one lookup to the next. This is guaranteed to happen when
Squid and the client are using completely different DNS resolver chains
for their lookups.

 -> If the DNS resolver difference is within your network, you need to
fix *that* instead of hacking away at the DNS cache in Squid to violate
DNS protocol requirements. The client and other DNS caches in your
network are still using those TTLs properly - so you are just shifting
the verify failure from one HTTP transaction to another.

 -> If the DNS chain difference is at the provider end (as it is for
Akamai CDN, and anyone using Google resolvers). Then you need to
*reduce* the number of out-of-sync lookups being done by both Squid and
the client. This TTL hack is the exact opposite of what you need. Best
workaround is to have your internal resolver setup to extend the TTLs
for the known problematic services.


Setting negative_dns_ttl to value less than 1 second causes every
*internal* use of the IP address by Squid to require a new DNS lookup.
This can result is weird behaviour like the arriving request http_access
rules matching against one IP, the server being connected to having a
second IP and the log entry recording yet another one.

Ignoring the proper TTLs can also result in your server being detected
by anti-DoS protection at your upstream DNS provider(s) and blocked from
service entirely.

You have been lucky that your config is so simple it does not do more
than 2 DNS queries per request, and/or that your traffic volume is so
low the premature repeat queries are not being noticed (yet).


FWIW: the use of "client_persistent_connections off" which you have does
more to address the problem those CDN create. It prevents clients
re-using a TCP connection setup with now-stale DNS details. Boosting
Squid's chance of seeing the same DNS the client has.


HTH
Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users