The choice in this election is between a small or large left-ward shift. McCain is a moderate Republican, Obama is a radical Democract. A bigger issue than the candidate is the Democrat-controlled congress. Our country was designed with the idea of checks and balances, but this system breaks down when the same party controls both the presidency and congress. Our country has prospered most when difference parties controlled these two branches of government.
Technology regulation is the biggest concern for us. McCain is famously over a hundred years old and has never sent an e-mail. Yet, Obama is not much better. Whereas neither candidate knows much about computers, McCain has extensive experience in telecoms regulation. It is here where McCain has demonstrated a greater understanding of the Internet and its history.
Obama has frequently described the Internet as something created by the government. In contrast, McCain watched the Internet evolve from its infancy. McCain remembers how the over-regulated telecommunications industry failed to innovate. He also remembers that the government did indeed design an Internet known as "GOSIP", and that this alternative Internet failed. McCain knows that today's Internet was designed not by government nor by corporations, but by mavericks that opposed both.
A test of the candidates' desire to regulate is "Net Neutrality". Obama sees this as government protecting the people. McCain sees this as yet another example of the type of overregulation that destroys innovation. What concerns McCain is that Net Neutrality laws protect business interests, giving power to those at the "ends" of the network (like search monopoly Google) over those providing Internet service (like AT&T). McCain is concerned with the fact that Google has spent millions lobbying congress to pass Net Neutrality legislation. McCain is worried about the way Google has hired former FCC employees and Internet luminaries to do its lobbying, exactly the sort of Washington cronyism that has stifled telecommunications for the last 30 years.
Government regulation cannot fix cybersecurity. There is a myth that some sort of "magic pill" will solve all security problems, and that government should just force everyone to take this "magic pill". This "magic pill" doesn't exist. If it did, everyone would have taken it already. No such pill will ever exist. Security is a tradeoff - each gain in security requires sacrificing something else. Different people want different tradeoffs and therefore different solutions (and different risks). Government regulation forces a one-size-fits all set of tradeoffs. We want less government regulation in cybersecurity. We want people to choose tradeoffs and risks for themselves.
The state of the art of hacking and defense changes faster than government regulators can keep up. Today's compliance issues were based on a model where hackers attacked "server" vulnerabilities. Now hackers target mostly "client" vulnerabilities, and those regulations are out of date. Regulatory compliance is forcing companies to keep their focus on the old threat rather than addressing these new threats.
Government regulation is corrupt. Laws are heavily influenced by lobbyists. Companies have cozy relationships with auditors that allow them to pass compliancy checks while having little or no security.
McCain is not our perfect candidate in regards to Internet regulation, but he is much better than Obama and the Democrat-controlled congress.
Economics is our second concern. Entrepreneurs and small companies drive the innovation in our industry. Most cybersecurity innovations come from the United States because of our business-friendly climate.
Obama's tax plan hurts small cybersecurity companies. The majority of people we know work 80-hour weeks. Their spare time is spent reading technical books to keep their skills sharp. They quit their jobs at large firms in order to create an independent consultancy or create a new product company. It is this highly skilled, hard working professional that Obama proposes to tax in order to send welfare checks to unskilled laborers that don't work as hard. The cybersecurity professionals we know don't have time to watch much TV, the average American receiving Obama's checks spends 28-hours a week in front of the TV. This income redistribution is a strong disincentive to entrepreneurs. Why improve your cybersecurity skills, work hard, or take the risk with a startup if you cannot enjoy the rewards of doing so? This is a selfish point of view, of course, but a large reason we support McCain.
Security is a luxury. It is one of first things companies cut when profits decline, it is one of the first things they invest in when things get better. Obama's anti-business policies, such as trade protectionism we cut corporate earnings and reduce their investment in cybersecurity.
And, the issue of regulation comes up again. American's start their own business at a rate of 10 to 1 vs. Europe precisely because it's easy. In most other countries, it can take a year's wages and months of hard work just to get the business licenses needed to start a company.
We are also concerned with foreign policy. Many foreign countries, notably China and Russia, have policies that encourage their citizens to attack American cyberspace. While we are not happy with the current president's Texas-cowboy approach of attacking foreign countries, neither are we happy with Obama's stated strategy of appeasement. We prefer McCain's more moderate approach between these two extremes. As a side note, we suggest that the next government respond in kind - making it easy for our own citizens respond to these attacks.
Both candidates displease us on certain issues. Both candidates failed on the issue of the so-called "Patriot" Act and the recent FISA bill. Both candidates fail on the issue of intellectual property. Both candidates fail on the issue of free speech, although we worry more about the passage of a so-called "Fairness" Doctrine next year designed to curtail right-wing speech.
These issues are like the slavery debate 200 years ago. The issues are so integrated into society that many people cannot see their obvious immorality. We understand how our society is based upon the protection of property rights, and how intellectual property is a leading American expert, but this should not blind us to the obvious abuse of intellectual property.
In summary, we believe John McCain is the best candidate for cybersecurity. The next president will not help cybersecurity much. The most we can hope for is that they resist the urge to meddle in something that government does not understand, cannot understand, and which will ultimately be driven more by special interests than technical knowledge.
EDIT: This blog asks should security company's endorse a president? It suggests our inspiration comes from movie stars, but in reality it comes frm Google's endorsement of Obama. Why is the search/advertising monopoly allowed to endorse a candidate but not a small security consultancy?
Wednesday, October 29, 2008
Sunday, October 12, 2008
WPA is NOT obsolete
Elcomsoft, a company that produces password cracking software, has recently announced an upgrade to that product that uses the computer's graphics processor (GPU) to crack Wi-Fi passwords 100 times faster than before. In response to this, one so-called expert has claimed this means that WPA/WPA2 is obsolete, and that you must use VPNs to secure Wi-Fi networks.
Not quite.
At worst, all this really means is that you have to add one extra character to your WPA password to achieve the same level of security. Password cracking is exponential. Each additional character in a password makes it 100 times more difficult to crack (assuming you use upper and lower case, numbers, and symbols).
The claim of 100 times is a little hyped. It's comparing the most expensive graphics card solution costing $1000 (dual GT280s) compared to a cheap CPU. On my system with a cheaper graphics card (Nvidia 8800GT), the GPU is likely to be only 5x faster than my CPU. If you are going to invest a lot of money in password cracking, you should probably invest in FPGAs (such as those from Pico Computing) instead.
You can only crack WPA passwords when everyone on the same network uses the same password (using "pre-shared keys" or PSK). Companies that give out different passwords to different people (using a RADIUS server and EAP) are not vulnerable to this sort of cracking. If home users are paranoid, then can install a RADIUS server.
Password crackers are good at figuring out the way people choose passwords. If you choose something like "Aardvark*Zebra", your password will be cracked quickly. Your WPA password needs to be both long AND complex.
The true danger of cracking tools like Elcomsoft's isn't the GPU, but the fact that it also uses distributed computing. You can grab all the computers in a small business and have them collaborate on cracking a single WPA password. Few people are going to invest in hardware for the purpose of cracking password, but lots of companies have "unused cycles" they can harness. If somebody were to release an open source program with GPU accelerated WPA cracking, then we'd have something more to worry about.
EDIT: George Ou also has an nice post debunking this idea.
Not quite.
At worst, all this really means is that you have to add one extra character to your WPA password to achieve the same level of security. Password cracking is exponential. Each additional character in a password makes it 100 times more difficult to crack (assuming you use upper and lower case, numbers, and symbols).
The claim of 100 times is a little hyped. It's comparing the most expensive graphics card solution costing $1000 (dual GT280s) compared to a cheap CPU. On my system with a cheaper graphics card (Nvidia 8800GT), the GPU is likely to be only 5x faster than my CPU. If you are going to invest a lot of money in password cracking, you should probably invest in FPGAs (such as those from Pico Computing) instead.
You can only crack WPA passwords when everyone on the same network uses the same password (using "pre-shared keys" or PSK). Companies that give out different passwords to different people (using a RADIUS server and EAP) are not vulnerable to this sort of cracking. If home users are paranoid, then can install a RADIUS server.
Password crackers are good at figuring out the way people choose passwords. If you choose something like "Aardvark*Zebra", your password will be cracked quickly. Your WPA password needs to be both long AND complex.
The true danger of cracking tools like Elcomsoft's isn't the GPU, but the fact that it also uses distributed computing. You can grab all the computers in a small business and have them collaborate on cracking a single WPA password. Few people are going to invest in hardware for the purpose of cracking password, but lots of companies have "unused cycles" they can harness. If somebody were to release an open source program with GPU accelerated WPA cracking, then we'd have something more to worry about.
EDIT: George Ou also has an nice post debunking this idea.
Wednesday, October 08, 2008
Google's "obfuscated TCP"
Google's "obfuscated TCP" (ObsTCP) has appeared in the news again (on Slashdot). This is a good example of something that's a bit too subtle for people to understand.
Security is a tradeoff. This means that security never comes for free, and that you must pay for it. That's why SSL isn't the default. It adds too much delay, and the additional processing power is too costly for websites.
ObsTCP is the idea is to add the maximum amount of encryption within the same amount of delay/processing budget we already have for TCP connections. That means establishing encrypted TCP connection with an additional round-trip delay or CPU power.
Why don't they use IPsec or better crypto algorithms? The answer is simply "because that would add more latency/CPU".
Can this encryption be broken? Yes, of course, that's why it's called "obfuscation". I can still break into your TCP connection if you are surfing the web in a coffee shop using ObsTCP. However, I would no longer be able to do so in a completely passive way like Sidejacking. I'd have to instead transmit some packets. This means you could catch me if you were paying attention (such as surfing to a site for which you already have a key and see if they match).
Widespread government wiretapping would have the same difficulty. They can do it now completely passively. With ObsTCP, they would either have to invest billions of dollars in breaking the ciphers, or they would have to actively transmit packets and reveal their wiretapping. ObsTCP doesn't protect the individual so much as protect society.
I'm bothered by the fact that they are avoiding some solutions because the IETF won't like them. This contravenes the principles that the IETF was based upon. It's not the IETF's job to dictate standards, but instead to document working protocols that people come up with. It's like dictionaries: their role is to document how people use words, not dictate how they SHOULD use words. The ObsTCP project should be mindful of stepping on other people's toes, but if need be, go forward. If they won't assign you a TCP option, just pick one and use it.
Security is a tradeoff. This means that security never comes for free, and that you must pay for it. That's why SSL isn't the default. It adds too much delay, and the additional processing power is too costly for websites.
ObsTCP is the idea is to add the maximum amount of encryption within the same amount of delay/processing budget we already have for TCP connections. That means establishing encrypted TCP connection with an additional round-trip delay or CPU power.
Why don't they use IPsec or better crypto algorithms? The answer is simply "because that would add more latency/CPU".
Can this encryption be broken? Yes, of course, that's why it's called "obfuscation". I can still break into your TCP connection if you are surfing the web in a coffee shop using ObsTCP. However, I would no longer be able to do so in a completely passive way like Sidejacking. I'd have to instead transmit some packets. This means you could catch me if you were paying attention (such as surfing to a site for which you already have a key and see if they match).
Widespread government wiretapping would have the same difficulty. They can do it now completely passively. With ObsTCP, they would either have to invest billions of dollars in breaking the ciphers, or they would have to actively transmit packets and reveal their wiretapping. ObsTCP doesn't protect the individual so much as protect society.
I'm bothered by the fact that they are avoiding some solutions because the IETF won't like them. This contravenes the principles that the IETF was based upon. It's not the IETF's job to dictate standards, but instead to document working protocols that people come up with. It's like dictionaries: their role is to document how people use words, not dictate how they SHOULD use words. The ObsTCP project should be mindful of stepping on other people's toes, but if need be, go forward. If they won't assign you a TCP option, just pick one and use it.
Friday, October 03, 2008
TCP Selective ACK considered evil
In my previous post, I pointed out that the claims of a new TCP DoS are probably true. Like the researchers that discovered the issues, I too have been playing around in TCP stacks, and I find weirdness.
One thing that has annoyed me recently is the way that stacks abuse the "selective ack" feature. In the past, the receiver would only acknowledge the continuous data received. If a packet were lost on the network, and a gap appeared, the sender wouldn't know the fate of the packets after the discontinuity. This was solved with "selective acks", where the receiver could say "I received your first 100,000 bytes, and bytes 101,000-108,000, but I'm missing those in between". This increased the speed at which TCP stacks could recover from lost packets and retransmit the necessary data.
I'm seeing something unexpected, though. When clients are downloading large files, the servers aren't immediately retransmitting the lost packets. The file download past the gap continues for a very long time. So far, I've seen the file download continue for 3-megabytes before the server goes back and fills in the gap. This can be easily 20 seconds later.
This annoys me because my network monitoring tools like Ferret have to buffer all that data. My TCP stack has to process data in-order, so I have to buffer 3-megabytes until I can process the retransmitted packet.
In the old days, kernels had a fixed amount of buffer space, usually not very big. They wouldn't be able to buffer 3-megabytes like this. This implies that the kernel is allocating more memory on demand, controlled by the other side of the connection.
This suggests a way that I can bluescreen a desktop computer. I would have a user follow a link to download a simple webpage. I then intentionally miss a packet as I send data in response. As the client selectively acknowledges my data, I continue streaming forever, but I never fill in that gap. A well-designed TCP stack would put a limit on how much memory it would allocated. A poorly designed stack would allocate data until it ran out, at which point the machine would likely crash the next time another kernel process needed more memory.
When an application runs out of memory, it can use "virtual memory" paged to disk. The kernel cannot. If it runs out of a virtual memory, just the application will crash. When the kernel runs out of memory, it bluescreens.
I could do the same thing with a server. I could connect to the web server, send a few bytes, "drop" a packet, then continue to stream data forever after that. An Apache web-server will only accept the first 16-kilobytes, but I don't care, because the kernel hasn't delivered the first 16-kilobytes yet - it is waiting for me to retransmit that missing packet before all the data goes up the stack to Apache.
I can't explain why the server is taking 20 seconds to retransmit data. One idea is that operating systems have specialized "sendfile" functions that hand off the kernel the responsibility for sending the contents of a file across the network socket. Maybe the reason it takes so long is that the missing packet isn't buffered in memory: the kernel has to re-read the data from the disk in order to re-transmit it. On a busy file server, this can take many seconds. If my theories are true, I could DoS a server by forcing it to go back and retransmit lots of 1-byte chunks all over the disk. I could cause the disk heads to grind away for very low bandwidth.
I'm not sure how selective-acks work with other mechanisms. In order for a TCP stack to acknowledge a "FIN" flag is to acknowledge the next byte after the flag. I can do that with selective-acks, without acknowledging the data right before it. This puts the TCP state machine into a weird place. One part knows that the FIN has been received and behave accordingly, but another part is still trying to retransmitted the data. This conflict wasn't possible with old stacks because acknowledging the FIN also acknowledged all the data up to it.
I find selective-acks annoying and I'm just writing a simple network monitoring application. I'm sure they cause stack designers a lot more headaches, and that if I write an active stack, I could cause a lot of problems. That's why I believe those researchers when they say they have found problems.
One thing that has annoyed me recently is the way that stacks abuse the "selective ack" feature. In the past, the receiver would only acknowledge the continuous data received. If a packet were lost on the network, and a gap appeared, the sender wouldn't know the fate of the packets after the discontinuity. This was solved with "selective acks", where the receiver could say "I received your first 100,000 bytes, and bytes 101,000-108,000, but I'm missing those in between". This increased the speed at which TCP stacks could recover from lost packets and retransmit the necessary data.
I'm seeing something unexpected, though. When clients are downloading large files, the servers aren't immediately retransmitting the lost packets. The file download past the gap continues for a very long time. So far, I've seen the file download continue for 3-megabytes before the server goes back and fills in the gap. This can be easily 20 seconds later.
This annoys me because my network monitoring tools like Ferret have to buffer all that data. My TCP stack has to process data in-order, so I have to buffer 3-megabytes until I can process the retransmitted packet.
In the old days, kernels had a fixed amount of buffer space, usually not very big. They wouldn't be able to buffer 3-megabytes like this. This implies that the kernel is allocating more memory on demand, controlled by the other side of the connection.
This suggests a way that I can bluescreen a desktop computer. I would have a user follow a link to download a simple webpage. I then intentionally miss a packet as I send data in response. As the client selectively acknowledges my data, I continue streaming forever, but I never fill in that gap. A well-designed TCP stack would put a limit on how much memory it would allocated. A poorly designed stack would allocate data until it ran out, at which point the machine would likely crash the next time another kernel process needed more memory.
When an application runs out of memory, it can use "virtual memory" paged to disk. The kernel cannot. If it runs out of a virtual memory, just the application will crash. When the kernel runs out of memory, it bluescreens.
I could do the same thing with a server. I could connect to the web server, send a few bytes, "drop" a packet, then continue to stream data forever after that. An Apache web-server will only accept the first 16-kilobytes, but I don't care, because the kernel hasn't delivered the first 16-kilobytes yet - it is waiting for me to retransmit that missing packet before all the data goes up the stack to Apache.
I can't explain why the server is taking 20 seconds to retransmit data. One idea is that operating systems have specialized "sendfile" functions that hand off the kernel the responsibility for sending the contents of a file across the network socket. Maybe the reason it takes so long is that the missing packet isn't buffered in memory: the kernel has to re-read the data from the disk in order to re-transmit it. On a busy file server, this can take many seconds. If my theories are true, I could DoS a server by forcing it to go back and retransmit lots of 1-byte chunks all over the disk. I could cause the disk heads to grind away for very low bandwidth.
I'm not sure how selective-acks work with other mechanisms. In order for a TCP stack to acknowledge a "FIN" flag is to acknowledge the next byte after the flag. I can do that with selective-acks, without acknowledging the data right before it. This puts the TCP state machine into a weird place. One part knows that the FIN has been received and behave accordingly, but another part is still trying to retransmitted the data. This conflict wasn't possible with old stacks because acknowledging the FIN also acknowledged all the data up to it.
I find selective-acks annoying and I'm just writing a simple network monitoring application. I'm sure they cause stack designers a lot more headaches, and that if I write an active stack, I could cause a lot of problems. That's why I believe those researchers when they say they have found problems.
Wednesday, October 01, 2008
TCP DoS (probably) real
This post by RSnake describing a dangerous new DoS attack is probably real.
These guys haven't published their tool, so there is no independent confirmation of their results. Therefore, my immediate reaction is skepticism: things like this tend to be hype. However, after listening to their audio interview, I believe they are probably right. They have been working deep withing TCP stacks. If such problems exist, then they would have certainly come across them.
The problem, in a nutshell, is that they can open a TCP connection that will never be closed. The only way to get rid of them is to reboot the server. This means that I can connect to the Internet with a dialup connection, then quickly take down www.google.com (or any other server) by maxing out the number of connections.
They describe one mechanism. A TCP stack tries to figure out the maximum speed of your connection, in order to slow down data transmission so that packets won't be dropped. One technique they describe is to behave as if their connection were getting slower and slower to the point that the TCP stack is tricked into believing it will take years to complete the transmission of data. This forces the TCP stack to keep trying for years to send just a few bytes.
How do we fix these problems? The problem is a resource-leak like the more common memory-leak. Back when I worked on the TCP stack for the Proventia IPS, we designed the code and test cases to deal with exactly this sort of resource-leak. The trick is to create billions of connections, with special tools like this, then verify that once everything is gone, that you indeed have gone back to zero resources.
EDIT: When I say "leaving the connection open", I refer to how we see the connection from the point of view of kernel resources. The socket, though, is probably closed. That's the essence of this problem: closing the socket doesn't necessarily free the connection resources if the connection is in a certain state. This makes the DoS different from things like the "LaBrea Tar Pit" that DoSes applications by forcing them to leave the socket open.
These guys haven't published their tool, so there is no independent confirmation of their results. Therefore, my immediate reaction is skepticism: things like this tend to be hype. However, after listening to their audio interview, I believe they are probably right. They have been working deep withing TCP stacks. If such problems exist, then they would have certainly come across them.
The problem, in a nutshell, is that they can open a TCP connection that will never be closed. The only way to get rid of them is to reboot the server. This means that I can connect to the Internet with a dialup connection, then quickly take down www.google.com (or any other server) by maxing out the number of connections.
They describe one mechanism. A TCP stack tries to figure out the maximum speed of your connection, in order to slow down data transmission so that packets won't be dropped. One technique they describe is to behave as if their connection were getting slower and slower to the point that the TCP stack is tricked into believing it will take years to complete the transmission of data. This forces the TCP stack to keep trying for years to send just a few bytes.
How do we fix these problems? The problem is a resource-leak like the more common memory-leak. Back when I worked on the TCP stack for the Proventia IPS, we designed the code and test cases to deal with exactly this sort of resource-leak. The trick is to create billions of connections, with special tools like this, then verify that once everything is gone, that you indeed have gone back to zero resources.
EDIT: When I say "leaving the connection open", I refer to how we see the connection from the point of view of kernel resources. The socket, though, is probably closed. That's the essence of this problem: closing the socket doesn't necessarily free the connection resources if the connection is in a certain state. This makes the DoS different from things like the "LaBrea Tar Pit" that DoSes applications by forcing them to leave the socket open.
Subscribe to:
Posts (Atom)
