[squid-users] Seeking Help with SSL Bump Configuration, for ECDSA Ciphers in Squid

Wed Sep 27 21:39:16 UTC 2023

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 at gmail.com
>     <mailto:nikhildeshpande18 at gmail.com>>
>     To: Shyam varun <shyam3898 at gmail.com <mailto:shyam3898 at gmail.com>>
>     Cc: squid-users at lists.squid-cache.org
>     <mailto:squid-users at lists.squid-cache.org>, jrose at qualys.com
>     <mailto:jrose at qualys.com>
>     Subject: Re: [squid-users] Seeking Help with SSL Bump Configuration
>              for ECDSA Ciphers in Squid
>     Message-ID:
>             
>     <CALO-o=xTe18tuGww-gsr-vAVKMJqRai1ZvNR-hRqaToWXp1NGQ at mail.gmail.com
>     <mailto:xTe18tuGww-gsr-vAVKMJqRai1ZvNR-hRqaToWXp1NGQ at mail.gmail.com>>
>     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 at gmail.com
>     <mailto:shyam3898 at gmail.com>> 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
>     ********************************************