Potential TLS config issue for API access with Deno.

[styro]

This would be a travellermap.com hosting issue rather than a problem with the code, so apologies if this is the wrong place.

I'm learning Typescript and trying it out against the travellermap API using Deno (similar to nodejs), and the combination of those two as server and client don't like each other. I don't have any problems connecting with browsers, curl or Python libs, and likewise Deno seems to connect to all the other sites I try it against.

As far as I can tell, it looks like a TLS config mismatch. Here is a relevant chunk of Deno debug log when trying the web Fetch API:

DEBUG RS - deno::proc_state:458 - Prepared module load.
DEBUG RS - deno_runtime::permissions:55 - ⚠️️  Granted net access to "travellermap.com"
DEBUG RS - reqwest::connect:560 - starting new connection: https://travellermap.com/
DEBUG RS - rustls::client::hs:56 - No cached session for DnsName(DnsName(DnsName("travellermap.com")))
DEBUG RS - rustls::client::hs:128 - Not resuming any session
error: Uncaught (in promise) TypeError: error sending request for url (https://travellermap.com/api/coordinates?sector=spin): error trying to connect: Connection reset by peer (os error 104)

I don't know for sure but suspect that the Rust TLS lib rustls (used by Deno and others) is very strict with its ciphers, while your hosting provider only providing weaker ones means that a TLS handshake can't be negotiated between the two.

For reference theses are the rustls cipher suites for TLS 1.2 and 1.3: https://docs.rs/rustls/latest/rustls/cipher_suite/index.html

TLS13_AES_128_GCM_SHA256
TLS13_AES_256_GCM_SHA384
TLS13_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

And with no overlaps, travellermap.com hosting supports these TLS 1.2 ciphers (from https://dev.ssllabs.com/ssltest/analyze.html?d=travellermap.com):

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

SSL Labs reckons those are all weak ciphers, so I suspect the very strict rustls deliberately doesn't support them.

Not a critical issue - I can use other libs. Although something to raise with your hosting provider perhaps - they might be missing out on serving connections from other strict clients.

[inexorabletash]

Indeed, my hosting provider apparently doesn't have updated cipher suites. I'll explore a bit more. On Mar 10, 2023, at 3:26 AM, Anton ***@***.***> wrote: This would be a travellermap.com hosting issue rather than a problem with the code, so apologies if this is the wrong place. I'm learning Typescript and trying it out against the travellermap API using Deno (similar to nodejs), and the combination of those two as server and client don't like each other. I don't have any problems connecting with browsers, curl or Python libs, and likewise Deno seems to connect to all the other sites I try it against. As far as I can tell, it looks like a TLS config mismatch. Here is a relevant chunk of Deno debug log when trying the web Fetch API: DEBUG RS - deno::proc_state:458 - Prepared module load. DEBUG RS - deno_runtime::permissions:55 - ⚠️️ Granted net access to "travellermap.com" DEBUG RS - reqwest::connect:560 - starting new connection: https://travellermap.com/ DEBUG RS - rustls::client::hs:56 - No cached session for DnsName(DnsName(DnsName("travellermap.com"))) DEBUG RS - rustls::client::hs:128 - Not resuming any session error: Uncaught (in promise) TypeError: error sending request for url (https://travellermap.com/api/coordinates?sector=spin): error trying to connect: Connection reset by peer (os error 104) I don't know for sure but suspect that the Rust TLS lib rustls (used by Deno and others) is very strict with its ciphers, while your hosting provider only providing weaker ones means that a TLS handshake can't be negotiated between the two. For reference theses are the rustls cipher suites for TLS 1.2 and 1.3: https://docs.rs/rustls/latest/rustls/cipher_suite/index.html TLS13_AES_128_GCM_SHA256 TLS13_AES_256_GCM_SHA384 TLS13_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 And with no overlaps, travellermap.com hosting supports these TLS 1.2 ciphers (from https://dev.ssllabs.com/ssltest/analyze.html?d=travellermap.com): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA SSL Labs reckons those are all weak ciphers, so I suspect the very strict rustls deliberately doesn't support them. Not a critical issue - I can use other libs. Although something to raise with your hosting provider perhaps - they might be missing out on serving connections from other strict clients. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ckennedy666]

This is due to the reliance on IIS 8. IIS is going to go away eventually, so porting to a modern architecture needs a priority boost.