You really think the guy behind hotgritsnatalyportmanphotos.org is trustworthy?

While you're right this was very negligent for a project of the stature and importance of openssl, merely discovering this bug in closed source software would have required a fuzzer and much luck, leaving it unfixed for whoever had managed to get a a copy of the source to exploit for much longer.

All I can say personally is I sure picked the right two years to get lazy about patching up.

Basically it means if you know any UNIX sysadmins, they'll be pretty cranky for the next week or so as they've been busy trying to put the poop back in the baby.

Oh yeah, and lots of your gadgets and favorite cloud services may be vulnerable, so anything stored on them may be in the hands of others.

Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.

Though the leading edge of development of end-user level UI for firewalls is on embedded projects like OpenWRT, firewall builder definitely deserves a look. It's close to many of the tools targeted at small-network administrators, like Cisco's ASDM for their ASA product. It may take a short time to learn about service objects and network objects, but that time will be payed back many times over.

The biggest issue an end-user will face with it is setting up the backends as it is less than totally flexible in that department (it has a particular deployment model in mind and is missing a couple hooks in certain places that prevent it from being used for certain purposes.) That said, it is very capable of allowing one to change backends easily (e.g. switch from one brand of firewall to another) with minimal adjustments.

You don't have to have an especially powerful signal to be able to see other devices. The occasional lucky packet will bounce around "just right" and leak through enough to see the device. So if GP said he didn't see many devices, it's because there just plain weren't many devices.

That said, even with the cheap vendors not putting dual-band in their crap devices, we're seeing a good number of devices in our dorms that are 5GHz capable. Enough to improve life significantly for everyone still stuck on 2.4GHz. Unfortunately many of them are Apples and they manage to turn this advantage into a liability because their drivers stick their heads up their own asses the minute they find AP using the same SSID on both 2.4 and 5, so they spend most of their time roaming between APs every two or three minutes and torturing their users with bad performance during roams. Supposedly OSX 10.9.2 helps undo some of this damage.

Last time I looked RTF (decade or so ago) was a pretty bare-bones least-common-denominator document markup specification.

Depends on your security requirements. Most OSes trust anything in the OS default trsuted CAs which includes most major CAs. If you're satisfied with the integrity of all the CAs in that list, you can buy a RADIUS server-side cert form them and the clients will trust it.

The problem comes in making sure the self-service user checks the box to perform the validation and also types in the expected owner name. By default most OSes do not validate this information so anyone with a stolen priate key from a CA-certified website can pose as your RADIUS server.

Now, for most OSes other than Android, this vulnerability only exists the first time a user connects to the network (or again whenever they delete the network manually) because the OS then takes the certificate it found and assumes it valid, but then will not accept any other certificate.

Android is a total slut about this and never validates, and the phone would have to be rooted just to be able to turn on validation. Word has it the newest version at least contains hooks that would allow a supplicant configurator to turn on validation, but I have yet to see an android that lets me type in an owner name. When even Apple is doing a better job at security than you, hang your head in shame.

You;re half right, but EAP-TLS doesn't have a password/account component, just the cert, so you are missing an authentication factor. If you're going through the trouble of actually making sure clients are running a secure supplicant to the point of making users add a client cert and a local CA trustpoint, just secure the settings on the TTLS/PEAP client and ban OSes like android that don't validate. Turn on verification of the client-side cert if you like, too.

MAC filtering should only be used as a herd immunity measure: people who don't update their AV are less likely to find it easier to spoof an existing MAC address than they find it to register in a captive portal and download their updates before they are allowed in.

Try to have an effective browsing experience with port 80 blocked.

Try "it keeps people from injecting exploits into your computer by impersonating web servers." Be glad you enabled it.

Can't tell what exactly the paper is about due to a paywall and the fact that the article was written by someone not very techincal.

EAP-TTLS, as long as you are validating the server certificate, is pretty safe. Safer with a locally managed CA and installed client cert, but at least as safe as the web browsing you'll be doing on it after connecting anyway. The safety advantage to WPA-Enterprise over WPA-PSK is mainly due to the fact that you don't have to distribute the same easily-cloned PSK to every client. In addition, if installing and validating client certificates (not the usual mode for EAP-TTLS) they can be locked to specific user accounts. For keeping out the riff-raff they can be locked to MAC addresses as well but that only serves to ban the amateurs.

Bad guess