[ARCHIVED] Transition your API URL to a legacy endpoint for your institution.

Jump to solution
sraju
Community Novice
‎07-30-2020 04:34 PM

Hi Team,

We have an API configured with Canvas talking to Perkins at the moment. We recently received and email from Canvas to action the below items. We are more concerned with this Transition your API URL to a legacy endpoint for your institution.  

What steps do we need to do, can you please provide us some step by step documentation how to configure this.

We need some help with this please:  

  • On Monday, our Canvas Release Notes (2020-08-15) announced an upcoming change to TLS 1.0 and 1.1 protocols. Your institution is affected by this change and action is required before 19 September 2020.

    You can address this behavior in one of two ways:

    • Transition to TLS 1.2 by September 19.
    • Transition your API URL to a legacy endpoint for your institution— (e.g. institution-name.legacyapi.instructure.com instead of institution-name.instructure.com). Legacy endpoints will be supported until 17 July 2021, which will provide additional time to transition to TLS 1.2.


    TLS Verification Tests

    To test your TLS or URL update, please use your institution’s beta or test environments.

    • TLS has already been disabled for 1.0 and 1.1 in the beta environment. Applications can be tested against the beta environment at any time.
    • On 15 August 15, TLS 1.0 and 1.1 will be disabled in the test environment. If you would like to have your applications tested against the test environment, please make a TLS or URL update configured to the test environment before that date.

    As this change is time sensitive, please note that your Customer Success Manager may contact you regarding your transition strategy.
    Thank you,

Kind Regards,

Shredhar Raju

Shredhar Raju

ICT Systems Engineer

354072_pastedImage_4.png

Labels (2)
Labels
0 Likes
1 Solution

Jump to solution
James
Community Champion
‎07-30-2020 09:10 PM

 @sraju  

First, it may not be anything that you have to change. In the list of 150 IP addresses they gave up, only 2 were actually from our institution. There were a lot from Russia, AmazonAWS and other places that I would attribute to someone trying to hack or perhaps a vendor using AWS who hadn't updated their sites yet. The hits could be from people making API calls from within Canvas using really outdated browsers that are no longer supported by Canvas (like Internet Explorer) or more likely servers that are running outdated software making those calls. I'm talking really outdated -- OpenSSL added support for TLS in version 1.0.1 in March 2012.

Then I found out that our report from Canvas was generated on June 29 and contained data from the prior 30 days. I patched our server last week when Chrome 84 stopped connecting, but that won't disappear from the report until 30 days after that (in mid-late August).

Upgrading your operating system is the best way to enable it. Instructions on how to do that vary by operating system. I had a stable server that had been running without rebooting for 5+ years running Ubuntu 10.04 LTS. The only upgrade path was to upgrade to Ubuntu 12.04 to get TLS 1.2, but that OS stopped being supported in 2017. I would have then had to update to 14.04, 16.04, and 18.04 to get something supported until 2023. Each of those was risky and would require several hours of downtime with the service running on it being unlikely to come back up working when I rebooted. What I did was build a new server from scratch with an up to date OS and TLS 1.2 support.

The legacyapi thing is a temporary work-around if you can't upgrade your servers in time. You would need to go into any code you have making API calls and change the hostname.

If you're running a Linux server, here's a command you can likely use to test your machine.

The first is just to check the version of openssl. You're looking for 1.0.1 or later.

openssl version

It seems that just because the openssl version is new enough doesn't mean that it's enabled. A better check is to actually try to connect somewhere with it.

openssl s_client -connect canvas.beta.instructure.com:443 -tls1_2

If you get certificate information, it supports tls 1.2. If you get an unknown option message with the list of commands, it's not supported. Here's the a portion of the output from an old server I had lying around (but not connecting to Canvas).  You can see the -tls1_2 is not listed.

-ssl2 - just use SSLv2
-ssl3 - just use SSLv3
-tls1 - just use TLSv1
-dtls1 - just use DTLSv1

By the way, if you try -tls1_1 or -tls1 with that command, you'll get messages like this. That's how you can tell if a site has disabled TLS1 or TLS1.1

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported

A successful call (with -tls1_2) gives you something like this:

CONNECTED(00000003)
depth=4 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
verify return:1
depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
verify return:1
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = beta.instructure.com
verify return:1

TLS 1.2 support for windows came out in Windows 7 SP 2. Hopefully you don't have servers running that. Windows Server 2008 didn't get it until 2017.

View solution in original post