Re: [squid-users] fallback to TLS1.0 if server closes TLS1.2?

> On 04/11/2014 11:01 PM, Amm wrote:

>> I recently upgraded OpenSSL from 1.0.0 to 1.0.1 (which supports TLS1.2)
>>
>> Now there is this (BROKEN) bank site:
>>
>> https://www.mahaconnect.in
>>
>> This site closes connection if you try TLS1.2 or TLS1.1
>>
>> When squid tries to connect, it says:
>>
>> Failed to establish a secure connection to 125.16.24.200
>>
>> The system returned: (71) Protocol error (TLS code:
>> SQUID_ERR_SSL_HANDSHAKE) Handshake with SSL server failed:
>> error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
>> failure
>>
>> The site works, if I specify:
>> sslproxy_options NO_TLSv1_1
>>
>>
>> But then it stops using TLS1.2 for sites supporting it.
>>
>> When I try in Chrome or Firefox without proxy settings, they auto detect
>> this and fallback to TLS1.0/SSLv3.
>>
>> So my question is shouldn't squid fallback to TLS1.0 when TLS1.2/1.1
>> fails? Just like Chrome/Firefox does?
>>
>> (PS: I can not tell bank to upgrade)
>>
>> Amm.

On 07/10/2014 09:27 AM, Vadim Rogoziansky wrote:

> Do you have any ideas how we can resolve it? I have the same issue.

I believe a proper support for "secure version fallback" requires some
development. I do not know of anybody working on this feature right now,
and there may be no formal feature requests on bugzilla, but it has been
informally requested before.

In addition to TLS v1.2->1.0 fallback, there are also servers that do
not support SSL Hellos that advertise TLS, so there is a need for
TLS->SSL fallback. Furthermore, some admins want Squid to talk TLS with
the client even if the server does not support TLS. Simply propagating
from-server "I want SSL" errors to the TLS-speaking client does not work
in such an environment, and a proper to-server fallback is needed.

Cheers,

Alex.
Received on Fri Jul 11 2014 - 04:15:23 MDT