Requesting specific old ciphers for TLS certificates

Help
1

From another recent server migration, I'm again having some trouble getting older TLS 1.0 ciphers to work again, as in here: New certificates missing TLS ciphers

I went ahead and did the same steps that previously seemed to work, but for some reason that didn't suffice here, as clients are getting TLS internal error during the handshake and nothing works.

I went ahead and ran nmap against both the old, working system and the new, nonworking system, to compare:

GOOD:

PORT      STATE SERVICE
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|_  least strength: A


BAD:

PORT      STATE SERVICE
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

It seems that I got ecdh_x25519 and what I want is secp256r1. The command that was originally used was: ~/.acme.sh/acme.sh --set-default-ca --server letsencrypt --keylength 2048 --always-force-new-domain-key --issue --alpn --cert-home /etc/letsencrypt -d example.com

The keylength argument had worked previously, but for some reason, this is giving me newer, incompatible ciphers now, rather than the older ciphers that I need. I can find some documentation of other parameters for certbot (which was in use on the old system) but not for acme.sh (which is in use on the new system). Is there some way to request that Let's Encrypt use the ciphers in the working example at the top here? The uppercase name is actually the same, but what's in parentheses is different, so I'm not sure if that's why --keylength failed to do what I needed here.

Thank you!

2

No, because that's not part of the certificate. It's a webserver configuration.

2 Likes
3

It's not for a webserver specifically, but the application configuration has not changed at all, and looking at release notes, I don't see any changes to the behavior, either.

Is there a good way to confirm the certificate supports what I want here and that the issue is with what's loading the certificate? I did cat both of the certs and they look similar (3 certificates in the full chain). If I decode them using a tool they both seem to be RSA-SHA256, sha256WithRSAEncryption; is there anything else that could be different that would matter or no?

4

Consider it confirmed. The only thing that might be different about the certificate that could impact cipher suite choices is whether it's RSA or ECDSA. So if both cases you're looking at are RSA, then there isn't any difference. Beyond the key type, it's entirely about the server and client configuration and which ciphers they can agree on.

5 Likes
5

Thanks, this does indeed seem to be the case. This did involve a jump from Debian 10 to Debian 12 and a corresponding jump in OpenSSL, but it seems like it should be fixable.

I did notice in the packet captures, a successful handshake results in the following cipher being chosen:

TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

This is the third cipher in the Client Hello list of ciphers, interestingly.

In the failing handshake, the Server Hello contains TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039), which is the first cipher in the Client Hello, but the server hello is immediately followed by the Fatal, Internal Error packet.

Even more interestingly, according to nmap, in the working scenario, it's client cipher preference and in the nonworking, it's server cipher preference, though the test above seems to suggest the opposite.

I'm trying to see if there's a way to force TLS_RSA_WITH_AES_256_CBC_SHA, since I know that works, but I've been having difficulty in picking that out. It doesn't show up in the output of openssl s_client -cipher on either machine:

