Fwd: Squid 4.8 with OpenSSL 1.1.1d

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

Fwd: Squid 4.8 with OpenSSL 1.1.1d

Yaroslav Pushko
Hi All

We use Squid 4.8 with OpenSSL 1.1.1d in a transparent mode for peek and splice interception.

With this version, we lost the possibility to connect to any HTTPS site.

There are a few issues: 

Support TLSv1.2.
OpenSSL 1.1.1d adds support of TLSv1.3. These changes added some kind of guard if we perform a handshake with a lower version of the TLS protocol than we support. In this scenario, we receive downgrade fallback error.
Handshake version TLSv1.2 vs. max support TLSv1.3.
In such case, we have the next error:
ERROR: negotiating TLS on FD 19: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback (1/-1/0)

OpenSSL already provided a fix for it. You can configure SSL session to use option SSL_MODE_SEND_FALLBACK_SCSV and setting SSL max proto version for current SSL session, but squid not yet supported these features.

You can find a patch in the attachments, will be grateful for the review.

The issue with TLS 1.3 support, we are still investigating, any advice will be pleasant.

Best regards,
Yaroslav Pushko.
-- 
Best Regards,
Yaroslav Pushko | Senior 
Software Engineer
GlobalLogic
P +380971842774  M +380634232226 S dithard
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt

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

squid-4.8-added_max_support_tlsversion.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Squid 4.8 with OpenSSL 1.1.1d

Alex Rousskov
On 12/17/19 9:00 AM, Yaroslav Pushko wrote:

> Hi All
>
> We use Squid 4.8 with OpenSSL 1.1.1d in a transparent mode for peek and
> splice interception.
>
> With this version, we lost the possibility to connect to any HTTPS site.
>
> There are a few issues: 
>
>   * support TLSv1.2 sites (already discussed in
>     thread http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-ssl-choose-client-version-inappropriate-fallback-on-some-sites-when-using-TLS1-2-td4688258.html )
>   * support TLSv1.3 sites.

Please see
http://lists.squid-cache.org/pipermail/squid-users/2019-December/021435.html
for several alternative fixes. AFAICT, those fixes are more flexible
and, after polishing, appropriate for the official inclusion because
they make fewer assumptions about the values sent via the supported
versions extension.

It is possible that your SSL_MODE_SEND_FALLBACK_SCSV change needs to be
integrated with the other fixes. Thank you for sharing that idea!

Alex.


> Support TLSv1.2.
>
>     OpenSSL 1.1.1d adds support of TLSv1.3. These changes added some
>     kind of guard if we perform a handshake with a lower version of the
>     TLS protocol than we support. In this scenario, we receive downgrade
>     fallback error.
>     Handshake version TLSv1.2 vs. max support TLSv1.3.
>
>     In such case, we have the next error:
>
>         ERROR: negotiating TLS on FD 19: error:1425F175:SSL
>         routines:ssl_choose_client_version:inappropriate fallback (1/-1/0)
>
>
>     OpenSSL already provided a fix for it. You can configure SSL session
>     to use option SSL_MODE_SEND_FALLBACK_SCSV and setting SSL max proto
>     version for current SSL session, but squid not yet supported these
>     features.
>
>     You can find a patch in the attachments, will be grateful for the
>     review.
>
>
> The issue with TLS 1.3 support, we are still investigating, any advice
> will be pleasant.
>
> Best regards,
> Yaroslav Pushko.
> -- 
> Best Regards,
> Yaroslav Pushko | Senior *Software Engineer*
> GlobalLogic
> P +380971842774  M +380634232226 S dithard
> www.globallogic.com <http://www.globallogic.com/>
> http://www.globallogic.com/email_disclaimer.txt
>
> _______________________________________________
> 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: Fwd: Squid 4.8 with OpenSSL 1.1.1d

Yaroslav Pushko
Hi Alex,

Thank you for the reply, we update our patch with provided changes.

One more thing, with TLSv1.3.

There is site https://3frontoffice.tre.se/login with specific behavior in the Chrome browser OS X El Capitan.

During establishing TLSv1.3 handshake after successfully send our Client Hello, the server answers us with Hello Retry Request.

In Squid this behavior interprets next Client Hello peek successfully and Hello Retry Request peeks as Server Hello.
After that, we splice it and send to OpenSSL and fail handshake establishing.

