debcrafters-packages team mailing list archive

[Mitchell Augustin <2122458@xxxxxxxxxxxxxxxxxx>]

** Description changed:

  SRU Justification:
  
  [ Impact ]
  
  Users who input an incorrect password to a WPA3-SAE Wi-Fi network will
  not receive a prompt to enter a new password when the authentication
  fails - instead, the connection will fail silently, and the user will
  need to "forget" the saved profile and try a fresh connection attempt.
  
  [ Test Plan ]
  
  1. Set up a WPA3-SAE access point
  2. On your test device, attempt to connect to the WPA3-SAE access point with the wrong password
  
  Expected behavior: User should be presented with a dialog to re-enter the password
  Actual behavior (without patch): The connection attempt will fail silently, and the user is never presented with an option to re-enter the password. As a result, they must forget the saved connection profile and try a fresh connection attempt.
  
  [ Fix ]
  
  Add a new function need_new_wpa3_secret(), invoked via handle_8021x_or_psk_auth_fail(), that will prompt for a new secret if a disconnection occurs after the wpa_supplicant AUTHENTICATING state.
  (This is needed since the current source is only adapted to WPA2, where authentication will fail during the 4-way handshake - whereas with WPA3-SAE, it can fail during the AUTHENTICATING state)
  
  [ Where problems could occur ]
  
  Valid connection attempts to WPA3 networks should not be impacted by
  this change, since it only impacts the code path for authentication
  failures.
  
  However, the new user experience could be slightly unexpected in some
  very niche scenarios - for example, if a system has multiple saved
  (working) wifi profiles, and they attempt to connect to a WPA3 one with
  the wrong password, they might not be used to it prompting them for the
  password and waiting for input if they are used to it silently failing
  and falling back to the next valid network.
  
- With this current approach (last state == AUTHENTICATING, current state == DISCONNECT, "sae" as network type are the key conditionals), we hit this same scenario if a WPA3 AP goes out of range or down, meaning the password request is brought up in this state as well, which does not make sense.
- The good thing is that I was able to confirm that with another available network in the area, the DUT will still continue scanning and eventually remove the dead WPA3 network, which will allow the DUT to reconnect to the other good network in the background - so the issue seems to be purely cosmetic. However, I will still discuss with networkmanager upstream to see if there's any info we can get from wpa_supplicant to limit when this check executes.
+ With this current approach (last state == AUTHENTICATING, current state
+ == DISCONNECT, "sae" as network type are the key conditionals), we hit
+ this same scenario if a WPA3 AP goes out of range or down, meaning the
+ password request is brought up in this state as well, which does not
+ make sense.
+ 
+ The proposed patch limits this occurrence by only showing the prompt if
+ this cycle happens twice, which is sufficient to nearly totally
+ eliminate the false positives in my testing so far.
+ 
+ The good thing is that I was able to confirm that with another available
+ network in the area, the DUT will still continue scanning and eventually
+ remove the dead WPA3 network, which will allow the DUT to reconnect to
+ the other good network in the background - so the unexpected behavior
+ seems to be purely cosmetic. From my discussions with NM upstream, there
+ really is not any higher level of precision we can get from
+ wpa_supplicant, due to their upstream not merging patches that would
+ expose the failure reason over dbus for NM to read - so this might be
+ the most precise approach we can get.
  
  [ Other Info ]
  Upstream patch: TBD
  
  Impacts Noble, Plucky, Questing
  
  Likely impacts Jammy (to be confirmed)

