David
Thanks for that I found it more succinct and insightful than what I had gleaned from generalized stuff, in the past. I found a reasonable overview article on WEP cracking, written in 2005 updated 2008 - by some guy (Peter Welcher) on an odd site called Chesapeake Webcraftsmen: How <http://www.netcraftsmen.net/resources/archived-articles/578-how-secure-is-w ep-anyway.html> Secure is WEP, Anyway? Now I can sniff the security of all my neighbours. _____ Ian Thomas Victoria Park, Western Australia _____ From: [email protected] [mailto:[email protected]] On Behalf Of David Connors Sent: Friday, November 12, 2010 8:11 AM To: ozDotNet Subject: Re: [OT] HTTPS and Email So putting all questions about likelihood and so on aside, WEP is not very secure. It has been half a decade since I looked at WEP but briefly from memory: 1. WEP was developed in private without peer review. As is almost always the case, this leads to implementation errors that allow you to find stuff using cryptoanalysis. 2. Real-time decryption of WEP relied on, I think, key information exposed in certain events on the RF. You could use that to work out the key and then decrypt traffic. 3. Yes, you can decrypt WEP-secured traffic in real-time, plenty of how-tos out there and I'm surprised that is not in firesheep (but I think the author and the press just discovered packet sniffing so we might have to wait a while for real-time WEP ecryption). Whether anyone does is a different matter. Not all variants of WPA are created equal - initial versions of WPA+TKIP used a message integrity check algorithm called Michael. As I understand it, the algorithm was specifically designed so that it could fit within the same memory/CPU/etc constraints as WEP and so theoretically be implemented on older hardware by way of firmware upgrade. This led to an interesting problem with the Cisco kit we use at the Microsoft events where, back in the day, staff wifi utilise a shared key and WPA+TKIP. Part of WPA+TKIP specifies that if the Michael message integrity check fails then the remote station is trying to haxor you. IOS implement a 'countermeasures' feature where the client is then banned from talking to the base station for a period of time (60 seconds normally but you can change it) before being allowed to re-associate. This is designed to stop the remote station fishing for data to do cryptoanalysis and work out the shared key. The issue is that as sure as the sun comes up Intel cannot write wifi drivers - so their drivers (used in every Dell/Lenovo/etc ergo used by every MS FTE) would corrupt the MIC randomly and so the APs would think they're under attack and boot that particular client for 60 seconds. The moral of that story I guess is that, while people can have the best of intentions, having a half-arsed set of requirements is never a good starting point if you're going to implement a new encryption algorithm. The correct advice should probably have been that everyone drop their WEP-capable APs in the nearest bin and get new ones. For pre-shared key wifi scenarios (which is almost always the case for small business and home scenarios), you want to use WPA2-Personal with AES/CCMP encryption. As of writing this and not-withstanding the obviously limitations of a shared key scheme, I believe that it is secure. Enterprises will or should always use an asymmetric encryption scheme with smart cards or soft certs etc. Also, to reiterate, all of the problems with Firesheep represents a failure to understand the very basics of encryption and the secure attribute in cookies on the part of Facebook etc. They should be pilloried for that, in my opinion. Open wifi just provides an attractive nugget for the press to grab on to, but remember that wired traffic is almost always in the clear at the transport layer. Someone who was sufficiently clever could make a Firesheep/ADSL analyser thingo to put in the Telstra pit outside your house and do the same thing. David. On 12 November 2010 09:41, Ian Thomas <[email protected]> wrote: David, that reminds me of something peripheral that has always puzzled me how insecure is WEP as opposed to WPA-xxx? Your remark was about unencrypted wifi (café wifi, etc), I realise. _____ Ian Thomas Victoria Park, Western Australia _____ From: [email protected] [mailto:[email protected]] On Behalf Of David Connors Sent: Friday, November 12, 2010 7:12 AM To: ozDotNet Subject: Re: [OT] HTTPS and Email On 12 November 2010 09:04, Bec Carter <[email protected]> wrote: Just signed up with a new web hosting company and noticed the web-based email doesn't have https.....so my login and password get passed in clear text. Is this normal procedure or should I be worried? "It depends" on your appetite for risk. The essential attack vector for grabbing your credentials or cookie is either over unencrypted wifi or by sniffing wired network traffic. Both have always been a risk but you'd think the issue arose yesterday with the amount of press that firesheep is getting. If you use unencrypted wifi a lot then it is probably an issue. Man-in-the-middle attacks on wired networks are not really practical in modern switched networks unless it is an inside job. People still send a pant load of stuff 'in the clear' over wired networks (i.e. even if you protect your e-mail web UI with HTTPS, the e-mail itself is still largely send between providers in the clear). That aside, I'd just ditch your web host e-mail and go with Google Apps or whatever the latest Live/Hotmail offering is. Google Apps has been on the SSL bandwagon for a couple of years now and is not susceptible to traffic sniffing attacks. I think Live/Hotmail just announced a complete implementation of SSL a week or so ago. Web host e-mail and calendaring is generally pretty lame and unreliable anyway. David. -- David Connors | <mailto:[email protected]> [email protected] | <http://www.codify.com> www.codify.com Software Engineer Codify Pty Ltd Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417 189 363 V-Card: <https://www.codify.com/cards/davidconnors> https://www.codify.com/cards/davidconnors Address Info: <https://www.codify.com/contact> https://www.codify.com/contact -- David Connors | <mailto:[email protected]> [email protected] | <http://www.codify.com> www.codify.com Software Engineer Codify Pty Ltd Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417 189 363 V-Card: <https://www.codify.com/cards/davidconnors> https://www.codify.com/cards/davidconnors Address Info: <https://www.codify.com/contact> https://www.codify.com/contact _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3249 - Release Date: 11/10/10
