Io(Custom { kind: InvalidData, error: AlertReceived(HandshakeFailure) }) about rustls HOT 6 CLOSED

ESP32 doesn't have a persistent RTC, so the time needs to be set at every boot. You could get the time from NTP, or maybe another source like GPS. We have a trait https://docs.rs/rustls/latest/rustls/time_provider/trait.TimeProvider.html for providing a different time source, which is useful if the one in std is unsuitable.

from rustls.

Hi @ctz

you are right, I just added the code below and it worked as a charm.

                    let ntp = EspSntp::new_default().unwrap();

                    info!("Synchronizing with NTP Server");
                    while ntp.get_sync_status() != SyncStatus::Completed {}
                    info!("Time Sync Completed");

Thank you all for your input.
Have a good one...

from rustls.

Hi there 👋

I think the issue is that the remote server closes the TLS connection abruptly when it doesn't get a Server Name Indication (SNI) extension.

I'm able to reproduce this with openssl s_client locally:

# Without SNI:
$> openssl s_client -tls1_3 -connect 104.26.8.125:443
CONNECTED(00000003)
4067F0F7FF7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1590:SSL alert number 40
<snipped>

# With SNI:
$> openssl s_client -tls1_3 -connect 104.26.8.125:443 -servername rococo-contracts-rpc.polkadot.io
<snipped>
Verify return code: 0 (ok)

It's also possible to reproduce with the tlsclient-mio example in-repo:

# Works
$> cargo run --package rustls-examples --bin tlsclient-mio -- -p 443 rococo-contracts-rpc.polkadot.io --http
# Fails
$> cargo run --package rustls-examples --bin tlsclient-mio -- -p 443 104.26.8.125 --http

I'm not familiar with the WSS library you're using, but I believe based on the .build(Url::parse("wss://104.26.8.125:443").unwrap()) part that the server name being given to Rustls is an IP address. In that case Rustls doesn't send an SNI extension because those are only valid for domain names and not bare IP addresses.

If you update your code to use a hostname does it still fail?

Is this connected with this issue (#893 (comment)) ?

I don't believe this is the case. It seems to me the server only supports TLS 1.3 in this case, but Rustls happily uses that protocol version.

from rustls.

If you update your code to use a hostname does it still fail?

yes it does with the same error.

So, since I am stuck I have added a fallback DNS server using the project configuration field CONFIG_LWIP_FALLBACK_DNS_SERVER_SUPPORT and CONFIG_LWIP_FALLBACK_DNS_SERVER_ADDRESS="8.8.8.8"(which is the google dns)

(...)
let mut root_store = rustls::RootCertStore::empty();
root_store.roots = webpki_roots::TLS_SERVER_ROOTS.iter().cloned().collect();

let rt = runtime::Builder::new_current_thread()
     .enable_all()
     .build()
     .unwrap();

rt.block_on(async move {
     let wifi = connect_wifi("****", "****");
     let dns_info = wifi.as_ref().unwrap().wifi().sta_netif().get_dns();
     let dns_info_secondary_dns = wifi.as_ref().unwrap().wifi().sta_netif().get_secondary_dns();
     info!("Wifi DNS info: {:?}", dns_info);
     info!("Wifi Secondary DNS info: {:?}", dns_info_secondary_dns);
     info!("is_empty {:?} ", root_store.clone().is_empty());

     let (sender, receiver) = WsTransportClientBuilder::default()
              .use_webpki_rustls()
              .build(Url::parse("wss://rococo-contracts-rpc.polkadot.io:443").unwrap())
              .await.unwrap();

});
(...)

And the error is now this: Io(Custom { kind: InvalidData, error: InvalidCertificate(NotValidYet) })

For sure I am doing something wrong here or is a bug from the ESP-IDF

By the way I have search in the badssl.rs and didn't find this case. Probably I am looking in the wrong place ?

Cheers,

from rustls.

That seems pretty strange. That error originates from https://github.com/rustls/webpki/blob/main/src/verify_cert.rs#L381, but https://www.ssllabs.com/ssltest/analyze.html?d=rococo%2dcontracts%2drpc.polkadot.io&s=104.26.8.125&latest says that the certificate is okay. Maybe your OS/environment doesn't have the time synced properly?

from rustls.

Thanks for reporting back. Glad to hear you've got things working now 👍

from rustls.