Chad Perrin: SOB

14 March 2008

Don’t let their BS fool you.

Filed under: Liberty — Tags: , , , , , , , — apotheon @ 05:37

The House on Friday approved a Democratic bill that would set rules for the government’s eavesdropping on phone calls and e-mails inside the United States. The bill, approved as lawmakers departed for a two-week break, faces a veto threat from President Bush. The margin of House approval was 213-197, largely along party lines.

You may have heard about this. Republicans (not all, but most) in the House of Representatives have been pushing for both legal support for warrantless wiretaps (a violation of the Fourth Amendment protections against unreasonable search and seizure, if you ask me) and retroactive immunity for telecoms that willingly — even eagerly — aided in such surveillance before members of Congress even tried to make it legal.

During the drama, Democrats in the House sought to address the matter. Knowing they were outnumbered, pro-surveillance and pro-immunity (or, alternatively, anti-rights) Republicans decided to stage a walk-out (call it a “tantrum” if you like) to display their (impotent) outrage that government officials would be held responsible for their actions in support of illegal wiretaps, particularly as regards providing evidence of what happened for Congress to review. Three Republicans remained (italicized names are Republicans) to vote their conscience, in support of the Bill of Rights.

From a discussion (and feel free to ignore the rampant right-wingnuttery there):

Let’s not jump the gun. I think this stunt by many GOP members DURING A MEMORIAL SERVICE FOR A DEMOCRATIC REPRESENTATIVE is going to backfire on them. Blowback. Unintended consequences. If I were the Democrats, I’d force Bush to veto his beloved warrantless wiretap bill and then impeach him if he allows the wiretaps to continue.

Wouldn’t that be nice?

Now, the House has passed a bill that does not grant retroactive immunity to the telecoms. Bush is expected to veto it (from the first link in this SOB entry):

Because of the promised veto, “this vote has no impact at all,” said Republican Whip Rep. Roy Blunt of Missouri.

Also from the same source, an explanation of why Bush and some House Republicans object to the bill:

The president’s main objection is that the bill does not protect from lawsuits the telecommunications companies that allowed the government to eavesdrop on their customers without a court’s permission after the Sept. 11, 2001, terrorist attacks. White House spokesman Tony Fratto called the measure a “political ploy” designed to give Democrats cover for their failure to grant full retroactive immunity to the telecom companies.

Don’t believe Republicans. Again from the same source:

Without that provision, House Republicans said, the companies won’t cooperate with U.S. intelligence.

“We cannot conduct foreign surveillance without them. But if we continue to subject them to billion-dollar lawsuits, we risk losing their cooperation in the future,” said Rep. Lamar Smith, R-Texas.

. . . except:

The government does have the power to compel telecommunications companies to cooperate with wiretaps if it gets warrants from a secret court. The government apparently did not get such warrants before initiating the post-9/11 wiretaps, which are the basis for the lawsuits.

So . . . all that crap about how government has its hands tied is just that: crap. The real problem Republicans have, apparently, is that they want the executive branch of government to be able to surveil whoever it wants, whenever it wants, regardless of any probable cause for suspicion or actual evidence of wrongdoing.

In the words of Scott Horton:

The integrity of our criminal justice system rests on the notion that we investigate crimes, not people.

Here’s the kicker in the current spate of things, again from the first link of this SOB entry:

“There is not one iota of evidence that the companies acted inappropriately whatsoever,” said Rep. Dan Lungren, R-Calif.

That was intended as advocacy for granting retroactive immunity. What really throws me is this:

If there’s no evidence of wrongdoing, there’s no need for immunity.

So . . . we know we shouldn’t believe the mainstream Republicans who oppose the current form of the House bill, because they want a version that provides retroactive immunity to telecoms. What about the Democrats, though?

The Democrats aren’t acting in our best interests, either. Sure, the bill the Democrats have pushed through avoids granting immunity to the telecoms for their complicity in warrantless wiretapping. The main purpose of the bill, however, is to take the place of the old FISA law, which expired in February this year. The purpose of this new bill is, effectively, to make some of the warrantless wiretapping that may yet get some telecoms and government officials in trouble into legal acts in the future — to legalize surveillance of US citizens without meaningful evidence of wrongdoing. That’s why all three of the Republicans who refused to participate in the walk-out (Gilchrest, North Carolina’s Jones, and Paul) and voted with the democrats to hold officials responsible for their part in illegal warrantless wiretapping, have now voted with the rest of the Republicans in opposing the new FISA replacement bill.

I count eleven Democrats who voted on the right side of things — with Republicans — this time around (I may have missed one or two). Kucinich, I know, did so for the right reasons. The other ten, I’m not so sure. You can see the vote results for yourself.

