Re: [squid-users] concurrency with ecap

[Alex Rousskov]

On 04/27/2017 03:33 PM, Yuri Voinov wrote:

> is it possible to get comprehensive example?

FYI: This is an eCAP question, not a Squid-specific question; you also
start discussing development. Such questions are better asked via eCAP
support channels[1] rather than on squid-users:

  [1] http://www.e-cap.org/Support

Virtually any eCAP adapter supports concurrent transactions. Concurrency
is built into the API. Many adapters do not make costly/lengthy
decisions so they do not need "threads" (just like many Squids do not
need threads to process thousands of transactions concurrently). Some
adapters that do make those lengthy decisions block the application
process while others use multiple threads (or multiple processes) to
minimize blocking.

IIRC, the eCAP ClamAV adapter[2] uses threads to minimize blocking. You
may use it as a comprehensive example.

  [2] http://www.e-cap.org/Downloads


> Adapter sample is non-obvious, not complete (non-obvious where to put
> mutex locking) and contains C-style rudiments (like external call,
> pthread.h etc.).
> 
> I think, this will be actual in 2017, with CMT world around.

I doubt there are high-quality public adapters that use C++11 threading
interfaces (if that is what you are looking for). Several aspects
contribute to that, including:

* There were no stable host applications that supported C++11 until
recently and few are going to rewrite older working adapters just to add
C++11 bells and whistles.

* IIRC, initial attempts to use C++11 thread-related atomic APIs in
Squid have failed due to poor compiler support (this is not related to
eCAP but illustrates that you are talking about state-of-the-art
features rather than something that is widely supported, used, and
understood like pthreads).

* The official libecap library itself is still using a couple of
pre-C++11 components (and changing that is difficult[3,4]!).

  [3] https://bugs.launchpad.net/ecap/+bug/1595488
  [4] https://bugs.launchpad.net/ecap/+bug/1595562

In summary, it may take some time for that C++11 threading technology to
surface in eCAP adapters.


HTH,

Alex.

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

Re: [squid-users] concurrency with ecap

[Yuri Voinov]

Alex,

is it possible to get comprehensive example?

Adapter sample is non-obvious, not complete (non-obvious where to put
mutex locking) and contains C-style rudiments (like external call,
pthread.h etc.).

I think, this will be actual in 2017, with CMT world around.

WBR, Yuri.


28.04.2017 3:29, Alex Rousskov пишет:
> On 04/27/2017 03:14 PM, joseph wrote:
>> is it possible in future  to change  the ecap to use concurrency like the
>> store-id so we can benefit from that 
> eCAP supports concurrent adaptations by design. No configuration is
> required to enable that support.
>
> Alex.
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
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

Re: [squid-users] concurrency with ecap

[Alex Rousskov]

On 04/27/2017 03:14 PM, joseph wrote:
> is it possible in future  to change  the ecap to use concurrency like the
> store-id so we can benefit from that 

eCAP supports concurrent adaptations by design. No configuration is
required to enable that support.

Alex.

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

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Yuri Voinov]

Be careful with intermediate CA's you grabbed. Check they validity,
fingerprints and attributes.

Proxying SSL requires much more work with Squid.


28.04.2017 3:12, David Touzeau пишет:
> Thanks Yuri
>
>  ! but i have still have the error " Error negotiating SSL on FD 13: 
> error::lib(0):func(0):reason(0) (5/0/0) " and cannot browse to site 
> ( as i seen you can with your squid...??? )
Yes. With two different versions.
>
> Created a file /etc/squid3/cabundle.pem
>
> Added Symantec certificates available here:
> https://knowledge.symantec.com/kb/index?page=content=CROSSLINK=INFO2047
>
> add
>
> sslproxy_foreign_intermediate_certs  /etc/squid3/cabundle.pem
>
> and perform a squid -k reconfigure
>
> Missing something ???
May be. I'm recommend to re-initialize mimic certificates DB also and
restart Squid, not reconfigure.