Did you already notice such behavior? 
Did you have some investigation on this issue, 
any advice will be pleasant?

Best regards,
Yaroslav.


On Tue, Dec 17, 2019 at 4:39 PM Alex Rousskov <[hidden email]> wrote:
On 12/17/19 9:00 AM, Yaroslav Pushko wrote:
> Hi All
>
> We use Squid 4.8 with OpenSSL 1.1.1d in a transparent mode for peek and
> splice interception.
>
> With this version, we lost the possibility to connect to any HTTPS site.
>
> There are a few issues: 
>
>   * support TLSv1.2 sites (already discussed in
>     thread http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-ssl-choose-client-version-inappropriate-fallback-on-some-sites-when-using-TLS1-2-td4688258.html )
>   * support TLSv1.3 sites.

Please see
http://lists.squid-cache.org/pipermail/squid-users/2019-December/021435.html
for several alternative fixes. AFAICT, those fixes are more flexible
and, after polishing, appropriate for the official inclusion because
they make fewer assumptions about the values sent via the supported
versions extension.

It is possible that your SSL_MODE_SEND_FALLBACK_SCSV change needs to be
integrated with the other fixes. Thank you for sharing that idea!

Alex.


> Support TLSv1.2.
>
>     OpenSSL 1.1.1d adds support of TLSv1.3. These changes added some
>     kind of guard if we perform a handshake with a lower version of the
>     TLS protocol than we support. In this scenario, we receive downgrade
>     fallback error.
>     Handshake version TLSv1.2 vs. max support TLSv1.3.
>
>     In such case, we have the next error:
>
>         ERROR: negotiating TLS on FD 19: error:1425F175:SSL
>         routines:ssl_choose_client_version:inappropriate fallback (1/-1/0)
>
>
>     OpenSSL already provided a fix for it. You can configure SSL session
>     to use option SSL_MODE_SEND_FALLBACK_SCSV and setting SSL max proto
>     version for current SSL session, but squid not yet supported these
>     features.
>
>     You can find a patch in the attachments, will be grateful for the
>     review.
>
>
> The issue with TLS 1.3 support, we are still investigating, any advice
> will be pleasant.
>
> Best regards,
> Yaroslav Pushko.
> -- 
> Best Regards,
> Yaroslav Pushko | Senior *Software Engineer*
> GlobalLogic
> P +380971842774  M +380634232226 S dithard
> www.globallogic.com <http://www.globallogic.com/>
> http://www.globallogic.com/email_disclaimer.txt
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>



--
Best Regards,
Yaroslav Pushko | Senior 
Software Engineer
GlobalLogic
P +380971842774  M +380634232226 S dithard
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

Re: Fwd: Squid 4.8 with OpenSSL 1.1.1d

Alex Rousskov
On 1/3/20 8:40 AM, Yaroslav Pushko wrote:

> During establishing TLSv1.3 handshake after successfully send our Client
> Hello, the server answers us with Hello Retry Request.

HelloRetryRequest is a TLS v1.3 feature that tells the client to restart
the negotiation (with additional info). Please keep in mind that:

1. If Squid peeks at TLS v1.3 data from the server, bumping the
connection is likely to be impossible. Since plain text TLS v1.3 server
bytes should not contain useful information, and encrypted TLS v1.3
server bytes are useless for a peeking transaction (and deadly for a
bumping transaction), the decision to bump such a transaction has to be
done no later than step2 (i.e. no later than after receiving TLS Client
Hello).

2. Squid TLS parser does not know about TLS v1.3 HelloRetryRequest
messages yet. Thus, if Squid is asked to parse from-server traffic
containing that message, Squid may not do what it should do (whatever
that is).

The changes discussed earlier in this email thread do not include adding
support for HelloRetryRequest, but they may help with the overall
situation by correctly identifying TLS v1.3 traffic. I think we are very
close to submitting an official pull request with these changes.

HTH,

Alex.