what’s really happening with an SSH SOCKS proxy

Filed under: Profession,Security — Tags: , , , , , — apotheon @ 03:16

I have recently written two articles in my TechRepublic IT Security column about browsing securely from unsecured networks via an SSH proxy. I figured I’d go into more detail about how it works behind the scenes. The specific articles in question are:

Technically, you can use PuTTY as a secure proxy on other OSes (such as FreeBSD and Debian GNU/Linux) as well, but OpenSSH is not only the obvious and default choice on such platforms — it’s also probably a better choice than PuTTY when you have it available. Regardless of what platform and tool you’re using, the explanation is essentially the same — and I’ll refer to your “SSH tool”, regardless of whether it’s OpenSSH or PuTTY.

Here’s how it works, in brief:

  1. When you set up the local proxy with the SSH tool, and you authenticate your SSH connection to the remote Unix/Linux system, you are creating two things:

    A. a connection to a remote system via SSH through which any data can be sent, including other networking protocols

    B. a local service that listens on a specific port and accepts whatever you give to it

  2. When you configure your browser to use a proxy, you are telling it to:

    A. send all HTTP requests to the SSH tool’s service

    B. listen for responses to those requests from the SSH tool’s service

  3. When the SSH tool receives requests from the browser, it forwards them to your remote Unix or Linux system. That forwarding is done over an encrypted SSH “tunnel”, which the local network only recognizes as a single SSH connection, regardless of what data may be passing through that connection.

  4. When the remote Unix or Linux system receives those requests, it acts as part of the proxy system, forwarding the requests to the Internet.

  5. When the remote system receives responses to those requests, it sends them back to your SSH tool.

  6. When your SSH tool gets them, your browser gets them.

As long as you have a broadband Internet connection at the location of the remote Unix/Linux system, you should not notice any real connection performance drop — unless the network you’re using with the local client system has an Internet connection significantly greater than that of the network where your remote system is connected. Assuming a 1.5Mbps connection at your home network (and assuming the home network is where the remote system is located), your connection to the Internet should be at a 1.5Mbps rate unless the network where you have your local client connected is slower.

Now . . . there may be some latency. You might be getting that 1.5Mbps rate (or whatever your ISP actually gives you, which may be less than the advertised 1.5Mbps) a tiny fraction of a second later than usual. It should be such a minor latency difference that you’ll never notice, however — unless there’s something odd going on, like your connection getting routed from your location in Kansas, through China, and back to Colorado where your home network is located. Of course, that’s absurdly unlikely. Like I said: “unless there’s something odd going on.”

There are a few more points that need to be made:

  • This is not the same as X forwarding over SSH, MS Windows Remote Desktop, or any other remote application access along those lines. All applications are being run locally, on your local client system. All that is being sent back and forth between your local client and your remote server is networking protocol data. If actual GUI application interface data were being sent back and forth:

    A. It could have a significant effect on networking performance. HTTP requests and responses alone are generally quite light-weight, carrying very little data across the network. GUI interface data, on the other hand, is very “heavy”, requiring a lot more data to be carried across the network connection — thus consuming more bandwidth that might otherwise be used to ensure quick response to network requests.

    B. Any file operations and other application behavior that depends upon local conditions treats the remote system as the local system, because it is the local system to the application. This means that (for instance) if you download a file with a browser run on the remote system via some kind of “remote desktop” software (like VNC, X forwarding, and MS Windows Remote Desktop), it will be downloaded to your remote server, on your home network — and not on the machine you’re using as your client system on the network away from home.

  • Because all the local, unsecured network sees is your encrypted SSH tunnel, nobody can “listen in” on your Web traffic through that tunnel. Any network packets sent through that tunnel are protected against eavesdropping of any kind by the strong encryption employed by SSH. The SSH protocol itself is designed so that your authentication (where login username and password) are sent to the server is encrypted as well, so that eavesdroppers cannot even pick that out of the network communications being sent back and forth. It is, however, still advisable to use key-based authentication, and to disable password authentication entirely on the server if you can, just to eliminate opportunity for brute force password cracking attacks and similar issues.

  • When setting up your proxy configuration options on your browser, don’t forget that you should configure it to use the localhost IP address (127.0.0.1) and the port number specified in your SSH tool’s proxy setup (8080 in the examples in both articles, though you may end up selecting a different port number). If you configure it to use the IP address or hostname of the remote network, your proxy connection won’t be set up properly.

Hopefully that helps settle any confusion or misunderstanding that may exist in readers of those articles. Let me know if you (my readers) have any questions.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License