Keep in mind, that SSL bump critical important for success. For example,
AFAIK stare often opposite to bump (in most cases). Read wiki article,
but also remember this functionality still evolving, and can changed
without notices. So, experiment.
>
> Best regards
>
> -Message d'origine-
> De : Yuri Voinov [mailto:yvoi...@gmail.com]
> Envoyé : jeudi 27 avril 2017 22:52
> À : David Touzeau ; squid-users@lists.squid-cache.org
> Objet : Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: 
> SQUID_ERR_SSL_HANDSHAKE)
>
> Squid can't have any intermediate certificates. As by as root CA's.
>
> You can use this:
>
> #  TAG: sslproxy_foreign_intermediate_certs
> #Many origin servers fail to send their full server certificate
> #chain for verification, assuming the client already has or can
> #easily locate any missing intermediate certificates.
> #
> #Squid uses the certificates from the specified file to fill in
> #these missing chains when trying to validate origin server
> #certificate chains.
> #
> #The file is expected to contain zero or more PEM-encoded
> #intermediate certificates. These certificates are not treated
> #as trusted root certificates, and any self-signed certificate in
> #this file will be ignored.
> #Default:
> # none
>
> However, you should identiry and collect them by yourself.
>
> The biggest problem:
>
> Instead of root CA's, which can be taken from Mozilla's, intermediate CAs 
> spreaded over CA's providers, have much shorter valid period (most cases up 
> to 5-7 years) and, by this reason, should be continiously maintained by 
> proxy admin.
>
> Also, remove this:
>
> sslproxy_flags DONT_VERIFY_PEER
> sslproxy_cert_error allow all
>
> From your config. Don't. Never. This is completely disable ANY security 
> checks for certificates, which leads to giant vulnerability to your users.
> ssl_proxy_cert_error should be restricted by very specific ACL(s) in your 
> config only for number of sites you trust.
>
> 28.04.2017 2:27, David Touzeau пишет:
>> Hi yuri
>>
>> I did not know if squid have Symantec intermediate certificate Squid
>> is installed as default...
>> Any howto ?
>>
>>
>> -Message d'origine-
>> De : squid-users [mailto:squid-users-boun...@lists.squid-cache.org] De
>> la part de Yuri Voinov Envoyé : jeudi 27 avril 2017 22:09 À :
>> squid-users@lists.squid-cache.org Objet : Re: [squid-users] 3.5.25:
>> (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
>>
>> Look. It can be intermediate certificates issue.
>>
>> Does Squid have Symantec intermediate certificates?
>>
>>
>> 27.04.2017 22:47, David Touzeau пишет:
>>> Hi,
>>> I'm unable to access to https://www.boutique.afnor.org website.
>>> I would like to know if this issue cannot be fixed and must deny bump
>>> website to fix it.
>>> Without Squid the website is correctly displayed
>>>
>>> Squid claim an error page with "(71) Protocol error (TLS code:
>>> SQUID_ERR_SSL_HANDSHAKE)"
>>>
>>> In cache.log: "Error negotiating SSL on FD 17:
>>> error::lib(0):func(0):reason(0) (5/0/0)"
>>>
>>> Using the following configuration:
>>>
>>> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump
>>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
>>> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem
>>> sslcrtd_program /lib/squid3/ssl_crtd -s
>>> /var/lib/squid/session/ssl/ssl_db -M 8MB sslcrtd_children 16
>>> startup=5
>>> idle=1 acl FakeCert ssl::server_name .apple.com acl FakeCert
>>> ssl::server_name .icloud.com acl FakeCert ssl::server_name
>>> .mzstatic.com acl FakeCert ssl::server_name .dropbox.com acl
>>> ssl_step1 at_step SslBump1 acl ssl_step2 at_step SslBump2 acl
>>> ssl_step3 at_step
>>> SslBump3 ssl_bump peek ssl_step1 ssl_bump splice FakeCert ssl_bump
>>> bump ssl_step2 all ssl_bump splice all
>>>
>>> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression sslproxy_cipher
>>> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:
>>> !aNULL
>>> :!eNULL
>>> sslproxy_flags DONT_VERIFY_PEER
>>> sslproxy_cert_error 

[squid-users] concurrency with ecap

[joseph]

is it possible in future  to change  the ecap to use concurrency like the
store-id
so we can benefit from that 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/concurrency-with-ecap-tp4682219.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] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[David Touzeau]

Thanks Yuri

 ! but i have still have the error " Error negotiating SSL on FD 13: 
error::lib(0):func(0):reason(0) (5/0/0) " and cannot browse to site 
( as i seen you can with your squid...??? )

Created a file /etc/squid3/cabundle.pem

Added Symantec certificates available here:
https://knowledge.symantec.com/kb/index?page=content=CROSSLINK=INFO2047

add

sslproxy_foreign_intermediate_certs  /etc/squid3/cabundle.pem

and perform a squid -k reconfigure

Missing something ???

Best regards

-Message d'origine-
De : Yuri Voinov [mailto:yvoi...@gmail.com]
Envoyé : jeudi 27 avril 2017 22:52
À : David Touzeau ; squid-users@lists.squid-cache.org
Objet : Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: 
SQUID_ERR_SSL_HANDSHAKE)

Squid can't have any intermediate certificates. As by as root CA's.

You can use this:

#  TAG: sslproxy_foreign_intermediate_certs
#Many origin servers fail to send their full server certificate
#chain for verification, assuming the client already has or can
#easily locate any missing intermediate certificates.
#
#Squid uses the certificates from the specified file to fill in
#these missing chains when trying to validate origin server
#certificate chains.
#
#The file is expected to contain zero or more PEM-encoded
#intermediate certificates. These certificates are not treated
#as trusted root certificates, and any self-signed certificate in
#this file will be ignored.
#Default:
# none

However, you should identiry and collect them by yourself.

The biggest problem:

Instead of root CA's, which can be taken from Mozilla's, intermediate CAs 
spreaded over CA's providers, have much shorter valid period (most cases up 
to 5-7 years) and, by this reason, should be continiously maintained by 
proxy admin.

Also, remove this:

sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

From your config. Don't. Never. This is completely disable ANY security 
checks for certificates, which leads to giant vulnerability to your users.
ssl_proxy_cert_error should be restricted by very specific ACL(s) in your 
config only for number of sites you trust.

