Introduction
In the Fall of 2014 several security issues directly or indirectly affecting CAS server and clients (applications) have come to light. This page summarizes some of these issues and suggests mitigation steps to take or test with your CAS client application. For questions and comments about any of these issues, please see the Resources section below.
Issues
Issue 1: CVE-2014-4172 CAS clients
Background
There is an important security vulnerability that allows URL parameter injection due to improper URL encoding at the back-channel ticket validation step of the CAS protocol in some CAS clients. See CAS Client Security Vulnerability CVE-2014-4172 for more details.
Mitigation
Update vulnerable CAS clients as described in the announcement cited above.
Date: 2014-10-27
Client testing and validation of the servlet filter CAS Server Security Filter in auth-test.b.e begins. Please report any issues noted when configuring your test CAS client applications to use auth-test.b.e for validation of this CAS server-side security filter.
Date: 2014-11-10
The servlet filter is deployed to the auth.b.e cluster. At that time, please report any issues noted for production CAS client applications.
Issue 2: CVE-2014-3566 SSLv3 vulnerability (POODLE)
Background
This vulnerability for the SSLv3 protocol allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. See, for example, POODLE: SSLv3 vulnerability (CVE-2014-3566) for more details.
Mitigation
Disable SSLv3 in CAS clients (applications). Refer to vendor documentation such as the RedHat article cited above addressing this issue.
Date: 2014-11-03
Client application testing and validation of the CAS servers (auth-test.b.e) with SSLv3 disabled begins. Please report any issues noted when configuring your test CAS client applications to use auth-test.b.e as the CAS server. This will help us to validate correct operations without SSLv3 enabled in the CAS server.
Date: 2014-12-01
The CAS servers (auth.b.e) are configured with SSLv3 disabled. Please report any issues noted for production CAS client applications.
Date: 2015-03-09
The CAS second-level servers (auth-key.b.e) are configured with SSLv3 disabled. Please report any issues noted for production CAS client applications.
Known issues reported
Error report 1
Analysis
Seen in the CAS server logs for the auth-test cluster are many service tickets being created for the redacted.berkeley.edu URL, but no ticket validations. There are no other errors in the logs related to this URL. This is consistent with a failure of the CAS client to contact the application to do the service ticket validation step because the lower-level communications are failing.
A simple test one can try against auth-test using OpenSSL on your hosts is the following:
vs.
If the latter succeeds, then your OpenSSL libraries are working correctly and it's likely a matter of configuring your CAS client to request using the equivalent to the -tls1 option used with s_client. Another suggestion seen is to wrap the SSL client app in stunnel as a proxy so that the client doesn't need to know anything about TLS, but that seems fairly complex for a production setup.
Solution
Error report 2
Solution
Error report 3
Aaron Russo reports:
Patch for mod_auth_cas on RHEL 5.x:
Error Report 4
Using the rubycas-client 2.3.9, SSL connections to auth.b.e fail.
Solution
Monkey-patch for rubycas-client in config/initializers/patches.rb:
Error Report 5
Another Perl fix when using the LWP::UserAgent module as part of a CAS client is to update some key Perl modules using cpan if necessary. If cpan is broken due to previous updates, get PathTools (Cwd and File::Spec* modules) from a host where cpan works, then copy to the broken system. First reconfigure cpan to prevent future overwrites, then update the key modules:
Update calls found in the CAS client code using LWP::UserAgent to explicitly use TLSv1:
Issue 3: Need to replace SHA-1-based certificates
Background
The common signing algorithm SHA-1 is less secure than newer SHA-2 algorithms now available. Several browser vendors and certificate authorities have announced accelerated time lines for the deprecation of SHA-1-based certificates which will cause browser warnings or failures for these older certificates as time passes. See the article Important change announcement - deprecation of SHA-1 from Comodo for more details. Comodo issues the certificates used for the CalNet InCommon-Comodo Certificate Service.
Mitigation
Update server and intermediate CA certificates using SHA-1 signatures with the longest expiration dates first. Root CA certificates are not affected. Refer to the CalNet InCommon Certificate service FAQ cited above for requesting certificate renewals.
Date: 2015-03-31
New SSH-2-based certificate is deployed for the off-site CAS server (cas-p4.calnet.b.e) and the auth-test.b.e cluster. Next up, the auth.b.e cluster: see CAS TLS Certificates
Resources
Please send comments and questions to Other discussions and announcements can be found on the calnet-developers@lists.berkeley.edu and ucb-security@lists.berkeley.edu email lists (please subscribe to post to and to follow these e-mail lists).