Yeah, to say that "standards don't keep up with technological progress" is a one-sided perspective, since technology doesn't keep up with standards. If it did, I'd be more of a coder and less of an implementer, because 80% of my time is papering over standards noncompliance in vendor equipment.
Better to say implementors and standards bodies don't coordinate like they should.
First of all, science is trying to better understand the world, by making models predicting something. It isn't engineering.
Engineers don't just apply known science, they deal with the parts of the system that aren't obeying the textbook rules and find places to look for new phenomena in the process. To do so they analyse behavior and build models that predict the tolerances needed to get things working with a high degree of confidence. The difference is they don't go off on tangents because they have an objective, but engineers are often the initial discoverers of phenomena. It usually takes a pure scientist to then go in to spend the time explain more precisely why they had to make the tweaks they did, but there is plenty of overlap and there are plenty of people you cannot put into one category or another.
most of the basic ideas in (mechanical) engineering are pretty much settled since Newton got hit by the apple
Um, no, mechanical engineering has more to deal with now than they did then, because materials science and nanotech are increasingly important components.
I don't know where you get your ideas about the engineering disciplines. They pretty much all have frontiers.
Again, I am not supporting or disclaiming Horgan's thesis, but I am suggesting that it is an interesting topic worthy of discussion.
It's a worn out thesis echoed many times over by the occasional erudite edlder for some physchological reasons that will perhaps never be fully understood, even by said erudite elders.
If you want an interesting discussion along these lines, it's much more interesting to discuss how educational techinique could be improved to bring people up to speed faster, given the amount of knowlege needed to make an impact is arguably higher but we obviously haven't managed to figure out how to teach faster. Or how we are starting to get culturally desensitized to discoveries that actually would be ground shaking back in the day. Or how emergent behaviors have suddenly made new areas of math not formerly considered worthy of the title of "science" much more pertinent, and after all, physicists were really doing just math to explain observations back when they made their Nobel winning discoveries.
I don't think so in this case. I normally would have waited on the firehose for a submission with a better writeup, but this was relatively urgent news so I upvoted it anyway.
(Yes someone did understand you weren't talking about the potential intentionality of the bug, don't despair there are people capable of comprehension out there and you may even meet one face to face someday:-)
There may seem to be more now because there is more auditing going on since the NSA revelations reminded people what had to be done, and also the slower trend of case law starting to punish mishandling of customer data. The halcyon days are over and the backlog is being cleared up.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory.
My computer is too busy calculating an MD5 in a managed memory VM that doesn't even have an unsigned or sized integer types and thus must perform basic left barrel roll operations in about 50 opcodes worth of abstraction container dereferencing, to allow me to respond to this post appropriately.
For sshd there was possibly some protection afforded by the privilege separation model. I'd store your old keys and wait to see something from someone who knows it cold.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.
I predict a lot more interest in turning on CRL pathways in the future.
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.
But AFAIK, there is no preloaded CA for EAP. You install only the CA of your organization, which narrows the opportunities to have a valid certificate.
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.
In my view EAP-TLS with mutual certificate authentication is still the most secure authentication option available.
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.
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.
It's not quite clear what the 97.25% figure actually means. They trained it on just 4000 faces. What number of faces they tested it on to derive that figure is not stated. It's a lot easier to be accurate within a smaller set than a larger set. Of course other intelligence could be used to prune the list of candidates down for some usage scenarios.
Every good engineer I know, software or otherwise, can't resist learning how the next new shiny works
There are too many next new shiny things for any one person to figure out how they all work. A good engineer has to have either instinct or guidance so they don't invest time in doomed flash-in-the-pan technologies so they can use the time more productively. Especially since a good engineer is already spending most of their time actually working their current assignments on top of learning new things.
Slashdot Mirror
Yeah, to say that "standards don't keep up with technological progress" is a one-sided perspective, since technology doesn't keep up with standards. If it did, I'd be more of a coder and less of an implementer, because 80% of my time is papering over standards noncompliance in vendor equipment.
Better to say implementors and standards bodies don't coordinate like they should.
First of all, science is trying to better understand the world, by making models predicting something. It isn't engineering.
Engineers don't just apply known science, they deal with the parts of the system that aren't obeying the textbook rules and find places to look for new phenomena in the process. To do so they analyse behavior and build models that predict the tolerances needed to get things working with a high degree of confidence. The difference is they don't go off on tangents because they have an objective, but engineers are often the initial discoverers of phenomena. It usually takes a pure scientist to then go in to spend the time explain more precisely why they had to make the tweaks they did, but there is plenty of overlap and there are plenty of people you cannot put into one category or another.
most of the basic ideas in (mechanical) engineering are pretty much settled since Newton got hit by the apple
Um, no, mechanical engineering has more to deal with now than they did then, because materials science and nanotech are increasingly important components.
I don't know where you get your ideas about the engineering disciplines. They pretty much all have frontiers.
Again, I am not supporting or disclaiming Horgan's thesis, but I am suggesting that it is an interesting topic worthy of discussion.
It's a worn out thesis echoed many times over by the occasional erudite edlder for some physchological reasons that will perhaps never be fully understood, even by said erudite elders.
If you want an interesting discussion along these lines, it's much more interesting to discuss how educational techinique could be improved to bring people up to speed faster, given the amount of knowlege needed to make an impact is arguably higher but we obviously haven't managed to figure out how to teach faster. Or how we are starting to get culturally desensitized to discoveries that actually would be ground shaking back in the day. Or how emergent behaviors have suddenly made new areas of math not formerly considered worthy of the title of "science" much more pertinent, and after all, physicists were really doing just math to explain observations back when they made their Nobel winning discoveries.
I don't think so in this case. I normally would have waited on the firehose for a submission with a better writeup, but this was relatively urgent news so I upvoted it anyway.
(Yes someone did understand you weren't talking about the potential intentionality of the bug, don't despair there are people capable of comprehension out there and you may even meet one face to face someday :-)
There may seem to be more now because there is more auditing going on since the NSA revelations reminded people what had to be done, and also the slower trend of case law starting to punish mishandling of customer data. The halcyon days are over and the backlog is being cleared up.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory.
My computer is too busy calculating an MD5 in a managed memory VM that doesn't even have an unsigned or sized integer types and thus must perform basic left barrel roll operations in about 50 opcodes worth of abstraction container dereferencing, to allow me to respond to this post appropriately.
For sshd there was possibly some protection afforded by the privilege separation model. I'd store your old keys and wait to see something from someone who knows it cold.
Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.
It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.
I predict a lot more interest in turning on CRL pathways in the future.
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.
But AFAIK, there is no preloaded CA for EAP. You install only the CA of your organization, which narrows the opportunities to have a valid certificate.
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.
In my view EAP-TLS with mutual certificate authentication is still the most secure authentication option available.
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.
WPA2 keeps the neighbors from eating mah bandwich?
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.
Once quantum computing fully arrives, I guess encryption will be mostly moot.
Bad guess
It's not quite clear what the 97.25% figure actually means. They trained it on just 4000 faces. What number of faces they tested it on to derive that figure is not stated. It's a lot easier to be accurate within a smaller set than a larger set. Of course other intelligence could be used to prune the list of candidates down for some usage scenarios.
Every good engineer I know, software or otherwise, can't resist learning how the next new shiny works
There are too many next new shiny things for any one person to figure out how they all work. A good engineer has to have either instinct or guidance so they don't invest time in doomed flash-in-the-pan technologies so they can use the time more productively. Especially since a good engineer is already spending most of their time actually working their current assignments on top of learning new things.
We sould really have a holiday of appreciation for these people, like we do for veteranarians.