28.04.2017 2:27, David Touzeau пишет:
> Hi yuri
>
> I did not know if squid have Symantec intermediate certificate Squid
> is installed as default...
> Any howto ?
>
>
> -Message d'origine-
> De : squid-users [mailto:squid-users-boun...@lists.squid-cache.org] De
> la part de Yuri Voinov Envoyé : jeudi 27 avril 2017 22:09 À :
> squid-users@lists.squid-cache.org Objet : Re: [squid-users] 3.5.25:
> (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
>
> Look. It can be intermediate certificates issue.
>
> Does Squid have Symantec intermediate certificates?
>
>
> 27.04.2017 22:47, David Touzeau пишет:
>> Hi,
>> I'm unable to access to https://www.boutique.afnor.org website.
>> I would like to know if this issue cannot be fixed and must deny bump
>> website to fix it.
>> Without Squid the website is correctly displayed
>>
>> Squid claim an error page with "(71) Protocol error (TLS code:
>> SQUID_ERR_SSL_HANDSHAKE)"
>>
>> In cache.log: "Error negotiating SSL on FD 17:
>> error::lib(0):func(0):reason(0) (5/0/0)"
>>
>> Using the following configuration:
>>
>> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
>> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem
>> sslcrtd_program /lib/squid3/ssl_crtd -s
>> /var/lib/squid/session/ssl/ssl_db -M 8MB sslcrtd_children 16
>> startup=5
>> idle=1 acl FakeCert ssl::server_name .apple.com acl FakeCert
>> ssl::server_name .icloud.com acl FakeCert ssl::server_name
>> .mzstatic.com acl FakeCert ssl::server_name .dropbox.com acl
>> ssl_step1 at_step SslBump1 acl ssl_step2 at_step SslBump2 acl
>> ssl_step3 at_step
>> SslBump3 ssl_bump peek ssl_step1 ssl_bump splice FakeCert ssl_bump
>> bump ssl_step2 all ssl_bump splice all
>>
>> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression sslproxy_cipher
>> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:
>> !aNULL
>> :!eNULL
>> sslproxy_flags DONT_VERIFY_PEER
>> sslproxy_cert_error allow all
>>
>>
>>
>> Openssl info
>> -
>> -
>> --
>> -
>> -
>> --
>> ---
>>
>> openssl s_client -connect 195.115.26.58:443 -showcerts
>>
>> CONNECTED(0003)
>> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU
>> = "(c)
>> 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3
>> Public Primary Certification Authority - G5 verify return:1
>> depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust
>> Network, CN = Symantec Class 3 Secure Server CA - G4 verify return:1
>> depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION
>> 

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Yuri Voinov]

Squid can't have any intermediate certificates. As by as root CA's.

You can use this:

#  TAG: sslproxy_foreign_intermediate_certs
#Many origin servers fail to send their full server certificate
#chain for verification, assuming the client already has or can
#easily locate any missing intermediate certificates.
#
#Squid uses the certificates from the specified file to fill in
#these missing chains when trying to validate origin server
#certificate chains.
#
#The file is expected to contain zero or more PEM-encoded
#intermediate certificates. These certificates are not treated
#as trusted root certificates, and any self-signed certificate in
#this file will be ignored.
#Default:
# none

However, you should identiry and collect them by yourself.

The biggest problem:

Instead of root CA's, which can be taken from Mozilla's, intermediate
CAs spreaded over CA's providers, have much shorter valid period (most
cases up to 5-7 years) and, by this reason, should be continiously
maintained by proxy admin.

Also, remove this:

sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

From your config. Don't. Never. This is completely disable ANY security checks 
for certificates, which leads to giant vulnerability to your users.
ssl_proxy_cert_error should be restricted by very specific ACL(s) in your 
config only for number of sites you trust.

