OpenSSL not honouring cipher selection?

[Headless1919]

I have switched from LibreSSL to OpenSSL, as per the impending removal notice slated for the end of the series. After switching from LibreSSL, I have noticed that the GUI cipher selection is not strictly honored anymore. Below is what I have configured for the GUI (also attached):

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

However, when I scan using testssl, an additional cipher is offered despite not being selected: TLS_AES_128_GCM_SHA256.

This behavior appears to be due to OpenSSL. When using LibreSSL, only the selected ciphers are offered, not an extra. This was also tested on two separate firewalls, on different versions, before and after upgrading: on LibreSSL, the selected and offered ciphers match. As soon as you switch to OpenSSL, this additional cipher is inserted despite no other configuration change.

Could this be a bug, or is this expected behavior? Where is this config located/controlled?

[Fright]

imho openssl just clearly follows the Compliance Requirements of rfc8446
https://www.rfc-editor.org/rfc/rfc8446#section-9.1

Code Select Expand

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
   [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
   [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
   Appendix B.4).

need to break the rules and edit openssl.cnf for an ideal rating )

[Headless1919]

I agree OpenSSL is conforming to the RFC, seen that snippet before. If that is the cause, LibreSSL clearly does not comply when making changes.

Do you perhaps know where the openssl.cnf file is located? I have this working on an Ubuntu server so know the configuration to apply, but not the specific file. I am assuming it is /usr/local/openssl/openssl.cnf but the syntax looks very different from what I was expecting to see.

[i81b4u]

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 are typically used with ECDSA certificates on TLSv1.2. Are you sure you have such a certificate? Otherwise I would select TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.

You would expect the software to be smart and that if you select TLSv1.2 while using RSA certificates, at least one RSA cipher would have to be selected.

That being said ... TLS_AES_128_GCM_SHA256 is a TLSv1.3 cipher and just tested it myself ... if it is not selected, it still is used. Is there any reason you do not want to use that cipher?

Best regards.

[i81b4u]

And yes ... because I was reading without logging in, I could not see the attachments which would have made me reconsider my previous answer. Sorry about that  :-[

[i81b4u]

By the way ... you were right about /usr/local/openssl/openssl.cnf

Not sure if you can accomplish what you want to achieve, but this article should be of some help, even with prioritizing chacha over aes for example (https://blog.germancoding.com/2020/05/30/undocumented-openssl-cnf-options-and-prioritizechacha/).

Best regards.

[Headless1919]

No need to apologise :)

The only real reason (and we can debate long and hard about this without coming to a definitive conclusion) is more around scoring and perfect grading. Is it good enough? Sure - its not vulnerable as far as anyone knows. Do I want it in use? Not really no.

It also bothers me a little bit (although I do understand the RFC component) that something I have not explicitly selected is being offered. I might just be chasing something here for the sake of it... but I would like to have it my way.

Thanks for the extra add - I will see if I can modify the file later or over the weekend and report back. Just wondering when/under what conditions that file is overwritten, if any.

[Headless1919]

I have added this configuration:

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=2
MinProtocol = TLSv1.2
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305
Options = ServerPreference,PrioritizeChaCha

to the below files:

• /usr/local/openssl/openssl.cnf
• /etc/ssl/openssl.cnf

The config after restarting the GUI via CLI is still present, but the scan results are the same. Suspecting the configuration is being stored or overridden somewhere else on the system. This exact configuration works on Ubuntu so its something specific to this setup.

[Fright]

can try to add

Code Select Expand

    "Ciphersuites" => "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
to /usr/local/etc/inc/plugins.inc.d/webgui.inc at line 418
and restart gui  ;)

[Headless1919]

Thanks Fright - you've pointed me on the right track  :)

Adding that into the file at line 418 does indeed restrict the TLS 1.3 ciphers to just those two - but reintroduces TLS 1.0 and 1.1, as well as a host of other TLS 1.2 ciphers. Final configuration offering just the four selected ciphers is as below (starting at line 417):

    "MinProtocol" => "TLSv1.2",
    "Ciphersuites" => "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256",
    "CipherString" => "EECDH+AESGCM:CHACHA20:!AES128:!SHA1:!SHA256:!SHA384",
#    "CipherString" => "{$config['system']['webgui']['ssl-ciphers']}"

Do you know if this file is persistent? I suspect it will be overwritten by package updates.

[chemlud]

I have no idea if this problem is in any way related to this here

https://forum.opnsense.org/index.php?topic=29284

[Fright]

but reintroduces TLS 1.0 and 1.1, as well as a host of other TLS 1.2 ciphers

hm. dont know how it possible if ciphers restricted to TLS1.2/1.3 suites?
for me testssl returns

Code Select Expand


SSLv2      not offered (OK)
SSLv3      not offered (OK)
TLS 1      not offered
TLS 1.1    not offered
TLS 1.2    not offered
TLS 1.3    offered (OK): final

with this changes

Do you know if this file is persistent? I suspect it will be overwritten by package updates.

yep, can be replaced with OPN update (need to add GUI settings for Ciphersuites ssl.openssl.ssl-conf-cmd option IMHO. not sure that devs agree with the need for such a gui parameter, but without trying you won't know  ;))

[Fright]

@chemlud
perhaps in part: you allowed TLS_CHACHA20_POLY1305_SHA256 only.
its TLS1.3 suite.
and for openssl TLSv1.3 ciphersuite list is configured with a separate option ( "-ciphersuites").
but webgui.inc use CipherString ("-cipherlist" openssl option which is used to indicate =< TLS1.2 suites) only.
so openssl not recognizing TLS_CHACHA20_POLY1305_SHA256 as a =<TLS1.2 suite (and you not allowed any =<TLS1.2 suite) and throws an error.

so imho it turns out to be a coincidence: not quite correct lighty configuration on OPN side and too strict cipher selection on yours..

[Headless1919]

@chemlud, Fright is right - similar but not the same thing. The breakdown posted above explains it perfectly.

@Fright - line 417 for me originally said
    "MinProtocol" => "TLSv1.0"

which I think was the issue. I modified it to 1.2, saved and restarted. This is why I suspected there was also config living somewhere else, since there were also other 1.2 ciphers being offered after the change.

I also agree a override/config drop in location would be nice - but the GUI should also be setting this correctly, i.e. only the ciphers selected and not the rest. Debatable though since it would violate the RFC - but a question for the dev team to answer as to which way is preferred.

EDIT: Line said "MinProtocol" => "TLSv1.0" not "MinProtocol" => "TLSv1.2"

[Fright]

@RZR
I can't agree more on the " the GUI should also be setting this correctly" part.
but in terms of rfc violation i would probably have expressed serious objections: we are talking about access to management interface, the accidental loss of which will cause a lot of complaints from users.
in the end, an advanced administrator can try to add additional restrictions on his own (for example, use gui via nginx?)