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?
imho openssl just clearly follows the Compliance Requirements of rfc8446
https://www.rfc-editor.org/rfc/rfc8446#section-9.1
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 )
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.
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.
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 :-[
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/ (https://blog.germancoding.com/2020/05/30/undocumented-openssl-cnf-options-and-prioritizechacha/)).
Best regards.
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.
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.
can try to add
"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 ;)
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.
I have no idea if this problem is in any way related to this here
https://forum.opnsense.org/index.php?topic=29284
Quotebut 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
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
QuoteDo 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 ;))
@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..
@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"
@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?)
Quote from: Fright on August 26, 2022, 03:14:31 PM
@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...
Quote from: chemlud on August 26, 2022, 03:46:37 PM
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.
QuoteThe 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 ;D.
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 ;)
@chemlud
QuoteWhat'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
back ref. https://github.com/opnsense/core/pull/5993
Good job! Let's see what @AdSchellevis decides :)
Quote from: Fright on August 26, 2022, 09:00:50 PM
back ref. https://github.com/opnsense/core/pull/5993
thanks a lot! the client can do tls 1.3 without doubt... ;-)
@i81b4u - pretty much :D 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.
I'm sure you'll get there! Thumbs up for you 8)
@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)
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 :)
@RZR
QuoteIs 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 ;))
On my OPNsense box, using the following command:
openssl ciphers -V -ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ECDHE+AESGCM:\!AES128:ECDHE+CHACHA20
returns the following ciphers:
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? ;)
@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.
@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 ;)
ciphers -V -ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ECDHE+AESGCM:\!AES128:ECDHE+CHACHA20:\!aRSA
@Fright, I went to look into config.xml but it reflects exactly what the GUI shows, so I am not convinced it will function as an override. Will bear it in mind thought, thanks!
@i81b4u, RSA does not offer Perfect Forward Secrecy so I prefer to remove it, but that will work - thanks.
@RZR, I think you got things mixed up.
Not talking TLSv1.3 specifics right now, but ...
With RSA-certificates you can achieve PFS. PFS only depends on the key exchange method.
With RSA key exchange a symmetric key is exchanged "over the line" so when someone obtains the private key, traffic can be decrypted when listening in on (or replaying recorded) traffic. When using Diffie-Hellman a symmetric key is "calculated" and never sent "over the line", so it can't be found by listening in on (or replaying recorded) traffic.
Hope that makes sense? ;)
@RZR
Quotereflects exactly what the GUI shows, so I am not convinced it will function as an override.
i checked )
but the mentioned fixes were not included in the 22.7.3.. so must be 'opnsense-patch'-ed manually
@i81b4u - you're right, I am using the term "RSA" too broadly (interchangeably), was referring specifically to KEX. Thanks ;)
@Fright, thanks - I should have clicked. Will check after the next patch/update to see what is there. Appreciated!
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.
get-mobdro.com (https://get-mobdro.com/)