OpenSSL not honouring cipher selection?

[chemlud]

@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..

What's wrong with going TLS1.3-only? The browser can do it, sense can (could? should?) do it, I don't get the point...

[Headless1919]

What's wrong with going TLS1.3-only? The browser can do it, sense can (could? should?) do it, I don't get the point...

Nothing wrong with going 1.3 only. What Fright is trying to say is that your config was too selective: server was only offering ChaCha20 which was not supported by your client - hence no connection.

[i81b4u]

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.

Hmmm. Okay. Think I know what you mean. That being said ... When using AESGCM ciphers in TLSv1.2 and all TLSv1.3 ciphers you should be good to go. And okay, I get it ... you want to eliminate the 128 bit ciphers too, to get a perfect score  .

The other thing that should bother you is the fact that OpenSSL does not prioritize chacha ciphers over aes ones by default. Some clients prefer chacha over aes. The article I shared a while earlier contains all the information needed to fix that too.

Anyway ... happy hunting and keep us posted 

[Fright]

@chemlud

What's wrong with going TLS1.3-only?

there is nothing wrong with the "TLS1.3-only" itself (except that it prevented openssl to use 1.2  ). it's just that you didn't leave support for TLS1.2, and TLS1.3 openssl command is configured incorrectly in webgui.inc imho

i'll try to make a ticket

[Fright]

back ref. https://github.com/opnsense/core/pull/5993

[i81b4u]

Good job! Let's see what @AdSchellevis decides 

[chemlud]

back ref. https://github.com/opnsense/core/pull/5993

thanks a lot! the client can do tls 1.3 without doubt... ;-)

[Headless1919]

@i81b4u - pretty much I got it sorted with some help from Fright. Check my post on the previous page, but basically in addition to modifying openssl.cnf (not entirely sure this is needed but probably is), there is additional lighttpd configuration required as well in /usr/local/etc/inc/plugins.inc.d/webgui.inc at line 418 as mentioned by Fright. With all of that - cipher selection matches what is presented in the GUI.

@Fright - thank you very much for your help and for the PR as well.

I think there may already be a way to make this persistent via override - had to do something similar to get OCSP stapling working with the GUI. Will test it out in a few days and see if it works.

[i81b4u]

I'm sure you'll get there! Thumbs up for you 

[Fright]

@RZR
with
https://github.com/opnsense/core/commit/d31bff3c3975fe8c043538bcccbe30674068eae8
and
https://github.com/opnsense/core/commit/840ddc52f7ad304eeb1dafaeaa33fd9aafd9841e
(thanks to the devs for the quick response as always!)
gui will not allow you to break rfc, sorry. but..
(if you really-really want to - you can add your combined cipher string in conf directly and this should be persistent. I don't think it's a supported option, but since you know what you're doing..)

for the gui OCSP staple support there is another ticket exists (https://github.com/opnsense/core/pull/5567)
but this really needs to be discussed imho as it can have consequences
(like https://forum.opnsense.org/index.php?topic=26812.0)

[Headless1919]

Thanks Fright, I understand - as long as there is a way to do it, I am not too concerned about whether it is exposed through the GUI or not. I did try adding that configuration into a new file in /usr/local/etc/lighttpd_webgui/conf.d (the same way I set my OCSP config) but the GUI fails to start. Suspect either my syntax is wrong, or its clashing with the already present config in the main file. Is this what you were referring to when you said "you can add your combined cipher string in conf directly and this should be persistent"?

On the subject of OCSP (know its off this topic but mentioning it anyway) - that ticket is basically how I am doing it. Generate cert with must-staple extension, create cron job to run the renew script once a day (just after the cert update check), create persistent config to reference the response file, profit. Not really sure how much discussion is required on it since users can already generate certs with must-staple - and if they do so without understanding (which is exactly what I did at first), things will break. Bringing in support for OCSP might lead to more people clicking on/selecting it, but its hardly likely to make the situation worse than it already is.

Either way, I digress

[Fright]

@RZR

Is this what you were referring to when you said "you can add your combined cipher string in conf directly and this should be persistent"?

no. you can just add (after applying the specified fixes) something like EECDH+AESGCM:CHACHA20:!AES128:!SHA1:!SHA256:!SHA384:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 to opnsense-system-webgui-ssl-cipher on /conf/config.xml (again: this is bad and not supported  )

[i81b4u]

On my OPNsense box, using the following command:

Code: [Select]

openssl ciphers -V -ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ECDHE+AESGCM:\!AES128:ECDHE+CHACHA20
returns the following ciphers:

Code: [Select]

0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
Those are the ciphers you (@RZR) were looking for? 

[Headless1919]

@Fright - thanks! I get it, bad idea not supported etc. busy documenting though so if I do mess something up, it should be easy to reverse. Best part is, in these situations there really is only one person to blame if something goes wrong. Really appreciate your help!

@i81b4u - minus the fourth and six entries yeah (RSA). I don't entirely trust RSA anymore, even if TLS 1.2 is still secure there are varying degrees of cipher strength within the overall spec.

[i81b4u]

@RZR.

Copy that. When using that cipherselection it will exclude the TLSv1.2 RSA-ciphers automatically when using ECDSA certificates. When assembling a cipher selection string the way I did, and not specifically naming each cipher, you can end up with extra ciphers.

But if you insist, by adding !aRSA you can also exclude the RSA-based (and I quote from the openssl manual page: "cipher suites using RSA authentication, i.e. the certificates carry RSA keys") ciphers 

Code: [Select]

ciphers -V -ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ECDHE+AESGCM:\!AES128:ECDHE+CHACHA20:\!aRSA