hi, taking some Steinbeck metaphor too far... oh, how I wish Lenny were a code name for MacOSX rather than Debian... anyway, or lovely friend Lenny or having a few issues compared to his friend George. Lenny wants to have the lovely Wifi...but cant. You see, Lenny has 'issues' and some of these issues wont be apparent until too late. anyway, a few choice quotes from some google searches and I am none the wiser. I know this Mac OSX seems to have some issues with Cisco Wireless kit in the LWAPP mode. Mac OSX seems to have some driver issues....especially since the same kit (Macbook Pro) running Vista has no wireless problems. hmm. however, a rather interesting log file from the RADIATOR release: "Improved compatibility with some EAP-TTLS clients that previously would have required EAPTTLS_NoAckRequired. Reported by Ian Forster." coupled with #This is added for Apple Macintosh Airport Extreme adapters EAPTTLS_NoAckRequired suggests that something more is afoot. so...how is MacOSX with you guys out there with FreeRADIUS? This 'issue with airport extreme' - is the code in FreeRADIUS also supporting of these ACK issues? the posse is closing these guys down. its only a matter of time. alan ("to kill a mockingbird" analogy next ;-) )
Hi,
oh, how I wish Lenny were a code name for MacOSX rather than Debian... anyway,
Linophile
or lovely friend Lenny or having a few issues compared to his friend George. Lenny wants to have the lovely Wifi...but cant. You see, Lenny has 'issues' and some of these issues wont be apparent until too late.
He wants to stroke it and pet it, but it doesn't want to be stroked or petted and accuses him of passive snooping and replay attacks.
anyway, a few choice quotes from some google searches and I am none the wiser. I know this
Mac OSX seems to have some issues with Cisco Wireless kit in the LWAPP mode.
Mac OSX has issues with wireless in general. I found an interesting issue the other day. If you connect to a wireless access point, and then have a 3rd party (KisMac) repeatedly send dissociate frames to clients connected on that access point, after a while the Mac will stop re-connecting... to anything. Wireshark running on the Mac shows the AP sending EAPOL-Identity Requests and shows the Mac sending EAPOL-Identity responses, but if you actually sniff the traffic passively, the Mac never sends anything! The wireless adapter is obviously still working as it can start authentication and associate, but once it gets that far, nothing ! To cure the Mac of it's ails it's a simple 'Turn Off', 'Turn On' of the wireless adapter, but still a very annoying problem.
Mac OSX seems to have some driver issues....especially since the same kit (Macbook Pro) running Vista has no wireless problems. hmm.
however, a rather interesting log file from the RADIATOR release:
"Improved compatibility with some EAP-TTLS clients that previously would have required EAPTTLS_NoAckRequired. Reported by Ian Forster."
coupled with
#This is added for Apple Macintosh Airport Extreme adapters EAPTTLS_NoAckRequired
suggests that something more is afoot.
so...how is MacOSX with you guys out there with FreeRADIUS? This 'issue with airport extreme' - is the code in FreeRADIUS also supporting of these ACK issues?
the posse is closing these guys down. its only a matter of time.
Let's not put Lenny out of his misery just yet. I've never had problems with EAP-TTLS on Macs, I've actually started recommending people use it, as it appears to be slightly more efficient than PEAPv0 (based purely on the number of rounds it takes to complete), and far better documented. Could you elaborate on what issues you're seeing? -X perhaps ? Or maybe a little PCAP.. Arran
Hi,
Let's not put Lenny out of his misery just yet. I've never had problems with EAP-TTLS on Macs, I've actually started recommending people use it, as it appears to be slightly more efficient than PEAPv0 (based purely on the number of rounds it takes to complete), and far better documented.
I use TTLS where/when I can - eg Nokia S60
Could you elaborate on what issues you're seeing? -X perhaps ? Or maybe a little PCAP..
Macs which connect but dont get an address. Macs which just keep dropping their connection every 60 seconds. I'm just mainly intrigued by other RADIUS products that contain client work-arounds and fixes... particularly when airport extremes are mentioned directly. alan
A.L.M.Buxey@lboro.ac.uk wrote:
taking some Steinbeck metaphor too far...
oh, how I wish Lenny were a code name for MacOSX rather than Debian... anyway, or lovely friend Lenny or having a few issues compared to his friend George. Lenny wants to have the lovely Wifi...but cant. You see, Lenny has 'issues' and some of these issues wont be apparent until too late.
A code name because those Mac's might start to work if they were just formatted with Debian slapped on there you mean?
anyway, a few choice quotes from some google searches and I am none the wiser. I know this
Mac OSX seems to have some issues with Cisco Wireless kit in the LWAPP mode. Mac OSX seems to have some driver issues....especially since the same kit (Macbook Pro) running Vista has no wireless problems. hmm.
In my experience, the Mac OS X weenies only complain when some Layer 2 thing makes the wireless card driver upset; you see the same thing with Symbian phones and the Cisco WLC controllers. I have gotten bored of reporting bugs to Cisco, unless you have an 'enterprise' client (any NIC with 'Intel' in the name that seems to mean) they are simply not interested. Issues I have found: 1) some Mac's really sulk if there is a combination of 802.11a and 802.11b/g AP's broadcasting the same SSID (it might just be 802.11a only) 2) if you set MFP protection to anything other than 'Optional' then a particular group of Mac's will grumble 3) if you do not have 'Infrastructure MFP Protection' enabled, another particular group of Mac's sulk 4) if the 'WMM Policy' is set to anything other than 'Allowed' then you get another group of Mac's grumbling 5) I am pretty sure they grumble if you have AES enabled for WPA(1) Enterprise too; I'm not 100% convinced on this, it might be in part linked to WPA Enterprise and WPA2 Enterprise being enabled on the same SSID. Of course there is also the buggy cack if you do persuade a Mac to connect where you need to force the DHCP client ID to something (I use 'cheese' and pretend to the users that it's the only ID we have found that works...); otherwise the Mac disagrees with your DHCP server and decides it does not like the colour of *that* particular IP and wants another instead. I'm not really surprised by all this cruft, after four months awaiting for a reply from Apple on an endian bug in a DHCP packet they spit out, I have not heard anything back. Christ, that's just a htonl() fix too :( "This Network Monkey recommends liberal use of 'fire' to solve your problems". The list above I have worked out through trial and error over two years and found now the combination I'm now using means my exposure to Mac users is minimised...so that's my motivation.
"Improved compatibility with some EAP-TTLS clients that previously would have required EAPTTLS_NoAckRequired. Reported by Ian Forster."
coupled with
#This is added for Apple Macintosh Airport Extreme adapters EAPTTLS_NoAckRequired
suggests that something more is afoot.
This sounds vaguely more like session resumption stuff, but that's me guessing and pulling ideas out of my.... Cheers -- Alexander Clouter .sigmonster says: A penny saved is a penny to squander. -- Ambrose Bierce
Hi, thanks for the list I can confirm all of these issues. Also, if you have WPA/AES turned on, then the Mac wont touch the lovely WPA2/AES - ie it wont do 802.11n properly. if you reratify the wifi so you only do WPA/TKIP and WPA2/AES then the Mac is a _little_ happier I can also confirm the DHCP issu e- if you set the client ID then the Mac gets a DHCP address faster. not the speed expected...but faster. (we use ISC DHCPD and I've been looking for ANYTHING that will speed the Mac client up!) we've put in another Cisco TAC case regarding Apple kit. I blame cisco as much as apple (the apple stuff works in different ways on Trapeze and netgear APs) back onto topic: I've noticed RADIUS stuff on the Mac is quite sucky...it seems to go through PEAP or TTLS at least once too many times. almost like its ignoring a reply or 'having another go' - is this something engineered into the OS so they work better with Airports ? :-( alan
A.L.M.Buxey@lboro.ac.uk wrote:
thanks for the list
Not a problem.
I can confirm all of these issues. Also, if you have WPA/AES turned on, then the Mac wont touch the lovely WPA2/AES - ie it wont do 802.11n properly. if you reratify the wifi so you only do WPA/TKIP and WPA2/AES then the Mac is a _little_ happier
Cheers for this, I just turned off AES for WPA Enterprise this morning trying to further minimise my 'exposure' :)
I can also confirm the DHCP issu e- if you set the client ID then the Mac gets a DHCP address faster. not the speed expected...but faster. (we use ISC DHCPD and I've been looking for ANYTHING that will speed the Mac client up!)
Strange, our's connects *really* quickly with no problems with ISC DHCPD. What was the issue I found was more with the Cisco WLC controller and *any* DHCP client. You have to disable that ghastly DHCP Proxying rubbish and then be *very* careful, depending on your local 'topology', about how to specify your DHCP relay servers and enforcement policies related to those. This sort of stuff is not FreeRADIUS related and I'm happy to take this offlist; it bug work arounds for the WLC. Anyway, I just took a DHCP capture from both the Mac end and the two DHCP servers we run and it all looks okay: http://stuff.digriz.org.uk/mac-dhcp/ You might want to compare it to your captures and see if there is anything interesting.
we've put in another Cisco TAC case regarding Apple kit. I blame cisco as much as apple (the apple stuff works in different ways on Trapeze and netgear APs)
back onto topic: I've noticed RADIUS stuff on the Mac is quite sucky...it seems to go through PEAP or TTLS at least once too many times. almost like its ignoring a reply or 'having another go'
Got any packet captures of that or -X output spiel, I'll be interested to have a nosey (off list if need be[1])? This does sound like it's trying to automatically test the inner authentication type. For example, first tries CHAP and then PAP....I know the moment I enable CHAP here at SOAS that all the Mac users were able to automagically connect to the wireless network here without any priming (other than saying 'yeah, this cert is good).
- is this something engineered into the OS so they work better with Airports ? :-(
I think it's more down to the 'eco-system' that Apple have setup; and to be frank that's why they are so popular with the users. The combinations of 'stuff' is low and so managable and all really Apple have to do is test their kit with their own stuff and the users are generally happy with "sorry, it does not have an Apple badge on it". Cisco *obviously* do the same with their kit and only test their stuff really with Intel cards...it's what probably makes up 60% of the NIC's our there at an organisation (particular if you have Dell desktops without the ghastly Broadcom or Realtek cack). All (hardware|software) sucks...some just sucks less. Maybe it's time to crack out the Plan9 ISO again. Cheers [1] should this not be a JRS Support query ;) -- Alexander Clouter .sigmonster says: Causes moderate eye irritation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan,
thanks for the list
I can confirm all of these issues. Also, if you have WPA/AES turned on, then the Mac wont touch the lovely WPA2/AES I haven't seen this. We have WPA/WPA2 TKIP/AES, and the Mac appears to always pick WPA2. Unfortunately I don't know what cipher it's using, as the controller won't tell me, and they got rid of the airport utility in leopard (grrr).
If you can get some Beacon frames with your Cisco APs, I can send you some from our HP kit, see if there's anything obvious about the way it's advertising supported ciphers/ security standards.
- ie it wont do 802.11n properly. if you reratify the wifi so you only do WPA/TKIP and WPA2/AES then the Mac is a _little_ happier
I can also confirm the DHCP issu e- if you set the client ID then the Mac gets a DHCP address faster. not the speed expected...but faster. (we use ISC DHCPD and I've been looking for ANYTHING that will speed the Mac client up!) Packet traces.... You should be able to take these on the Mac with tcpdump or Wireshark. DHCP is a relatively easy protocol to debug; if there are issues, report them to Apple.
It might be something stupid like the event generated by the supplicant that prods the DHCP client into trying to get a lease, is generated when the supplicant gets an EAP-Success *not* when the 4-Way handshake completes. From my experience Macs usually try and renew their previous lease before requesting a new one, so this may add some additional latency.
we've put in another Cisco TAC case regarding Apple kit. I blame cisco as much as apple (the apple stuff works in different ways on Trapeze and netgear APs) Yes, i've found them to work more reliably on Trapeze. Mine was connecting fine using WPA2-Enterprise at NW to an Aruba 802.11n AP... hmm actually it did take a few 'Turn offs' 'Turn ons' to get an IP with those.... But then the Cambridge infrastructure seemed to be pretty sucky anyway.
With the ProCurve 530s we used to have, the Macs would sometimes go blind to all networks other than the one they were currently connected to. I.e. when you click the little wireless Icon, you'd only see the network you were connected to.
back onto topic: I've noticed RADIUS stuff on the Mac is quite sucky...it seems to go through PEAP or TTLS at least once too many times. almost like its ignoring a reply or 'having another go' - is this something engineered into the OS so they work better with Airports ? :-(
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one? We saw the 'having another go' issue, but it was due to a timer problem on our WESM (Wireless Edge Service Module). The WESM would send ST Nonce to the Mac, then restart authentication by sending an EAP-Identity-Request, it'd do this a ~13 times before letting the Mac respond with ST Nonce. This may not be a RADIUS issue at all. Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknbV84ACgkQcaklux5oVKIHqQCcCwLelr4pJ71c0JlkKU+Yf3uv 6wgAn2t7ww0+5nX6un73XfUP9DWaORYI =1hdq -----END PGP SIGNATURE-----
Hi,
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one?
as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX alan
I too have had weird behavior on macs. I just ended up using mac-address authentication (due to insecurities in EAP. (or possibly rumored, i havn't seen a paper on it yet)) On Tue, Apr 7, 2009 at 7:08 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one?
as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Random quote of the week/month/whenever i get to updating it: "Opportunity knocked. My doorman threw him out." - Adrienne Gusoff "At school you don't get parole, good behavior only brings a longer sentence." - The History Boys
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Bartell wrote:
I too have had weird behavior on macs. I just ended up using mac-address authentication (due to insecurities in EAP. (or possibly rumored, i havn't seen a paper on it yet)) Wait what... You went to Mac-Based authentication because you thought EAP was insecure ?
Ohh are you referring to the scaremongering 'The Register' was doing last year? Because of course, anyone with a hacked copy of FreeRADIUS can steal all your users credentials !
On Tue, Apr 7, 2009 at 7:08 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one? as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknbbVAACgkQcaklux5oVKI4EwCgkRjarq9VkbO5HS3BNGugSU6D 1vUAniLDBrvpkluK/EpMpreAb5w/vPvL =87NT -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
Ohh are you referring to the scaremongering 'The Register' was doing last year? Because of course, anyone with a hacked copy of FreeRADIUS can steal all your users credentials !
Unfortunately, people read his column, and believe him. They might also believe that he actually writes his own material. Alan DeKok.
I'm aware of an attack on a bank which had implemented EAP, and had fun when a Pen tester was simply getting domain login credentials without having to work much at all. Could you maybe provide a rebuttal for this attack? and/or explain how to make it especially secure? On Tue, Apr 7, 2009 at 8:28 AM, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
Ohh are you referring to the scaremongering 'The Register' was doing last year? Because of course, anyone with a hacked copy of FreeRADIUS can steal all your users credentials !
Unfortunately, people read his column, and believe him. They might also believe that he actually writes his own material.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Random quote of the week/month/whenever i get to updating it: "Opportunity knocked. My doorman threw him out." - Adrienne Gusoff "At school you don't get parole, good behavior only brings a longer sentence." - The History Boys
Paul Bartell <paul.bartell@gmail.com> wrote:
I'm aware of an attack on a bank which had implemented EAP, and had fun when a Pen tester was simply getting domain login credentials without having to work much at all.
Could you maybe provide a rebuttal for this attack? and/or explain how to make it especially secure?
Think of EAP like HTTP...a transport medium. PEAP/TTLS is EAP's version of SSL...would you expect a bank to use a valid certificate on their online banking page? Same thing, 100% the same thing. Network administrators, whilst generally in the mood "lets get this pesky thing working and fix the 101 other problems I have", easily forget: 1) if you do not force the root CA to a single registrar you can go to *any* registrar (you can use a self-signed one) and make sure the subject field in the certificate matches what the client is expecting (if anything) to leech user credentials 2) if no forced subject field match is made[1], then as long as you get a certificate signed by the marked registrar in (1), if you did indeed specify one, then you can leech user credentials If you miss either of these two, you might as well slap all your users credentials on your organisations website in a textfile for folk to download. This (vaguely) works transparently for web browsers as they have a stash of root CA's[2] to call upon and those registrars supposedly[3] verify and check that you are legit and there are no duplicates....the web browser then checks whatever is in the address bar. With EAP you have to tell it what to expect in it's "address bar", this is why you have to specify the FQDN of the server. Actually, the whole SSL/TLS thing is horribly broken and we should just dump it...I'm not bright enough to suggest something better though :) Cheers [1] dear god, do not ever use wildcarded certificates, for it will be your 'crime and your punishment' [2] of course we all handle certificate revocations don't we? [3] http://www.amug.org/~glguerin/opinion/revocation.html http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ -- Alexander Clouter .sigmonster says: /earth is 98% full ... please delete anyone you can.
Paul Bartell wrote:
I'm aware of an attack on a bank which had implemented EAP, and had fun when a Pen tester was simply getting domain login credentials without having to work much at all.
Could you maybe provide a rebuttal for this attack? and/or explain how to make it especially secure?
You say there's an attack. Great... what is it? Someone got domain login credentials... how? Alan DeKok.
Right. Its better to give crackers less information versus more. so others do not get login credentials. Though, if certificates were properly implemented, there would be mutual authentication On Tue, Apr 7, 2009 at 8:12 AM, Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Bartell wrote:
I too have had weird behavior on macs. I just ended up using mac-address authentication (due to insecurities in EAP. (or possibly rumored, i havn't seen a paper on it yet)) Wait what... You went to Mac-Based authentication because you thought EAP was insecure ?
Ohh are you referring to the scaremongering 'The Register' was doing last year? Because of course, anyone with a hacked copy of FreeRADIUS can steal all your users credentials !
On Tue, Apr 7, 2009 at 7:08 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one? as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknbbVAACgkQcaklux5oVKI4EwCgkRjarq9VkbO5HS3BNGugSU6D 1vUAniLDBrvpkluK/EpMpreAb5w/vPvL =87NT -----END PGP SIGNATURE-----
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Random quote of the week/month/whenever i get to updating it: "Opportunity knocked. My doorman threw him out." - Adrienne Gusoff "At school you don't get parole, good behavior only brings a longer sentence." - The History Boys
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Bartell wrote:
Right. Its better to give crackers less information versus more. so others do not get login credentials. Though, if certificates were properly implemented, there would be mutual authentication
Exactly. The only attacks I know of that can be easily implemented rely on administrator/user ignorance/stupidity. For example some administrators tell users to explicitly uncheck the 'Validate Server Certificate' check box in their supplicants (i've actually seen this in eduroam documentation *shudder*). The result (depending on the EAP method used) is that when an attacker comes along with an AP broadcasting the same SSID as trusted wireless infrastructure, users (or their supplicant software) hand credentials over no questions asked. With PEAPv0, the inner method (MsCHAPv2) is insecure which is why it's wrapped in a TLS tunnel. If you strip off the TLS tunnel MsCHAPv2 becomes trivial to break. EAP itself is not insecure, but is susceptible to exactly the same kind 'phishing' attacks used with other methods that rely a user entering a userid and password (possibly more so as many supplicants will cache credentials). Arran
On Tue, Apr 7, 2009 at 8:12 AM, Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote: Paul Bartell wrote:
I too have had weird behavior on macs. I just ended up using mac-address authentication (due to insecurities in EAP. (or possibly rumored, i havn't seen a paper on it yet)) Wait what... You went to Mac-Based authentication because you thought EAP was insecure ?
Ohh are you referring to the scaremongering 'The Register' was doing last year? Because of course, anyone with a hacked copy of FreeRADIUS can steal all your users credentials !
On Tue, Apr 7, 2009 at 7:08 AM, <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one? as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkneX+UACgkQcaklux5oVKInpgCeJ1zXDxSXmHhSi/gYyuVI/JkO fkUAn0wrgrRFZH+2i3YJtGUI5dBbyTHx =/r0T -----END PGP SIGNATURE-----
Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
Paul Bartell wrote:
Right. Its better to give crackers less information versus more. so others do not get login credentials. Though, if certificates were properly implemented, there would be mutual authentication
Exactly. The only attacks I know of that can be easily implemented rely on administrator/user ignorance/stupidity.
For example some administrators tell users to explicitly uncheck the 'Validate Server Certificate' check box in their supplicants (i've actually seen this in eduroam documentation *shudder*). The result (depending on the EAP method used) is that when an attacker comes along with an AP broadcasting the same SSID as trusted wireless infrastructure, users (or their supplicant software) hand credentials over no questions asked.
Yeah, do a suitable[1] Google hack against 'ac.uk' and I wish we drank a lot more beer at Networkshop. Sigh. :-/ [1] I'll leave it as an exercise to the reader to work out how to build their own 'suitable' query -- Alexander Clouter .sigmonster says: You are as I am with You.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Clouter wrote:
Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
Paul Bartell wrote:
Right. Its better to give crackers less information versus more. so others do not get login credentials. Though, if certificates were properly implemented, there would be mutual authentication Exactly. The only attacks I know of that can be easily implemented rely on administrator/user ignorance/stupidity.
For example some administrators tell users to explicitly uncheck the 'Validate Server Certificate' check box in their supplicants (i've actually seen this in eduroam documentation *shudder*). The result (depending on the EAP method used) is that when an attacker comes along with an AP broadcasting the same SSID as trusted wireless infrastructure, users (or their supplicant software) hand credentials over no questions asked.
Yeah, do a suitable[1] Google hack against 'ac.uk' and I wish we drank a lot more beer at Networkshop.
Sigh. :-/ Plymouth, LSE and Exeter are all examples of this. In fact idiot proof examples are hard to come by.
This is our offering: https://wwwnew.sussex.ac.uk/roaming/mod/doc_pages/index.php?doc=setup_guide.... With Windows 2K/XP/Vista, supplicant settings are configured on a per SSID basis, so should be locked down to a organisational CAs and specific certificate CNs. We tell users to check the 'Do not prompt user to authorize new servers or trusted certification authorities' for just that reason. Never underestimate the desperation or blind stupidity of a student craving a facebook fix. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkneguQACgkQcaklux5oVKJR3gCeK8fakVEfR6+QsjCGjnscrkFx 5YoAniSNy5g8F3Q0S5SXyd5FGWB0TZYS =WiPo -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Have you actually traced the wireless traffic (passively), are you sure it's the Macs at fault with this one?
as everything works fine on the same Mac when it runs Vista (yes, I know...) and works all okay on random PCs and PDAs/smartphones..the big greasy pointy finger is pointing decidedly at the OSX
Well no, that just points to an incompatibility with the Mac broadcom drivers and/ or Mac OSX supplicant and the Cisco APs you're using. It doesn't mean that the Macs are at fault. I'm sitting here quite happily connected to an AP broadcasting 4 BSIDs, with two radios (a) & (b/g), running WPA/2-Enterprise with TKIP/AES, authenticated with FreeRADIUS 2.0.6 using EAP-TTLS-PAP with an anonymous outer identity. I went over to the cafe earlier to get a muffin; once I had acquired said Muffin, I sat down by a nice sunny window, opened up my MBP and had a network connection within 10 seconds. After reading XKCD and consuming muffiny goodness I came back to engg1, opened my MBP and woo network connection. Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknbcOEACgkQcaklux5oVKI81wCePQfQfuQ6/qVEK4P2eVcLIzcP FWIAnRXEPkY4kCpig3yttf21y88Nmcks =hNHu -----END PGP SIGNATURE-----
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
ac221 -
Alan DeKok -
Alexander Clouter -
Arran Cudbard-Bell
-
Paul Bartell