WPA needs SSID broadcast?

[Jurgen Kramer]

I finally moved my wireless connection from WEP128 to WPA-PSK now that
NetworkManager supports it out-of-the-box in FC5. Although WPA works, it
only does so when a enable SSID broadcasting. Is this normal for WPA?
I'd really like to disable SSID broadcasting again.

This is with my laptop with a Intel IPW2200 and a Netgear DG834G
wireless router. I've also seen the same behavior when I tried using WPA
with a US Robotics router.

Jurgen

[Andy Green]

Jurgen Kramer wrote:
>  I finally moved my wireless connection from WEP128 to WPA-PSK now
> that
>  NetworkManager supports it out-of-the-box in FC5. Although WPA works, it
>  only does so when a enable SSID broadcasting. Is this normal for WPA?
>  I'd really like to disable SSID broadcasting again.
>  
>  This is with my laptop with a Intel IPW2200 and a Netgear DG834G
>  wireless router. I've also seen the same behavior when I tried using WPA
>  with a US Robotics router. 
wpa_supplicant is new to me, but I noticed wpa_passphrase eats the ssid 
along with the PSK to generate the magic key.  Maybe try to regenerate 
this with a null ssid in wpa_passphrase and see if it is happier with no 
incoming ssid.

-Andy

[Michael H. Warfield]

On Thu, 2006-04-27 at 21:21 +0200, Jurgen Kramer wrote:
>  I finally moved my wireless connection from WEP128 to WPA-PSK now
> that
>  NetworkManager supports it out-of-the-box in FC5. Although WPA works, it
>  only does so when a enable SSID broadcasting. Is this normal for WPA?
>  I'd really like to disable SSID broadcasting again. 
	I can't speak to what NetworkManager does or doesn't do.  I don't use
it and don't care for it.  I have noticed with wpa-supplicant, which
NetworkManager uses, that I have needed to specify the expected SSID in
advance in the ifcfg-{device} file for some networks.  I presumed that's
because of the SSID broadcast, or lack thereof.  If I don't specify the
SSID in advance, wpa-supplicant will grab whatever network is
broadcasting an SSID that it knows about.  If it can't see that
broadcast poll, then it won't see the network is there to try and
configure against it, and there you are.  Preconfiguring an SSID in the
WLAN card setup before firing up wpa-supplicate does seem to get around
that.

	Couple of points...

	* WPA-PSK...  I hope you configured a REALLY strong WPA-PSK password.
For even respectable passwords (less than 20 characters) WPA-PSK may be
easier to break than WEP128.  An attacker only has to capture 4 packets
for WPA-PSK (as opposed to a half a million or so for a reasonable
WEP128 crack using aircrack or such) and they can then do an off-line
brute force attack on the PSK.

	Robert Moskowitz, Senior Technical Director of ICSA Labs wrote this
back in late 2003:

	http://wifinetnews.com/archives/002452.html

>  A passphrase typically has about 2.5 bits of security per character,
>  so the passphrase of n bytes equates to a key with about 2.5n + 12
>  bits of security. Hence, it provides a relatively low level of
>  security, with keys generated from short passwords subject to
>  dictionary attack. Use of the key hash is recommended only where it is
>  impractical to make use of a stronger form of user authentication. A
>  key generated from a passphrase of less than about 20 characters is
>  unlikely to deter attacks.
>  
>  The PTK is used in the 4-Way handshake to produce a hash of the
>  frames. There is a long history of offline dictionary attacks against
>  hashes. Any of these programs can be altered to use the information in
>  the 4-Way Handshake as input to perform the offline attack. Just about
>  any 8-character string a user may select will be in the dictionary. As
>  the standard states, passphrases longer than 20 characters are needed
>  to start deterring attacks. This is considerably longer than most
>  people will be willing to use.
>  
>  This offline attack should be easier to execute than the WEP attacks. 

	Since you can "force" and active connection to an AP to
"disassociate",
you can force the client to reauthenticate so it's really easy to get
those first 4 packets of the WPA-PSK authentication.


	* SSID broadcast.  Why worry about not broadcasting the SSID?  Turning
off SSID broadcast is of no benefit, security wise.  Kismet and other,
similar, tools readily "decloak" networks which don't broadcast SSID, so
you're not hiding much (you're not hiding ANYTHING, in fact).  I've
heard the argument that broadcasting the SSID is like having a welcome,
open to the public, sign out front and not broadcasting is indicating
that this is not a "public" access point.  That argument only goes so
far, though.  The fact that you are encrypted is argument enough that it
is not a "open" access point, for those who do not have the key.

	The other argument (and this goes both ways) is that not broadcasting
the SSID removes that AP from the network list of "available" networks
(say in Windows WiFi available networks list).  Ok...  Then you have to
explicitly specify the SSID to being with.  So, that relates back to
your original question.  Do you want your connections to your AP to
autoconfigure or not?  That's your choice to make.

>  This is with my laptop with a Intel IPW2200 and a Netgear DG834G
>  wireless router. I've also seen the same behavior when I tried using WPA
>  with a US Robotics router.
>  
>  Jurgen 
	Mike
-- 
Michael H. Warfield (AI4NB) | [phone] |  mhw(a)WittsEnd.com
   /\/\|=mhw=|\/\/          | [phone] |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

[Jurgen Kramer]

