Re: 802.11 autoassoc

[Martin Pieuchot]

Hey Vadim, I'm happy to see you've put some efforts into improving
how wireless networks are configured on OpenBSD.  I have some questions
below.

On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
 
 This is a proof-of-concept patch that implements network profiles
 in kernel, using IEEE 802.11 network name and/or BSSID.

Why did you choose to put this in the kernel, did you encounter any
technical problem, or was it easier/better that way?

 Current idea is as following:
 
   1. Each 802.11 interface now have flag autoassoc. If enabled,
  kernel will automatically scan for known networks. Interval
  between scans is hardcoded to 3 seconds for now.

 
  If a known network is found, the interface gets automatically
  reconfigured using corresponding profile, and userland will
  receive notification via routing socket.

But if a new network is selected, assuming that I run dhclient(8) on
this interface, what will happen?

  If another known network is already configured and has higher
  precedence (i.e., it's placed earlier in the list), nothing
  will be done (for that interface).
 
   2. Profiles are loaded (and could be viewed) via sysctl syscall.
  At the present, there is not support to display profiles,
  though (lazy me).
 
   3. There is a userland companion for this functionality - reworked
  autonetd, that I'll present separately, if this patch (after
  polishing, of course) will go in.

What does this deamon do?  How does it integrate itself with the
existing way of configuring interfaces (/etc/hostname.if*)? 

 Oh, and about the sys/net/if_slvar.h and sys/net/ppdefs.h: we were
 lucky enough that duplicated definition didn't bite us yet, but
 now it is.

Don't worry about that, if_slvar.h is going to disappear soon ;)

 I'm posting this right before going to country for the weekend.
 So, unfortunately, I'll be able to answer any questions in the Monday.

Your diff below is really big and will scare a lot of people.  I don't
think we can discuss it without having a clear picture of how to auto-
configure wireless network.  But I'd recommend you to make sure it
respects style(9) and you could even split it into various parts.

Martin

Re: 802.11 autoassoc

[Stefan Sperling]

On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote:
 Hey Vadim, I'm happy to see you've put some efforts into improving
 how wireless networks are configured on OpenBSD.  I have some questions
 below.
 
 On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
  
  This is a proof-of-concept patch that implements network profiles
  in kernel, using IEEE 802.11 network name and/or BSSID.
 
 Why did you choose to put this in the kernel, did you encounter any
 technical problem, or was it easier/better that way?

Note also that there is an existing 'autoassoc' behaviour.
The net80211 stack will try to automatically associate with
an open wireless network as soon as the interface is brought up.
I think it would make sense to try to keep this behaviour for
encrypted networks for which the key has been pre-loaded into
kernel memory somehow. The primary focus of the kernel should be
on trying to get link on an interface, like it does with open wifi.

Below is a diff I once wrote which caches network keys in the kernel.
It's not perfect either because it still requires users to enter the
nwid they want to associate with if a network is encrypted. In other words,
it doesn't require users to enter a wep/wpa key more than once while the
system is accumulating uptime. But there is no automatic association
with an encrypted network found during a scan, and no integration with
userland via routing sockets (an idea which I like a lot because it
opens up the possibility for desktop integration and other nice things).