AES128-GCM-SHA256              DHE-PSK-AES256-CBC-SHA384      ECDHE-ECDSA-AES128-GCM-SHA256  ECDHE-PSK-AES256-CBC-SHA384    PSK-AES128-CBC-SHA256          RSA-PSK-AES256-CBC-SHA384
AES128-SHA                     DHE-PSK-AES256-GCM-SHA384      ECDHE-ECDSA-AES128-SHA         ECDHE-PSK-CHACHA20-POLY1305    PSK-AES128-GCM-SHA256          RSA-PSK-AES256-GCM-SHA384
AES128-SHA256                  DHE-PSK-CHACHA20-POLY1305      ECDHE-ECDSA-AES128-SHA256      ECDHE-RSA-AES128-GCM-SHA256    PSK-AES256-CBC-SHA             RSA-PSK-CHACHA20-POLY1305
AES256-GCM-SHA384              DHE-RSA-AES128-GCM-SHA256      ECDHE-ECDSA-AES256-GCM-SHA384  ECDHE-RSA-AES128-SHA           PSK-AES256-CBC-SHA384          SRP-AES-128-CBC-SHA
AES256-SHA                     DHE-RSA-AES128-SHA             ECDHE-ECDSA-AES256-SHA         ECDHE-RSA-AES128-SHA256        PSK-AES256-GCM-SHA384          SRP-AES-256-CBC-SHA
AES256-SHA256                  DHE-RSA-AES128-SHA256          ECDHE-ECDSA-AES256-SHA384      ECDHE-RSA-AES256-GCM-SHA384    PSK-CHACHA20-POLY1305          SRP-RSA-AES-128-CBC-SHA
DHE-PSK-AES128-CBC-SHA         DHE-RSA-AES256-GCM-SHA384      ECDHE-ECDSA-CHACHA20-POLY1305  ECDHE-RSA-AES256-SHA           RSA-PSK-AES128-CBC-SHA         SRP-RSA-AES-256-CBC-SHA
DHE-PSK-AES128-CBC-SHA256      DHE-RSA-AES256-SHA             ECDHE-PSK-AES128-CBC-SHA       ECDHE-RSA-AES256-SHA384        RSA-PSK-AES128-CBC-SHA256      TLS_AES_128_GCM_SHA256
DHE-PSK-AES128-GCM-SHA256      DHE-RSA-AES256-SHA256          ECDHE-PSK-AES128-CBC-SHA256    ECDHE-RSA-CHACHA20-POLY1305    RSA-PSK-AES128-GCM-SHA256      TLS_AES_256_GCM_SHA384
DHE-PSK-AES256-CBC-SHA         DHE-RSA-CHACHA20-POLY1305      ECDHE-PSK-AES256-CBC-SHA       PSK-AES128-CBC-SHA             RSA-PSK-AES256-CBC-SHA         TLS_CHACHA20_POLY1305_SHA256

The applications themselves show what ciphers are available, too, but even there I don't see it listed exactly:

TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, DHE-DSS-AES256-GCM-SHA384, DHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305, DHE-RSA-CHACHA20-POLY1305, ECDHE-ECDSA-AES256-CCM8, ECDHE-ECDSA-AES256-CCM, DHE-RSA-AES256-CCM8, DHE-RSA-AES256-CCM, ECDHE-ECDSA-ARIA256-GCM-SHA384, ECDHE-ARIA256-GCM-SHA384, DHE-DSS-ARIA256-GCM-SHA384, DHE-RSA-ARIA256-GCM-SHA384, ADH-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, DHE-DSS-AES128-GCM-SHA256, DHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES128-CCM8, ECDHE-ECDSA-AES128-CCM, DHE-RSA-AES128-CCM8, DHE-RSA-AES128-CCM, ECDHE-ECDSA-ARIA128-GCM-SHA256, ECDHE-ARIA128-GCM-SHA256, DHE-DSS-ARIA128-GCM-SHA256, DHE-RSA-ARIA128-GCM-SHA256, ADH-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA384, DHE-RSA-AES256-SHA256, DHE-DSS-AES256-SHA256, ECDHE-ECDSA-CAMELLIA256-SHA384, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256, DHE-DSS-CAMELLIA256-SHA256, ADH-AES256-SHA256, ADH-CAMELLIA256-SHA256, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA256, DHE-DSS-AES128-SHA256, ECDHE-ECDSA-CAMELLIA128-SHA256, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-DSS-CAMELLIA128-SHA256, ADH-AES128-SHA256, ADH-CAMELLIA128-SHA256, ECDHE-ECDSA-AES256-SHA, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, DHE-RSA-CAMELLIA256-SHA, DHE-DSS-CAMELLIA256-SHA, AECDH-AES256-SHA, ADH-AES256-SHA, ADH-CAMELLIA256-SHA, ECDHE-ECDSA-AES128-SHA, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, DHE-RSA-SEED-SHA, DHE-DSS-SEED-SHA, DHE-RSA-CAMELLIA128-SHA, DHE-DSS-CAMELLIA128-SHA, AECDH-AES128-SHA, ADH-AES128-SHA, ADH-SEED-SHA, ADH-CAMELLIA128-SHA, RSA-PSK-AES256-GCM-SHA384, DHE-PSK-AES256-GCM-SHA384, RSA-PSK-CHACHA20-POLY1305, DHE-PSK-CHACHA20-POLY1305, ECDHE-PSK-CHACHA20-POLY1305, DHE-PSK-AES256-CCM8, DHE-PSK-AES256-CCM, RSA-PSK-ARIA256-GCM-SHA384, DHE-PSK-ARIA256-GCM-SHA384, AES256-GCM-SHA384, AES256-CCM8, AES256-CCM, ARIA256-GCM-SHA384, PSK-AES256-GCM-SHA384, PSK-CHACHA20-POLY1305, PSK-AES256-CCM8, PSK-AES256-CCM, PSK-ARIA256-GCM-SHA384, RSA-PSK-AES128-GCM-SHA256, DHE-PSK-AES128-GCM-SHA256, DHE-PSK-AES128-CCM8, DHE-PSK-AES128-CCM, RSA-PSK-ARIA128-GCM-SHA256, DHE-PSK-ARIA128-GCM-SHA256, AES128-GCM-SHA256, AES128-CCM8, AES128-CCM, ARIA128-GCM-SHA256, PSK-AES128-GCM-SHA256, PSK-AES128-CCM8, PSK-AES128-CCM, PSK-ARIA128-GCM-SHA256, AES256-SHA256, CAMELLIA256-SHA256, AES128-SHA256, CAMELLIA128-SHA256, ECDHE-PSK-AES256-CBC-SHA384, ECDHE-PSK-AES256-CBC-SHA, SRP-DSS-AES-256-CBC-SHA, SRP-RSA-AES-256-CBC-SHA, SRP-AES-256-CBC-SHA, RSA-PSK-AES256-CBC-SHA384, DHE-PSK-AES256-CBC-SHA384, RSA-PSK-AES256-CBC-SHA, DHE-PSK-AES256-CBC-SHA, ECDHE-PSK-CAMELLIA256-SHA384, RSA-PSK-CAMELLIA256-SHA384, DHE-PSK-CAMELLIA256-SHA384, AES256-SHA, CAMELLIA256-SHA, PSK-AES256-CBC-SHA384, PSK-AES256-CBC-SHA, PSK-CAMELLIA256-SHA384, ECDHE-PSK-AES128-CBC-SHA256, ECDHE-PSK-AES128-CBC-SHA, SRP-DSS-AES-128-CBC-SHA, SRP-RSA-AES-128-CBC-SHA, SRP-AES-128-CBC-SHA, RSA-PSK-AES128-CBC-SHA256, DHE-PSK-AES128-CBC-SHA256, RSA-PSK-AES128-CBC-SHA, DHE-PSK-AES128-CBC-SHA, ECDHE-PSK-CAMELLIA128-SHA256, RSA-PSK-CAMELLIA128-SHA256, DHE-PSK-CAMELLIA128-SHA256, AES128-SHA, SEED-SHA, CAMELLIA128-SHA, PSK-AES128-CBC-SHA256, PSK-AES128-CBC-SHA, PSK-CAMELLIA128-SHA256, ECDHE-ECDSA-NULL-SHA, ECDHE-RSA-NULL-SHA, AECDH-NULL-SHA, NULL-SHA256, ECDHE-PSK-NULL-SHA384, ECDHE-PSK-NULL-SHA256, ECDHE-PSK-NULL-SHA, RSA-PSK-NULL-SHA384, RSA-PSK-NULL-SHA256, DHE-PSK-NULL-SHA384, DHE-PSK-NULL-SHA256, RSA-PSK-NULL-SHA, DHE-PSK-NULL-SHA, NULL-SHA, NULL-MD5, PSK-NULL-SHA384, PSK-NULL-SHA256, PSK-NULL-SHA, DEFAULT, @SECLEVEL=1, @SECLEVEL=2, @SECLEVEL=3, @SECLEVEL=4, @SECLEVEL=5'

This one above is from the working machine, so somehow the available ciphers must make it work. And this actually does show up on the nonworking machine, but that isn't the cipher the server chooses. I'm thinking that the server is choosing the wrong cipher here, and for some reason, one that's not compatible with the client, but it seems strange I can't force this particular cipher just to make it work - does it go by another name I can use? Been having trouble finding what else it could be in these lists.

6