On Thu, 2006-04-27 at 15:54 -0400, Michael H. Warfield wrote:
>  On Thu, 2006-04-27 at 21:21 +0200, Jurgen Kramer wrote:
>  > I finally moved my wireless connection from WEP128 to WPA-PSK now that
>  > NetworkManager supports it out-of-the-box in FC5. Although WPA works, it
>  > only does so when a enable SSID broadcasting. Is this normal for WPA?
>  > I'd really like to disable SSID broadcasting again.
>  
>  	I can't speak to what NetworkManager does or doesn't do.  I don't use
>  it and don't care for it.  I have noticed with wpa-supplicant, which
>  NetworkManager uses, that I have needed to specify the expected SSID in
>  advance in the ifcfg-{device} file for some networks.  I presumed that's
>  because of the SSID broadcast, or lack thereof.  If I don't specify the
>  SSID in advance, wpa-supplicant will grab whatever network is
>  broadcasting an SSID that it knows about.  If it can't see that
>  broadcast poll, then it won't see the network is there to try and
>  configure against it, and there you are.  Preconfiguring an SSID in the
>  WLAN card setup before firing up wpa-supplicate does seem to get around
>  that.
>  
>  	Couple of points...
>  
>  	* WPA-PSK...  I hope you configured a REALLY strong WPA-PSK password.
>  For even respectable passwords (less than 20 characters) WPA-PSK may be
>  easier to break than WEP128.  An attacker only has to capture 4 packets
>  for WPA-PSK (as opposed to a half a million or so for a reasonable
>  WEP128 crack using aircrack or such) and they can then do an off-line
>  brute force attack on the PSK.
>  
>  	Robert Moskowitz, Senior Technical Director of ICSA Labs wrote this
>  back in late 2003:
>  
>  	http://wifinetnews.com/archives/002452.html
>  
>  > A passphrase typically has about 2.5 bits of security per character,
>  > so the passphrase of n bytes equates to a key with about 2.5n + 12
>  > bits of security. Hence, it provides a relatively low level of
>  > security, with keys generated from short passwords subject to
>  > dictionary attack. Use of the key hash is recommended only where it is
>  > impractical to make use of a stronger form of user authentication. A
>  > key generated from a passphrase of less than about 20 characters is
>  > unlikely to deter attacks.
>  > 
>  > The PTK is used in the 4-Way handshake to produce a hash of the
>  > frames. There is a long history of offline dictionary attacks against
>  > hashes. Any of these programs can be altered to use the information in
>  > the 4-Way Handshake as input to perform the offline attack. Just about
>  > any 8-character string a user may select will be in the dictionary. As
>  > the standard states, passphrases longer than 20 characters are needed
>  > to start deterring attacks. This is considerably longer than most
>  > people will be willing to use.
>  > 
>  > This offline attack should be easier to execute than the WEP attacks.
>  
>  
>  	Since you can "force" and active connection to an AP to
> "disassociate",
>  you can force the client to reauthenticate so it's really easy to get
>  those first 4 packets of the WPA-PSK authentication.
>  
>  
>  	* SSID broadcast.  Why worry about not broadcasting the SSID?  Turning
>  off SSID broadcast is of no benefit, security wise.  Kismet and other,
>  similar, tools readily "decloak" networks which don't broadcast SSID, so
>  you're not hiding much (you're not hiding ANYTHING, in fact).  I've
>  heard the argument that broadcasting the SSID is like having a welcome,
>  open to the public, sign out front and not broadcasting is indicating
>  that this is not a "public" access point.  That argument only goes so
>  far, though.  The fact that you are encrypted is argument enough that it
>  is not a "open" access point, for those who do not have the key.
>  
>  	The other argument (and this goes both ways) is that not broadcasting
>  the SSID removes that AP from the network list of "available" networks
>  (say in Windows WiFi available networks list).  Ok...  Then you have to
>  explicitly specify the SSID to being with.  So, that relates back to
>  your original question.  Do you want your connections to your AP to
>  autoconfigure or not?  That's your choice to make.
>  
>  > This is with my laptop with a Intel IPW2200 and a Netgear DG834G
>  > wireless router. I've also seen the same behavior when I tried using WPA
>  > with a US Robotics router.
>  > 
>  > Jurgen 
Thanks for the insight, I will lengthen my WPA password a bit. WPA2
would probably the better option but it seem it is not supported yet?

Jurgen

>  	Mike
>  -- 
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

[Ingemar Nilsson]

Jurgen Kramer <gtm.kramer(a)inter.nl.net&gt; writes:

>  Thanks for the insight, I will lengthen my WPA password a bit. WPA2
>  would probably the better option but it seem it is not supported yet? 
By what? I use WPA2 at home with a >20 character password, and it works
fine. The only exception is that NetworkManager in FC4 (which is what I
have on my laptop) does not seem to support (any) WPA.

Since I have written a wpa_supplicant config file, starting it manually
isn't that much of a hassle though.

Regards
Ingemar

[Klaasjan Brand]

On 4/27/06, Jurgen Kramer <gtm.kramer(a)inter.nl.net&gt; wrote:
>  I finally moved my wireless connection from WEP128 to WPA-PSK now that
>  NetworkManager supports it out-of-the-box in FC5. Although WPA works, it
>  only does so when a enable SSID broadcasting. Is this normal for WPA?
>  I'd really like to disable SSID broadcasting again. 

There's an updated version of NetworkManager in the "testing" repository
with release notes claiming some WPA bugs were fixed.
It's probably waiting for a few brave souls to try it out to see if nothing
breaks ;).

Kj