Wifi security

[brainstorm]

Fixes issue #63 and readies SSH Stamp for security audit in #7.

Implements WPA2-WPA3 security by default... there seems to be a problem (bug?) with WPA3-only mode on esp_hal I need to investigate further: NetworkManager mis-identifies the network as WEP and PMF is disabled (should be enabled/mandatory in WPA3).

TODO:

• Move more of the console messages to debug!() instead of info!() so that the user sees the generated wifi password easily and can copy-paste it on their client easily.
• Investigate WPA3 issue on esp_hal.
• Test thoroughly on hardware.

[jubeormk1]

Overall I like the way this is looking! But there are a couple of things:

• The board starts and the wifi is up but I cannot reach by ping or ssh ssh-stamp. We need to review what has changed.
• Opinion: I would apply the WiFi ENV_VAR at once given that there is no error parsing SSID or PSK once all the environment variables have been processed as I mentioned in an inline comment.

[brainstorm]

The board starts and the wifi is up but I cannot reach by ping or ssh ssh-stamp. We need to review what has changed.

Weird, I just tested now and seems to work fine? A few checkpoints needed here:

1. Start with espflash erase-flash, just to make sure we start from known pre-conditions.
2. Make sure you delete the old hostkey from your ~/.ssh/known_hosts before re-flashing the device.
3. Does echo $SSH_STAMP_PUBKEY show an ed25519 pubkey before running ssh -o SendEnv=SSH_STAMP_PUBKEY zssh@192.168.4.1?
4. Before all that, do you "forget ssh-stamp access point on your client" and input the wireless PSK and does it connect alright?

This is what I'm seeing on my machine at the time of writing this on this branch as-is:

[jubeormk1]

While you have it fresh in your mind, could you add doc comments for what this function and wifi_up does? They retrieve the wifi_password and wifi_ssid from config.

Would it be reasonable defining these functions as part of config or you rather have them here because they are part of espressif configuration requirements?

[jubeormk1]

Extensive hardware testing has found more points to look at. For now I am not digging in the source of the problems but there are some issues that we need to address. Sit down and grab a hot drink because this is a long review!

Hardware Testing

I am doing some manual hardware testing:

