CAS TLS update

1 Overview
2 What is the change?
3 Why is this change happening?
4 What is this change going to impact?
5 How can I make sure that my application works after this change?
- 5.1 Java
- 5.2 .NET Framework
- 5.3 OpenSSL
  - 5.3.1 Node JS
  - 5.3.2 Python
  - 5.3.3 Ruby

Overview

Network security architecture relies on the Transport Layer Security (TLS) protocol for ensuring interaction with CAS over the internet occurs securely without transmissions being vulnerable to outside entities. TLS encrypts a channel between two endpoints (for example, between a web browser and web server) to provide privacy and reliability of data transmitted over the communications channel.

What is the change?

Out of concern for known vulnerabilities in TLS 1.0 and TLS 1.1 and to comply with industry standards, beginning Mar 14, 2021 CAS will only support TLS 1.2 network connections from your applications. From that point forward, CAS will refuse connections from applications that are not TLS 1.2 compliant. Your systems will need to connect to CAS using the TLS 1.2 protocol by 6:00 AM EST on Mar 14, 2021 to avoid any interruption in service. Support for TLS 1.0/1.1 will be discontinued at that time.

Why is this change happening?

Numerous vulnerabilities have been discovered in TLS 1.0 and TLS 1.1 over the years that make them insecure, making the server vulnerable to man in the middle attacks. Please refer to best practices outlined in RFC-7525 for reasons why it is discouraged to use protocol TLS 1.0 and TLS 1.1. It recommends users switch from protocol TLS 1.0 and adopt protocol TLS 1.2+.

What is this change going to impact?

CAS authentication flow comprises two steps.

Browser is redirected to the CAS login page for authentication. This step would not be impacted, since all popular browsers already support TLS 1.2+.
On successful authentication, the server makes a call back to the CAS for validating the ticket. This could be impacted with SSL handshake errors if the application platform does not support, or is not configured to support TLS 1.2+

Please note that this change will only impact applications that authenticate against CAS directly. The applications that integrate with Shibboleth over SAML will not be impacted. The IAM team will make sure that Shibboleth integration with CAS keeps working after this change.

How can I make sure that my application works after this change?

We will be making the change on the test CAS (https://secure-tst.its.yale.edu/cas) on 21st January. Please point your test environment to test CAS and make sure if it works as expected. If you encounter SSL handshake errors, then you will have to delve deeper to figure out if you need to upgrade the application technology stack to support TLS 1.2+ or just need configuration changes.

In planning for the migration to TLS 1.2, developers should be aware of the potential for incompatible protocol versions in their applications. If you have developed applications that authenticate against CAS, you should take steps to ensure that they will continue to function with TLS 1.2. Of course every development framework and language is different with regard to how TLS is handled, but some general guidelines are provided in the following sections that should help you in determining what impacts the TLS 1.2 requirement may have on your systems.

Java

Exception in case of incorrect TLS version

javax.net.ssl.SSLException: Received fatal alert: protocol_version
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
    at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2038)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1135)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)

If the application builds a custom SSLSocketFactory with a TLS 1.0 or TLS 1.1 protocol, then the code needs to changed to preferably not specify any specific protocol version and utilize the platform defaults.
If the application runs on Java 1.7 or Java 1.6 (update 111 or later), you can set the https.protocols system property when starting the JVM to enable additional protocols – by setting -Dhttps.protocols=TLSv1.2.
If the application runs on Java 1.8 (update 121 or lower), you can set the https.protocols system property when starting the JVM to enable additional protocols – by setting -Dhttps.protocols=TLSv1.2
If the applications runs on Java 1.8 (update 122 or later) or Java 11 then TLS 1.2+ is the default protocol setting.

For more details see the Java Platform Group, Product Management Blog: Diagnosing TLS, SSL, and HTTPS.

.NET Framework

In order to support TLS 1.2 you must be running .NET Framework v4.5 or later for your .NET application development. Please refer to Microsoft’s helpful knowledge base article on TLS best practices with .NET Framework to assist you in determining the best course of action depending on your particular situation. Additionally, the following points may help you in supporting TLS 1.2 in your .NET applications.

If you are using .NET 4.5, you can explicitly set the Security Protocol to TLS 1.2:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
TLS 1.2 is not supported in .NET 4.0. However, you can install .NET 4.5 (or later) and set the Security Protocol to TLS 1.2 by using the explicit value 3072:
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
If you have applications that target .NET 3.5, they do not include support for TLS 1.2. However, Microsoft Security Update 3 includes TLS 1.2 and can be installed on older servers so that the registry can be configured to use the operating system defaults for SSL and TLS.

OpenSSL

OpenSSL contains an open-source implementation of the TLS protocol. TLS 1.2 was first supported in OpenSSL version 1.0.1. You can quickly determine the version of OpenSSL you are running by executing openssl version at the command line. You can also use the following command to verify the TLS 1.2 support

openssl s_client -connect secure-tst.its.yale.edu:443 -tls1_2

Many languages (Ruby, Python, Node JS, PHP etc) have wrappers allowing the use of OpenSSL as the underlying SSL library. After validating that the underlying OpenSSL library supports TLS 1.2, the developers will need to check into language specific TLS 1.2 considerations.

Node JS

If your code specifies a particular TLS protocol by supplying secureProtocol option to https request object, then you should preferably remove that option and utilize the platform default.

You can determine whether or not your Node platform needs to be updated to TLS 1.2 by running the following code snippet in your environment.

var https = require("https");
var req = https.request({
  host: "secure-tst.its.yale.edu",
  port: "443",
  path: "/cas/validate",
  method: "GET",
  secureProtocol: "TLSv1_2_method",
  headers: {
    "Authorization": "Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2",
    "Accept": "application/json",
    "Content-Type": "application/x-www-form-urlencoded",
  }
}, function (res) {
  res.on("data", function (data) {
    console.log("TLS 1.2 supported, no action required.");
  });
});
req.end();
req.on("error", function(err) {
  if (err.code == "ECONNRESET") {
    console.log("TLS 1.2 not supported! You will need to upgrade");
  } else {
    console.log("Unknown error talking to Stripe, please try again later.");
  }
});

amitpoddar@Amits-MacBook-Pro Downloads % node ssl.js
TLS 1.2 supported, no action required.

If you receive the message “TLS 1.2 is supported”, you will not need to change anything. Otherwise, you will need to upgrade your OpenSSL version.

Python

If you are using Python 2.7.9 or higher, TLS 1.2 is enabled by default.

Ruby

To check if your current Ruby environment supports TLS 1.2, execute the following on the command prompt

If Ruby 2.0.0 is used with OpenSSL 1.0.1 or higher, TLS 1.2 is enabled by default. Furthermore using the :TLSv1_2 symbol with an SSLContext's ssl_version helps ensure that TLS 1.0 or earlier is disabled.

The symbol :TLSv1_2 does not exist for Ruby 1.9.3 or below, though it might be possible to patch Ruby to add this symbol and compile with OpenSSL 1.0.1 or higher.