blowfish - OpenSSL 3.0 command fail to setting cipher - Stack Overflow
One of the key differences between OpenSSL 3.0 and earlier versions is that crypto algorithms are now supplied through "providers". Most commonly used ciphers are available in the "default" provider - which gets loaded by default. You are trying to use the blowfish cipher. That cipher is implemented in the "legacy" OpenSSL 3.0 provider:

https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html

3 Likes
7

Thanks, but I don't think this is it. I went ahead and did that so legacy is enabled now, but the same exact thing is happening as before. The server is choosing 0x39 cipher instead of 0x35. I wonder if I could make it work by disabling 0x39 (and 0x38, for that matter) to make it choose 0x35 as on the working server.

Unfortunately, I don't think I'm able to blacklist ciphers, only specify all the allowed ones explicitly, so that's why I'm a bit flummoxed that I can't seem to find an acceptable name for the cipher. I don't think these are legacy, actually. I seem SEED ciphers that showed up on the old server and are now also showing up on the new server, when I query the available ciphers, but otherwise, there's no change.

1 Like
8

clients shouldn't offer it can't talk: what kind of client is it?

3 Likes
9

It's an out of support embedded device. There certainly could be bugs with it, but there's absolutely nothing I can do about it, I just need to make the server accommodate it, like the old one did without needing to do anything special.

I think the behavior is strange, but for some reason, the old server does offer 0x0035 and that works. I don't know if it's normal, or maybe I'm not understanding the client hello preference order from the pcap, but that's what I'm seeing, at least. There are 21 ciphers in the client hello cipher suites, x39, x38, then x35 and some others.

10

ah, server selected DHE ciphter but it crashes it doesn't have DH privkey
what's your server side?

3 Likes
11

Okay, progress! It's called the "AES128-SHA" cipher.

I don't know where this is documented, but I got lucky as somebody said it was here: ssl - OpenSSL: modes of operation in cipher suites - Stack Overflow

If I force that cipher specifically, now my client handshakes successfully. I suspect maybe the other ciphers weren't preferred on the old server so that's why they were skipped. I'll probably have to fine tune this, to ensure it's still compatible with other TLS 1.0 clients, but this is a starting point, at least...

what's your server side?

The server is an Asterisk server using pjproject (PJSIP). There are two transports set up for TLS, one for TLS 1.2 and one for TLS 1.0 - all of this concerns TLS 1.0 only.

12

From the list shown:

I would try excluding all the ones that...

  • start with DHE
  • contain PSK
  • start with SRP
4 Likes
13

So, that boils the list down to:

AES128-GCM-SHA256              ECDHE-ECDSA-AES128-SHA256      ECDHE-RSA-AES256-GCM-SHA384    
AES128-SHA                     ECDHE-ECDSA-AES256-GCM-SHA384  ECDHE-RSA-AES256-SHA           
AES128-SHA256                  ECDHE-ECDSA-AES256-SHA         ECDHE-RSA-AES256-SHA384        
AES256-GCM-SHA384              ECDHE-ECDSA-AES256-SHA384      ECDHE-RSA-CHACHA20-POLY1305    
AES256-SHA                     ECDHE-ECDSA-CHACHA20-POLY1305  TLS_AES_128_GCM_SHA256
AES256-SHA256                  ECDHE-RSA-AES128-GCM-SHA256    TLS_AES_256_GCM_SHA384
ECDHE-ECDSA-AES128-GCM-SHA256  ECDHE-RSA-AES128-SHA           TLS_CHACHA20_POLY1305_SHA256
ECDHE-ECDSA-AES128-SHA         ECDHE-RSA-AES128-SHA256
3 Likes
14

Thanks, I gave this a try and it still seems to work, so I'll probably leave it here, this should be good enough for my needs I think:

cipher=AES128-GCM-SHA256,AES128-SHA,AES128-SHA256,AES256-GCM-SHA384,AES256-SHA,AES256-SHA256,ECDHE-ECDSA-AES128-SHA,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES128-SHA,ECDHE-ECDSA-AES128-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES256-SHA,ECDHE-ECDSA-AES256-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-CHACHA20-POLY1305,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256

2 Likes
15

You listed "ECDHE-ECDSA-AES128-SHA" twice.

2 Likes
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.