error trying to connect: tls handshake eof #6427
Comments
|
I'm having the same issue. ATM, I'm dead in the water as this is a blocking issue for me to adopt Deno. I have a POST request to a remote REST API that uses a standard GoDaddy Cert so it's not self signed like I'm seeing in other issues. From my understanding the issue's root is with the TLS method used but I'm unclear how to change or correct it. I can successfully make the call using Node or GO. The Go code used for reference is below with certain details changed due to security and confidentiality issues. package main
import (
"fmt"
"io/ioutil"
"net/http"
"strings"
)
func main() {
url := "https://api.test.com/webapi/api/session"
method := "POST"
payload := strings.NewReader("{\"UserId\":\"test@test.com\",\"Password\":\"P@$$w0rd\",\"SourceSystem\":\"BUDDY\"}")
client := &http.Client{}
req, err := http.NewRequest(method, url, payload)
if err != nil {
fmt.Println(err)
}
req.Header.Add("Content-Type", "application/json;charset=UTF-8")
res, err := client.Do(req)
defer res.Body.Close()
body, err := ioutil.ReadAll(res.Body)
fmt.Println(string(body))
} |
|
I temporarily solved it on my end by proxying through another cert. https://github.com/Freeboard/thingproxy |
|
I did try adding cors and origin to my request headers using soxa but to no effect. @enjikaka I'll look into thingproxy as a temporary solution. |
|
@zinthose CORS doesn't matter here. It's the HTTPS management in Deno and/or the rust lib it uses that doesn't handle specific certs correctly. With that thingproxy it'll use another cert that Deno doesn't error on, which is a temporary hack around the issue. :) |
|
To compare here's
I think |
|
I did a DIFF compare with the results below. It dose appear the protocol is the issue.
|
|
FYI: I created a thingproxy docker image for the time being as an alternative workaround for others. |
|
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 Exampleconst response = await phetch("https://postman-echo.com/get?foo1=bar1&oo2=bar2");
console.log(response.status);
// e.g. 200 console.log(response.statusText);
// e.g. "OK" const jsonData = await response.json(); |
|
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. |
|
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. |
|
Got a reply at rustls/rustls#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. |
|
As long as Deno uses rustls as its TLS library exclusively, it inherits the constraints imposed by rustls. Rustls is quite opinionated about security. An alternative would be to enable Deno to use another TLS crate, like native-tls (that uses schannel on Windows and OpenSSL on Linux), which supports a very wide range of ciphersuites and certificates and protocols - including those that have known vulnerabilities and weaknesses. Perhaps with some "feel bad" command line flag, like |
|
The connections are still secure, just not as secure as more modern cipher suites. I do like the idea of using a wider supported SSL library like native-tls. Not sure exactly if you could block specific cipher suites though. |
|
@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. |
|
@Spoonbender Certainly a much better solution than what Deno currently has. |
|
Hello, any progress over this case? |
|
No. |
|
Hey. I have the same problem , any progress over this case 😭 |
|
I have this problem too 😭 |
|
The original issue (fetching For others: This is not a Deno issue. Your server is using an old insecure TLS version that Deno refuses to accept. Try with |
|
@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. |
|
I only need a simple server for localhost. Do I need to go through everything just to do a small localhost that only live for a few hours? |
For some reason doing a GET on
https://copernicus.discomap.eea.europa.eu/arcgis/rest/services/Corine/CLC2018_WM/MapServer/0?f=jsoncrashes Deno with:
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:
or
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
The text was updated successfully, but these errors were encountered: