Configure multiple TLS Protocols in Elytron using expression

[Marco Strauch]

Hi,

currently we migrate picketbox / picketlink to elytron. In the past we had follow undertow configuration to optionally configure the supported TLS protocols from outside the standalone.xml:

<https-listener name="https" security-realm="UndertowRealm" verify-client="${pos.https.verifyClient:NOT_REQUESTED}" enabled-cipher-suites="${pos.https.enabledCipherSuites:HIGH}" enabled-protocols="${pos.https.enabledProtocols:TLSv1,TLSv1.1,TLSv1.2}" enable-http2="true"/>

In Elytron I configure the keystore and keymanager within the elytron subsystem. But I have a problem configuring the supported tls protocols for the server ssl context using the same syntax as in the above example.

<server-ssl-context name="MTLS_Context" cipher-suite-filter="${https.enabledCipherSuites:HIGH}" protocols="${https.enabledProtocols:TLSv1.1,TLSv1.2}" need-client-auth="true" key-manager="My_KeyManager" trust-manager="My_TrustManager"/>

If configuring the protocols without an environment variable this would look like this

<server-ssl-context name="MTLS_Context" protocols="TLSv1.1 TLSv1.2" key-manager="My_KeyManager"/> 

But using an expression this don't work. I tried with follow syntax:

${https.enabledProtocols:TLSv1.1,TLSv1.2}

${https.enabledProtocols:TLSv1.1 TLSv1.2}

${https.enabledProtocols:[TLSv1.1 TLSv1.2]}

Butting nothing works. Either wildfly does not accept the syntax (the last 2 samples) or elytron does not split the values correctly (first example).

So how can I configure multiple protocols using the expression syntax?

Regards

Marco

  

[Prarthona Paul]

Hello Marco, 

Is there a reason why you are using the expressions? 
Usually the ${expression:default value} format is used if you expect the expression value to be a system property or environment variable. So, when resolving the expression, wildly will first go to the env variables or system properties to see if http.enabledProtocols is there. If nothing comes up, then the default value is used. Are there cases in your application where the protocol is specified using env variables or system properties? If not is there another reason behind using expressions? 
Here is some more information about expression resolution in wildFly: https://docs.wildfly.org/30/Admin_Guide.html#Expression_Resolution
I would assume that the following format would work: 

 ${https.enabledProtocols:TLSv1.1 TLSv1.2}
Something to note is that when parsing the expression, https.enabledProtocols is converted to HTTPS_ENABLEDPROTOCOL. 
Additionally, there are a few nuances for how the expressions are read from env and system properties, so if you are expecting wildfly to read those, pleas ensure that you are following those guidelines. 
Please feel free to respond here with more followups if you have any. 
Best, 

Prarthona

[Marco Strauch]

Hi  Prarthona,

in our setup we use this env varibale to optionally override the pre configured default settings. So in most cases the java env property "https.enabledProtocols" will not be set and the default will be used. But in some use cases we set this env property on a specific customer system. When we update the system we replace the whole default configuration but the set env variable on the specifc customer system will be reused.

I tried  

 ${https.enabledProtocols:TLSv1.1 TLSv1.2}

 but this runs in follow error

OPVDX001: Validierungsfehler in standalone.xml ---------------------------------
|....
|
| Die prim�re zugrunde liegende Fehlermeldung lautete:
| > ParseError at [row,col]:[563,21]
| > Message: "WFLYCTL0129: Invalid value
| >   ${pos.mtls.enabledProtocols:TLSv1.1 for protocols; legal values are
| >   [\"SSLv2\", \"SSLv2Hello\", \"SSLv3\", \"TLSv1\", \"TLSv1.1\",
| >   \"TLSv1.2\", \"TLSv1.3\"]"
|
|-------------------------------------------------------------------------------

It seems that the parser don't accept the spaces within the default value.

By the way: We are currently using Widlfy 24.

Regards 

Marco

[Bartosz Baranowski]

Be wary. AFAIR, by default elytron has certain protocols not in "enabled" list, because of their known vulnerabilities. So if you tinker with such options take extra care.