This redirect does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||
|
The contents of the Wireless LAN security page were merged into Wireless security on November 7, 2011 and it now redirects there. For the contribution history and old versions of the merged article please see its history. |
I added the cleanup-tag just because I don't have enough confidence in the work I've done here. I'd appreciate if somebody looked through this article and removed the cleanup-tag :-) tobixen 16:22, 31 March 2006 (UTC)
IMHO, the information under Solutions header is how-to. How-to does not belong to WP. Raanoo 18:04, 14 August 2006 (UTC)
i'd like to comment on the recent back and forth about legal responsibilities of the AP owner, I know in the US this is still an issue of some debate but my lawyers tell me that you're probably protected by the same laws that protect your ISP...and while im sure that the laws will vary from country to country I find it hard to believe that in the entire EU the law is the same (surely such a topic was not deemed important enough to make its way into the EU constitution?)...can we get someone who is a lawyer to speak on this subject, because, as with all security topics, such information is always of interest --Michael Lynn 20:15, 27 March 2007 (UTC)
some of the more recent edits regarding ediquete of open vs closed aps doesnt seem to be taking a neutral point of view, i think this should either be removed, or it should be balanced well (my vote is that it simply be removed)... --Michael Lynn 22:50, 13 April 2007 (UTC)
Reading Wireless security makes me doubt the wisdom of merging this into that. This present article has little to add to that one, which is already a good thorough introduction for workers who manage a big corporate LAN and wish to learn how to secure it. This one is smaller and not so narrowly focused, so it only partly duplicates that one. I do not propose to keep it going forever, but propose to delete the parts that rightly belong in the more advanced article. Then move this one into Access point or Home network or other appropriate article, as a Security section supplying information appropriate to a reader who uses a home router to share a DSL or other home Internet connection and wants an elementary understanding of how and whether to control access. Anybody agree that the present merge flag ought to be taken down? Or disagree? Jim.henderson 03:26, 19 June 2007 (UTC). I'd agree that they should be merged, and suggest that the name of the other one be changed to Wireless LAN security. LittleBen (talk) 23:01, 14 March 2009 (UTC)
I need some help with this. I'm unsure who authored this; it may have been someone who doesn't speak English as their first language. The section doesn't read well and I'm unclear on what the section is trying to say.
The disadvantage with this approach is that it can be difficult to cover all the traffic with encryption on the router level, or VPN, it's just one switch to get all traffic encrypted (even UDP and DNS lookups), while with end-to-end encryption, one has to "turn on encryption" for each and every service one wants to use, and quite often also for each and every connection. For sending emails, all the recipients must support the encryption and keys have to be exchanged. For web, not all web sites offer https - and even if using end-to-end-encryption on everything, the IP addresses you communicate with will go in clear text.
.
The ambiguity starts right away..."disadvantage" to what approach? Layer three or lower encryption or layer seven encryption? E_dog95' Hi ' 00:24, 14 November 2007 (UTC)
The disadvantage with the end to end method is, it may fail to cover all traffic. With encryption on the router level or VPN, a single switch encrypts all traffic, even UDP and DNS lookups. With end-to-end encryption on the other hand, each service to be secured must have its encryption "turned on," and often every connection must also be "turned on" separately. For sending emails, every recipient must support the encryption method, and must exchange keys correctly. For Web, not all web sites offer https, and even if they do, the browser sends out IP addresses in clear text.
I'm going to improve the references for this article as there are none. I'm going to do so by converting the external links.
I just don't think this was a good time to add non inline material to support the article. It doesn't need that. If you truly think these books are finer material than the external links provided, source them. I believe their usefulness here is limited otherwise.
This is especially true for an article that has ((Original research|article|date=December 2007)) placed on it.