Re: splnet() and SIOCSIFADDR

2014-09-30 Thread Martin Pieuchot
On 11/09/14(Thu) 10:49, Martin Pieuchot wrote:
 On 03/09/14(Wed) 20:59, Alexander Bluhm wrote:
  On Wed, Sep 03, 2014 at 03:53:34PM +0200, Martin Pieuchot wrote:
   @@ -1078,7 +1079,7 @@ in6_purgeaddr(struct ifaddr *ifa)
void
in6_unlink_ifa(struct in6_ifaddr *ia6, struct ifnet *ifp)
{
   - int s = splnet();
   + splsoftassert(IPL_SOFTNET);

 ifa_del(ifp, ia6-ia_ifa);

  
  I think there are code paths that can trigger this assertion
  
  netinet6/in6.c: in6_unlink_ifa()
  netinet6/in6.c: in6_purgeaddr()
  netinet6/nd6_rtr.c: purge_detached()
  netinet6/nd6_rtr.c: nd6_prelist_add()
  netinet6/in6.c: in6_control()
  netinet/tcp_usrreq.c:   tcp_usrreq()
  kern/sys_socket.c:  soo_ioctl()
  
  netinet6/in6.c: in6_unlink_ifa()
  netinet6/in6.c: in6_purgeaddr()
  netinet6/nd6_rtr.c: purge_detached()
  netinet6/nd6_rtr.c: nd6_prelist_add()
  netinet6/in6_ifattach.c:in6_ifattach_linklocal()
  netinet/ip_carp.c   carp_set_enaddr()
  netinet/ip_carp.c   carp_ioctl()
  ...
  
  nd6_prelist_add() does some splsoftnet() already.  I think you
  should put one around purge_detached() there.
 
 Nice catch, updated diff below.

Any comment or ok?

 Index: net/if_loop.c
 ===
 RCS file: /home/ncvs/src/sys/net/if_loop.c,v
 retrieving revision 1.57
 diff -u -p -r1.57 if_loop.c
 --- net/if_loop.c 22 Jul 2014 11:06:09 -  1.57
 +++ net/if_loop.c 11 Sep 2014 08:45:29 -
 @@ -288,15 +288,13 @@ loioctl(struct ifnet *ifp, u_long cmd, c
  {
   struct ifaddr *ifa;
   struct ifreq *ifr;
 - int s, error = 0;
 + int error = 0;
  
   switch (cmd) {
  
   case SIOCSIFADDR:
 - s = splnet();
   ifp-if_flags |= IFF_RUNNING;
   if_up(ifp); /* send up RTM_IFINFO */
 - splx(s);
  
   ifa = (struct ifaddr *)data;
   if (ifa != 0)
 Index: netinet/in.c
 ===
 RCS file: /home/ncvs/src/sys/netinet/in.c,v
 retrieving revision 1.103
 diff -u -p -r1.103 in.c
 --- netinet/in.c  3 Sep 2014 08:59:06 -   1.103
 +++ netinet/in.c  11 Sep 2014 08:45:29 -
 @@ -612,7 +612,7 @@ in_ifinit(struct ifnet *ifp, struct in_i
  {
   u_int32_t i = sin-sin_addr.s_addr;
   struct sockaddr_in oldaddr;
 - int s, error = 0;
 + int error = 0;
  
   splsoftassert(IPL_SOFTNET);
  
 @@ -627,7 +627,6 @@ in_ifinit(struct ifnet *ifp, struct in_i
   rt_ifa_delloop(ia-ia_ifa);
   ifa_del(ifp, ia-ia_ifa);
   }
 - s = splnet();
   oldaddr = ia-ia_addr;
   ia-ia_addr = *sin;
  
 @@ -639,10 +638,8 @@ in_ifinit(struct ifnet *ifp, struct in_i
   if (ifp-if_ioctl 
   (error = (*ifp-if_ioctl)(ifp, SIOCSIFADDR, (caddr_t)ia))) {
   ia-ia_addr = oldaddr;
 - splx(s);
   goto out;
   }
 - splx(s);
  
   if (ia-ia_netmask == 0) {
   if (IN_CLASSA(i))
 Index: netinet/ip_carp.c
 ===
 RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v
 retrieving revision 1.234
 diff -u -p -r1.234 ip_carp.c
 --- netinet/ip_carp.c 8 Sep 2014 06:24:13 -   1.234
 +++ netinet/ip_carp.c 11 Sep 2014 08:45:29 -
 @@ -2059,10 +2059,11 @@ carp_ioctl(struct ifnet *ifp, u_long cmd
   struct ifaddr *ifa = (struct ifaddr *)addr;
   struct ifreq *ifr = (struct ifreq *)addr;
   struct ifnet *cdev = NULL;
 - int i, error = 0;
 + int s, i, error = 0;
  
   switch (cmd) {
   case SIOCSIFADDR:
 + s = splnet();
   switch (ifa-ifa_addr-sa_family) {
  #ifdef INET
   case AF_INET:
 @@ -2087,6 +2088,7 @@ carp_ioctl(struct ifnet *ifp, u_long cmd
   break;
   }
   break;
 + splx(s);
  
   case SIOCSIFFLAGS:
   vhe = LIST_FIRST(sc-carp_vhosts);
 Index: netinet6/in6.c
 ===
 RCS file: /home/ncvs/src/sys/netinet6/in6.c,v
 retrieving revision 1.140
 diff -u -p -r1.140 in6.c
 --- netinet6/in6.c26 Aug 2014 21:44:29 -  1.140
 +++ netinet6/in6.c11 Sep 2014 08:45:29 -
 @@ -172,7 +172,7 @@ in6_control(struct socket *so, u_long cm
   struct  in6_ifaddr *ia6 = NULL;
   struct  in6_aliasreq *ifra = (struct in6_aliasreq *)data;
   struct sockaddr_in6 *sa6;
 - int privileged;
 + int s, privileged;
  
   privileged = 0;
   if ((so-so_state  SS_PRIV) != 0)
 @@ -463,7 +463,6 @@ in6_control(struct socket *so, u_long cm
   {
   int i, error = 0;
   struct nd_prefix pr0, *pr;
 - int s;
  
   /* reject 

Re: [Patch]openrcs: atoi to strtonum

2014-09-30 Thread Nicholas Marriott
ok nicm



On Sat, Sep 27, 2014 at 05:07:58PM +0200, Otto Moerbeek wrote:
 On Fri, Sep 26, 2014 at 09:23:08PM +0200, Fritjof Bornebusch wrote:
 
  On Wed, Sep 24, 2014 at 10:31:17PM +0200, Otto Moerbeek wrote:
  Hi,
  
   On Wed, Sep 24, 2014 at 05:13:47PM +0200, Fritjof Bornebusch wrote:
   
Hi,

I changed atoi to strtonum in order to avoid overflows.
   
   One concern: atoi() does not mind trailing stuff, while strtonum()
   does. Did you verify that the strings are just numbers in all cases?
   
  
  according to the code and the manpages there are two different methods
  available to specify the timezone.
  
  - LT
  - +-hh:mm
  
  LT is handled seperatly and the code below - atoi(3) - only converts the 
  hour and 
  minute string values after seperation into int, e.g. +09:88 - h = 09; m 
  = 88.
  The + or - sign will be handled in a different part of the code.
  
  I think this diff won't change functionality.
 
 OK, that looks good. Anybody else wnat to ok this so I can commit?
 
  
  
 -Otto
   
  
  fritjof
  

fritjof



Index: rcstime.c
===
RCS file: /cvs/src/usr.bin/rcs/rcstime.c,v
retrieving revision 1.4
diff -u -p -r1.4 rcstime.c
--- rcstime.c   29 Apr 2014 07:44:19 -  1.4
+++ rcstime.c   24 Sep 2014 15:06:42 -
@@ -36,6 +36,7 @@ rcs_set_tz(char *tz, struct rcs_delta *r
int tzone;
int pos;
char *h, *m;
+   const char *errstr;
struct tm *ltb;
time_t now;
 
@@ -62,8 +63,8 @@ rcs_set_tz(char *tz, struct rcs_delta *r
 
memcpy(tb, rdp-rd_date, sizeof(*tb));
 
-   tzone = atoi(h);
-   if ((tzone = 24) || (tzone = -24))
+   tzone = strtonum(h, -23, 23, errstr);
+   if (errstr)
errx(1, %s: not a known time zone, tz);
 
if (pos) {
@@ -78,9 +79,9 @@ rcs_set_tz(char *tz, struct rcs_delta *r
tb-tm_hour = 0;
 
if (m != NULL) {
-   tzone = atoi(m);
-   if (tzone = 60)
-   errx(1, %s: not a known time zone, 
tz);
+   tzone = strtonum(m, 0, 59, errstr);
+   if (errstr)
+   errx(1, %s: not a known minute, m);
 
if ((tb-tm_min + tzone) = 60) {
tb-tm_hour++;
 



Re: VPLS patch [1/3]: prepare sys/ to receive pseudowire implementation

2014-09-30 Thread Martin Pieuchot
Hello Rafael,

On 14/09/14(Sun) 23:49, Rafael Zalamena wrote:
 The following patch is just a preparation for the code that is coming to
 implement the wire network interface (the VPLS datapath) to work on OpenBSD.
 
 This code turns the mpe code that handles route and labels into some general
 use functions that will be called by mpe and wire.

Would it be possible to use  the new rt_ifa_add() and rt_ifa_del() instead of
keeping what is basically a copy of the old rtinit()?

In your case you want to use the lladdr's ifa and you can check for
RTF_MPLS in the flags to add the corresponding MPLS_OP_POP value.


 diff --git sys/net/if_mpe.c sys/net/if_mpe.c
 index 74039dc..98d69f4 100644
 --- sys/net/if_mpe.c
 +++ sys/net/if_mpe.c
 @@ -61,7 +61,6 @@ int mpeioctl(struct ifnet *, u_long, caddr_t);
  void mpestart(struct ifnet *);
  int  mpe_clone_create(struct if_clone *, int);
  int  mpe_clone_destroy(struct ifnet *);
 -int  mpe_newlabel(struct ifnet *, int, struct shim_hdr *);
  
  LIST_HEAD(, mpe_softc)   mpeif_list;
  struct if_clone  mpe_cloner =
 @@ -319,36 +318,17 @@ mpeioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
   break;
   }
   shim.shim_label = htonl(shim.shim_label  MPLS_LABEL_OFFSET);
 - if (ifm-sc_shim.shim_label == shim.shim_label)
 - break;
 - LIST_FOREACH(ifm, mpeif_list, sc_list) {
 - if (ifm != ifp-if_softc 
 - ifm-sc_shim.shim_label == shim.shim_label) {
 - error = EEXIST;
 - break;
 - }
 - }
 - if (error)
 - break;
 - ifm = ifp-if_softc;
 - if (ifm-sc_shim.shim_label) {
 - /* remove old MPLS route */
 - mpe_newlabel(ifp, RTM_DELETE, ifm-sc_shim);
 - }
 - /* add new MPLS route */
 - error = mpe_newlabel(ifp, RTM_ADD, shim);
 - if (error)
 - break;
 - ifm-sc_shim.shim_label = shim.shim_label;
 + error = mpls_shim_set(ifp, shim, ifm-sc_shim);
   break;
   case SIOCSIFRDOMAIN:
   /* must readd the MPLS route for our label */
   ifm = ifp-if_softc;
   if (ifr-ifr_rdomainid != ifp-if_rdomain) {
 - if (ifm-sc_shim.shim_label) {
 - shim.shim_label = ifm-sc_shim.shim_label;
 - error = mpe_newlabel(ifp, RTM_ADD, shim);
 - }
 + shim.shim_label = ifm-sc_shim.shim_label;
 +
 + /* XXX trick mpls_shim_set() to reinstall the route */
 + bzero(ifm-sc_shim, sizeof(ifm-sc_shim));
 + error = mpls_shim_set(ifp, shim, ifm-sc_shim);
   }
   /* return with ENOTTY so that the parent handler finishes */
   return (ENOTTY);
 @@ -444,36 +424,13 @@ mpe_input6(struct mbuf *m, struct ifnet *ifp, struct 
 sockaddr_mpls *smpls,
  #endif   /* INET6 */
  
  int
 -mpe_newlabel(struct ifnet *ifp, int cmd, struct shim_hdr *shim)
 +mpe_label_exists(const struct shim_hdr *shim)
  {
 - struct rtentry *nrt;
 - struct sockaddr_mpls dst;
 - struct rt_addrinfo info;
 - int error;
 -
 - bzero(dst, sizeof(dst));
 - dst.smpls_len = sizeof(dst);
 - dst.smpls_family = AF_MPLS;
 - dst.smpls_label = shim-shim_label;
 -
 - bzero(info, sizeof(info));
 - info.rti_flags = RTF_UP | RTF_MPLS;
 - info.rti_mpls = MPLS_OP_POP;
 - info.rti_info[RTAX_DST] = smplstosa(dst);
 - info.rti_info[RTAX_GATEWAY] = (struct sockaddr *)ifp-if_sadl;
 -
 - error = rtrequest1(cmd, info, RTP_CONNECTED, nrt, 0);
 - rt_missmsg(cmd, info, error ? 0 : nrt-rt_flags, ifp, error, 0);
 - if (cmd == RTM_DELETE) {
 - if (error == 0  nrt != NULL) {
 - if (nrt-rt_refcnt = 0) {
 - nrt-rt_refcnt++;
 - rtfree(nrt);
 - }
 - }
 - }
 - if (cmd == RTM_ADD  error == 0  nrt != NULL) {
 - nrt-rt_refcnt--;
 - }
 - return (error);
 + struct  mpe_softc *mpe_sc;
 +
 + LIST_FOREACH(mpe_sc, mpeif_list, sc_list)
 + if (shim-shim_label == mpe_sc-sc_shim.shim_label)
 + return (1);
 +
 + return (0);
  }
 diff --git sys/netmpls/mpls.h sys/netmpls/mpls.h
 index 2903aa4..0363d86 100644
 --- sys/netmpls/mpls.h
 +++ sys/netmpls/mpls.h
 @@ -176,9 +176,13 @@ extern int   mpls_inkloop;
  void mpls_init(void);
  void mplsintr(void);
  
 +int   mpe_label_exists(const struct shim_hdr *);
 +
  struct mbuf  *mpls_shim_pop(struct mbuf *);
  struct mbuf  *mpls_shim_swap(struct mbuf *, struct rt_mpls *);
  struct mbuf  *mpls_shim_push(struct mbuf *, struct rt_mpls 

Re: [Patch] use exit() directly in usage()

2014-09-30 Thread Nicholas Marriott
If we do this then these usage functions also need to be marked __dead.



On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote:
 Hi,
 
 after usage() was called, there is no where you can go.
 
 fritjof
 
 
 Index: ci.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/ci.c,v
 retrieving revision 1.217
 diff -u -p -r1.217 ci.c
 --- ci.c  19 May 2014 19:42:24 -  1.217
 +++ ci.c  2 Jun 2014 22:18:25 -
 @@ -97,6 +97,8 @@ checkin_usage(void)
 [-j[rev]] [-k[rev]] [-l[rev]] [-M[rev]] [-mmsg]\n
 [-Nsymbol] [-nsymbol] [-r[rev]] [-sstate] [-t[str]]\n
 [-u[rev]] [-wusername] [-xsuffixes] [-ztz] file ...\n);
 +
 + exit(1);
  }
  
  /*
 @@ -221,7 +223,6 @@ checkin_main(int argc, char **argv)
   break;
   default:
   (usage)();
 - exit(1);
   }
   }
  
 @@ -231,7 +232,6 @@ checkin_main(int argc, char **argv)
   if (argc == 0) {
   warnx(no input file);
   (usage)();
 - exit(1);
   }
  
   if ((pb.username = getlogin()) == NULL)
 Index: co.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/co.c,v
 retrieving revision 1.117
 diff -u -p -r1.117 co.c
 --- co.c  16 Apr 2013 20:24:45 -  1.117
 +++ co.c  2 Jun 2014 22:19:38 -
 @@ -79,7 +79,6 @@ checkout_main(int argc, char **argv)
   if (RCS_KWEXP_INVAL(kflag)) {
   warnx(invalid RCS keyword substitution mode);
   (usage)();
 - exit(1);
   }
   break;
   case 'l':
 @@ -141,7 +140,6 @@ checkout_main(int argc, char **argv)
   break;
   default:
   (usage)();
 - exit(1);
   }
   }
  
 @@ -151,7 +149,6 @@ checkout_main(int argc, char **argv)
   if (argc == 0) {
   warnx(no input file);
   (usage)();
 - exit (1);
   }
  
   if ((username = getlogin()) == NULL)
 @@ -229,6 +226,8 @@ checkout_usage(void)
   usage: co [-TV] [-ddate] [-f[rev]] [-I[rev]] [-kmode] [-l[rev]]\n
 [-M[rev]] [-p[rev]] [-q[rev]] [-r[rev]] [-sstate]\n
 [-u[rev]] [-w[user]] [-xsuffixes] [-ztz] file ...\n);
 +
 + exit(1);
  }
  
  /*
 Index: merge.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/merge.c,v
 retrieving revision 1.7
 diff -u -p -r1.7 merge.c
 --- merge.c   23 Jul 2010 21:46:05 -  1.7
 +++ merge.c   2 Jun 2014 22:20:55 -
 @@ -77,7 +77,6 @@ merge_main(int argc, char **argv)
   exit(0);
   default:
   (usage)();
 - exit(D_ERROR);
   }
   }
   argc -= optind;
 @@ -86,7 +85,6 @@ merge_main(int argc, char **argv)
   if (argc != 3) {
   warnx(%s arguments, (argc  3) ? not enough : too many);
   (usage)();
 - exit(D_ERROR);
   }
  
   for (; labels  3; labels++)
 @@ -118,4 +116,6 @@ merge_usage(void)
  {
   (void)fprintf(stderr,
   usage: merge [-EepqV] [-L label] file1 file2 file3\n);
 +
 + exit(D_ERROR);
  }
 Index: rcsclean.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/rcsclean.c,v
 retrieving revision 1.52
 diff -u -p -r1.52 rcsclean.c
 --- rcsclean.c28 Jul 2010 09:07:11 -  1.52
 +++ rcsclean.c2 Jun 2014 22:22:05 -
 @@ -60,7 +60,6 @@ rcsclean_main(int argc, char **argv)
   if (RCS_KWEXP_INVAL(kflag)) {
   warnx(invalid RCS keyword substitution mode);
   (usage)();
 - exit(1);
   }
   break;
   case 'n':
 @@ -90,7 +89,6 @@ rcsclean_main(int argc, char **argv)
   break;
   default:
   (usage)();
 - exit(1);
   }
   }
  
 @@ -104,7 +102,6 @@ rcsclean_main(int argc, char **argv)
   if ((dirp = opendir(.)) == NULL) {
   warn(opendir);
   (usage)();
 - exit(1);
   }
  
   while ((dp = readdir(dirp)) != NULL) {
 @@ -127,6 +124,8 @@ rcsclean_usage(void)
   fprintf(stderr,
   usage: rcsclean [-TV] [-kmode] [-n[rev]] [-q[rev]] [-r[rev]]\n
   [-u[rev]] [-xsuffixes] [-ztz] [file ...]\n);
 +
 + exit(1);
  }
  
  static void
 Index: rcsdiff.c
 ===
 RCS file: /cvs/src/usr.bin/rcs/rcsdiff.c,v
 

Re: 802.11 autoassoc

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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: [Patch] use exit() directly in usage()

2014-09-30 Thread Otto Moerbeek
On Tue, Sep 30, 2014 at 10:05:00AM +0100, Nicholas Marriott wrote:

 If we do this then these usage functions also need to be marked __dead.

Agreed, Fritjof, can you aadd that to your diff?

-Otto

 
 
 
 On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote:
  Hi,
  
  after usage() was called, there is no where you can go.
  
  fritjof
  
  
  Index: ci.c
  ===
  RCS file: /cvs/src/usr.bin/rcs/ci.c,v
  retrieving revision 1.217
  diff -u -p -r1.217 ci.c
  --- ci.c19 May 2014 19:42:24 -  1.217
  +++ ci.c2 Jun 2014 22:18:25 -
  @@ -97,6 +97,8 @@ checkin_usage(void)
[-j[rev]] [-k[rev]] [-l[rev]] [-M[rev]] [-mmsg]\n
[-Nsymbol] [-nsymbol] [-r[rev]] [-sstate] [-t[str]]\n
[-u[rev]] [-wusername] [-xsuffixes] [-ztz] file ...\n);
  +
  +   exit(1);
   }
   
   /*
  @@ -221,7 +223,6 @@ checkin_main(int argc, char **argv)
  break;
  default:
  (usage)();
  -   exit(1);
  }
  }
   
  @@ -231,7 +232,6 @@ checkin_main(int argc, char **argv)
  if (argc == 0) {
  warnx(no input file);
  (usage)();
  -   exit(1);
  }
   
  if ((pb.username = getlogin()) == NULL)
  Index: co.c
  ===
  RCS file: /cvs/src/usr.bin/rcs/co.c,v
  retrieving revision 1.117
  diff -u -p -r1.117 co.c
  --- co.c16 Apr 2013 20:24:45 -  1.117
  +++ co.c2 Jun 2014 22:19:38 -
  @@ -79,7 +79,6 @@ checkout_main(int argc, char **argv)
  if (RCS_KWEXP_INVAL(kflag)) {
  warnx(invalid RCS keyword substitution mode);
  (usage)();
  -   exit(1);
  }
  break;
  case 'l':
  @@ -141,7 +140,6 @@ checkout_main(int argc, char **argv)
  break;
  default:
  (usage)();
  -   exit(1);
  }
  }
   
  @@ -151,7 +149,6 @@ checkout_main(int argc, char **argv)
  if (argc == 0) {
  warnx(no input file);
  (usage)();
  -   exit (1);
  }
   
  if ((username = getlogin()) == NULL)
  @@ -229,6 +226,8 @@ checkout_usage(void)
  usage: co [-TV] [-ddate] [-f[rev]] [-I[rev]] [-kmode] [-l[rev]]\n
[-M[rev]] [-p[rev]] [-q[rev]] [-r[rev]] [-sstate]\n
[-u[rev]] [-w[user]] [-xsuffixes] [-ztz] file ...\n);
  +
  +   exit(1);
   }
   
   /*
  Index: merge.c
  ===
  RCS file: /cvs/src/usr.bin/rcs/merge.c,v
  retrieving revision 1.7
  diff -u -p -r1.7 merge.c
  --- merge.c 23 Jul 2010 21:46:05 -  1.7
  +++ merge.c 2 Jun 2014 22:20:55 -
  @@ -77,7 +77,6 @@ merge_main(int argc, char **argv)
  exit(0);
  default:
  (usage)();
  -   exit(D_ERROR);
  }
  }
  argc -= optind;
  @@ -86,7 +85,6 @@ merge_main(int argc, char **argv)
  if (argc != 3) {
  warnx(%s arguments, (argc  3) ? not enough : too many);
  (usage)();
  -   exit(D_ERROR);
  }
   
  for (; labels  3; labels++)
  @@ -118,4 +116,6 @@ merge_usage(void)
   {
  (void)fprintf(stderr,
  usage: merge [-EepqV] [-L label] file1 file2 file3\n);
  +
  +   exit(D_ERROR);
   }
  Index: rcsclean.c
  ===
  RCS file: /cvs/src/usr.bin/rcs/rcsclean.c,v
  retrieving revision 1.52
  diff -u -p -r1.52 rcsclean.c
  --- rcsclean.c  28 Jul 2010 09:07:11 -  1.52
  +++ rcsclean.c  2 Jun 2014 22:22:05 -
  @@ -60,7 +60,6 @@ rcsclean_main(int argc, char **argv)
  if (RCS_KWEXP_INVAL(kflag)) {
  warnx(invalid RCS keyword substitution mode);
  (usage)();
  -   exit(1);
  }
  break;
  case 'n':
  @@ -90,7 +89,6 @@ rcsclean_main(int argc, char **argv)
  break;
  default:
  (usage)();
  -   exit(1);
  }
  }
   
  @@ -104,7 +102,6 @@ rcsclean_main(int argc, char **argv)
  if ((dirp = opendir(.)) == NULL) {
  warn(opendir);
  (usage)();
  -   exit(1);
  }
   
  while ((dp = readdir(dirp)) != NULL) {
  @@ -127,6 +124,8 @@ rcsclean_usage(void)
  fprintf(stderr,
  usage: rcsclean [-TV] [-kmode] [-n[rev]] [-q[rev]] [-r[rev]]\n
  [-u[rev]] [-xsuffixes] [-ztz] [file ...]\n);
  +
  +   exit(1);
   }
   
   static void
  Index: 

Re: 802.11 autoassoc

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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

2014-09-30 Thread 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.



improving OpenBSD's gmac.c...

2014-09-30 Thread John-Mark Gurney
So, as I was working on FreeBSD's implementation of gmac.c, I noticed
that I was able to get a significant speed up by using a mask instead
of an if branch in ghash_gfmul in gmac.c from OpenBSD...

Add a mask var and replace the code between the comments
update Z and update V w/:
mask = !!(x[i  3]  (1  (~i  7)));
mask = ~(mask - 1);

z[0] ^= v[0]  mask;
z[1] ^= v[1]  mask;
z[2] ^= v[2]  mask;
z[3] ^= v[3]  mask;

And you should see a nice performance increase...

I also have an implementation of ghash that does a 4 bit lookup table
version with the table split between cache lines in p4 at:
https://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/opencrypto/sys/opencrypto/gfmult.cREV=4

This also has a version with does 4 blocks at a time getting a
further speed up...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.



Re: 802.11 autoassoc

2014-09-30 Thread 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.



unused argument in pfr_create_kentry()

2014-09-30 Thread Alexandr Nedvedicky
Hello,

while working with PF code we've found the arg1 (flags) of pfr_create_kentry()
is unused.

the patch is trivial, just in case you are interested.

regards
sasha

 cut here to get patch --

Index: pf_table.c
===
RCS file: /cvs/src/sys/net/pf_table.c,v
retrieving revision 1.103
diff -u -r1.103 pf_table.c
--- pf_table.c  8 Sep 2014 06:24:13 -   1.103
+++ pf_table.c  30 Sep 2014 16:01:47 -
@@ -148,7 +148,7 @@
 voidpfr_mark_addrs(struct pfr_ktable *);
 struct pfr_kentry  *pfr_lookup_addr(struct pfr_ktable *,
struct pfr_addr *, int);
-struct pfr_kentry  *pfr_create_kentry(struct pfr_addr *, u_int32_t);
+struct pfr_kentry  *pfr_create_kentry(struct pfr_addr *);
 voidpfr_destroy_kentries(struct pfr_kentryworkq *);
 voidpfr_destroy_kentry(struct pfr_kentry *);
 voidpfr_insert_kentries(struct pfr_ktable *,
@@ -306,7 +306,7 @@
ad.pfra_fback = PFR_FB_NONE;
}
if (p == NULL  q == NULL) {
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
senderr(ENOMEM);
if (pfr_route_kentry(tmpkt, p)) {
@@ -482,7 +482,7 @@
ad.pfra_fback = PFR_FB_DUPLICATE;
goto _skip;
}
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
senderr(ENOMEM);
if (pfr_route_kentry(tmpkt, p)) {
@@ -820,7 +820,7 @@
 }
 
 struct pfr_kentry *
-pfr_create_kentry(struct pfr_addr *ad, u_int32_t flags)
+pfr_create_kentry(struct pfr_addr *ad)
 {
struct pfr_kentry_all   *ke;
 
@@ -917,7 +917,7 @@
p = pfr_lookup_addr(kt, ad, 1);
if (p != NULL)
return (0);
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
return (EINVAL);
 
@@ -1614,7 +1614,7 @@
senderr(EINVAL);
if (pfr_lookup_addr(shadow, ad, 1) != NULL)
continue;
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
senderr(ENOMEM);
if (pfr_route_kentry(shadow, p)) {
Index: pf_table.c
===
RCS file: /cvs/src/sys/net/pf_table.c,v
retrieving revision 1.103
diff -u -r1.103 pf_table.c
--- pf_table.c  8 Sep 2014 06:24:13 -   1.103
+++ pf_table.c  30 Sep 2014 16:01:47 -
@@ -148,7 +148,7 @@
 voidpfr_mark_addrs(struct pfr_ktable *);
 struct pfr_kentry  *pfr_lookup_addr(struct pfr_ktable *,
struct pfr_addr *, int);
-struct pfr_kentry  *pfr_create_kentry(struct pfr_addr *, u_int32_t);
+struct pfr_kentry  *pfr_create_kentry(struct pfr_addr *);
 voidpfr_destroy_kentries(struct pfr_kentryworkq *);
 voidpfr_destroy_kentry(struct pfr_kentry *);
 voidpfr_insert_kentries(struct pfr_ktable *,
@@ -306,7 +306,7 @@
ad.pfra_fback = PFR_FB_NONE;
}
if (p == NULL  q == NULL) {
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
senderr(ENOMEM);
if (pfr_route_kentry(tmpkt, p)) {
@@ -482,7 +482,7 @@
ad.pfra_fback = PFR_FB_DUPLICATE;
goto _skip;
}
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
senderr(ENOMEM);
if (pfr_route_kentry(tmpkt, p)) {
@@ -820,7 +820,7 @@
 }
 
 struct pfr_kentry *
-pfr_create_kentry(struct pfr_addr *ad, u_int32_t flags)
+pfr_create_kentry(struct pfr_addr *ad)
 {
struct pfr_kentry_all   *ke;
 
@@ -917,7 +917,7 @@
p = pfr_lookup_addr(kt, ad, 1);
if (p != NULL)
return (0);
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = pfr_create_kentry(ad);
if (p == NULL)
return (EINVAL);
 
@@ -1614,7 +1614,7 @@
senderr(EINVAL);
if (pfr_lookup_addr(shadow, ad, 1) != NULL)
continue;
-   p = pfr_create_kentry(ad, kt-pfrkt_flags);
+   p = 

Re: 802.11 autoassoc

2014-09-30 Thread 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



nofault mappings

2014-09-30 Thread Mark Kettenis
The diff below intorduces a new flag for mmap(2) that creates mappings
that cannot fault.  Normally, if you mmap a file, and your mapping is
larger than the mapped file, memory access to full pages beyond the
end of the file will fault.  Depending on the OS you will get a
SIGSEGV or SIGBUS and if you don't catch those, you die.  This is
especially nasty if you use file descriptor passing to share the file
descriptor with some other process and this other proces ftruncates
the file without telling you.

The new xserver that matthieu@ just imported has the new xshm
extension which mmaps file descriptors passed by clients through file
descriptor passing.  To protect itself from being trivially DOSed by a
malicious (or careless) client, it keeps a list of mappings and
installs a SIGBUS signal handler that checks whether the fault address
matches any of these mappings.  In that case it mmaps a private
anonymous page on top of the faulting address and returns.  Since
OpenBSD generates SIGSEGV instead of SIGBUS in this case, this doesn't
work for us, so I made sure matthieu@ disabled this functionality for
now.  But the new xshm extension would actually be a nice thing to
have as it circumvents certain problems with the traditional xshm
extension that we have because of privsep.  And file descriptor
passing is also being used for DRI3 which we may want to support one
day.  Oh, and Wayland, which some people claim will replace X any day
now, heavily uses mapping file descriptors passed over sockets as
well.

We could of course change the xserver code to also trap SIGSEGV.  But
this workaround is rather ugly.  So my idea is to make X use this new
flag and disable the stupid busfault code.

The diff is remarkably simple.  We already have the infrastructure in
place to replace mapped pages with anons to support MAP_PRIVATE and
copy-on-write.  This diff simply leverages that infrastructure to
replace a page that can't be read from the underlying object by an
anonymous pages.  Some open issues:

 * I need to check whether all combinations of flag actually make
   sense.  Should we only support __MAP_NOFAULT with non-anonymous
   mappings?

 * Should we only fixup the fault for access beyond the end of the
   mapped object (VM_PAGER_BAD) and still fault for actual IO erors
   (VM_PAGER_ERROR)?

 * Should the flag be exported without the leading underscores since
   we actually want to encourage its use?

Thoughts?


Index: sys/mman.h
===
RCS file: /cvs/src/sys/sys/mman.h,v
retrieving revision 1.26
diff -u -p -r1.26 mman.h
--- sys/mman.h  10 Jul 2014 19:00:23 -  1.26
+++ sys/mman.h  30 Sep 2014 20:34:42 -
@@ -58,8 +58,9 @@
 #define__MAP_NOREPLACE 0x0800  /* fail if address not available */
 #defineMAP_ANON0x1000  /* allocated from memory, swap space */
 #defineMAP_ANONYMOUS   MAP_ANON/* alternate POSIX spelling */
+#define__MAP_NOFAULT   0x2000
 
-#defineMAP_FLAGMASK0x1ff7
+#defineMAP_FLAGMASK0x3ff7
 
 #ifdef _KERNEL
 /*
Index: uvm/uvm.h
===
RCS file: /cvs/src/sys/uvm/uvm.h,v
retrieving revision 1.56
diff -u -p -r1.56 uvm.h
--- uvm/uvm.h   11 Jul 2014 16:35:40 -  1.56
+++ uvm/uvm.h   30 Sep 2014 21:03:43 -
@@ -90,7 +90,8 @@ struct uvm {
 #define UVM_ET_SUBMAP  0x02/* it is a vm_map submap */
 #define UVM_ET_COPYONWRITE 0x04/* copy_on_write */
 #define UVM_ET_NEEDSCOPY   0x08/* needs_copy */
-#defineUVM_ET_HOLE 0x10/* no backend */
+#define UVM_ET_HOLE0x10/* no backend */
+#define UVM_ET_NOFAULT 0x20/* don't fault */
 #define UVM_ET_FREEMAPPED  0x80/* map entry is on free list (DEBUG) */
 
 #define UVM_ET_ISOBJ(E)(((E)-etype  UVM_ET_OBJ) != 0)
@@ -98,6 +99,7 @@ struct uvm {
 #define UVM_ET_ISCOPYONWRITE(E)(((E)-etype  UVM_ET_COPYONWRITE) != 0)
 #define UVM_ET_ISNEEDSCOPY(E)  (((E)-etype  UVM_ET_NEEDSCOPY) != 0)
 #define UVM_ET_ISHOLE(E)   (((E)-etype  UVM_ET_HOLE) != 0)
+#define UVM_ET_ISNOFAULT(E)(((E)-etype  UVM_ET_NOFAULT) != 0)
 
 #ifdef _KERNEL
 
Index: uvm/uvm_extern.h
===
RCS file: /cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.119
diff -u -p -r1.119 uvm_extern.h
--- uvm/uvm_extern.h11 Jul 2014 16:35:40 -  1.119
+++ uvm/uvm_extern.h30 Sep 2014 20:08:36 -
@@ -148,14 +148,15 @@ typedef int   vm_prot_t;
 #define UVM_ADV_MASK   0x7 /* mask */
 
 /* mapping flags */
-#define UVM_FLAG_FIXED   0x01 /* find space */
-#define UVM_FLAG_OVERLAY 0x02 /* establish overlay */
-#define UVM_FLAG_NOMERGE 0x04 /* don't merge map entries */
-#define UVM_FLAG_COPYONW 0x08 /* set copy_on_write flag */
-#define UVM_FLAG_AMAPPAD 0x10 /* for bss: pad amap to reduce malloc() 

fix for nginx SSL session reuse

2014-09-30 Thread Ted Unangst
This issue also affects 5.4, 5.5 and 5.6. Patches available in the
respective directories.

5.5 patch follows.

http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/011_nginx.patch.sig

untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N93yafiuGu4x20xhAgMsmcjCmHJrYJBolmNu2NJUqcC3s+pOmCbUPPX2GxRlEIotfwpbcVG23OoCHguJSk8FZc+Qk=

OpenBSD 5.5 errata 11, Oct 1, 2014:  Fix for the SSL session reuse
vulnerability (CVE-2014-3616).

Apply patch using:

signify -Vep /etc/signify/openbsd-55-base.pub -x 011_nginx.patch.sig -m - | 
\
(cd /usr/src  patch -p0)

Then build and install nginx:

cd /usr/src/usr.sbin/nginx
make -f Makefile.bsd-wrapper obj 
make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install

Index: usr.sbin/nginx/src/event/ngx_event_openssl.c
===
RCS file: /cvs/src/usr.sbin/nginx/src/event/ngx_event_openssl.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 ngx_event_openssl.c
--- usr.sbin/nginx/src/event/ngx_event_openssl.c1 Jun 2013 16:12:54 
-   1.12
+++ usr.sbin/nginx/src/event/ngx_event_openssl.c18 Sep 2014 14:18:24 
-
@@ -27,6 +27,8 @@ static void ngx_ssl_connection_error(ngx
 ngx_err_t err, char *text);
 static void ngx_ssl_clear_error(ngx_log_t *log);
 
+static ngx_int_t ngx_ssl_session_id_context(ngx_ssl_t *ssl,
+ngx_str_t *sess_ctx);
 ngx_int_t ngx_ssl_session_cache_init(ngx_shm_zone_t *shm_zone, void *data);
 static int ngx_ssl_new_session(ngx_ssl_conn_t *ssl_conn,
 ngx_ssl_session_t *sess);
@@ -1659,13 +1661,15 @@ ngx_ssl_session_cache(ngx_ssl_t *ssl, ng
 {
 long  cache_mode;
 
+if (ngx_ssl_session_id_context(ssl, sess_ctx) != NGX_OK) {
+   return NGX_ERROR;
+}
+
 if (builtin_session_cache == NGX_SSL_NO_SCACHE) {
 SSL_CTX_set_session_cache_mode(ssl-ctx, SSL_SESS_CACHE_OFF);
 return NGX_OK;
 }
 
-SSL_CTX_set_session_id_context(ssl-ctx, sess_ctx-data, sess_ctx-len);
-
 if (builtin_session_cache == NGX_SSL_NONE_SCACHE) {
 
 /*
@@ -1769,6 +1773,94 @@ ngx_ssl_session_cache_init(ngx_shm_zone_
 return NGX_OK;
 }
 
+static ngx_int_t
+ngx_ssl_session_id_context(ngx_ssl_t *ssl, ngx_str_t *sess_ctx)
+{
+int   n, i;
+X509 *cert;
+X509_NAME*name;
+EVP_MD_CTXmd;
+unsigned int  len;
+STACK_OF(X509_NAME)  *list;
+u_charbuf[EVP_MAX_MD_SIZE];
+
+/*
+ * Session ID context is set based on the string provided,
+ * the server certificate, and the client CA list.
+ */
+
+EVP_MD_CTX_init(md);
+
+if (EVP_DigestInit_ex(md, EVP_sha1(), NULL) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  EVP_DigestInit_ex() failed);
+goto failed;
+}
+
+if (EVP_DigestUpdate(md, sess_ctx-data, sess_ctx-len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  EVP_DigestUpdate() failed);
+goto failed;
+}
+
+cert = SSL_CTX_get_ex_data(ssl-ctx, ngx_ssl_certificate_index);
+
+if (X509_digest(cert, EVP_sha1(), buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  X509_digest() failed);
+goto failed;
+}
+
+if (EVP_DigestUpdate(md, buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  EVP_DigestUpdate() failed);
+goto failed;
+}
+
+list = SSL_CTX_get_client_CA_list(ssl-ctx);
+
+if (list != NULL) {
+n = sk_X509_NAME_num(list);
+
+for (i = 0; i  n; i++) {
+name = sk_X509_NAME_value(list, i);
+
+if (X509_NAME_digest(name, EVP_sha1(), buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  X509_NAME_digest() failed);
+goto failed;
+}
+
+if (EVP_DigestUpdate(md, buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  EVP_DigestUpdate() failed);
+goto failed;
+}
+}
+}
+
+if (EVP_DigestFinal_ex(md, buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  EVP_DigestUpdate() failed);
+goto failed;
+}
+
+EVP_MD_CTX_cleanup(md);
+
+if (SSL_CTX_set_session_id_context(ssl-ctx, buf, len) == 0) {
+ngx_ssl_error(NGX_LOG_EMERG, ssl-log, 0,
+  SSL_CTX_set_session_id_context() failed);
+return NGX_ERROR;
+}
+
+return NGX_OK;
+
+failed:
+
+EVP_MD_CTX_cleanup(md);
+
+return NGX_ERROR;
+}
 
 /*
  * The length of the session id is 16 bytes for SSLv2 sessions and




openssl.cnf req defaults - default_md sha256

2014-09-30 Thread Stuart Henderson
Over the coming months, web browsers will progressively start to first
warn for certificate chains including SHA-1 hashes, then treat them
as insecure (including disabling certain content - scripts etc).
Chrome are initially doing this for certs expiring after Jan 2017,
but will progressively slide it forward to certs expiring after
Jan 2016.

Since my previous attempt to at least show this in ssl(8) examples
for openssl req a few months ago, I've spent some time digging for
where the defaults are set in the code as a nicer place to set sane
values, but haven't tracked it down yet. Would it be OK to set it
in the default config for now? (or does anyone have an idea of where
in the code this comes from?)

Index: openssl.cnf
===
RCS file: /cvs/src/lib/libcrypto/openssl.cnf,v
retrieving revision 1.1
diff -u -p -r1.1 openssl.cnf
--- openssl.cnf 11 Apr 2014 22:51:53 -  1.1
+++ openssl.cnf 30 Sep 2014 22:42:53 -
@@ -7,7 +7,8 @@
 
 
 [ req ]
-default_bits   = 1024
+default_bits   = 2048
+default_md = sha256
 default_keyfile= privkey.pem
 distinguished_name = req_distinguished_name
 attributes = req_attributes





[patch] dhclient: support for RFC 3442 Local Subnet Routes

2014-09-30 Thread Matthew Dempsky
From RFC 3442:

   Local Subnet Routes

   In some cases more than one IP subnet may be configured on a link.
   In such cases, a host whose IP address is in one IP subnet in the
   link could communicate directly with a host whose IP address is in a
   different IP subnet on the same link.  In cases where a client is
   being assigned an IP address on an IP subnet on such a link, for each
   IP subnet in the link other than the IP subnet on which the client
   has been assigned the DHCP server MAY be configured to specify a
   router IP address of 0.0.0.0.

   For example, consider the case where there are three IP subnets
   configured on a link: 10.0.0/24, 192.168.0/24, 10.0.21/24.  If the
   client is assigned an IP address of 10.0.21.17, then the server could
   include a route with a destination of 10.0.0/24 and a router address
   of 0.0.0.0, and also a route with a destination of 192.168.0/24 and a
   router address of 0.0.0.0.

   A DHCP client whose underlying TCP/IP stack does not provide this
   capability MUST ignore routes in the Classless Static Routes option
   whose router IP address is 0.0.0.0.  Please note that the behavior
   described here only applies to the Classless Static Routes option,
   not to the Static Routes option nor the Router option.

The patch below adds support for these routes to dhclient.  It
refactors the existing magic direct-route incantation I added in
r1.272, and reuses it in add_classless_static-routes().

I've experimentally verified that this makes OpenBSD work on Google
Compute Engine again.  E.g., a DHCP lease with:

fixed-address 10.240.142.165;
option subnet-mask 255.255.255.255;
option classless-static-routes 10.240.0.1/32 0.0.0.0, 0.0.0.0/0 10.240.0.1;

now results in a routing table like:

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio 
Iface
default10.240.0.1 UGS00 - 8 vio0
10.240.0.1 link#1 UHLc   10 - 8 vio0
10.240.0.1/32  link#1 UCS10 - 8 vio0
10.240.142.165 42:01:0a:f0:8e:a5  UHLl   00 - 1 lo0
10.240.142.165/32  link#1 UC 00 - 4 vio0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UH 10 32768 4 lo0
224/4  127.0.0.1  URS00 32768 8 lo0

ok?

Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.319
diff -u -p -r1.319 dhclient.c
--- dhclient.c  11 Aug 2014 18:41:13 -  1.319
+++ dhclient.c  1 Oct 2014 00:47:22 -
@@ -108,9 +108,10 @@ struct client_lease *clone_lease(struct 
 voidsocket_nonblockmode(int);
 voidapply_ignore_list(char *);
 
+void add_direct_route(int, struct in_addr, struct in_addr, struct in_addr);
 void add_default_route(int, struct in_addr, struct in_addr);
 void add_static_routes(int, struct option_data *);
-void add_classless_static_routes(int, struct option_data *);
+void add_classless_static_routes(int, struct option_data *, struct in_addr);
 
 int compare_lease(struct client_lease *, struct client_lease *);
 void set_lease_times(struct client_lease *);
@@ -872,10 +873,12 @@ bind_lease(void)
add_address(ifi-name, ifi-rdomain, client-active-address, mask);
if (options[DHO_CLASSLESS_STATIC_ROUTES].len) {
add_classless_static_routes(ifi-rdomain,
-   options[DHO_CLASSLESS_STATIC_ROUTES]);
+   options[DHO_CLASSLESS_STATIC_ROUTES],
+   client-active-address);
} else if (options[DHO_CLASSLESS_MS_STATIC_ROUTES].len) {
add_classless_static_routes(ifi-rdomain,
-   options[DHO_CLASSLESS_MS_STATIC_ROUTES]);
+   options[DHO_CLASSLESS_MS_STATIC_ROUTES],
+   client-active-address);
} else {
opt = options[DHO_ROUTERS];
if (opt-len = sizeof(gateway)) {
@@ -883,17 +886,13 @@ bind_lease(void)
gateway.s_addr = ((struct in_addr *)opt-data)-s_addr;
 
/*
-* If we were given a /32 IP assignment, then make sure
-* the gateway address is routable with equivalent of
-*
-* route add -net $gw -netmask 255.255.255.255 \
-* -cloning -iface $addr
+* To be compatible with ISC DHCP behavior on Linux, if
+* we were given a /32 IP assignment, then add a /32
+* direct route for the gateway to make it routable.