28.04.2017 2:27, David Touzeau пишет:
> Hi yuri
>
> I did not know if squid have Symantec intermediate certificate
> Squid is installed as default...
> Any howto ?
>
>
> -Message d'origine-
> De : squid-users [mailto:squid-users-boun...@lists.squid-cache.org] De la 
> part de Yuri Voinov
> Envoyé : jeudi 27 avril 2017 22:09
> À : squid-users@lists.squid-cache.org
> Objet : Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: 
> SQUID_ERR_SSL_HANDSHAKE)
>
> Look. It can be intermediate certificates issue.
>
> Does Squid have Symantec intermediate certificates?
>
>
> 27.04.2017 22:47, David Touzeau пишет:
>> Hi,
>> I'm unable to access to https://www.boutique.afnor.org website.
>> I would like to know if this issue cannot be fixed and must deny bump 
>> website to fix it.
>> Without Squid the website is correctly displayed
>>
>> Squid claim an error page with "(71) Protocol error (TLS code:
>> SQUID_ERR_SSL_HANDSHAKE)"
>>
>> In cache.log: "Error negotiating SSL on FD 17:
>> error::lib(0):func(0):reason(0) (5/0/0)"
>>
>> Using the following configuration:
>>
>> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
>> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
>> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem 
>> sslcrtd_program /lib/squid3/ssl_crtd -s 
>> /var/lib/squid/session/ssl/ssl_db -M 8MB sslcrtd_children 16 startup=5 
>> idle=1 acl FakeCert ssl::server_name .apple.com acl FakeCert 
>> ssl::server_name .icloud.com acl FakeCert ssl::server_name 
>> .mzstatic.com acl FakeCert ssl::server_name .dropbox.com acl ssl_step1 
>> at_step SslBump1 acl ssl_step2 at_step SslBump2 acl ssl_step3 at_step 
>> SslBump3 ssl_bump peek ssl_step1 ssl_bump splice FakeCert ssl_bump 
>> bump ssl_step2 all ssl_bump splice all
>>
>> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression sslproxy_cipher 
>> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:
>> !aNULL
>> :!eNULL
>> sslproxy_flags DONT_VERIFY_PEER
>> sslproxy_cert_error allow all
>>
>>
>>
>> Openssl info
>> --
>> --
>> --
>> --
>> ---
>>
>> openssl s_client -connect 195.115.26.58:443 -showcerts
>>
>> CONNECTED(0003)
>> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU 
>> = "(c)
>> 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 
>> Public Primary Certification Authority - G5 verify return:1
>> depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, 
>> CN = Symantec Class 3 Secure Server CA - G4 verify return:1
>> depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION 
>> FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE 
>> NORMALISATION, CN = www.boutique.afnor.org verify return:1
>> ---
>> Certificate chain
>>  0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE 
>> NORMALISATION/OU=ASSOCIATION FRANCAISE DE 
>> NORMALISATION/CN=www.boutique.afnor.org
>>i:/C=US/O=Symantec Corporation/OU=Symantec Trust 
>> Network/CN=Symantec Class 3 Secure Server CA - G4 -BEGIN 
>> CERTIFICATE- ../..
>> -END CERTIFICATE-
>>  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust 
>> Network/CN=Symantec Class 3 Secure Server CA - G4
>>i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
>> VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public 
>> Primary Certification Authority - G5 

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[David Touzeau]

Hi yuri

I did not know if squid have Symantec intermediate certificate
Squid is installed as default...
Any howto ?


-Message d'origine-
De : squid-users [mailto:squid-users-boun...@lists.squid-cache.org] De la part 
de Yuri Voinov
Envoyé : jeudi 27 avril 2017 22:09
À : squid-users@lists.squid-cache.org
Objet : Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: 
SQUID_ERR_SSL_HANDSHAKE)

Look. It can be intermediate certificates issue.

Does Squid have Symantec intermediate certificates?


27.04.2017 22:47, David Touzeau пишет:
> Hi,
> I'm unable to access to https://www.boutique.afnor.org website.
> I would like to know if this issue cannot be fixed and must deny bump 
> website to fix it.
> Without Squid the website is correctly displayed
>
> Squid claim an error page with "(71) Protocol error (TLS code:
> SQUID_ERR_SSL_HANDSHAKE)"
>
> In cache.log: "Error negotiating SSL on FD 17:
> error::lib(0):func(0):reason(0) (5/0/0)"
>
> Using the following configuration:
>
> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump 
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB 
> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem 
> sslcrtd_program /lib/squid3/ssl_crtd -s 
> /var/lib/squid/session/ssl/ssl_db -M 8MB sslcrtd_children 16 startup=5 
> idle=1 acl FakeCert ssl::server_name .apple.com acl FakeCert 
> ssl::server_name .icloud.com acl FakeCert ssl::server_name 
> .mzstatic.com acl FakeCert ssl::server_name .dropbox.com acl ssl_step1 
> at_step SslBump1 acl ssl_step2 at_step SslBump2 acl ssl_step3 at_step 
> SslBump3 ssl_bump peek ssl_step1 ssl_bump splice FakeCert ssl_bump 
> bump ssl_step2 all ssl_bump splice all
>
> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression sslproxy_cipher 
> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:
> !aNULL
> :!eNULL
> sslproxy_flags DONT_VERIFY_PEER
> sslproxy_cert_error allow all
>
>
>
> Openssl info
> --
> --
> --
> --
> ---
>
> openssl s_client -connect 195.115.26.58:443 -showcerts
>
> CONNECTED(0003)
> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU 
> = "(c)
> 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 
> Public Primary Certification Authority - G5 verify return:1
> depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, 
> CN = Symantec Class 3 Secure Server CA - G4 verify return:1
> depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION 
> FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE 
> NORMALISATION, CN = www.boutique.afnor.org verify return:1
> ---
> Certificate chain
>  0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE 
> NORMALISATION/OU=ASSOCIATION FRANCAISE DE 
> NORMALISATION/CN=www.boutique.afnor.org
>i:/C=US/O=Symantec Corporation/OU=Symantec Trust 
> Network/CN=Symantec Class 3 Secure Server CA - G4 -BEGIN 
> CERTIFICATE- ../..
> -END CERTIFICATE-
>  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust 
> Network/CN=Symantec Class 3 Secure Server CA - G4
>i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
> VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public 
> Primary Certification Authority - G5 -BEGIN CERTIFICATE- ../..
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE 
> DE NORMALISATION/OU=ASSOCIATION FRANCAISE DE 
> NORMALISATION/CN=www.boutique.afnor.org
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust 
> Network/CN=Symantec Class 3 Secure Server CA - G4
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 3105 bytes and written 616 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit 
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1
> Cipher: AES128-SHA
> Session-ID:
> 833BA2346F50C5AAFC6B5188B4EBD9304CD25411BECFF0713F8D76C65D9D
> Session-ID-ctx:
> Master-Key:
> D2DF6C62264D03D7D44AF44EB8C0B1B7AD0E650D34DF6EBEB1CBEBFE4F30CB9C6F5080
> AA94F5
> D6B5955DD8DF06608416
> Key-Arg   : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1493311275
> Timeout   : 300 (sec)
> Verify return code: 0 (ok)
> ---
> read:errno=0
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

