netdev - Re: [PATCH v2] Set ssid when authenticating

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Feb 2023 19:04:22 +0000
From:   Marc Bornand <dev.mbornand@...temb.ch>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     linux-wireless@...r.kernel.org,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Kalle Valo <kvalo@...nel.org>,
        Yohan Prod'homme <kernel@...do.fr>, stable@...r.kernel.org
Subject: Re: [PATCH v2] Set ssid when authenticating

On Monday, February 13th, 2023 at 18:37, Johannes Berg <johannes@...solutions.net> wrote:


>
>
> Hi,
>
> As an aside - there's little point in encrypting the mail sent to me
> when you send it also to a public list :) Just makes it more annoying to
> use.
Really Sorry, The mail service I am using is currently not letting me deactivate
encryption for recipients with a wkd, I think I will try to contact support
and ask there.

>
> > > This is incorrect, doing an authentication doesn't require doing an
> > > association afterwards, and doesn't necessarily imply any state change
> > > in the kernel.
> >
> > So is it intended behavior that the ssid in wireless_dev is not set
> > or is there a place were this state change should happen?
>
>
> It's incorrect in that this is the wrong place to set it.
>
> I don't have a strong feeling about whether it should be set, but I
> clearly assumed that it is indeed set ...

The upstream behavior for know is that the SSID is not set in
wireless_dev.u.client.ssid, when cfg80211_connect is not used.
This is the case at least one some setup with iwd and wpa3.

>
> > > > alternatives:
> > > > 1. Do the same but during association and not authentication.
> > >
> > > Which should probably be done after successful authentication, even in
> > > the CONNECT command case, which currently does it in cfg80211_connect()
> > > but I guess that should move to __cfg80211_connect_result().
> >
> > Is there an existing way to get the ssid in __cfg80211_connect_result()?
>
>
> There's the BSS, or multiple pointers for multi-link.
>
> > Just a side question do the BSSes all have the same SSID?
>
>
> In multi-link? Yes, I don't think we actively enforce that wpa_s does
> that, but we'd probably fail to connect to the AP if that weren't the
> case. So yeah. Maybe we should check it in assoc.
>
> Here I think you can safely just pick any of the BSSes and look at the
> SSID. Really we could even do the same in the nl80211 code, but it's
> probably easier to fill in the ssid when we already have it anyway.
>
> In the connect case it might be needed to fill it in earlier for use by
> the SME state machine, not sure.
>
> johannes


Marc