> In Squid this behavior interprets next Client Hello peek
> successfully and Hello Retry Request peeks as Server Hello.
> After that, we splice it and send to OpenSSL and fail handshake
> establishing.
>
> Did you already notice such behavior? 
> Did you have some investigation on this issue, any advice will be pleasant?
>
> Best regards,
> Yaroslav.
>
>
> On Tue, Dec 17, 2019 at 4:39 PM Alex Rousskov wrote:
>
>     On 12/17/19 9:00 AM, Yaroslav Pushko wrote:
>     > Hi All
>     >
>     > We use Squid 4.8 with OpenSSL 1.1.1d in a transparent mode for
>     peek and
>     > splice interception.
>     >
>     > With this version, we lost the possibility to connect to any HTTPS
>     site.
>     >
>     > There are a few issues: 
>     >
>     >   * support TLSv1.2 sites (already discussed in
>     >   
>      thread http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-ssl-choose-client-version-inappropriate-fallback-on-some-sites-when-using-TLS1-2-td4688258.html )
>     >   * support TLSv1.3 sites.
>
>     Please see
>     http://lists.squid-cache.org/pipermail/squid-users/2019-December/021435.html
>     for several alternative fixes. AFAICT, those fixes are more flexible
>     and, after polishing, appropriate for the official inclusion because
>     they make fewer assumptions about the values sent via the supported
>     versions extension.
>
>     It is possible that your SSL_MODE_SEND_FALLBACK_SCSV change needs to be
>     integrated with the other fixes. Thank you for sharing that idea!
>
>     Alex.
>
>
>     > Support TLSv1.2.
>     >
>     >     OpenSSL 1.1.1d adds support of TLSv1.3. These changes added some
>     >     kind of guard if we perform a handshake with a lower version
>     of the
>     >     TLS protocol than we support. In this scenario, we receive
>     downgrade
>     >     fallback error.
>     >     Handshake version TLSv1.2 vs. max support TLSv1.3.
>     >
>     >     In such case, we have the next error:
>     >
>     >         ERROR: negotiating TLS on FD 19: error:1425F175:SSL
>     >         routines:ssl_choose_client_version:inappropriate fallback
>     (1/-1/0)
>     >
>     >
>     >     OpenSSL already provided a fix for it. You can configure SSL
>     session
>     >     to use option SSL_MODE_SEND_FALLBACK_SCSV and setting SSL max
>     proto
>     >     version for current SSL session, but squid not yet supported these
>     >     features.
>     >
>     >     You can find a patch in the attachments, will be grateful for the
>     >     review.
>     >
>     >
>     > The issue with TLS 1.3 support, we are still investigating, any advice
>     > will be pleasant.
>     >
>     > Best regards,
>     > Yaroslav Pushko.
>     > -- 
>     > Best Regards,
>     > Yaroslav Pushko | Senior *Software Engineer*
>     > GlobalLogic
>     > P +380971842774  M +380634232226 S dithard
>     > www.globallogic.com <http://www.globallogic.com>
>     <http://www.globallogic.com/>
>     > http://www.globallogic.com/email_disclaimer.txt
>     >
>     > _______________________________________________
>     > squid-users mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > http://lists.squid-cache.org/listinfo/squid-users
>     >
>
>
>
> --
> Best Regards,
> Yaroslav Pushko | Senior *Software Engineer*
> GlobalLogic
> P +380971842774  M +380634232226 S dithard
> www.globallogic.com <http://www.globallogic.com/>
> <http://www.globallogic.com/>
> http://www.globallogic.com/email_disclaimer.txt

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

Re: Fwd: Squid 4.8 with OpenSSL 1.1.1d

John Sweet-Escott
Alex

Really looking forward to this patch being submitted and hopefully accepted. Let me know if it would be helpful for me to do some independent testing of the patch.

John