** Description changed:

  SRU Justification:
  
  [ Impact ]
  
  Users who input an incorrect password to a WPA3-SAE Wi-Fi network will
  not receive a prompt to enter a new password when the authentication
  fails - instead, the connection will fail silently, and the user will
  need to "forget" the saved profile and try a fresh connection attempt.
  
  [ Test Plan ]
  
  1. Set up a WPA3-SAE access point
  2. On your test device, attempt to connect to the WPA3-SAE access point with the wrong password
  
  Expected behavior: User should be presented with a dialog to re-enter the password
  Actual behavior (without patch): The connection attempt will fail silently, and the user is never presented with an option to re-enter the password. As a result, they must forget the saved connection profile and try a fresh connection attempt.
  
  [ Fix ]
  
  Add a new function need_new_wpa3_secret(), invoked via handle_8021x_or_psk_auth_fail(), that will prompt for a new secret if a disconnection occurs after the wpa_supplicant AUTHENTICATING state.
  (This is needed since the current source is only adapted to WPA2, where authentication will fail during the 4-way handshake - whereas with WPA3-SAE, it can fail during the AUTHENTICATING state)
  
  [ Where problems could occur ]
  
  Valid connection attempts to WPA3 networks should not be impacted by
  this change, since it only impacts the code path for authentication
  failures.
  
  However, the new user experience could be slightly unexpected in some
  very niche scenarios - for example, if a system has multiple saved
  (working) wifi profiles, and they attempt to connect to a WPA3 one with
  the wrong password, they might not be used to it prompting them for the
  password and waiting for input if they are used to it silently failing
  and falling back to the next valid network.
  
  With this current approach (last state == AUTHENTICATING, current state
  == DISCONNECT, "sae" as network type are the key conditionals), we hit
  this same scenario if a WPA3 AP goes out of range or down, meaning the
  password request is brought up in this state as well, which does not
  make sense.
  
  The proposed patch limits this occurrence by only showing the prompt if
  this cycle happens twice, which is sufficient to nearly totally
  eliminate the false positives in my testing so far.
  
  The good thing is that I was able to confirm that with another available
  network in the area, the DUT will still continue scanning and eventually
  remove the dead WPA3 network, which will allow the DUT to reconnect to
  the other good network in the background - so the unexpected behavior
  seems to be purely cosmetic. From my discussions with NM upstream, there
  really is not any higher level of precision we can get from
  wpa_supplicant, due to their upstream not merging patches that would
  expose the failure reason over dbus for NM to read - so this might be
  the most precise approach we can get.
  
  [ Other Info ]
- Upstream patch: TBD
+ Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282
  
  Impacts Noble, Plucky, Questing
  
  Likely impacts Jammy (to be confirmed)

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2122458

Title:
  Password re-entry popup does not appear on incorrect password entry
  with WPA3 networks

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Noble:
  New
Status in network-manager source package in Plucky:
  New
Status in network-manager source package in Questing:
  In Progress

Bug description:
  SRU Justification:

  [ Impact ]

  Users who input an incorrect password to a WPA3-SAE Wi-Fi network will
  not receive a prompt to enter a new password when the authentication
  fails - instead, the connection will fail silently, and the user will
  need to "forget" the saved profile and try a fresh connection attempt.

  [ Test Plan ]

  1. Set up a WPA3-SAE access point
  2. On your test device, attempt to connect to the WPA3-SAE access point with the wrong password

  Expected behavior: User should be presented with a dialog to re-enter the password
  Actual behavior (without patch): The connection attempt will fail silently, and the user is never presented with an option to re-enter the password. As a result, they must forget the saved connection profile and try a fresh connection attempt.

  [ Fix ]

  Add a new function need_new_wpa3_secret(), invoked via handle_8021x_or_psk_auth_fail(), that will prompt for a new secret if a disconnection occurs after the wpa_supplicant AUTHENTICATING state.
  (This is needed since the current source is only adapted to WPA2, where authentication will fail during the 4-way handshake - whereas with WPA3-SAE, it can fail during the AUTHENTICATING state)

  [ Where problems could occur ]

  Valid connection attempts to WPA3 networks should not be impacted by
  this change, since it only impacts the code path for authentication
  failures.

  However, the new user experience could be slightly unexpected in some
  very niche scenarios - for example, if a system has multiple saved
  (working) wifi profiles, and they attempt to connect to a WPA3 one
  with the wrong password, they might not be used to it prompting them
  for the password and waiting for input if they are used to it silently
  failing and falling back to the next valid network.

  With this current approach (last state == AUTHENTICATING, current
  state == DISCONNECT, "sae" as network type are the key conditionals),
  we hit this same scenario if a WPA3 AP goes out of range or down,
  meaning the password request is brought up in this state as well,
  which does not make sense.

  The proposed patch limits this occurrence by only showing the prompt
  if this cycle happens twice, which is sufficient to nearly totally
  eliminate the false positives in my testing so far.

  The good thing is that I was able to confirm that with another
  available network in the area, the DUT will still continue scanning
  and eventually remove the dead WPA3 network, which will allow the DUT
  to reconnect to the other good network in the background - so the
  unexpected behavior seems to be purely cosmetic. From my discussions
  with NM upstream, there really is not any higher level of precision we
  can get from wpa_supplicant, due to their upstream not merging patches
  that would expose the failure reason over dbus for NM to read - so
  this might be the most precise approach we can get.

  [ Other Info ]
  Upstream patch: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2282

  Impacts Noble, Plucky, Questing

  Likely impacts Jammy (to be confirmed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2122458/+subscriptions