[3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

David Touzeau-3

Hi

I'm using SSL transparent method :

https_port 0.0.0.0:53695  intercept disable-pmtu-discovery=transparent
name=MyPortNameID22 ssl-bump  generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB
cert=/etc/squid3/ssl/cb623e9bfc65772f68b84393604cd6ea.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 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 all

sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

As you can see squid just intercept ssl queries and bump nothing ( just to
filter connections from url_rewrite program  and log ssl connections )

When connecting to mozilla.org using transparent, we receive this error:

* About to connect() to www.mozilla.org port 443 (#0)
*   Trying 104.16.41.2...
* connected
* Connected to www.mozilla.org (104.16.41.2) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection #0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol


And squid access.log

1485110919.564      3 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html

When using squid using standard port ( connected port/TUNNEL ) mozilla is
correctly dispalyed without any error.


How to whitelist mozilla.org without create a bypass iptables rule  ?


Best regards




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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

David Touzeau-3
Same issue with https://www.digitalocean.com/
is somebody did not encounter the issue using Squid in transparent mode with SSL ??


-----Message d'origine-----
De : squid-users [mailto:[hidden email]] De la part de David Touzeau
Envoyé : dimanche 22 janvier 2017 19:49
À : [hidden email]
Objet : [squid-users] [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol


Hi

I'm using SSL transparent method :

https_port 0.0.0.0:53695  intercept disable-pmtu-discovery=transparent
name=MyPortNameID22 ssl-bump  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/cb623e9bfc65772f68b84393604cd6ea.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 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 all

sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

As you can see squid just intercept ssl queries and bump nothing ( just to filter connections from url_rewrite program  and log ssl connections )

When connecting to mozilla.org using transparent, we receive this error:

* About to connect() to www.mozilla.org port 443 (#0)
*   Trying 104.16.41.2...
* connected
* Connected to www.mozilla.org (104.16.41.2) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Closing connection #0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol


And squid access.log

1485110919.564      3 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html

When using squid using standard port ( connected port/TUNNEL ) mozilla is correctly dispalyed without any error.


How to whitelist mozilla.org without create a bypass iptables rule  ?


Best regards




_______________________________________________
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: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

Amos Jeffries
Administrator
On 24/01/2017 12:28 p.m., David Touzeau wrote:
> Same issue with https://www.digitalocean.com/
> is somebody did not encounter the issue using Squid in transparent mode with SSL ??
>

The TLS / HTTP Senvironment is in the process of stabilizing, but still
quite volatile.

Since the error message says "unknown protocol" I suspect it is
something like WebSockets, HTTP/2 or SPDY which you are actually
intercepting on port 443. Not HTTP/1 which Squid supports.

Or maybe it is some non-TLS traffic that OpenSSL does not support.

Mozilla do cert pinning, so teh bump/intercept should probably not work
anyway. I'm not sure about digitalocean.

Amos

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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

David Touzeau-3
De : squid-users [mailto:[hidden email]] De la
part de Amos Jeffries
Envoyé : mardi 24 janvier 2017 01:01
À : [hidden email]
Objet : Re: [squid-users] [3.5.23]: mozilla.org failed using SSL transparent
SSL23_GET_SERVER_HELLO:unknown protocol

On 24/01/2017 12:28 p.m., David Touzeau wrote:
> Same issue with https://www.digitalocean.com/ is somebody did not
> encounter the issue using Squid in transparent mode with SSL ??
>

The TLS / HTTP Senvironment is in the process of stabilizing, but still
quite volatile.

Since the error message says "unknown protocol" I suspect it is something
like WebSockets, HTTP/2 or SPDY which you are actually intercepting on port
443. Not HTTP/1 which Squid supports.

Or maybe it is some non-TLS traffic that OpenSSL does not support.

Mozilla do cert pinning, so teh bump/intercept should probably not work
anyway. I'm not sure about digitalocean.
------------------------------------------------------------------------------------------------------------------------------------

Thanks Amos for the answer but...

I did not want to bump these sites, only pass trough the squid
port and process the request without try decrypting the protocol.

Tried :

acl nossl dstdomain -i .mozilla.org
ssl_bump none nossl
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 all

or

acl nossl dst 104.16.40.2
ssl_bump none nossl
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 all


But squid is still unable to process the request.

Any workaround ?


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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

Amos Jeffries
Administrator
On 24/01/2017 2:11 p.m., David Touzeau wrote:

> De :  Amos Jeffries
>
> On 24/01/2017 12:28 p.m., David Touzeau wrote:
>> Same issue with https://www.digitalocean.com/ is somebody did not
>> encounter the issue using Squid in transparent mode with SSL ??
>>
>
> The TLS / HTTP Senvironment is in the process of stabilizing, but still
> quite volatile.
>
> Since the error message says "unknown protocol" I suspect it is something
> like WebSockets, HTTP/2 or SPDY which you are actually intercepting on port
> 443. Not HTTP/1 which Squid supports.
>
> Or maybe it is some non-TLS traffic that OpenSSL does not support.
>
> Mozilla do cert pinning, so teh bump/intercept should probably not work
> anyway. I'm not sure about digitalocean.
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Thanks Amos for the answer but...
>
> I did not want to bump these sites, only pass trough the squid
> port and process the request without try decrypting the protocol.

Aye. Sorry I noticed that just after pressing send.

Which means it is probably OpenSSL itself that does not know the
protocol. Could be TLS/1.3, from a big name like Mozilla port 443 is
unlikely to be non-TLS unless somebody upstream of you is doing
something funky for that specific traffic.


>
> Tried :
>
> acl nossl dstdomain -i .mozilla.org
> ssl_bump none nossl
> 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 all
>
> or
>
> acl nossl dst 104.16.40.2
> ssl_bump none nossl
> 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 all
>
>
> But squid is still unable to process the request.
>
> Any workaround ?

Use 'splice' instead of 'none'. Mixing the SSL-Bump feature versions
like that is bad.

Also, what is showing up in your access.log for these transactions? The
ACL deciding not to even peek needs to correcly match the faked CONNECT
request containing only the dst-IP address.


I'm not aware of any other workaround for Squid-3. The
on_unsupported_protocol might be able to handle it in Squid-4.


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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

Alex Rousskov
In reply to this post by David Touzeau-3
On 01/23/2017 04:28 PM, David Touzeau wrote:
> ssl_bump peek ssl_step1
> ssl_bump splice all
>
> sslproxy_flags DONT_VERIFY_PEER
> sslproxy_cert_error allow all


> When connecting to mozilla.org using transparent, we receive this error:
>
> * About to connect() to www.mozilla.org port 443 (#0)
> *   Trying 104.16.41.2...
> * connected
> * Connected to www.mozilla.org (104.16.41.2) port 443 (#0)
> * successfully set certificate verify locations:
> *   CAfile: none
>   CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):
> * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> * Closing connection #0
> curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
> protocol
>
>
> And squid access.log
>
> 1485110919.564      3 192.168.1.236 TAG_NONE/403 6263 CONNECT
> 104.16.41.2:443 - HIER_NONE/- text/html

Amos, please note that the above failing test is done using curl, not
some fancy/non-HTTP/websocket traffic from a "browser".

David, you need to figure out why Squid is denying the intercepted
connection attempt (the /403 part in your access.log). Check your
http_access rules to start with. They were applied to the denied fake
CONNECT request shown above.

AFAICT, Squid denies the [fake] CONNECT without bumping the client
connection to serve a secure error message. That is _not_ what I would
expect because usually Squid bumps to serve errors, even when dealing
with non-bumping ssl_bump rules. However, I may be misinterpreting the
"unknown protocol" part; perhaps OpenSSL can use that phrase for an
unsupported TLS version as well? Or perhaps Squid failed to bump the
client for some reason?

Capture packets to see what Squid is sending to curl.


HTH,

Alex.

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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

James Lay
On Mon, 2017-01-23 at 19:54 -0700, Alex Rousskov wrote:
On 01/23/2017 04:28 PM, David Touzeau wrote:
ssl_bump peek ssl_step1 ssl_bump splice all sslproxy_flags DONT_VERIFY_PEER sslproxy_cert_error allow all
When connecting to mozilla.org using transparent, we receive this error: * About to connect() to www.mozilla.org port 443 (#0) * Trying 104.16.41.2... * connected * Connected to www.mozilla.org (104.16.41.2) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol * Closing connection #0 curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol And squid access.log 1485110919.564 3 192.168.1.236 TAG_NONE/403 6263 CONNECT 104.16.41.2:443 - HIER_NONE/- text/html
Amos, please note that the above failing test is done using curl, not some fancy/non-HTTP/websocket traffic from a "browser". David, you need to figure out why Squid is denying the intercepted connection attempt (the /403 part in your access.log). Check your http_access rules to start with. They were applied to the denied fake CONNECT request shown above. AFAICT, Squid denies the [fake] CONNECT without bumping the client connection to serve a secure error message. That is _not_ what I would expect because usually Squid bumps to serve errors, even when dealing with non-bumping ssl_bump rules. However, I may be misinterpreting the "unknown protocol" part; perhaps OpenSSL can use that phrase for an unsupported TLS version as well? Or perhaps Squid failed to bump the client for some reason? Capture packets to see what Squid is sending to curl. HTH, Alex.

Seems like pretty standard stuff:

Jan 23 20:09:04 (squid): 192.168.1.109 - - [23/Jan/2017:20:09:04 -0700] "CONNECT 104.16.40.2:443 HTTP/1.1" www.mozilla.org - 200 916167 TCP_TUNNEL:ORIGINAL_DST

TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 secp256r1

James

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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

Amos Jeffries
Administrator
> On Mon, 2017-01-23 at 19:54 -0700, Alex Rousskov wrote:
>> On 01/23/2017 04:28 PM, David Touzeau wrote:
>>>
>>> ssl_bump peek ssl_step1
>>> ssl_bump splice all
>>>
>>> sslproxy_flags DONT_VERIFY_PEER
>>> sslproxy_cert_error allow all
>>
>>>
>>> When connecting to mozilla.org using transparent, we receive this
>>> error:
>>>
>>> * About to connect() to www.mozilla.org port 443 (#0)
>>> *   Trying 104.16.41.2...
>>> * connected
>>> * Connected to www.mozilla.org (104.16.41.2) port 443 (#0)
>>> * successfully set certificate verify locations:
>>> *   CAfile: none
>>>   CApath: /etc/ssl/certs
>>> * SSLv3, TLS handshake, Client hello (1):
>>> * error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
>>> protocol
>>> * Closing connection #0
>>> curl: (35) error:140770FC:SSL
>>> routines:SSL23_GET_SERVER_HELLO:unknown
>>> protocol
>>>
>>>
>>> And squid access.log
>>>
>>> 1485110919.564      3 192.168.1.236 TAG_NONE/403 6263 CONNECT
>>> 104.16.41.2:443 - HIER_NONE/- text/html
>> Amos, please note that the above failing test is done using curl, not
>> some fancy/non-HTTP/websocket traffic from a "browser".

Doh! Thats why its weird. The error is coming from curls OpenSSL
library, not Squid's one.


>>
>> David, you need to figure out why Squid is denying the intercepted
>> connection attempt (the /403 part in your access.log). Check your
>> http_access rules to start with. They were applied to the denied fake
>> CONNECT request shown above.
>>
>> AFAICT, Squid denies the [fake] CONNECT without bumping the client
>> connection to serve a secure error message. That is _not_ what I
>> would
>> expect because usually Squid bumps to serve errors, even when dealing
>> with non-bumping ssl_bump rules. However, I may be misinterpreting
>> the
>> "unknown protocol" part; perhaps OpenSSL can use that phrase for an
>> unsupported TLS version as well? Or perhaps Squid failed to bump the
>> client for some reason?
>>
>> Capture packets to see what Squid is sending to curl.
>>


On 24/01/2017 4:15 p.m., James Lay wrote:
> Seems like pretty standard stuff:
> Jan 23 20:09:04 (squid): 192.168.1.109 - - [23/Jan/2017:20:09:04 -0700]
> "CONNECT 104.16.40.2:443 HTTP/1.1" www.mozilla.org - 200 916167
> TCP_TUNNEL:ORIGINAL_DST
> TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 secp256r1
> James

This is a different log trace from David's.

Here Squid is setting up a TUNNEL to the clients original dst-IP,
successfully. Any TLS funky stuff going on for this transaction is done
directly between server and client. Squid's only involvement is to peek
at the Hello messages and record them for its log.

But some of those details (ie the agreed cipher) come from the
ServerHello on successful TLS setup. So I think no errors happened in
that log entries transaction.

Amos

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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

David Touzeau-3

This is a different log trace from David's.

Here Squid is setting up a TUNNEL to the clients original dst-IP,
successfully. Any TLS funky stuff going on for this transaction is done
directly between server and client. Squid's only involvement is to peek at
the Hello messages and record them for its log.

But some of those details (ie the agreed cipher) come from the ServerHello
on successful TLS setup. So I think no errors happened in that log entries
transaction.

Amos

______________________________________________________________________________________________


Hi tried with

acl nossl dst 104.16.41.2
acl nossl2 dstdomain -i .mozilla.org
ssl_bump splice nossl
ssl_bump splice nossl2
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 all
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

1485252508.663      2 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html
1485252509.385      2 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html

Using squid port 3128 without any bump allow accessing to mozilla

So if there are any acl it will be blocked on both.

Return back to list with a full debug mode..


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

Re: [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

David Touzeau-3


-----Message d'origine-----
De : squid-users [mailto:[hidden email]] De la part de David Touzeau
Envoyé : mardi 24 janvier 2017 11:42
À : [hidden email]
Objet : Re: [squid-users] [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol


This is a different log trace from David's.

Here Squid is setting up a TUNNEL to the clients original dst-IP, successfully. Any TLS funky stuff going on for this transaction is done directly between server and client. Squid's only involvement is to peek at the Hello messages and record them for its log.

But some of those details (ie the agreed cipher) come from the ServerHello on successful TLS setup. So I think no errors happened in that log entries transaction.

Amos

______________________________________________________________________________________________


Hi tried with

acl nossl dst 104.16.41.2
acl nossl2 dstdomain -i .mozilla.org
ssl_bump splice nossl
ssl_bump splice nossl2
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 all
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all

1485252508.663      2 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html
1485252509.385      2 192.168.1.236 TAG_NONE/403 6263 CONNECT
104.16.41.2:443 - HIER_NONE/- text/html

Using squid port 3128 without any bump allow accessing to mozilla

So if there are any acl it will be blocked on both.

Return back to list with a full debug mode..


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



Using acl nossl ssl::server_name working like a charme.
Also after restarting C-ICAP everything is fine.
Thanks everyone

* * * TOPIC CLOSED * * *


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