--
Bugs to the Future

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

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Yuri Voinov]

Look. It can be intermediate certificates issue.

Does Squid have Symantec intermediate certificates?


27.04.2017 22:47, David Touzeau пишет:
> Hi,
> I'm unable to access to https://www.boutique.afnor.org website.
> I would like to know if this issue cannot be fixed and must deny bump
> website to fix it.
> Without Squid the website is correctly displayed 
>
> Squid claim an error page with "(71) Protocol error (TLS code:
> SQUID_ERR_SSL_HANDSHAKE)"
>
> In cache.log: "Error negotiating SSL on FD 17:
> error::lib(0):func(0):reason(0) (5/0/0)"
>
> Using the following configuration:
>
> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem
> sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/squid/session/ssl/ssl_db -M
> 8MB
> sslcrtd_children 16 startup=5 idle=1
> acl FakeCert ssl::server_name .apple.com
> acl FakeCert ssl::server_name .icloud.com
> acl FakeCert ssl::server_name .mzstatic.com
> acl FakeCert ssl::server_name .dropbox.com
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> ssl_bump peek ssl_step1
> ssl_bump splice FakeCert
> ssl_bump bump ssl_step2 all
> ssl_bump splice all
>
> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression
> sslproxy_cipher
> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL
> :!eNULL
> sslproxy_flags DONT_VERIFY_PEER
> sslproxy_cert_error allow all
>
>
>
> Openssl info 
> 
> 
> ---
>
> openssl s_client -connect 195.115.26.58:443 -showcerts
>
> CONNECTED(0003)
> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c)
> 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public
> Primary Certification Authority - G5
> verify return:1
> depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN =
> Symantec Class 3 Secure Server CA - G4
> verify return:1
> depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION
> FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE NORMALISATION, CN
> = www.boutique.afnor.org
> verify return:1
> ---
> Certificate chain
>  0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
> NORMALISATION/OU=ASSOCIATION FRANCAISE DE
> NORMALISATION/CN=www.boutique.afnor.org
>i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> -BEGIN CERTIFICATE-
> ../..
> -END CERTIFICATE-
>  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
>i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
> Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
> Certification Authority - G5
> -BEGIN CERTIFICATE-
> ../..
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
> NORMALISATION/OU=ASSOCIATION FRANCAISE DE
> NORMALISATION/CN=www.boutique.afnor.org
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 3105 bytes and written 616 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES128-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1
> Cipher: AES128-SHA
> Session-ID:
> 833BA2346F50C5AAFC6B5188B4EBD9304CD25411BECFF0713F8D76C65D9D
> Session-ID-ctx:
> Master-Key:
> D2DF6C62264D03D7D44AF44EB8C0B1B7AD0E650D34DF6EBEB1CBEBFE4F30CB9C6F5080AA94F5
> D6B5955DD8DF06608416
> Key-Arg   : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1493311275
> Timeout   : 300 (sec)
> Verify return code: 0 (ok)
> ---
> read:errno=0
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
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

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Yuri Voinov]

This one?

http://i.imgur.com/kI9SxiN.png

It's works under bump.


27.04.2017 22:47, David Touzeau пишет:
> Hi,
> I'm unable to access to https://www.boutique.afnor.org website.
> I would like to know if this issue cannot be fixed and must deny bump
> website to fix it.
> Without Squid the website is correctly displayed 
>
> Squid claim an error page with "(71) Protocol error (TLS code:
> SQUID_ERR_SSL_HANDSHAKE)"
>
> In cache.log: "Error negotiating SSL on FD 17:
> error::lib(0):func(0):reason(0) (5/0/0)"
>
> Using the following configuration:
>
> http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

> cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
What's is this? Which certificate?
> sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem
> sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/squid/session/ssl/ssl_db -M
> 8MB
> sslcrtd_children 16 startup=5 idle=1
> acl FakeCert ssl::server_name .apple.com
> acl FakeCert ssl::server_name .icloud.com
> acl FakeCert ssl::server_name .mzstatic.com
> acl FakeCert ssl::server_name .dropbox.com
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> ssl_bump peek ssl_step1
> ssl_bump splice FakeCert
> ssl_bump bump ssl_step2 all
> ssl_bump splice all
>
> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression
> sslproxy_cipher
> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL
> :!eNULL
> sslproxy_flags DONT_VERIFY_PEER
> sslproxy_cert_error allow all
>
>
>
> Openssl info 
> 
> 
> ---
>
> openssl s_client -connect 195.115.26.58:443 -showcerts
>
> CONNECTED(0003)
> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c)
> 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public
> Primary Certification Authority - G5
> verify return:1
> depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN =
> Symantec Class 3 Secure Server CA - G4
> verify return:1
> depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION
> FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE NORMALISATION, CN
> = www.boutique.afnor.org
> verify return:1
> ---
> Certificate chain
>  0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
> NORMALISATION/OU=ASSOCIATION FRANCAISE DE
> NORMALISATION/CN=www.boutique.afnor.org
>i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> -BEGIN CERTIFICATE-
> ../..
> -END CERTIFICATE-
>  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
>i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
> Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
> Certification Authority - G5
> -BEGIN CERTIFICATE-
> ../..
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
> NORMALISATION/OU=ASSOCIATION FRANCAISE DE
> NORMALISATION/CN=www.boutique.afnor.org
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 3105 bytes and written 616 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES128-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol  : TLSv1
> Cipher: AES128-SHA
> Session-ID:
> 833BA2346F50C5AAFC6B5188B4EBD9304CD25411BECFF0713F8D76C65D9D
> Session-ID-ctx:
> Master-Key:
> D2DF6C62264D03D7D44AF44EB8C0B1B7AD0E650D34DF6EBEB1CBEBFE4F30CB9C6F5080AA94F5
> D6B5955DD8DF06608416
> Key-Arg   : None

> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1493311275
> Timeout   : 300 (sec)
> Verify return code: 0 (ok)
> ---
> read:errno=0
>
>
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
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

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

[Yuri Voinov]

3.5 and above have "server-first" only for backward compatibility.


27.04.2017 22:50, William Lima пишет:
> Hi,
>
> The problem occurs due to some ssl_bump directive actions, so Squid cannot 
> get all information (X.509 v3 extensions) to mimic. "ssl_bump server-first 
> all" should work.
>
> William Lima
>
> - Original Message -
> From: "Flashdown" 
> To: "Yuri Voinov" 
> Cc: squid-users@lists.squid-cache.org
> Sent: Thursday, April 27, 2017 1:41:48 PM
> Subject: Re: [squid-users] ssl bump and chrome 58
>
> I've tested the registry setting and it worked out. You can copy the 
> below lines in a .reg file and execute it.
>
> Windows Registry Editor Version 5.00
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
> "EnableCommonNameFallbackForLocalAnchors"=dword:0001
>
>
> Best regards,
> Flashdown
>
> Am 2017-04-27 18:34, schrieb Flashdown:
>> Hello together,
>>
>> here is a workaround that you could use in the meanwhile.
>>
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
>>
>> Source:
>> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors
>>> BEGIN
>> EnableCommonNameFallbackForLocalAnchors
>> Whether to allow certificates issued by local trust anchors that are
>> missing the subjectAlternativeName extension
>>
>> Data type:
>> Boolean [Windows:REG_DWORD]
>> Windows registry location:
>> 
>> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors
>> Mac/Linux preference name:
>> EnableCommonNameFallbackForLocalAnchors
>> Android restriction name:
>> EnableCommonNameFallbackForLocalAnchors
>> Supported on:
>>
>> Google Chrome (Linux, Mac, Windows) since version 58 until 
>> version 65
>> Google Chrome OS (Google Chrome OS) since version 58 until 
>> version 65
>> Google Chrome (Android) since version 58 until version 65
>>
>> Supported features:
>> Dynamic Policy Refresh: Yes, Per Profile: No
>> Description:
>>
>> When this setting is enabled, Google Chrome will use the
>> commonName of a server certificate to match a hostname if the
>> certificate is missing a subjectAlternativeName extension, as long as
>> it successfully validates and chains to a locally-installed CA
>> certificates.
>>
>> Note that this is not recommended, as this may allow bypassing the
>> nameConstraints extension that restricts the hostnames that a given
>> certificate can be authorized for.
>>
>> If this policy is not set, or is set to false, server certificates
>> that lack a subjectAlternativeName extension containing either a DNS
>> name or IP address will not be trusted.
>> Example value:
>> 0x (Windows), false (Linux), false (Android),  
>> (Mac)
>>  END
>>
>>
>>
>> Am 2017-04-27 18:16, schrieb Flashdown:
>>> Hello together,
>>>
>>> Suddenly I am facing the same issue when users Chrome has been updated
>>> to V58. I am running Squid 3.5.23.
>>>
>>> This is the reason:
>>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/
>>> Short: Common Name Support Removed in Chrome 58 and Squid does not
>>> create certs with DNS-Alternatives names in it. Because of that it
>>> fails.
>>>
>>> Chrome says:
>>> 1. Subject Alternative Name Missing - The certificate for this site
>>> does not contain a Subject Alternative Name extension containing a
>>> domain name or IP address.
>>> 2. Certificate Error - There are issues with the site's certificate
>>> chain (net::ERR_CERT_COMMON_NAME_INVALID).
>>>
>>> Can we get Squid to add the DNS-Alternative Name to the generated
>>> certs? Since this is what I believe is now required in Chrome 58+
>>>
>>> Best regards,
>>> Enrico
>>>
>>>
>>> Am 2017-04-21 15:35, schrieb Yuri Voinov:
 I see no problem with it on all five SSL Bump-aware servers with new
 Chrome. So fare so good.


 21.04.2017 18:29, Marko Cupać пишет:
