On 2023-09-27 08:22, nikhil deshpande wrote:
[Question]: Are you trying to bump TLS client connections when and only when the TLS
client is offering to use one of those ciphers in its ClientHello
message? Or do you want Squid to use one of those ciphers when bumping
all TLS client connections? Or something else? Please clarify.
[Answer]:In our case client is offering these two
ciphers (ECDHE-ECDSA-AES256-GCM-SHA384 &
ECDHE-ECDSA-AES128-GCM-SHA256) in Client Hello but squid is failing
to complete handshake with client while performing SSL-Bump.
We have attached logs and network capture.
Thank you for sharing that information!
If I start "openssl s_server" configured with the certificate generated
by Squid (as extracted from your debugging log), then that server
rejects an "openssl s_client" TLS ClientHello offering the two TLS v1.2
ciphers you have mentioned above. The server error in this case is "no
shared cipher".
If I remove the cipher restriction from the client, the test connection
succeeds. The negotiated cipher in this case is not one of the two:
ECDHE-RSA-AES256-GCM-SHA384
This is not my area of expertise, but I believe that the certificate
generated by Squid (and mimicking true origin server certificate
properties) is not compatible with ciphers supported by the client: The
ciphers want ECDSA certificate authentication algorithm, but the
generated certificate uses RSA authentication. The two sides cannot
communicate because they do not share an authentication algorithm.
Public Key Algorithm: rsaEncryption
BTW, I get similar results when s_client talks to the true origin server
in question _without_ restricting s_client ciphers: Successful TLS with
ECDHE-RSA-AES256-GCM-SHA384 cipher.
If I do restrict s_client ciphers when talking to true origin server,
then the test transaction also succeeds, but the server returns a
different certificate and a different cipher is negotiated:
ECDHE-ECDSA-AES256-GCM-SHA384. In this case, the certificate says:
Public Key Algorithm: id-ecPublicKey
These true origin server experiments support my explanation above.
Why does the origin server send Squid a certificate that the client does
not support? I believe that happens because Squid _adds_ client cipher
to Squid-generated ClientHello: Your packet capture does show the two
client ciphers in from-Squid ClientHello, but that ClientHello has 29
other ciphers as well! The origin server then picks a different cipher
offered by Squid and sends a matching server certificate (the one the
client cannot support).
Going forward, I see two possible options, both requiring non-trivial
Squid source code modifications:
1. Stop adding OpenSSL ciphers to mimicked ClientHello
I speculate that if Squid were to exactly mimic client cipher offerings
in its ClientHello sent to the origin server (instead of adding
client-supported ciphers to OpenSSL-supported ones), then the origin
server would have returned a different certificate, Squid would have
mimicked that, and the client-Squid TLS connection would have succeeded.
I do not know whether there are cases where mimicking the client ciphers
exactly would prevent Squid from successfully bumping the connection.
I do not know how easy it would be for Squid to stop OpenSSL from adding
all supported ciphers.
2. Mimic origin certificate to be compatible with client ciphers.
For example, when the two algorithms differ, instead of mimicking the
certificate authentication algorithm in the origin server certificate,
use the algorithm compatible with client-offered ciphers.
Doing so will allow Squid to bump more connections, and even increase
security guarantees in some cases (where the algorithm used by the
server is weaker than what client and Squid can support), but may also
weaken security guarantees in some cases (in opposite cases).
Others on this mailing list may suggest better alternatives.
https://wiki.squid-cache.org/SquidFaq/AboutSquid#how-to-add-a-new-squid-feature-enhance-of-fix-something
[Question]: FWIW, to restrict Squid use of ciphers on accepted TLS client
connections, use the http_port (or https_port) "cipher" option.
[Answer]: We dontwant to restrict to usethisspecific ciphers only. We
wanted that Squid should use strong ciphers.
Squid cannot use strong ciphers with the client (_and_ bump the
connection). If you want Squid to always use strong ciphers with the
server, but still bump the weaker client connection, then you need a
combination of two things (at least) AFAICT:
* Option 2 above (Mimic origin certificate to be client-compatible)
* tls_outgoing_options that prohibit weak ciphers (already supported?)
One more point I wanted to add here is that this issue is getting
reproduced with latest squid also.
Yes, the problem you are facing affects all moderns Squids AFAICT.
Please respond to the _individual_ mailing list message on your thread,
not the digest with all the messages.
Thank you,
Alex.
Message: 3
Date: Mon, 25 Sep 2023 15:01:05 +0530
From: nikhil deshpande <nikhildeshpande18@xxxxxxxxx
<mailto:nikhildeshpande18@xxxxxxxxx>>
To: Shyam varun <shyam3898@xxxxxxxxx <mailto:shyam3898@xxxxxxxxx>>
Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>, jrose@xxxxxxxxxx
<mailto:jrose@xxxxxxxxxx>
Subject: Re: Seeking Help with SSL Bump Configuration
for ECDSA Ciphers in Squid
Message-ID:
<CALO-o=xTe18tuGww-gsr-vAVKMJqRai1ZvNR-hRqaToWXp1NGQ@xxxxxxxxxxxxxx
<mailto:xTe18tuGww-gsr-vAVKMJqRai1ZvNR-hRqaToWXp1NGQ@xxxxxxxxxxxxxx>>
Content-Type: text/plain; charset="utf-8"
Hi team,
Any update on this?
Regards,
Nikhil
On Thu, Sep 14, 2023 at 6:05?PM Shyam varun <shyam3898@xxxxxxxxx
<mailto:shyam3898@xxxxxxxxx>> wrote:
> Dear Squid Mailing List Community,
>
> I hope this email finds you well. I am currently working on
configuring
> SSL bump in Squid proxy server to support ECDSA ciphers, and I am
seeking
> assistance with a particular issue I've encountered.
>
> To provide some context:
>
> - *Squid Version:* Squid 5.2
> - *OpenSSL Version*: OpenSSL 1.1.1l
> - *OS:* Alpine Linux v3.16
> -
> *Squid Configuration: *
>
> * sslproxy_cert_error allow all*
>
> * sslcrtd_program /usr/lib/squid/security_file_certgen -s
/var/lib/ssl_db
> -M 4MB*
>
>
> * http_port 3129 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB
cert=/opt/ssl/intermediate_certificate.pem
> key=/opt/ssl/intermediate_key.pem
options=SINGLE_DH_USE,SINGLE_ECDH_USE
> tls-dh=/opt/dhparam.pem*
>
>
> * tls_outgoing_options min-version=1.1 options=NO_SSLv3*
>
>
> * acl step1 at_step SslBump1*
>
> * ssl_bump peek step1*
>
> * ssl_bump bump all*
>
>
> The goal of my configuration is to enable SSL bump for ECDSA ciphers,
> specifically the "ECDHE-ECDSA-AES256-GCM-SHA384" and
> "ECDHE-ECDSA-AES128-GCM-SHA256" cipher suites. However, I've run into
> challenges and issues while trying to achieve this.
>
> *Things I tried:*
>
> 1. I created an ECDSA-based certificate chain using OpenSSL.
> 2. I configured the ECDSA-based certificate certs in squid as
shown in
> above snippet but still not able to make it work.
>
>
> I've thoroughly reviewed the Squid documentation and online
resources, but
> I haven't been able to resolve these issues on my own.
>
> I would greatly appreciate any guidance, insights, or assistance
from the
> Squid community regarding the proper configuration for SSL bump
with ECDSA
> ciphers. If you have successfully configured Squid to support
ECDSA ciphers
> or if you have expertise in this area, your input would be
invaluable.
>
> Thank you in advance for your time and support. I look forward to
your
> responses and insights.
>
End of squid-users Digest, Vol 109, Issue 19
********************************************
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
