deno: error trying to connect: tls handshake eof
For some reason doing a GET on https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0?f=json
crashes Deno with:
error: Uncaught Http: error sending request for url (https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0?f=json):
error trying to connect: tls handshake eof
Works fine with curl and client side JS. Something wrong with SSL management in Deno? Calling on HTTP doesn’t work either since Deno upgrades to HTTPS.
Steps to reproduce
Source:
const layerInfoURL = 'https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0?f=json';
const json = await fetch(layerInfoURL).then(r => r.json());
console.log(json);
or
deno run --allow-net https://deno.land/x/gh:enjikaka:terrain-server/poor_api.ts
Version
deno 1.1.1 v8 8.5.104 typescript 3.9.2 macOS 10.15.5 (19F101) also fails in docker on hayd/alpine-deno:1.1.1
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 23 (9 by maintainers)
@lucacasonato you answer here:
does not resolve the issue. TLS gets upgraded to better more secure versions over time. Old servers (that Deno users do not control) can keep using old versions. The old versions are not “insecure”, they are less secure, as you can never achieve 100% security.
If Deno (or the underlying Rust library) is not willing to provide a way to communicate with these (admittedly) old servers, then a workaround would be highly desirable (with the appropriate warnings).
In my case, I am trying to communicate with iCloud webdav calendar servers. I doubt I will be able to convince Apple in a reasonable timeframe that their servers are “insecure” and that they should upgrade.
Don’t mean to sound snarky, just pointing to a real world issue. Thanks for all the great work you’ve all put into Deno.
It’s quite a showstopper for using Deno if you can’t consume certain third-party APIs… Will be bad for adoption.
Is rustls planning support? Otherwise I guess an alternative needs to be evaluated.
@jacobgc the native-tls crate won’t let us control the exact ciphersuites, but it does enable controlling the min and max TLS protocol version, trusted root certificate, and whether to accept or reject invalid certificates.
FYI: I created a thingproxy docker image for the time being as an alternative workaround for others.
No.
Got a reply at https://github.com/ctz/rustls/issues/381 The host runs an old version of IIS and thus has old certificates that just aren’t supported. Not sure what else to suggest. They need to move with the times. For now, I’d suggest keeping with the proxy setup you’ve got going.
I agree completely. In an ideal world though these sites would upgrade their SSL certs to more modern ciphers. However this isn’t going to happen. I dont think rustls has any plans to add in AES without GCM however I’ll raise an issue and see what I get back.
I know it seems silly to put so much effort into a workaround, but here you go anyway. 🤪
I created a module, zinthose/thingproxy-deno , that can replace the
fetchapi to automatically forward requests through a thingproxy server.⚠️ The module is fairly simple but may still have bugs. ⚠️
Example
Hey. I have the same problem , any progress over this case 😭
To compare here’s
curl -vwith the plain server vs proxied response:curl -v https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0\?f\=jsoncurl -v https://thingproxy.freeboard.io/fetch/https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0/\?f\=jsonI think
ALPN, server did not agree to a protocolis the issue here?I temporarily solved it on my end by proxying through another cert. https://github.com/Freeboard/thingproxy