Windows 10 Wifi-Sense - Discuss how to detect and block.
-
I'm fairly sure Wifi Sense does not work- and will never work- with WPA2 Enterprise networks. I just set up a separate VLAN with a guest wifi AP using WPA2 Enterprise. I set up long-term RADIUS user accounts for different people that come over regularly, and I'll create a generic Guest account for one-off guests.
Honestly, I wish everything supported WPA2 Enterprise. It's much better than WPA2-PSK, even if you only use a single username/password. Anyone with the PSK can trivially capture and decrypt other users' traffic. WPA2 Enterprise, on the other hand, negotiates a different key for each client. I'd move everything to WPA2 Enterprise if I could, but unfortunately I have too many devices that don't support it (e.g., Chromecast).
-
So you don't think wifi sense could store a username and a password vs just the psk??
The point is not that they can sniff other users traffic while on your network, the point is that they could get on your network in the first place.. Using something like EAP-TLS would prevent the sharing of the username and password from allowing access to the network.
As to your enterprise vs psk for stuff that doesn't support it - then just run a ssid that uses psk for those devices.
-
So you don't think wifi sense could store a username and a password vs just the psk??
Could it? Sure. But it would be an incredibly stupid move. I don't think Wifi Sense was a great idea to begin with, but I can understand why someone would view it as a compelling feature with minimal security impact. In practice most people are pretty quick to share Wifi passwords. At least this way you don't need to directly hand over the password. And users still decide what they will share. If you give your friend your wifi password, there's nothing stopping them from turning around and sharing it to others. The semi-automatic nature of this makes me uncomfortable, though.
But, there's absolutely no expectation that users would share EAP/PEAP credentials in the same way as WPA-PSK passwords. So, there's no legitimate reason to do it, and there's certain to be a lot of angry corporate customers if they did.
The point is not that they can sniff other users traffic while on your network, the point is that they could get on your network in the first place.. Using something like EAP-TLS would prevent the sharing of the username and password from allowing access to the network.
As to your enterprise vs psk for stuff that doesn't support it - then just run a ssid that uses psk for those devices.
While it wouldn't happen, Microsoft could just as easily share EAP-TLS keys as WPA-PSK or PEAP passwords (assuming they're "soft" credentials, not keys on smart cards). If you don't think Microsoft has any common sense left, EAP-TLS is any better than PEAP.
Anyways, my comments on WPA2 Enterprise were more of an aside, rather than being directly related to Wifi Sense. My point was merely that if you're running a wifi network where you're fairly widely sharing the key(s) to access it, you're much, much better off if you use WPA2 Enterprise, rather than WPA2-PSK.
-
Hello everyone,
pfSense comes with a really good captive portal that can perhaps be used to solve this clients out.
If I visit the Adobe website, and want to update or download a new version of their flashplayer,
the Adobe website is knowing my OS and the by me used browser! Even I do so! So there must
be code inside of the website to find this out, to offer me the right flash version for my OS and
used browser, likes:Windows 7 64Bit and Opera as an example.
So if now this code will be placed inside of the captive portal "Welcome page" of pfSense it must
be also able to gain up those informations like, Windows 10 or MS WiFi Sense from the WiFi clients
that tries to join the captive portal page, or am I wrong now with this?And based on this informations the user will be then lead;
- to another website (redirected) with a explanation or declaration about
their OS status and that they would be, let us call it, classified or judged
as a security problem and can´t join exactly this network, related to MS
WiFi Sense or Windows 10 or what ever. - Or likes all others XP,7,8,8.1 will be directed to the real login page of the captive portal
Is this able to realize with the captive portal homepage, some rediretion pasges and some
code like the code used by the Adobe website?- captive Portal is there
- redirection pages must be defined (login and deny page)
- the code must be adjusted or updated for sure?
- to another website (redirected) with a explanation or declaration about
-
"My point was merely that if you're running a wifi network where you're fairly widely sharing the key(s) to access it, you're much, much better off if you use WPA2 Enterprise, rather than WPA2-PSK."
Somewhat agree - running a enterprise in an open wifi network would be a PITA.. It is clearly way more complicated of a setup, for guests I would put them on their own wireless network vs one shared with say employee's anyway. Be it your employees used enterprise or psk.
Your point about enterprise support on devices is key point here, you can not be sure that the device a guest is using will not balk at invalid cert, or even support it at all. For sure it is way more complicated for "guests" to connect to that is for sure. Shoot many users have problem with something as simple as captive portal, and if it does not support and use a valid cert for the ssl connection even more sore. Shoot apple devices log in method will not even work without a valid cert and user has to launch a browser and accept the invalid cert to even get to the portal some times, etc.
If your using a guest network you should have no expectations that the traffic is not being viewed by others on the same network and take precautions on your own to secure your traffic if your worried, etc. All of which is beyond comprehension of your day to day users sad to say.
-
Somewhat agree - running a enterprise in an open wifi network would be a PITA.. It is clearly way more complicated of a setup, for guests I would put them on their own wireless network vs one shared with say employee's anyway. Be it your employees used enterprise or psk.
Your point about enterprise support on devices is key point here, you can not be sure that the device a guest is using will not balk at invalid cert, or even support it at all. For sure it is way more complicated for "guests" to connect to that is for sure. Shoot many users have problem with something as simple as captive portal, and if it does not support and use a valid cert for the ssl connection even more sore. Shoot apple devices log in method will not even work without a valid cert and user has to launch a browser and accept the invalid cert to even get to the portal some times, etc.
Agree, mostly, on all points. Certainly it's good to separate your enterprise network from your guest network.
But, I think WPA2 Enterprise support is complicated because we've (the collective "we") have allowed it to be complicated. If you let your devices connect to open or WPA2-PSK networks (as nearly everyone does), then there's no reason not to let them connect to WPA2-Enterprise networks without warning about certs. There should, of course, be a way to configure certain profiles/networks that will enforce cert checks, but I don't see why they are always checked, given that in other situations we're happy to connect to unauthenticated APs.
(Presumably the poor device support for WPA2-Enterprise is due in part to the more computationally-intensive crypto required. But I'm sure things like a Chromecast or Roku have the power to set up a TLS pipe. It seems like much less of an issue today than it might have been 10+ years ago.)
And while I agree with your general point about not trusting guest networks, I think it's a bad model if different wifi users on even a trusted network can snoop on each other. There's very little justification for that, given just about any device now can do a TLS negotiation in a reasonable amount of time.
@BlueKobold:
And based on this informations the user will be then lead;
- to another website (redirected) with a explanation or declaration about
their OS status and that they would be, let us call it, classified or judged
as a security problem and can´t join exactly this network, related to MS
WiFi Sense or Windows 10 or what ever. - Or likes all others XP,7,8,8.1 will be directed to the real login page of the captive portal
If you're using captive portal, why even lock out Win10 users? Wifi Sense isn't going save and share the captive portal username/password.
- to another website (redirected) with a explanation or declaration about
-
The initiate thread was started by @vbentley with one of this main questions;
A captive portal with device/browser detection.
And yes I consider to do so and believe this way.
If you're using captive portal, why even lock out Win10 users?
This was the entire question starting this thread along it was changing a bit of
course this is normal in a discussion and it comes closer to the second question
set by @vbentley;So how best to detect and block Windows 10 devices?
As today WiFi networks and also the local country laws are quite different from
each other I would be not suggest everybody the same idea, because he can
surely get much problems in his country, this at first.And for sure it is really often not the same if I am inside of a corporate network,
inside a coffee bar with public WiFi access or inside a auto garage that offers also
public WiFi inside of the car store!To setup a open public WiFi network can be a good choice if you are hired and there
is a party, smaller music concert, lan party or a unique events, for sure this could be
running to narrow down the entire cost and complexity. Or perhaps an official installment
like an public park with from the major or cityhall offered open WiFi mesh network, this is
really often to see more and more in today days. But in all other fields this is a NoGo area.In our company network we use a captive portal with a voucher system, that delivers
the voucher to each mobile device, so that guest can fast connect to the Internet only
if we have meetings in the company. We were setting up it in this direction:- company network cable based devices auth. over LDAP server - internet & company network
- company network cable less devices auth. over Radius server in an extra vlan - internet & company network
- WiFi Guests over the captive portal with voucher system in an extra vlan - internet only
- private devices, but from the employees, checking their email in the lunch break in an extra vlan - Internet only
WPA2 AES-CCM & 2048Bit certificates installed local at the company devices
client isolation is enabled on all WiFi vlansOSSec - host based IDS
Snort - network based IDS -
@BlueKobold-
I understand the original question of the OP. But in the OP itself, along with the follow-up posts, it seems like @vbentley is concerned about blocking WiFi sense devices from sharing information sufficient to get access to network resources.Now, I always hate it when people jump on OPs asking how to do something in a thread only to tell the OP that their proposed solution is wrong and they should do it a different way. The situation here is a little different. The OP has laid out a fairly coherent list of concerns with the impact of Windows 10's WiFi Sense feature on their network.
As far as I can tell, any plausible solution to (strongly) blocking WiFi Sense involves some combination of: 1) separate VLANs for guests, 2) client isolation, 3) captive portal, and 4) WPA2-Enterprise using EAP-TLS or PEAP. And any combination of those technologies sufficient to guard against WiFi Sense appears to be sufficient to protect your network even if Windows 10 devices (with WiFi Sense enabled) get on your network.
While the OP asked about blocking Windows 10 devices, it appears to either be based on: 1) a mistaken belief that it would help address the threat of WiFi Sense, or 2) general rage against Microsoft and/or Windows 10, resulting in a desire to block such devices out of spite.
There may be legitimate reasons to want to block Windows 10 devices, but I didn't see any concern listed in this thread that would justify that. And if you have a legitimate reason to block Windows 10 devices, I'd think you'd want to use something stronger than just a User-Agent check, which is probably all Adobe (and other websites) do. FreeRADIUS supports Microsoft Statement-of-Health claims with PEAP. I bet you could configure it to look at the Windows version number to reject Windows 10 devices.
-
My point was that EAP-TLS with MAC locking would just automatically block any attempt to share the network connection with another host, period, including wifi-sense.
-
While the OP asked about blocking Windows 10 devices, it appears to either be based on: 1) a mistaken belief that it would help address the threat of WiFi Sense, or 2) general rage against Microsoft and/or Windows 10, resulting in a desire to block such devices out of spite.
I am treating Windows 10 devices just like I treat any unauthorised device that doesn't comply with or breaches our security policy. I don't think that my attitude is any different to Windows 10 as it would be to an unauthorised Wireless Access Point plugged in to the network.
AFAIK, WiFi sense isn't implemented on earlier Windows devices except on Windows phone. If I have a 'mistaken belief' are you saying you know that WiFi sense is implemented on other devices other than Windows 10?
Yes. I'm no longer a fan of Microsoft or any of its products. Perhaps my Windows Mobile experience scarred me for life. I'm not a fan of any technology or company that is privacy invasive, insecure, or just makes my life harder. We have Windows 7 and some Apple devices on our networks. They are not exactly sandboxed or quarantined but they are all actively monitored for suspicious activity. We have no plans to deploy Windows 10 yet and probably won't ever need to. From Windows 2.0 to Windows 7, I have been bitten enough times by Microsoft over the last 28 years to become spiteful.
Now that pfSense 2.2.4 has been released, I can continue purging PSK and rolling out cert logins again.