tirithen / tradfri_gateway

A rust crate for connecting to the Ikea TRÃ…DFRI gateway, and for controlling your home devices through the gateway.
https://crates.io/crates/tradfri_gateway
Apache License 2.0
6 stars 0 forks source link

No ciphers enabled for max supported SSL/TLS version #1

Open SickanK opened 7 months ago

SickanK commented 7 months ago

Hello,

When trying to run the example program I'm getting the error below, regardless of gateway_code. I've tried updating the openssl dependencies without any success.

Error: CoapError(Error { cause: "Failure(Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 167772341, library: \"SSL routines\", function: \"ssl_cipher_list_to_bytes\", reason: \"no ciphers available\", file: \"ssl/statem/statem_clnt.c\", line: 4138, data: \"No ciphers enabled for max supported SSL/TLS version\" }]))) }, X509VerifyResult { code: 0, error: \"ok\" }))" })

Love the project and I hope to be able to use it for my own homelab soon! 😄

tirithen commented 7 months ago

Hi @SickanK ! Sorry for the late reply! Glad that you are interested in the project.

I tested it now, and it connects correctly on my machine to my gateway, even if I got some error from one of my lights, possibly the gateway has received some update since I last ran. I'm by far not an expert on Coap/dtls/SSL, but I know some Rust, lets try to debug.

When using invalid gateway code I get this (not the same as you):

$ cargo run --example light
   Compiling tradfri_gateway v0.2.0 (/home/user/tradfri_gateway)
    Finished dev [unoptimized + debuginfo] target(s) in 24.94s
     Running `target/debug/examples/light`
Error: CoapError(Error { cause: "Failure(Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 167773180, library: \"SSL routines\", function: \"dtls1_read_bytes\", reason: \"sslv3 alert bad record mac\", file: \"ssl/record/rec_layer_d1.c\", line: 613, data: \"SSL alert number 20\" }]))) }, X509VerifyResult { code: 0, error: \"ok\" }))" })

When I add the credentials as it is printed on a sticker under my gateway I get the following:

$ cargo run --example light
   Compiling tradfri_gateway v0.2.0 (/home/user/tradfri_gateway)
    Finished dev [unoptimized + debuginfo] target(s) in 1.28s
     Running `target/debug/examples/light`
TradfriGateway {
    address: 192.168.1.123,
    identifier: "**maskeduser**",
    session_key: "**maskedkey**",
}
...

The idea is then to use the identifier and session_key on later connections as if you keep requesting new keys each time you run the application the gateway will eventually start dropping the oldest keys which likely resides in your phone app and you would need to re-connect your phone.

I would suggest that we compare the gateway that we are both using (IKEA also has a newer one that I have not tested), and the machine that we compile/run the example on.

I'm using a gateway that looks like this https://www.ikea.com/se/sv/customer-service/product-support/app-gateway/ with the type: E1526 printed on the sticker under the device.

I'm building and running the project on an Arch Linux machine.

You seem to have an error "no ciphers available", so possibly there is something wrong with the openssl crate and its available ciphers? There is also a vendored feature available for openssl that I seem to have set to always be active, maybe disabling that would help?

If you are on a Mac or Windows machine maybe openssl has a different set of ciphers available in the vendored version?

Try cloning the repo and removing the vendored feature from openssl https://github.com/tirithen/tradfri_gateway/blob/main/Cargo.toml#L16

If we solve it I would love to add the fixes to the repo.

tirithen commented 7 months ago

I actually saw now when I tried with the identifier and session_key that I was given from the gateway_code that I get your error when trying to connect:

Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/examples/light`
TradfriGateway {
    address: 192.168.1.123,
    identifier: "**maskeduser**",
    session_key: "**maskedkey**",
}
Error: CoapError(Error { cause: "Failure(Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 167772341, library: \"SSL routines\", function: \"ssl_cipher_list_to_bytes\", reason: \"no ciphers available\", file: \"ssl/statem/statem_clnt.c\", line: 4138, data: \"No ciphers enabled for max supported SSL/TLS version\" }]))) }, X509VerifyResult { code: 0, error: \"ok\" }))" })

So something must have changed since the last time I ran this project, maybe they have upgraded the authentication part of the API on the gateway. I have limited time work on this at the current moment.

Probably you also got stuck after the first run where it generated the credentials?

As I remember it I had a hard time finding existing coap libraries in native Rust that also supported the dtls layer IKEA uses for encrypting the connection. I think I borrowed a lot of code from the https://github.com/TimonPost/udp-dtls repo stripping out the things that I did not need and fixing some things that was broken. Maybe there is something there that needs to be checked a bit more.

Give it a go if you feel up to it, I might return to this eventually as I'm interested both in a cli and a dioxus app for controlling ikea lights with, bit I'm currently per-occupied on other tracks.

madbonkey commented 1 month ago

I'm also facing the error that OP was/is facing (and now you as well, if I understand correctly @tirithen)

After cloning this repo locally, I removed the vendored feature from openssl, as well as updating both openssl dependencies to their latest versions - sadly, to no avail.

I fiddled a bit with the code in some places, too, but haven't been able to achieve anything. That said, I only spent about half an hour with the code, so no suprise. I'll try to debug some more.

I'm running on macOS, in case that might be relevant.

Hopefully we can get this fixed :)