darksky api: TLS requirements changed, library no longer works

I've been using this C# library wrapper for the darksky API:

 https://github.com/amweiss/dark-sky-core

In my implementation I poll once every 3 minutes to get the forecast, which I use in my home thermostat network:

    async void GetForecast()
    {
        // https://darksky.net/dev/docs#forecast-request
        float Temp, DewPoint, WindSpeed, WindChill, Humidity, HeatIndex;
        var client = new DarkSkyService("user-api-key");
        try
        {
            Forecast fc = await client.GetWeatherDataAsync(38.329444, -87.412778);
            Temp = (float)Math.Floor(fc.Currently.Temperature);
            PublishTemp(Temp);

            // for database, get temp,  dewpoint, calculate windchill, calculate heatindex
            DewPoint = (float)fc.Currently.DewPoint;
            WindSpeed = (float)fc.Currently.WindSpeed;
            Humidity = (float)fc.Currently.Humidity;  // range: 0-1
            WindChill = (float)CalculateWindChill(Temp, WindSpeed);
            HeatIndex = (float)CalculateHeatIndex(Temp, Humidity);
            SaveToDatabase(Temp, DewPoint, WindChill, HeatIndex);

            RxForecast = true;
            if (DateTime.Now.Hour != LastForecastHour)
            {
                LatestForecast = fc;
                LastForecastHour = DateTime.Now.Hour;
                PublishForecasts();
            }
        }
        catch (Exception s) {
            RxForecast = false;
        }
     ForecastWaitTime = RxForecast ? FAST_FORECAST_CYCLE : SLOW_FORECAST_CYCLE;
    }

This has worked fine for about 4 months before it abruptly stopped working a week ago. Darksky support said that they have recently implemented security updates and no longer support most common TLS ciphers (quoting):

- TLS 1.0
- TLS 1.1
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA

You can definitively determine whether your app works with the new SSL permissions by testing against
https://api.darksky.net:4433/. If you decide to update SSL on your end, you can test the API by sending a request here: https://api.darksky.net:4433/v1/status.txt.

Note that we will be making additional security-related updates in the coming weeks so there will be more changes in the near future. We don't have a notification system for alerting users to changes made on our backend but we do offer a feed for our status page, which often includes information about updates that have been or will be made (https://status.darksky.net/). We'll do our very best to make sure we communicate them as we're able to. Additionally, to avoid future disruptions we strongly recommend switching to one of the following, which should carry you through any of the additional security updates that will be applied in the near future:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

I have no idea what changes I need to make to this code to 'update TLS', and I can't seem to get any more information from darksky. In the meantime, my alarm system is at a standstill.

One thing I don't understand is that, if I type this URL in a browser:

https://api.darksky.net/forecast/my-api-key/38.329444, -87.412778

It works fine, and immediately returns a huge JSON forecast string. Trying this with HttpWebRequest, HttpClient, or WebClient, in code results in different "errors occurred" exceptions. Overall, I'd rather use the library for the returned Forecast object that is easy to interpret.

Is this TLS update something I do at the system level, outside the devlopment environment?

Or, are there any alternatives to darksky that I could switch to?

Solution

You have two options:

1: update the library you are using and recompile. This issue was reported on its github page:

https://github.com/jcheng31/DarkSkyApi/issues/28

2: It's a bit of work but you could move the forecast module to Linux/Raspberry Pi, where TLS12 is already configured. You will have to rewrite the routine in Python to do this. I verified this approach would work on my own PI network.