He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than
This problem is easy to solve technically with an IDN character blacklist. The https-to-http redirection is far more insidious.
HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the status bar section?
You and I know to look for these signals, but most users don't. They'll see the padlock and think they're good to go. We need to train them to look for obvious unspoofable signals that are common across browsers, like the green background under the address bar of an EV site.
If we tell a bunch of high school students, "don't enter your credit card information into any website unless you see a padlock icon on the status bar and a blue background on the icon next to the address bar", what they'll get out of it (if they're listening at all) is "mumble mumble look for the padlock mumble mumble." We need to make security blindingly obvious!
I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees.
I think the EV model here is useful. Create a new CA that's specifically marked as being free and make browsers display a different UI for a site encrypted by a certificate originating with this free CA --- say, an orange address bar. Making the free-encrypted UI different will encourage users to not treat self-signed sites as being as secure as CA-verified ones, and won't diminish the value of a CA-verified certificate. It'll also train users to understand different degrees of security.
The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/
Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unnecessary.
The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.
SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.
That's still impossible unless you're okay with the client getting the wrong certificate. In a corporate environment, you can just install a CA certificate in every client and the user will be none-the-wiser. But in general, SSL is not vulnerable to undetected MITM attacks.
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
This capability is part of the plugin API and works in every major browser, as documented by Sun. And unlike Silverlight, most people actually have Java installed.
The reimplementation also restores the ability to use try-catch exceptions within JavaScript, and is free of the increasing number of other bugs introduced by the decline of the original LiveConnect (e.g., java.lang.String and arrays not working properly).
the malware has locked the registry against editing, sometimes even in safe mode
Registry keys are controlled by ACLs just like files are. Just change the permissions.
only way to be sure is to fdisk from orbit
That's good advice for any compromised system, not just a Windows box. See the famous Reflections on Trusting Trust paper for the frightening reason.
As for gconf - it's a fanboys' implementation of the MS Windows registry for linux except you not only have one per user but you also can do even less to modify, import and export keys than you can in the MS Windows version
More data format support is a good thing. Why the ad hominem attack though? I like how gconf keys are documented directly in the schema, how there's an API for modifying these keys, and how applications immediately respect changes made directly to the configuration. gconf has never given me trouble.
Once you get a registry hive that is too big to back up onto a floppy you can really forget about any speed increase you might have originally had from it being a hierarchical collection of data in a binary. That is where the majority of sytems using it stand.
Performance reading configuration data is a non-issue on today's systems regardless of whether it's stored in a registry hive or a flat text file.
Personally my main criticism is it is difficult to parse the registry to find where problems lie, which is where it loses in comparison to the most insane plain text configuration file I could think of.
Are you talking about parsing the registry hive files? The file format is documented. If you're talking about the APIs --- what don't you like about them? Also, any registry editing tool will include a registry-wide search function. Also, under cygwin, you can just use find and grep! What could be easier?
And speaking of insane configuration files --- sendmail.cf is pure divine revelation from heaven compared to radiusd's configuration.
The design of the registry is one of the things that makes [malware] so difficult to remove. The registry even makes the really horrible native sendmail configuration file look simple, to answer yet another question.
I really don't see how either of these claims can be true. The latter doesn't make sense --- sendmail.cf is insane in that it's specialized, irregular, delicate, and nearly write-only. It's completely unlike anything else out there. The Windows registry, on the other hand, isn't even a format per se, but a data model. It's a simple hierarchical system with well-defined datatypes. You can even manipulate it as a filesystem under Cygwin. Editing it is a snap. It's not the registry's fault that some applications use an overly-complex schema. I never really understood criticism of the registry; it's really not any more complex than Linux's/sys, or Gnome's gconf.
As for the registry making malware more difficult to remove -- that's not true. What you're actually complaining about is COM registration, which goes through the registry. A piece of Malware can register an IE extension and stick it under a registry key with a hundred other subkeys, all of which are named using incomprehensible GUIDs. But look at a Firefox extension directory sometime -- you'll see the same naming scheme. What you're really complaining about is a consequence of the extensibility of the system, not the registry design.
Please, can you provide a specific example of the way in which the design of the registry is a malware enabler?
You don't know what you're talking about. Windows doesn't fork at all, ever. Processes are created from scratch by CreateProcess. In principle, that requires less overhead than the fork() case. But as another poster explained, the Windows security model adds enough complexity to eclipse the gain from not fork()ing.
I think whoever came up with HTML and CSS was smoking crack. There are so many inconsistencies and bizarre rules that it's impossible for me to believe that a sane person came up with all this.
Browser implementation, web standards, and hell, even programming languages, APIs and file formats are more evolved than designed. Think of a community of bacteria growing on a petri dish competing for resources and occasionally swapping genes. You'll end up with organisms very different from the ones you started with, and they'll probably have some quirky mechanisms in them.
Like in this culture, today's technology ecosystem is the cumulative result of lots of incremental changes that seemed like the right thing at the time. It's no surprise that we're dealing with the technology equivalent to such inexplicable evolution results as our retinas being wired backwards, the male urethra going right through the prostate (which is very prone to swelling), the birth canal being narrow enough to often cause the mother's death, or thymine (one of the components of DNA) being prone to forming dimers and corrupting the cell's machinery. Again, the decisions that seemed like the right thing at the time result in a system that's thoroughly confusing and that in retrospect appears insane.
If you live in Buffalo, NY, check out Bill Rapaport's Buffalo Restaurant Guide. It's put together by a CS professor at the University at Buffalo. Although the web design is right out of 1995, but it's extremely fair, useful, and informative site, and a model for other grass-roots restaurant review services to emulate.
You got paid....not really wasted time....for you anyway.
There's more to life than money. Some of us want to do something useful or important with our time here on Earth. As Keynes said, in the long run, we're all dead.
What exactly are you proposing? What changes in existing APIs and protocols would be required to implement your proposal?
Obviously, we need to be able to freely specify the destination address! And the source address already cannot vary much: that's what egress filtering is for. Sure, you can give your outbound packets any source IP you want, but unless source IP matches your ISP's records, your packets won't be forwarded to the larger internet.
What benefit does your circuit-switched proposal give us that TCP doesn't?
You name calling liberals are all the same, no respect for the traditions and institutions that made this country great and kept it going for the past two centuries.
I strongly identify as a liberal and a progressive. However, I couldn't care less about gun control. Criminals will have guns regardless. Conversely, most people will not bother to own guns, regardless. That means that gun ownership is also not a solution to crime.
We need effective police, and more importantly, we need social policies that eliminate the bitter poverty related to a lot of gun-related crime. If you release harmless prisoners, increase welfare, legalize marijuana, provide higher education for all and good jobs for everyone, you will see a decrease in gun-related violence. Happy people don't go on shooting sprees.
Others have explained why gated communities don't provide additional security. I believe they're correct. But even if gated communities were effective, they'd still be both wrong and worrisome: You can tell the degree of a society's progress or regression by examining the change in the number of gated communities.
Gated communities are a sign of a diseased society with a siege mentality. In Europe, the manors that started appearing in Late Antiquity (i.e., after the Roman Empire was in irreversible decline) were that era's gated communities: by building walls and becoming economically self-contained, petty landlords became more secure against the bandits of the day. (Our word "vandal" actually comes from the name of a tribe that sacked Rome.) The empire was increasingly unable to guarantee security for all, and so fomented an insular mentality that would stop the clock of progress until the Italian Renaissance.
Likewise, every gated community we build is a symbol of our giving up on collective security a bit. There's a reason you see gated communities in countries with high wealth disparities, like Mexico, Brazil, and the Middle Eastern nations: gated communities allow those inside to view the people outside as somewhat less than they are, which of course leads the inhabitants to adopt views and policies that further these views. In a way, are both the result and cause of policies that lead to further wealth inequality and eventually, complete societal collapse.
A UTM device... [is] another tool in the arsenal a good network admin can use in the fight against morons, not a replacement for a good admin.
Of course not. But by being marketed as turn-key solution, you know very well that managers will see UTMs as replacements for quality network administrators. A UTM cannot* do anything that a well-configured OpenBSD box with pf, squid, and ClamAV can.
I think our fundamental disagreement is over whether companies will see UTMs as tools for competent system administrators, or as replacements for competent system administrators. You assert the former, but the latter is a pattern we've seen throughout computing history. I think it's naive to believe that management won't see a "turn-key security solution" as a reason to not sure a real system administrator, or to push the job onto an overworked software developer. These jerks will cut costs in any way possible using any flimsy excuse we give them.
The UTM would NOT be useless in the VPN example you gave.
That's not the point. If a boss says "I need to print and access my files from home", a quality system administrator will tell the boss he needs to buy a dedicated, secure laptop to access the VPN --- or partition some services off to a separate insecure network that the boss' diseased laptop can access. These things can be done with or without a VPN. On the other hand, a cheap sycophant with an expensive UTM will just configure the UTM to allow the boss' personal, spyware-infested laptop full access to the internal network.
* not in principle anyway: I'm sure the software stack I mentioned and some commercial UTM might have slightly different feature sets. The architecture, however, is identical.
Oh, don't get me wrong. Limited user accounts, UAC, and so on are great. They give an educated useruneducated user would just click through all the security dialogs, see the dancing bunny, and become part of a botnet.
Technical improvements can make user education more effective, but that education is still necessary. I'd love to see some tongue-in-cheek "just click NO" public service ads.
(On a side note, it's good to hear about another Linux user in my fair city of Buffalo.)
Your UTM is great until your boss decides update subscriptions are too expensive, stops paying the bill, and some script kiddy uses a just-discovered security vulnerability to breach your out-of-date firewall. Your UTM is also useless if your pimply-faced dirt-cheap IT intern decides he wants to play ShootEmUpGame3 and disables some critical filtering features. Your UTM is useless if your boss insists that you give his personal laptop full access to the company VPN.
The fact is that competent system administrators are worth their weight in gold. They cannot be replaced by all-in-one machines, no matter how impressively expensive they might be. And a quality system administrator doesn't need a UTM box to do his job.
Security is a social problem, not a technical one, and requires a real person to continuously address. As they say, security isn't a state, but a state of mind.
Slashdot Mirror
This problem is easy to solve technically with an IDN character blacklist. The https-to-http redirection is far more insidious.
You and I know to look for these signals, but most users don't. They'll see the padlock and think they're good to go. We need to train them to look for obvious unspoofable signals that are common across browsers, like the green background under the address bar of an EV site.
If we tell a bunch of high school students, "don't enter your credit card information into any website unless you see a padlock icon on the status bar and a blue background on the icon next to the address bar", what they'll get out of it (if they're listening at all) is "mumble mumble look for the padlock mumble mumble." We need to make security blindingly obvious!
I think the EV model here is useful. Create a new CA that's specifically marked as being free and make browsers display a different UI for a site encrypted by a certificate originating with this free CA --- say, an orange address bar. Making the free-encrypted UI different will encourage users to not treat self-signed sites as being as secure as CA-verified ones, and won't diminish the value of a CA-verified certificate. It'll also train users to understand different degrees of security.
Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unnecessary.
The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.
That's still impossible unless you're okay with the client getting the wrong certificate. In a corporate environment, you can just install a CA certificate in every client and the user will be none-the-wiser. But in general, SSL is not vulnerable to undetected MITM attacks.
A site should never lead the user to type sensitive information into a form on an unencrypted page, even if the form's data goes to an encrypted location when submitted. Doing this trains users to be lazy. What's even worse is trying to alleviate users very correct fears by putting a padlock icon next to the form. That's even worse: doing that trains users to believe that a website can signal its own trustworthiness apart from the browser UI, and that could have disastrous consequences.
I have a technical solution, but it won't be popular: browsers should display a warning when submitting a form on an unencrypted page to an encrypted URL. Since web designers are afraid warnings will spook users, they'll switch to making the form-entry pages encrypted as well.
This attack does not break SSL in any way. It simply tricks users into entering sensitive information into unencrypted context.
The solution is user education. We need to train users to look for the browser padlock icon. We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user. We need to train users to click "no" on security dialogs when they appear. We need to tell users that a padlock icon a website puts next to a form is unacceptable. We need to train users to be vigilant, because nasty people are trying to steal their information.
I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings. I'd like to see public service advertisements. I'd like to see basic computer safety classes in public schools. User education is the only hope we have against stupid users!
The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.
The old Mozilla implementation is flawed. The "technology" itself is fine. The new implementation is fine. MDC often contains stale stuff.
As for Flash --- its Javascript integration is a joke. Every call between Flash and browser Javascript is serialized to XML and re-parsed on the other end. No thanks.
This capability is part of the plugin API and works in every major browser, as documented by Sun. And unlike Silverlight, most people actually have Java installed.
Sounds like it's fine now.
Registry keys are controlled by ACLs just like files are. Just change the permissions.
That's good advice for any compromised system, not just a Windows box. See the famous Reflections on Trusting Trust paper for the frightening reason.
More data format support is a good thing. Why the ad hominem attack though? I like how gconf keys are documented directly in the schema, how there's an API for modifying these keys, and how applications immediately respect changes made directly to the configuration. gconf has never given me trouble.
Performance reading configuration data is a non-issue on today's systems regardless of whether it's stored in a registry hive or a flat text file.
Are you talking about parsing the registry hive files? The file format is documented. If you're talking about the APIs --- what don't you like about them? Also, any registry editing tool will include a registry-wide search function. Also, under cygwin, you can just use find and grep! What could be easier?
And speaking of insane configuration files --- sendmail.cf is pure divine revelation from heaven compared to radiusd's configuration.
I really don't see how either of these claims can be true. The latter doesn't make sense --- sendmail.cf is insane in that it's specialized, irregular, delicate, and nearly write-only. It's completely unlike anything else out there. The Windows registry, on the other hand, isn't even a format per se, but a data model. It's a simple hierarchical system with well-defined datatypes. You can even manipulate it as a filesystem under Cygwin. Editing it is a snap. It's not the registry's fault that some applications use an overly-complex schema. I never really understood criticism of the registry; it's really not any more complex than Linux's /sys, or Gnome's gconf.
As for the registry making malware more difficult to remove -- that's not true. What you're actually complaining about is COM registration, which goes through the registry. A piece of Malware can register an IE extension and stick it under a registry key with a hundred other subkeys, all of which are named using incomprehensible GUIDs. But look at a Firefox extension directory sometime -- you'll see the same naming scheme. What you're really complaining about is a consequence of the extensibility of the system, not the registry design.
Please, can you provide a specific example of the way in which the design of the registry is a malware enabler?
Untrue. LiveConnect allows communication between Java applets and Javascript, and it works just fine.
You don't know what you're talking about. Windows doesn't fork at all, ever. Processes are created from scratch by CreateProcess. In principle, that requires less overhead than the fork() case. But as another poster explained, the Windows security model adds enough complexity to eclipse the gain from not fork()ing.
Browser implementation, web standards, and hell, even programming languages, APIs and file formats are more evolved than designed. Think of a community of bacteria growing on a petri dish competing for resources and occasionally swapping genes. You'll end up with organisms very different from the ones you started with, and they'll probably have some quirky mechanisms in them.
Like in this culture, today's technology ecosystem is the cumulative result of lots of incremental changes that seemed like the right thing at the time. It's no surprise that we're dealing with the technology equivalent to such inexplicable evolution results as our retinas being wired backwards, the male urethra going right through the prostate (which is very prone to swelling), the birth canal being narrow enough to often cause the mother's death, or thymine (one of the components of DNA) being prone to forming dimers and corrupting the cell's machinery. Again, the decisions that seemed like the right thing at the time result in a system that's thoroughly confusing and that in retrospect appears insane.
Battlestar Galactica --- on the run from the Cylons, fans of Starbucks and Tide.
If you live in Buffalo, NY, check out Bill Rapaport's Buffalo Restaurant Guide. It's put together by a CS professor at the University at Buffalo. Although the web design is right out of 1995, but it's extremely fair, useful, and informative site, and a model for other grass-roots restaurant review services to emulate.
Still works a lot better than make install.
There's more to life than money. Some of us want to do something useful or important with our time here on Earth. As Keynes said, in the long run, we're all dead.
Amazing: the only punctuation character he used, he used incorrectly: '
The apostrophe never makes a word plural.
What exactly are you proposing? What changes in existing APIs and protocols would be required to implement your proposal?
Obviously, we need to be able to freely specify the destination address! And the source address already cannot vary much: that's what egress filtering is for. Sure, you can give your outbound packets any source IP you want, but unless source IP matches your ISP's records, your packets won't be forwarded to the larger internet.
What benefit does your circuit-switched proposal give us that TCP doesn't?
In the panopticon network being (vaguely) proposed in the original article, the kind of proxy onion routing depends on simply wouldn't be allowed.
On the off chance you're not trolling...
I strongly identify as a liberal and a progressive. However, I couldn't care less about gun control. Criminals will have guns regardless. Conversely, most people will not bother to own guns, regardless. That means that gun ownership is also not a solution to crime.
We need effective police, and more importantly, we need social policies that eliminate the bitter poverty related to a lot of gun-related crime. If you release harmless prisoners, increase welfare, legalize marijuana, provide higher education for all and good jobs for everyone, you will see a decrease in gun-related violence. Happy people don't go on shooting sprees.
Others have explained why gated communities don't provide additional security. I believe they're correct. But even if gated communities were effective, they'd still be both wrong and worrisome: You can tell the degree of a society's progress or regression by examining the change in the number of gated communities.
Gated communities are a sign of a diseased society with a siege mentality. In Europe, the manors that started appearing in Late Antiquity (i.e., after the Roman Empire was in irreversible decline) were that era's gated communities: by building walls and becoming economically self-contained, petty landlords became more secure against the bandits of the day. (Our word "vandal" actually comes from the name of a tribe that sacked Rome.) The empire was increasingly unable to guarantee security for all, and so fomented an insular mentality that would stop the clock of progress until the Italian Renaissance.
Likewise, every gated community we build is a symbol of our giving up on collective security a bit. There's a reason you see gated communities in countries with high wealth disparities, like Mexico, Brazil, and the Middle Eastern nations: gated communities allow those inside to view the people outside as somewhat less than they are, which of course leads the inhabitants to adopt views and policies that further these views. In a way, are both the result and cause of policies that lead to further wealth inequality and eventually, complete societal collapse.
Of course not. But by being marketed as turn-key solution, you know very well that managers will see UTMs as replacements for quality network administrators. A UTM cannot* do anything that a well-configured OpenBSD box with pf, squid, and ClamAV can.
I think our fundamental disagreement is over whether companies will see UTMs as tools for competent system administrators, or as replacements for competent system administrators. You assert the former, but the latter is a pattern we've seen throughout computing history. I think it's naive to believe that management won't see a "turn-key security solution" as a reason to not sure a real system administrator, or to push the job onto an overworked software developer. These jerks will cut costs in any way possible using any flimsy excuse we give them.
That's not the point. If a boss says "I need to print and access my files from home", a quality system administrator will tell the boss he needs to buy a dedicated, secure laptop to access the VPN --- or partition some services off to a separate insecure network that the boss' diseased laptop can access. These things can be done with or without a VPN. On the other hand, a cheap sycophant with an expensive UTM will just configure the UTM to allow the boss' personal, spyware-infested laptop full access to the internal network.
* not in principle anyway: I'm sure the software stack I mentioned and some commercial UTM might have slightly different feature sets. The architecture, however, is identical.
Oh, don't get me wrong. Limited user accounts, UAC, and so on are great. They give an educated useruneducated user would just click through all the security dialogs, see the dancing bunny, and become part of a botnet.
Technical improvements can make user education more effective, but that education is still necessary. I'd love to see some tongue-in-cheek "just click NO" public service ads.
(On a side note, it's good to hear about another Linux user in my fair city of Buffalo.)
Your UTM is great until your boss decides update subscriptions are too expensive, stops paying the bill, and some script kiddy uses a just-discovered security vulnerability to breach your out-of-date firewall. Your UTM is also useless if your pimply-faced dirt-cheap IT intern decides he wants to play ShootEmUpGame3 and disables some critical filtering features. Your UTM is useless if your boss insists that you give his personal laptop full access to the company VPN.
The fact is that competent system administrators are worth their weight in gold. They cannot be replaced by all-in-one machines, no matter how impressively expensive they might be. And a quality system administrator doesn't need a UTM box to do his job.
Security is a social problem, not a technical one, and requires a real person to continuously address. As they say, security isn't a state, but a state of mind.