Sometime in 2018 we will be disabling TLS 1.0 and RC4 on the production WebLogin servers. It is important that anyone running any services using WebAuth test for this change. We have created a single production WebLogin server (weblogin4.stanford.edu) you can use for testing purposes that has TLS 1.0 and RC4 disabled.
When will you disable TLS 1.0 and RC4 on the WebLogin servers?
The date is not yet set, but sometime in 2018. Watch this space for updates on the exact date.
Why are you removing TLS 1.0 and RC4 from the WebLogin servers?
TLS 1.0 is only secure against the BEAST attack when using RC4, but RC4 is no longer considered secure. So, disabling both TLS 1.0 and RC4 is needed to remain secure. See also RC4 in TLS is Broken: Now What?
Who is affected?
Any browser that does not support TLS 1.1 or TLS 1.2 will not be able to authenticate using WebLogin. Only very old browsers do not support TLS 1.1 or TLS 1.2. See also
en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers.
On the server side, a WebAuth application server communicates with the WebLogin servers using TLS, so if the server does not support TLS 1.1 or TLS 1.2 the WebAuth protocol will fail.
Non-browser-based application that authenticate directly against the weblogin servers will also need to work with TLS 1.0 disabled.
How is weblogin4 different than the other WebLogin servers?
This server is identical to the other production WebLogin servers with two exceptions: it is NOT part of the production load-balanced WebLogin pool (so it will never normally be used) and it has TLS 1.0 and RC4 disabled.
How do I use weblogin4 for testing?
Client-side Testing Testing on the client side means having a computer's browser authenticate against weblogin4.stanford.edu instead of the usual WebLogin load-balanced pool. To do this, the computer where the browser is running must be configured to return the IP address 171.67.218.26 when resolving weblogin.stanford.edu. To do this for Windows, Macs, and Linux, add this line to the "hosts" file:
171.67.218.26 weblogin4 weblogin.stanford.edu
To find the "hosts" file see the hosts (file) article in Wikipedia.
Server-side Testing The procedure to test a WebAuth server is the same as testing a client: change the server's hosts file as described above, restart the web service, and do a test authentication.
My server failed testing. Now what?
If your server failed testing it probably means that your cryptographic libraries do not support TLS 1.1 or TLS 1.2. Your best course is to upgrade your systems to support the newer protocols.
I am using SAML: do I need to care?
Our SAML IdPs currently acts as a WebAuth applications and thus requires the user to authenticate using the WebLogin servers, so SAML-based applications are affected, but only insofar as the user's browser is affected (see "Who is affected?" above.)