Index: ieee80211_crypto.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_crypto.c,v
retrieving revision 1.60
diff -u -p -r1.60 ieee80211_crypto.c
--- ieee80211_crypto.c  11 Jan 2011 15:42:05 -  1.60
+++ ieee80211_crypto.c  21 Aug 2013 14:17:25 -
@@ -65,6 +65,7 @@ ieee80211_crypto_attach(struct ifnet *if
struct ieee80211com *ic = (void *)ifp;
 
TAILQ_INIT(ic-ic_pmksa);
+   TAILQ_INIT(ic-ic_pws);
if (ic-ic_caps  IEEE80211_C_RSN) {
ic-ic_rsnprotos = IEEE80211_PROTO_WPA | IEEE80211_PROTO_RSN;
ic-ic_rsnakms = IEEE80211_AKM_PSK;
@@ -91,6 +92,8 @@ ieee80211_crypto_detach(struct ifnet *if
free(pmk, M_DEVBUF);
}
 
+   ieee80211_passwd_remove_all(ic);
+
/* clear all group keys from memory */
for (i = 0; i  IEEE80211_GROUP_NKID; i++) {
struct ieee80211_key *k = ic-ic_nw_keys[i];
@@ -648,4 +651,159 @@ ieee80211_pmksa_find(struct ieee80211com
break;
}
return pmk;
+}
+
+#define IEEE80211_PW_CACHE_SIZE 16
+
+#define IEEE80211_PW_DEBUG
+
+/*
+ * Cache a WPA PSK for the current desired ESSID.
+ * If PSK is NULL, clear the cached PSK.
+ */
+struct ieee80211_passwd *
+ieee80211_passwd_psk(struct ieee80211com *ic, u_int8_t *psk)
+{
+   struct ieee80211_passwd *pw;
+#ifdef IEEE80211_PW_DEBUG
+   char essid[IEEE80211_NWID_LEN + 1];
+#endif
+
+   if (ic-ic_npws = IEEE80211_PW_CACHE_SIZE) {
+   /* TODO expire least recently used entry instead of return */
+   return NULL;
+   }
+
+   if (ic-ic_des_esslen == 0)
+   return NULL;
+
+#ifdef IEEE80211_PW_DEBUG
+   memcpy(essid, pw-pw_nwid, IEEE80211_NWID_LEN);
+   essid[IEEE80211_NWID_LEN] = '\0';
+#endif
+
+   pw = ieee80211_passwd_find(ic);
+   if (pw == NULL) {
+   if (psk == NULL)
+   return NULL;
+#ifdef IEEE80211_PW_DEBUG
+   printf(%s: new wpa psk for %s\n, __func__, essid);
+#endif
+   pw = malloc(sizeof(*pw), M_DEVBUF, M_ZERO|M_NOWAIT);
+   if (pw == NULL)
+   return NULL;
+   memcpy(pw-pw_nwid, ic-ic_des_essid, IEEE80211_NWID_LEN);
+   TAILQ_INSERT_TAIL(ic-ic_pws, pw, pw_next);
+   ic-ic_npws++;
+   }
+#ifdef IEEE80211_PW_DEBUG
+   else
+   printf(%s: changing wpa psk for %s\n, __func__, essid);
+#endif
+
+   if (psk) {
+   memcpy(pw-pw_psk, psk, IEEE80211_PMK_LEN);
+   pw-pw_flags |= IEEE80211_PASSWD_HAVE_PSK;
+   } else if (pw-pw_flags  IEEE80211_PASSWD_HAVE_PSK) {
+   explicit_bzero(pw-pw_psk, IEEE80211_PMK_LEN);
+   pw-pw_flags = ~IEEE80211_PASSWD_HAVE_PSK;
+   }
+
+   return pw;
+}
+
+/*
+ * Cache WEP keys for the current desired ESSID.
+ * Clear cached keys if KEYS is NULL.
+ */
+struct ieee80211_passwd *
+ieee80211_passwd_wep(struct ieee80211com *ic, struct ieee80211_key *keys,
+int def_txkey)
+{
+   struct ieee80211_passwd *pw;
+#ifdef IEEE80211_PW_DEBUG
+   char essid[IEEE80211_NWID_LEN + 1];
+#endif
+   int i;
+
+   if (ic-ic_npws = IEEE80211_PW_CACHE_SIZE) {
+   /* TODO expire least recently used entry instead of return */
+   return NULL;
+   }
+
+   if (ic-ic_des_esslen == 0)
+   return NULL;
+

Re: 802.11 autoassoc

[Vadim Zhukov]

2014-09-30 13:59 GMT+04:00 Martin Pieuchot mpieuc...@nolizard.org:
 Hey Vadim, I'm happy to see you've put some efforts into improving
 how wireless networks are configured on OpenBSD.  I have some questions
 below.

 On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:

 This is a proof-of-concept patch that implements network profiles
 in kernel, using IEEE 802.11 network name and/or BSSID.

 Why did you choose to put this in the kernel, did you encounter any
 technical problem, or was it easier/better that way?

I was asked to try this way some time ago, when I presented autonetd.

I don't feel myself enough experienced to judge hard which way it's
better. Actually, there are pros and cons either way. All I want is to
have easy-to-use and robust Wi-Fi (at least) configuration. :) So I'm
open to any ideas and improvements.

 Current idea is as following:

   1. Each 802.11 interface now have flag autoassoc. If enabled,
  kernel will automatically scan for known networks. Interval
  between scans is hardcoded to 3 seconds for now.


  If a known network is found, the interface gets automatically
  reconfigured using corresponding profile, and userland will
  receive notification via routing socket.

 But if a new network is selected, assuming that I run dhclient(8) on
 this interface, what will happen?

With autonetd, dhclient(8) will be stopped/(re-)run, depending on
profile. But your question gave me an idea - we could forcefully
remove all addresses on interface, as a matter of sanity. dhclient(8)
will die itself then.

  If another known network is already configured and has higher
  precedence (i.e., it's placed earlier in the list), nothing
  will be done (for that interface).

   2. Profiles are loaded (and could be viewed) via sysctl syscall.
  At the present, there is not support to display profiles,
  though (lazy me).

   3. There is a userland companion for this functionality - reworked
  autonetd, that I'll present separately, if this patch (after
  polishing, of course) will go in.

 What does this daemon do?

1. Loads profiles to kernel at startup or reload.

2. Monitors interfaces marked with autoassoc flag for changes of
current profile; when this happens, it performs userland-side
configuration steps: static addressing, running dhclient,
notifications, etc.

 How does it integrate itself with the
 existing way of configuring interfaces (/etc/hostname.if*)?

# echo nwflag autoassoc /etc/hostname.iwn0

(or , if you want to configure some interface options, too).

 Oh, and about the sys/net/if_slvar.h and sys/net/ppdefs.h: we were
 lucky enough that duplicated definition didn't bite us yet, but
 now it is.

 Don't worry about that, if_slvar.h is going to disappear soon ;)

Cool. :)

 I'm posting this right before going to country for the weekend.
 So, unfortunately, I'll be able to answer any questions in the Monday.

 Your diff below is really big and will scare a lot of people.  I don't
 think we can discuss it without having a clear picture of how to auto-
 configure wireless network.  But I'd recommend you to make sure it
 respects style(9) and you could even split it into various parts.

I'll try to compile some sort of presentation tomorrow, explaining all
the stuff I'm working on.

Thank you for overview!

--
  WBR,
  Vadim Zhukov

Re: 802.11 autoassoc

[Vadim Zhukov]

2014-09-30 14:27 GMT+04:00 Stefan Sperling s...@openbsd.org:
 On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote:
 Hey Vadim, I'm happy to see you've put some efforts into improving
 how wireless networks are configured on OpenBSD.  I have some questions
 below.

 On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
 
  This is a proof-of-concept patch that implements network profiles
  in kernel, using IEEE 802.11 network name and/or BSSID.

 Why did you choose to put this in the kernel, did you encounter any
 technical problem, or was it easier/better that way?

 Note also that there is an existing 'autoassoc' behaviour.
 The net80211 stack will try to automatically associate with
 an open wireless network as soon as the interface is brought up.
 I think it would make sense to try to keep this behaviour for
 encrypted networks for which the key has been pre-loaded into
 kernel memory somehow. The primary focus of the kernel should be
 on trying to get link on an interface, like it does with open wifi.

Yes, I've seen that behaviour. And it actually bothers me - what if I
get associated with untrusted network, and my already opened
Ajax-enabled browser will start to transfer data via it without
notification?.. This can be avoided by forcing some unlikely nwid in
hostname.if, but this is not secure by default. Or maybe I search
for security in the wrong place, dunno...

 Below is a diff I once wrote which caches network keys in the kernel.
 It's not perfect either because it still requires users to enter the
 nwid they want to associate with if a network is encrypted. In other words,
 it doesn't require users to enter a wep/wpa key more than once while the
 system is accumulating uptime. But there is no automatic association
 with an encrypted network found during a scan, and no integration with
 userland via routing sockets (an idea which I like a lot because it
 opens up the possibility for desktop integration and other nice things).

I'll look at it in the evening, thanks!

 Index: ieee80211_crypto.c
 ===
 RCS file: /cvs/src/sys/net80211/ieee80211_crypto.c,v
 retrieving revision 1.60
 diff -u -p -r1.60 ieee80211_crypto.c
 --- ieee80211_crypto.c  11 Jan 2011 15:42:05 -  1.60
 +++ ieee80211_crypto.c  21 Aug 2013 14:17:25 -
 @@ -65,6 +65,7 @@ ieee80211_crypto_attach(struct ifnet *if
 struct ieee80211com *ic = (void *)ifp;

 TAILQ_INIT(ic-ic_pmksa);
 +   TAILQ_INIT(ic-ic_pws);
 if (ic-ic_caps  IEEE80211_C_RSN) {
 ic-ic_rsnprotos = IEEE80211_PROTO_WPA | IEEE80211_PROTO_RSN;
 ic-ic_rsnakms = IEEE80211_AKM_PSK;
 @@ -91,6 +92,8 @@ ieee80211_crypto_detach(struct ifnet *if
 free(pmk, M_DEVBUF);
 }

 +   ieee80211_passwd_remove_all(ic);
 +
 /* clear all group keys from memory */
 for (i = 0; i  IEEE80211_GROUP_NKID; i++) {
 struct ieee80211_key *k = ic-ic_nw_keys[i];
 @@ -648,4 +651,159 @@ ieee80211_pmksa_find(struct ieee80211com
 break;
 }
 return pmk;
 +}
 +
 +#define IEEE80211_PW_CACHE_SIZE 16
 +
 +#define IEEE80211_PW_DEBUG
 +
 +/*
 + * Cache a WPA PSK for the current desired ESSID.
 + * If PSK is NULL, clear the cached PSK.
 + */
 +struct ieee80211_passwd *
 +ieee80211_passwd_psk(struct ieee80211com *ic, u_int8_t *psk)
 +{
 +   struct ieee80211_passwd *pw;
 +#ifdef IEEE80211_PW_DEBUG
 +   char essid[IEEE80211_NWID_LEN + 1];
 +#endif
 +
 +   if (ic-ic_npws = IEEE80211_PW_CACHE_SIZE) {
 +   /* TODO expire least recently used entry instead of return */
 +   return NULL;
 +   }
 +
 +   if (ic-ic_des_esslen == 0)
 +   return NULL;
 +
 +#ifdef IEEE80211_PW_DEBUG
 +   memcpy(essid, pw-pw_nwid, IEEE80211_NWID_LEN);
 +   essid[IEEE80211_NWID_LEN] = '\0';
 +#endif
 +
 +   pw = ieee80211_passwd_find(ic);
 +   if (pw == NULL) {
 +   if (psk == NULL)
 +   return NULL;
 +#ifdef IEEE80211_PW_DEBUG
 +   printf(%s: new wpa psk for %s\n, __func__, essid);
 +#endif
 +   pw = malloc(sizeof(*pw), M_DEVBUF, M_ZERO|M_NOWAIT);
 +   if (pw == NULL)
 +   return NULL;
 +   memcpy(pw-pw_nwid, ic-ic_des_essid, IEEE80211_NWID_LEN);
 +   TAILQ_INSERT_TAIL(ic-ic_pws, pw, pw_next);
 +   ic-ic_npws++;
 +   }
 +#ifdef IEEE80211_PW_DEBUG
 +   else
 +   printf(%s: changing wpa psk for %s\n, __func__, essid);
 +#endif
 +
 +   if (psk) {
 +   memcpy(pw-pw_psk, psk, IEEE80211_PMK_LEN);
 +   pw-pw_flags |= IEEE80211_PASSWD_HAVE_PSK;
 +   } else if (pw-pw_flags  IEEE80211_PASSWD_HAVE_PSK) {
 +   explicit_bzero(pw-pw_psk, IEEE80211_PMK_LEN);
 +   pw-pw_flags = ~IEEE80211_PASSWD_HAVE_PSK;
 +   }
 +
 +   return pw;
 +}
 +
 +/*
 + * Cache WEP 

Re: 802.11 autoassoc

[Stefan Sperling]

On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote:
 Yes, I've seen that behaviour. And it actually bothers me - what if I
 get associated with untrusted network, and my already opened
 Ajax-enabled browser will start to transfer data via it without
 notification?.. This can be avoided by forcing some unlikely nwid in
 hostname.if, but this is not secure by default. Or maybe I search
 for security in the wrong place, dunno...

Why do you even already have an interface that is up when
entering an untrusted environment?

How can you be sure that you're connecting to the right AP even
at home? The AP is usually not authenticated. I could come to your
house with a strong antenna AP and grab associations from anything
that attempts to use open wifi, no matter what nwid/bssid the devices
would want to use. If I managed to figure out your WPA key you'd have
to set up WPA enterprise and authenticate the AP to prevent a snooping
attack, or just forget about wifi offering any form of snooping protection
and use some kind of VPN (just like you would on the internet).

I don't use netstart on laptops. I leave all interfaces down at
startup (empty hostname.if files) and always re-configure them
manually as needed. I make sure laptops always use a VPN (unless
I'm at home, so if someone figures out my nwkey and comes to my
place I'm owned). I don't care if the wifi is open or encrypted,
it just provides an uplink I can run VPN on top of. 
My setup currently runs wifi interfaces and OpenVPN in rdomain 1.
Anything else is in rdomain 0 so there is no chance some random
appliation will leak traffic to the wifi link.

Still, I would welcome a more convenient solution than this.
I'm just not sure we've found it yet.

Can autonetd make use of IPsec and/or SSH-based VPNs (or even
OpenVPN if these other options can't manage to tunnel out)?
If it makes that easy to use, then we don't have to worry too
much about which wifi link is used as long as we can reach the
VPN server via that link.

Re: 802.11 autoassoc

[sven falempin]

On Tue, Sep 30, 2014 at 7:16 AM, Stefan Sperling s...@openbsd.org wrote:
 On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote:
 Yes, I've seen that behaviour. And it actually bothers me - what if I
 get associated with untrusted network, and my already opened
 Ajax-enabled browser will start to transfer data via it without
 notification?.. This can be avoided by forcing some unlikely nwid in
 hostname.if, but this is not secure by default. Or maybe I search
 for security in the wrong place, dunno...

 Why do you even already have an interface that is up when
 entering an untrusted environment?

 How can you be sure that you're connecting to the right AP even
 at home? The AP is usually not authenticated. I could come to your
 house with a strong antenna AP and grab associations from anything
 that attempts to use open wifi, no matter what nwid/bssid the devices
 would want to use. If I managed to figure out your WPA key you'd have
 to set up WPA enterprise and authenticate the AP to prevent a snooping
 attack, or just forget about wifi offering any form of snooping protection
 and use some kind of VPN (just like you would on the internet).

 I don't use netstart on laptops. I leave all interfaces down at
 startup (empty hostname.if files) and always re-configure them
 manually as needed. I make sure laptops always use a VPN (unless
 I'm at home, so if someone figures out my nwkey and comes to my
 place I'm owned). I don't care if the wifi is open or encrypted,
 it just provides an uplink I can run VPN on top of.
 My setup currently runs wifi interfaces and OpenVPN in rdomain 1.
 Anything else is in rdomain 0 so there is no chance some random
 appliation will leak traffic to the wifi link.

 Still, I would welcome a more convenient solution than this.
 I'm just not sure we've found it yet.

 Can autonetd make use of IPsec and/or SSH-based VPNs (or even
 OpenVPN if these other options can't manage to tunnel out)?
 If it makes that easy to use, then we don't have to worry too
 much about which wifi link is used as long as we can reach the
 VPN server via that link.


 If openBSD auto connect to open wireless spot I will have to patch the kernel
to use it.
Auto connection to hotspot, especially the 'open' one is the worse thing ever.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: 802.11 autoassoc

[Peter Hessler]

On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote:
:2014-09-30 14:27 GMT+04:00 Stefan Sperling s...@openbsd.org:
: On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote:
: Hey Vadim, I'm happy to see you've put some efforts into improving
: how wireless networks are configured on OpenBSD.  I have some questions
: below.
:
: On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
: 
:  This is a proof-of-concept patch that implements network profiles
:  in kernel, using IEEE 802.11 network name and/or BSSID.
:
: Why did you choose to put this in the kernel, did you encounter any
: technical problem, or was it easier/better that way?
:
: Note also that there is an existing 'autoassoc' behaviour.
: The net80211 stack will try to automatically associate with
: an open wireless network as soon as the interface is brought up.
: I think it would make sense to try to keep this behaviour for
: encrypted networks for which the key has been pre-loaded into
: kernel memory somehow. The primary focus of the kernel should be
: on trying to get link on an interface, like it does with open wifi.
:
:Yes, I've seen that behaviour. And it actually bothers me - what if I
:get associated with untrusted network, and my already opened
:Ajax-enabled browser will start to transfer data via it without
:notification?.. This can be avoided by forcing some unlikely nwid in
:hostname.if, but this is not secure by default. Or maybe I search
:for security in the wrong place, dunno...
:

If we have any network configuration, then we SHOULD NOT connect to any
random wifi point.  If there is no (or minimal) configs, then I am not
too bothered by connecting randomly.

However, I would cheer a change to not auto-connect to the first open
wifi point.

FWIW, OSX allows for a list of wifi points to connect to, and does not
automagically connect to any open access point.

-- 
Wasting time is an important part of living.

Re: 802.11 autoassoc

[sven falempin]

On Tue, Sep 30, 2014 at 8:04 AM, Peter Hessler phess...@theapt.org wrote:
 On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote:
 :2014-09-30 14:27 GMT+04:00 Stefan Sperling s...@openbsd.org:
 : On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote:
 : Hey Vadim, I'm happy to see you've put some efforts into improving
 : how wireless networks are configured on OpenBSD.  I have some questions
 : below.
 :
 : On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
 : 
 :  This is a proof-of-concept patch that implements network profiles
 :  in kernel, using IEEE 802.11 network name and/or BSSID.
 :
 : Why did you choose to put this in the kernel, did you encounter any
 : technical problem, or was it easier/better that way?
 :
 : Note also that there is an existing 'autoassoc' behaviour.
 : The net80211 stack will try to automatically associate with
 : an open wireless network as soon as the interface is brought up.
 : I think it would make sense to try to keep this behaviour for
 : encrypted networks for which the key has been pre-loaded into
 : kernel memory somehow. The primary focus of the kernel should be
 : on trying to get link on an interface, like it does with open wifi.
 :
 :Yes, I've seen that behaviour. And it actually bothers me - what if I
 :get associated with untrusted network, and my already opened
 :Ajax-enabled browser will start to transfer data via it without
 :notification?.. This can be avoided by forcing some unlikely nwid in
 :hostname.if, but this is not secure by default. Or maybe I search
 :for security in the wrong place, dunno...
 :

 If we have any network configuration, then we SHOULD NOT connect to any
 random wifi point.  If there is no (or minimal) configs, then I am not
 too bothered by connecting randomly.

 However, I would cheer a change to not auto-connect to the first open
 wifi point.

 FWIW, OSX allows for a list of wifi points to connect to, and does not
 automagically connect to any open access point.


the apple connect to whatever it can, just like the droid and this is annoying .

(like if a signal drop you may end up trying to connect to a printer -_-)

 --
 Wasting time is an important part of living.




-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: 802.11 autoassoc

[Peter Hessler]

On 2014 Sep 30 (Tue) at 08:10:40 -0400 (-0400), sven falempin wrote:
:On Tue, Sep 30, 2014 at 8:04 AM, Peter Hessler phess...@theapt.org wrote:
: On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote:
: :2014-09-30 14:27 GMT+04:00 Stefan Sperling s...@openbsd.org:
: : On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote:
: : Hey Vadim, I'm happy to see you've put some efforts into improving
: : how wireless networks are configured on OpenBSD.  I have some questions
: : below.
: :
: : On 26/09/14(Fri) 21:38, Vadim Zhukov wrote:
: : 
: :  This is a proof-of-concept patch that implements network profiles
: :  in kernel, using IEEE 802.11 network name and/or BSSID.
: :
: : Why did you choose to put this in the kernel, did you encounter any
: : technical problem, or was it easier/better that way?
: :
: : Note also that there is an existing 'autoassoc' behaviour.
: : The net80211 stack will try to automatically associate with
: : an open wireless network as soon as the interface is brought up.
: : I think it would make sense to try to keep this behaviour for
: : encrypted networks for which the key has been pre-loaded into
: : kernel memory somehow. The primary focus of the kernel should be
: : on trying to get link on an interface, like it does with open wifi.
: :
: :Yes, I've seen that behaviour. And it actually bothers me - what if I
: :get associated with untrusted network, and my already opened
: :Ajax-enabled browser will start to transfer data via it without
: :notification?.. This can be avoided by forcing some unlikely nwid in
: :hostname.if, but this is not secure by default. Or maybe I search
: :for security in the wrong place, dunno...
: :
:
: If we have any network configuration, then we SHOULD NOT connect to any
: random wifi point.  If there is no (or minimal) configs, then I am not
: too bothered by connecting randomly.
:
: However, I would cheer a change to not auto-connect to the first open
: wifi point.
:
: FWIW, OSX allows for a list of wifi points to connect to, and does not
: automagically connect to any open access point.
:
:
:the apple connect to whatever it can, just like the droid and this is annoying 
.
:
:(like if a signal drop you may end up trying to connect to a printer -_-)

You are talking about an (optional) feature of the iphone.  My iphone
and android devices do not behave that way.

I was talking about OSX on the laptop.



-- 
Can you hammer a 6-inch spike into a wooden plank with your penis?

Uh, not right now.

Tsk.  A girl has to have some standards.
-- Real Genius

Re: 802.11 autoassoc

[Stefan Sperling]

On Tue, Sep 30, 2014 at 07:59:04AM -0400, sven falempin wrote:
  If openBSD auto connect to open wireless spot I will have to patch the 
 kernel
 to use it.
 Auto connection to hotspot, especially the 'open' one is the worse thing ever.

You need to bring the wifi interface up first, manually or via
/etc/hostname.if. By default the interface is down.

If you are bringing an interface up, you're telling the kernel
that you want link on it. Of course, we could stop connecting
to the strongest open network and always require users to type
an nwid before they get link. But that can be annoying in cases
where you don't know which network has the best signal.
But the kernel can tell. I used this feature just last weekend at
eurobsdcon which had 2 wifi networks, where one or the other was
better depending on where I was sitting.

So instead of patching the kernel, I'd suggest you run:

ifconfig iwn0 down # default state after boot
ifconfig iwn0 scan
ifconfig iwn0 nwid foo
ifconfig iwn0 up   # or: dhclient iwn0

This gives you the behaviour you want.
As long as you don't run ifconfig iwn0 -nwid you'll never connect
to a network of a different name.

However, whether the AP you're naming is actually the one you're
connecting to is a different question and that problem can't be
solved with a kernel patch ;-) Unless perhaps if you changed the
laws of physics, or made WPA enterprise mandatory everywhere, both
of which seem somewhat unlikely options.

Re: 802.11 autoassoc

[Ted Unangst]

On Tue, Sep 30, 2014 at 14:18, Stefan Sperling wrote:

 If you are bringing an interface up, you're telling the kernel
 that you want link on it. Of course, we could stop connecting
 to the strongest open network and always require users to type
 an nwid before they get link. But that can be annoying in cases
 where you don't know which network has the best signal.
 But the kernel can tell. I used this feature just last weekend at
 eurobsdcon which had 2 wifi networks, where one or the other was
 better depending on where I was sitting.

The problem is that a wifi interface can have many links. This would
be like running ifconfig em0 up, and it also bringing up em1, em2,
etc...

 
 So instead of patching the kernel, I'd suggest you run:
 
 ifconfig iwn0 down # default state after boot
 ifconfig iwn0 scan
 ifconfig iwn0 nwid foo
 ifconfig iwn0 up   # or: dhclient iwn0

That looks like a lot of work. Revamping autoassoc to include WPA
networks seems like a good opportunity to remove the any and all
open networks feature.

Re: 802.11 autoassoc

[Vadim Zhukov]

2014-09-30 15:16 GMT+04:00 Stefan Sperling s...@openbsd.org:
 On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote:
 Yes, I've seen that behaviour. And it actually bothers me - what if I
 get associated with untrusted network, and my already opened
 Ajax-enabled browser will start to transfer data via it without
 notification?.. This can be avoided by forcing some unlikely nwid in
 hostname.if, but this is not secure by default. Or maybe I search
 for security in the wrong place, dunno...

 Why do you even already have an interface that is up when
 entering an untrusted environment?

 How can you be sure that you're connecting to the right AP even
 at home? The AP is usually not authenticated. I could come to your
 house with a strong antenna AP and grab associations from anything
 that attempts to use open wifi, no matter what nwid/bssid the devices
 would want to use. If I managed to figure out your WPA key you'd have
 to set up WPA enterprise and authenticate the AP to prevent a snooping
 attack, or just forget about wifi offering any form of snooping protection
 and use some kind of VPN (just like you would on the internet).

 I don't use netstart on laptops. I leave all interfaces down at
 startup (empty hostname.if files) and always re-configure them
 manually as needed. I make sure laptops always use a VPN (unless
 I'm at home, so if someone figures out my nwkey and comes to my
 place I'm owned). I don't care if the wifi is open or encrypted,
 it just provides an uplink I can run VPN on top of.
 My setup currently runs wifi interfaces and OpenVPN in rdomain 1.
 Anything else is in rdomain 0 so there is no chance some random
 appliation will leak traffic to the wifi link.

 Still, I would welcome a more convenient solution than this.
 I'm just not sure we've found it yet.

This is a very good point, indeed: if someone wants to be safe, he
should start caring from the beginning. So we have the following use
cases then:

1) Trusted networking, as in 802.1x auth (hello, wpa_supplicant). We
search for trusted network and use it if possible. This will be
possible if we'll move in the way I propose.

2) Secure tunneling: nothing gets out from interface except what
needed for IPSec/OpenVPN/etc. tunnel.
There is one corner case: web auth networks; I have some ideas there
but lets postpone this case until some code arrive. With automatic
interface addresses removal on de-association (I think this should be
done always?), this case will be easy to have, too.

3) Everything else: false sense of security. Well, WPA2 will save you
from kiddie attacks, and if it's all you really care of, then - fine,
why not? You'd always compare price of attack and price of result. If
attack price is enough high (ready-to-use fake BSSs aren't sold on
every street, and compiling own one require valuable knowledge) and
your data (photos of your new kitty) is not, you can sleep well. At
least, today. And this already works here on my laptop.

In conclusion: I see what could be improved now, excluding the patch
from thread starting mail. I'll try to prepare new patches as soon as
possible.

 Can autonetd make use of IPsec and/or SSH-based VPNs (or even
 OpenVPN if these other options can't manage to tunnel out)?
 If it makes that easy to use, then we don't have to worry too
 much about which wifi link is used as long as we can reach the
 VPN server via that link.

Yes, it could. You just tell it run those commands on
(de-)association, dude - it could be ipsecctl, wpa_cli and so on. The
idea is that we already have tools - we just need to make them play
together without requiring extra attention from human.

--
  WBR,
  Vadim Zhukov