> Hi,
>
> I have squid setup with ssl bump which worked fine, but since I 
> updated
> chrome to 58 it won't display any https sites, throwing
> NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous
> chrome version, as well as in IE.
>
> Anything I can do in squid config to get ssl-bumped sites in chrome
> again?
>
> Thank you in advance,
 ___
 squid-users mailing list
 squid-users@lists.squid-cache.org
 http://lists.squid-cache.org/listinfo/squid-users
>>> ___
>>> squid-users 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
> ___
> squid-users mailing list
> 

Re: [squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[Olly Lennox]

Hi David,

I'm battling with similar problems at the moment. One thing that I've found is 
that the system seems happier when you don't peek prior to a bump, my current 
config is:

acl nobumpserver ssl::server_name "/etc/squid/nobump"
acl ignoreclients src "/etc/squid/nobumpclients"
acl step1 at_step SslBump1

ssl_bump peek nobumpserver step1
ssl_bump peek ignoreclients step1
ssl_bump splice nobumpserver
ssl_bump splice ignoreclients 

ssl_bump stare step1 !nobumpserver !ignoreclients 

ssl_bump bump !nobumpserver !ignoreclients

where nobump is a list of regex domains (like .apple.com) and nobumpclients is 
a list of IPs I never want to bump. I'm still battling with errors and sites 
not always working but of all the configurations I've tried this one seems to 
work for the majority of sites

Cheers, 
oli...@lennox-it.uk
lennox-it.uk
tel: 07900 648 252




From: David Touzeau 
To: squid-users@lists.squid-cache.org 
Sent: Thursday, 27 April 2017, 17:48
Subject: [squid-users] 3.5.25: (71) Protocol error (TLS code:
SQUID_ERR_SSL_HANDSHAKE)




Hi,

I'm unable to access to https://www.boutique.afnor.org website.

I would like to know if this issue cannot be fixed and must deny bump

website to fix it.

Without Squid the website is correctly displayed 


Squid claim an error page with "(71) Protocol error (TLS code:

SQUID_ERR_SSL_HANDSHAKE)"


In cache.log: "Error negotiating SSL on FD 17:

error::lib(0):func(0):reason(0) (5/0/0)"


Using the following configuration:


http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump

generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn

sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem

sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/squid/session/ssl/ssl_db -M

8MB

sslcrtd_children 16 startup=5 idle=1

acl FakeCert ssl::server_name .apple.com

acl FakeCert ssl::server_name .icloud.com

acl FakeCert ssl::server_name .mzstatic.com

acl FakeCert ssl::server_name .dropbox.com

acl ssl_step1 at_step SslBump1

acl ssl_step2 at_step SslBump2

acl ssl_step3 at_step SslBump3

ssl_bump peek ssl_step1

ssl_bump splice FakeCert

ssl_bump bump ssl_step2 all

ssl_bump splice all


sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression

sslproxy_cipher

ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL

:!eNULL

sslproxy_flags DONT_VERIFY_PEER

sslproxy_cert_error allow all




Openssl info 





---


openssl s_client -connect 195.115.26.58:443 -showcerts


CONNECTED(0003)

depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c)

2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public

Primary Certification Authority - G5

verify return:1

depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN =

Symantec Class 3 Secure Server CA - G4

verify return:1

depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION

FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE NORMALISATION, CN

= www.boutique.afnor.org

verify return:1

---

Certificate chain

0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE

NORMALISATION/OU=ASSOCIATION FRANCAISE DE

NORMALISATION/CN=www.boutique.afnor.org

   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec

Class 3 Secure Server CA - G4

-BEGIN CERTIFICATE-

../..

-END CERTIFICATE-

1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec

Class 3 Secure Server CA - G4

   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,

Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary

Certification Authority - G5

-BEGIN CERTIFICATE-

../..

-END CERTIFICATE-

---

Server certificate

subject=/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE

NORMALISATION/OU=ASSOCIATION FRANCAISE DE

NORMALISATION/CN=www.boutique.afnor.org

issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec

Class 3 Secure Server CA - G4

---

No client certificate CA names sent

---

SSL handshake has read 3105 bytes and written 616 bytes

---

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : TLSv1

Cipher: AES128-SHA

Session-ID:

833BA2346F50C5AAFC6B5188B4EBD9304CD25411BECFF0713F8D76C65D9D

Session-ID-ctx:

Master-Key:

D2DF6C62264D03D7D44AF44EB8C0B1B7AD0E650D34DF6EBEB1CBEBFE4F30CB9C6F5080AA94F5

D6B5955DD8DF06608416

Key-Arg   : None

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1493311275

Timeout   : 300 (sec)

Verify return code: 

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

[William Lima]

Hi,

The problem occurs due to some ssl_bump directive actions, so Squid cannot get 
all information (X.509 v3 extensions) to mimic. "ssl_bump server-first all" 
should work.

William Lima

- Original Message -
From: "Flashdown" 
To: "Yuri Voinov" 
Cc: squid-users@lists.squid-cache.org
Sent: Thursday, April 27, 2017 1:41:48 PM
Subject: Re: [squid-users] ssl bump and chrome 58

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

Windows Registry Editor Version 5.00

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


Best regards,
Flashdown

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