> On 6 Jan 2020, at 14:53, Alex Rousskov <[hidden email]> wrote:
>
> On 1/3/20 8:40 AM, Yaroslav Pushko wrote:
>
>> During establishing TLSv1.3 handshake after successfully send our Client
>> Hello, the server answers us with Hello Retry Request.
>
> HelloRetryRequest is a TLS v1.3 feature that tells the client to restart
> the negotiation (with additional info). Please keep in mind that:
>
> 1. If Squid peeks at TLS v1.3 data from the server, bumping the
> connection is likely to be impossible. Since plain text TLS v1.3 server
> bytes should not contain useful information, and encrypted TLS v1.3
> server bytes are useless for a peeking transaction (and deadly for a
> bumping transaction), the decision to bump such a transaction has to be
> done no later than step2 (i.e. no later than after receiving TLS Client
> Hello).
>
> 2. Squid TLS parser does not know about TLS v1.3 HelloRetryRequest
> messages yet. Thus, if Squid is asked to parse from-server traffic
> containing that message, Squid may not do what it should do (whatever
> that is).
>
> The changes discussed earlier in this email thread do not include adding
> support for HelloRetryRequest, but they may help with the overall
> situation by correctly identifying TLS v1.3 traffic. I think we are very
> close to submitting an official pull request with these changes.
>
> HTH,
>
> Alex.
>
>
>> In Squid this behavior interprets next Client Hello peek
>> successfully and Hello Retry Request peeks as Server Hello.
>> After that, we splice it and send to OpenSSL and fail handshake
>> establishing.
>>
>> Did you already notice such behavior?
>> Did you have some investigation on this issue, any advice will be pleasant?
>>
>> Best regards,
>> Yaroslav.
>>
>>
>> On Tue, Dec 17, 2019 at 4:39 PM Alex Rousskov wrote:
>>
>>>    On 12/17/19 9:00 AM, Yaroslav Pushko wrote:
>>> Hi All
>>>
>>> We use Squid 4.8 with OpenSSL 1.1.1d in a transparent mode for
>>    peek and
>>> splice interception.
>>>
>>> With this version, we lost the possibility to connect to any HTTPS
>>    site.
>>>
>>> There are a few issues:
>>>
>>>    * support TLSv1.2 sites (already discussed in
>>>    
>>     thread http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-ssl-choose-client-version-inappropriate-fallback-on-some-sites-when-using-TLS1-2-td4688258.html )
>>>    * support TLSv1.3 sites.
>>
>>    Please see
>>    http://lists.squid-cache.org/pipermail/squid-users/2019-December/021435.html
>>    for several alternative fixes. AFAICT, those fixes are more flexible
>>    and, after polishing, appropriate for the official inclusion because
>>    they make fewer assumptions about the values sent via the supported
>>    versions extension.
>>
>>    It is possible that your SSL_MODE_SEND_FALLBACK_SCSV change needs to be
>>    integrated with the other fixes. Thank you for sharing that idea!
>>
>>    Alex.
>>
>>
>>> Support TLSv1.2.
>>>
>>>      OpenSSL 1.1.1d adds support of TLSv1.3. These changes added some
>>>      kind of guard if we perform a handshake with a lower version
>>    of the
>>>      TLS protocol than we support. In this scenario, we receive
>>    downgrade
>>>      fallback error.
>>>      Handshake version TLSv1.2 vs. max support TLSv1.3.
>>>
>>>      In such case, we have the next error:
>>>
>>>          ERROR: negotiating TLS on FD 19: error:1425F175:SSL
>>>          routines:ssl_choose_client_version:inappropriate fallback
>>    (1/-1/0)
>>>
>>>
>>>      OpenSSL already provided a fix for it. You can configure SSL
>>    session
>>>      to use option SSL_MODE_SEND_FALLBACK_SCSV and setting SSL max
>>    proto
>>>      version for current SSL session, but squid not yet supported these
>>>      features.
>>>
>>>      You can find a patch in the attachments, will be grateful for the
>>>      review.
>>>
>>>
>>> The issue with TLS 1.3 support, we are still investigating, any advice
>>> will be pleasant.
>>>
>>> Best regards,
>>> Yaroslav Pushko.
>>> --
>>> Best Regards,
>>> Yaroslav Pushko | Senior *Software Engineer*
>>> GlobalLogic
>>> P +380971842774  M +380634232226 S dithard
>>> www.globallogic.com <http://www.globallogic.com>
>>    <http://www.globallogic.com/>
>>> http://www.globallogic.com/email_disclaimer.txt
>>>
>>> _______________________________________________
>>> squid-users mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Yaroslav Pushko | Senior *Software Engineer*
>> GlobalLogic
>> P +380971842774  M +380634232226 S dithard
>> www.globallogic.com <http://www.globallogic.com/>
>> <http://www.globallogic.com/>
>> http://www.globallogic.com/email_disclaimer.txt
>
> _______________________________________________
> 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