• Erasing-flash espflash erase-flash
• Running `cargo run-esp32c6
• Connect to SSID without password should fail: Ok
• Connect to SSID with incorrect password fails: Ok
• Connect to SSID with correct password should pass: Ok
• Connecting to the SSID after an incorrect password with a correct password should work: Not OK See issue 1
• All checks from Auth PR (#62) keep working as expected: Ok
• Bridge works both ways: Ok
• Repeated ssh connections to 192.168.4.1 run as expected: Ok
• Updating PSK via env variable: Works triggering some issues
• Updating empty PSK via env variable fails: Ok, minimum password length 8 chars
• Updating SSID via env variable: Not Ok See issue 3
• Updating SSID and PSK at once via env variable: Not Ok See issue 4
• Provisioning public key, SSID and PSK in first connection: Not OK See issue 4

Issues

1. Connecting to the SSID after an incorrect password with a correct password fails

Further testing reveals that after a connection to the SSID with the wrong password the SSID dissapears from the list. At some point nmcli dev wifi shows two SSID with the same name and same BSSID.

Repeated connection and disconnections with the right password does work as expected and 192.168.4.1 is reachable when expected too.

2. Updating password

The password is updated, the system reboots and so espflash monitor displays it. However the session gets stuck.

Maybe we need to:

• Fail the session in order to resolve this situation or
• Document this behaviour or
• Continue the session and reset on client disconnection

A second effect is that given that network-manager and other connection methods remember passwords, they fail on the authentication and trigger issue 1.

3. Updating SSID fails

The system restart after providing the new SSID via SSH_STAMP_WIFI_SSID with no errors or warnings. However on reboot there is no SSID detected and espflash monitor shows a message with the original SSID, ssh-stamp.

Another effect noticed is that as in the issue updating password the session hangs.

4. Provisioning of public key, SSID and PSK fails

As a summary, the client only sends one env variable other than LANG at a time.

Warning error received: Unauthenticated SessionShell rejected. Looking at the espflash monitor logs with debug messages shows that only LANG and SSH_STAMP_WIFI_PSK were processed before the SessionShell event. Looking at client side verbose logs, only those two variables were sent.

Only sending one env var at a time is present when provisioning all parameters at once and when the SSID and PSK were sent with auth. Maybe I am doing something wrong. See .ssh/config entry:

# Tested also using individual SendEnv 
Host ssh-stamp-pkey-wpass-wssid
    HostName 192.168.4.1
    StrictHostKeyChecking=no
    UserKnownHostsFile=/dev/null
    SetEnv SSH_STAMP_WIFI_PSK="hil-ssh-stamp"
#    SendEnv SSH_STAMP_WIFI_PSK
    SetEnv SSH_STAMP_WIFI_SSID="ssh-stamp-2"
#    SendEnv SSH_STAMP_WIFI_SSID
    SetEnv SSH_STAMP_PUBKEY="ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFgsW7cs8Ka5xxNScN9ubnoflW+0Eefk3h5lFPlAsnbf worker@hil-ssh-stamp"
#    SendEnv SSH_STAMP_PUBKEY
    SendEnv SSH_STAMP_PUBKEY SSH_STAMP_WIFI_SSID SSH_STAMP_WIFI_PSK

debug logs flags: ESP_LOG=ssh_stamp=debug cargo run-esp32c6

Espressif platform bug?

Sometimes after triggering the issue 2 of this list, erasing the flash and flashing a new version, the SSID seems to not start announcing itself even when the monitor logs look fine. resetting the program via monitor does not work but pressing the physical button or calling espflash hold-in-reset follow by a a ctl+r from espflash monitor brings the SSID back.

As there is a know problem in the Espressif blob, that does not enable WPA3 but the esp_hal announce it, I wonder if there is a bug here

[brainstorm]

I think I managed to fix the last 3 issues with the environment variables! ... in a somewhat convoluted way using NEEDS_RESET atomic to be effective after a client quits instead of immediately resetting, but I couldn't think of a better alternative for now... now at least passing several env vars at once (in a single client connection) seems to work?

I need to understand the HSM logic better overall, sigh.

Also, I couldn't fix the invalid password and then valid password issue (reproduced it and it's indeed annoying to see the AP SSID disappear :-!).

I'll leave the following extra pointers for future exploration, might open a separate issue to tackle this particular one, actually and reflect this issue as a KNOWN_BUGS file for now unless anybody has better ideas on what might be happening in this case? :-/

Here's a few options we could test though:

// Option 1: Add explicit channel
AccessPointConfig::default()
    .with_ssid(...)
    .with_auth_method(Wpa2Wpa3Personal)
    .with_password(...)
    .with_channel(esp_radio::wifi::Channel::C1)  // Explicit channel

// Option 2: Add PMF configuration (if available)
// WPA2/WPA3 transition mode may help
Workarounds for users:
- On the client side: nmcli connection delete ssh-stamp then reconnect
- Or "Forget network" in WiFi settings before retrying
Hardware debugging needed:
- Enable esp-radio=debug logging to see if auth failure events are emitted
- Check if WifiEvent::ApStaDisconnected exists and should be handled

The WPA3 (non-transitional, SAE, PMF-mandatory version) issue is another hard pickle, see the following PRs and esp-hal Matrix chat exchange for reference:

Here are my experimental branches on the subject as I was referring to the chat conversation above:

brainstorm/esp-hal@a61baf7
https://github.com/brainstorm/ssh-stamp/tree/wpa3

But TL;DR, the wifi binary blobs from esp-wifi-sys need to be recompiled via https://github.com/esp-rs/esp-wireless-drivers-3rdparty with CONFIG_ESP_WIFI_ENABLE_WPA3_SAE=y sdkconfig options and some esp-idf documented caveats... so no easy WPA3-only operation for esp_hal upstream for now.