[squid-users] 3.5.25: (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

[David Touzeau]

Hi,
I'm unable to access to https://www.boutique.afnor.org website.
I would like to know if this issue cannot be fixed and must deny bump
website to fix it.
Without Squid the website is correctly displayed 

Squid claim an error page with "(71) Protocol error (TLS code:
SQUID_ERR_SSL_HANDSHAKE)"

In cache.log: "Error negotiating SSL on FD 17:
error::lib(0):func(0):reason(0) (5/0/0)"

Using the following configuration:

http_port 0.0.0.0:3128  name=MyPortNameID20 ssl-bump
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
cert=/etc/squid3/ssl/0c451f46b4d05031560d8195f30165cb.dyn
sslproxy_foreign_intermediate_certs /etc/squid3/intermediate_ca.pem
sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/squid/session/ssl/ssl_db -M
8MB
sslcrtd_children 16 startup=5 idle=1
acl FakeCert ssl::server_name .apple.com
acl FakeCert ssl::server_name .icloud.com
acl FakeCert ssl::server_name .mzstatic.com
acl FakeCert ssl::server_name .dropbox.com
acl ssl_step1 at_step SslBump1
acl ssl_step2 at_step SslBump2
acl ssl_step3 at_step SslBump3
ssl_bump peek ssl_step1
ssl_bump splice FakeCert
ssl_bump bump ssl_step2 all
ssl_bump splice all

sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression
sslproxy_cipher
ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL
:!eNULL
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all



Openssl info 


---

openssl s_client -connect 195.115.26.58:443 -showcerts

CONNECTED(0003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c)
2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public
Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN =
Symantec Class 3 Secure Server CA - G4
verify return:1
depth=0 C = FR, ST = Seine Saint Denis, L = ST DENIS, O = ASSOCIATION
FRANCAISE DE NORMALISATION, OU = ASSOCIATION FRANCAISE DE NORMALISATION, CN
= www.boutique.afnor.org
verify return:1
---
Certificate chain
 0 s:/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
NORMALISATION/OU=ASSOCIATION FRANCAISE DE
NORMALISATION/CN=www.boutique.afnor.org
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
Class 3 Secure Server CA - G4
-BEGIN CERTIFICATE-
../..
-END CERTIFICATE-
 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
Class 3 Secure Server CA - G4
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
-BEGIN CERTIFICATE-
../..
-END CERTIFICATE-
---
Server certificate
subject=/C=FR/ST=Seine Saint Denis/L=ST DENIS/O=ASSOCIATION FRANCAISE DE
NORMALISATION/OU=ASSOCIATION FRANCAISE DE
NORMALISATION/CN=www.boutique.afnor.org
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
Class 3 Secure Server CA - G4
---
No client certificate CA names sent
---
SSL handshake has read 3105 bytes and written 616 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: AES128-SHA
Session-ID:
833BA2346F50C5AAFC6B5188B4EBD9304CD25411BECFF0713F8D76C65D9D
Session-ID-ctx:
Master-Key:
D2DF6C62264D03D7D44AF44EB8C0B1B7AD0E650D34DF6EBEB1CBEBFE4F30CB9C6F5080AA94F5
D6B5955DD8DF06608416
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1493311275
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0



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

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

[Flashdown]

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


Windows Registry Editor Version 5.00

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


Best regards,
Flashdown

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

Hello together,

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

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

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

BEGIN

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

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

Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors

Mac/Linux preference name:
EnableCommonNameFallbackForLocalAnchors
Android restriction name:
EnableCommonNameFallbackForLocalAnchors
Supported on:

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

Google Chrome (Android) since version 58 until version 65

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

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

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

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

 END



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

Hello together,

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

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

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

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

Best regards,
Enrico


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

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


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

Hi,

I have squid setup with ssl bump which worked fine, but since I 
updated

chrome to 58 it won't display any https sites, throwing
NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous
chrome version, as well as in IE.

Anything I can do in squid config to get ssl-bumped sites in chrome
again?

Thank you in advance,


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

___
squid-users 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

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

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

[Flashdown]

Hello together,

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

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

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

BEGIN

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


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

Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors

Mac/Linux preference name:
EnableCommonNameFallbackForLocalAnchors
Android restriction name:
EnableCommonNameFallbackForLocalAnchors
Supported on:

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

Google Chrome (Android) since version 58 until version 65

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

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


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


If this policy is not set, or is set to false, server certificates 
that lack a subjectAlternativeName extension containing either a DNS 
name or IP address will not be trusted.

Example value:
0x (Windows), false (Linux), false (Android),  
(Mac)

 END



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

Hello together,

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

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

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

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

Best regards,
Enrico


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

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


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

Hi,

I have squid setup with ssl bump which worked fine, but since I 
updated

chrome to 58 it won't display any https sites, throwing
NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous
chrome version, as well as in IE.

Anything I can do in squid config to get ssl-bumped sites in chrome
again?

Thank you in advance,


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

___
squid-users 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] ssl bump and chrome 58

[Flashdown]

Hello together,

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


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


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


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


Best regards,
Enrico


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

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


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

Hi,

I have squid setup with ssl bump which worked fine, but since I 
updated

chrome to 58 it won't display any https sites, throwing
NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous
chrome version, as well as in IE.

Anything I can do in squid config to get ssl-bumped sites in chrome
again?

Thank you in advance,


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

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