Specifying TLS protocols and ciphers?

151 views
Skip to first unread message

Baron Fujimoto

unread,
Feb 4, 2021, 8:53:35 PM2/4/21
to CAS Community
We've been disabling TLS protocols and ciphers that have been deemed weak (e.g., TLSv1, TLSv1.1). While we've done so for our Tomcat configs, I noticed the following in our CAS logs today:

DEBUG [org.apereo.cas.authentication.FileTrustStoreSslSocketFactory] - <Enabled protocols: [TLSv1.2, TLSv1.1, TLSv1]>
DEBUG [org.apereo.cas.authentication.FileTrustStoreSslSocketFactory] - <Enabled cipher suites:[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_EC
DH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES
_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA38
4, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_C
BC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_D
SS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMP
TY_RENEGOTIATION_INFO_SCSV]>

I didn't see anything that looked relevant in cas.properties that would allow us to specify which TLS protocols and cipher suites were enabled. Is there a way for us to also deprecate them where they are being used here?
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

Misagh Moayyed

unread,
Feb 5, 2021, 2:12:02 AM2/5/21
to CAS Community
That depends on whether you are running embedded or external. If external, you should be changes to tomcat yourself and manually and you should review the tomcat documentation. If embedded, then you should consider using `server.ssl.enabled-protocols=` which is a setting provided by Spring Boot to CAS that controls the enabled protocols and auto-configures the embedded tomcat.


Baron Fujimoto

unread,
Feb 5, 2021, 11:41:49 AM2/5/21
to CAS Community
AFAIK, our CAS 5.0.x instances are using external Tomcat. We've always set the protocols and ciphers in its own config. Everything that connects to us (e.g. SSL Labs server tests) suggests we are using this external Tomcat. Yet we still get the logs provided previously, and I don't think we've done anything to explicitly enable or disable any internal Tomcat. Where would I find information on doing so?

On Thu, Feb 4, 2021 at 9:12 PM Misagh Moayyed <misagh....@gmail.com> wrote:
That depends on whether you are running embedded or external. If external, you should be changes to tomcat yourself and manually and you should review the tomcat documentation. If embedded, then you should consider using `server.ssl.enabled-protocols=` which is a setting provided by Spring Boot to CAS that controls the enabled protocols and auto-configures the embedded tomcat.


--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/b865a483-8388-4dcd-b12e-31a4d5efecc1n%40apereo.org.

Misagh

unread,
Feb 5, 2021, 12:10:08 PM2/5/21
to CAS Community
The logs you see above from FileTrustStoreSslSocketFactory have
nothing to do with Tomcat whether external or internal, or the
connection exposed over http.

And if you have not anything explicit to enable or disable the
internal tomcat, then you get it by default. So you end up with a CAS
application that is pregnant with an apache tomcat instance. If you
deploy to an external tomcat, the embedded tomcat will automatically
back away and will have no effect. To disable it from inclusion, you
should make sure this is set to blank:

https://github.com/apereo/cas-overlay-template/blob/master/gradle.properties#L5-L7
> To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL0%2Bxt0onQDqd-m%2BjAdYym%2BPyZu27ouMM24Fy%3DPEjaxLBw%40mail.gmail.com.

Baron Fujimoto

unread,
Feb 5, 2021, 12:44:35 PM2/5/21
to CAS Community
I guess I'm back to my original question then of is there a way to disable deprecated protocols and ciphers for this (org.apereo.cas.authentication.FileTrustStoreSslSocketFactory) for general consistency. Or is this something we should not bother with ( and why not)?

Our 5.0.x builds are still using maven, is there a pom.xml or other equivalent to the gradle.properties you referenced?

Reply all
Reply to author
Forward
0 new messages