random neuron misfires

This is a couple of years old, but bears repeating here in-full. With the recent news that travelers’ laptops and effects may be indefinitely detained at the border, the issue of our basic human right to privacy rears its head again.

” Federal agents may take a traveler’s laptop or other electronic device to an off-site location for an unspecified period of time without any suspicion of wrongdoing, as part of border search policies the Department of Homeland Security recently disclosed.

Also, officials may share copies of the laptop’s contents with other agencies and private entities for language translation, data decryption or other reasons, according to the policies, dated July 16 and issued by two DHS agencies, U.S. Customs and Border Protection and U.S. Immigration and Customs Enforcement.”

Original essay from Bruce follows:

The Eternal Value of Privacy
Bruce Schneier Email 05.18.06

The most common retort against privacy advocates — by those in favor of ID checks, cameras, databases, data mining and other wholesale surveillance measures — is this line: “If you aren’t doing anything wrong, what do you have to hide?”

Some clever answers: “If I’m not doing anything wrong, then you have no cause to watch me.” “Because the government gets to define what’s wrong, and they keep changing the definition.” “Because you might do something wrong with my information.” My problem with quips like these — as right as they are — is that they accept the premise that privacy is about hiding a wrong. It’s not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect.

Two proverbs say it best: Quis custodiet custodes ipsos? (”Who watches the watchers?”) and “Absolute power corrupts absolutely.”

Cardinal Richelieu understood the value of surveillance when he famously said, “If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged.” Watch someone long enough, and you’ll find something to arrest — or just blackmail — with. Privacy is important because without it, surveillance information will be abused: to peep, to sell to marketers and to spy on political enemies — whoever they happen to be at the time.

Privacy protects us from abuses by those in power, even if we’re doing nothing wrong at the time of surveillance.

We do nothing wrong when we make love or go to the bathroom. We are not deliberately hiding anything when we seek out private places for reflection or conversation. We keep private journals, sing in the privacy of the shower, and write letters to secret lovers and then burn them. Privacy is a basic human need.

A future in which privacy would face constant assault was so alien to the framers of the Constitution that it never occurred to them to call out privacy as an explicit right. Privacy was inherent to the nobility of their being and their cause. Of course being watched in your own home was unreasonable. Watching at all was an act so unseemly as to be inconceivable among gentlemen in their day. You watched convicted criminals, not free citizens. You ruled your own home. It’s intrinsic to the concept of liberty.

For if we are observed in all matters, we are constantly under threat of correction, judgment, criticism, even plagiarism of our own uniqueness. We become children, fettered under watchful eyes, constantly fearful that — either now or in the uncertain future — patterns we leave behind will be brought back to implicate us, by whatever authority has now become focused upon our once-private and innocent acts. We lose our individuality, because everything we do is observable and recordable.

How many of us have paused during conversation in the past four-and-a-half years, suddenly aware that we might be eavesdropped on? Probably it was a phone conversation, although maybe it was an e-mail or instant-message exchange or a conversation in a public place. Maybe the topic was terrorism, or politics, or Islam. We stop suddenly, momentarily afraid that our words might be taken out of context, then we laugh at our paranoia and go on. But our demeanor has changed, and our words are subtly altered.

This is the loss of freedom we face when our privacy is taken from us. This is life in former East Germany, or life in Saddam Hussein’s Iraq. And it’s our future as we allow an ever-intrusive eye into our personal, private lives.

Too many wrongly characterize the debate as “security versus privacy.” The real choice is liberty versus control. Tyranny, whether it arises under threat of foreign physical attack or under constant domestic authoritative scrutiny, is still tyranny. Liberty requires security without intrusion, security plus privacy. Widespread police surveillance is the very definition of a police state. And that’s why we should champion privacy even when we have nothing to hide.

Another quote of the day… a follow-up to my previous post about the ridiculous security theater presented by the TSA.

“But governments need to overreact! If you don’t think of the children, the terrorists have won!”

“Ah but if you don’t think of the terrorists, the children have won!”

There seems to be a lot of “confusion” lately about what exactly the proper screening requirements are of TSA employees and the new regulations governing domestic flight and travel.

The TSA has announced new requirements that claim to be for “increased security”. The requirement goes on to say:

Beginning Saturday, June 21, 2008 passengers that willfully refuse to provide identification at security checkpoint will be denied access to the secure area of airports. This change will apply exclusively to individuals that simply refuse to provide any identification or assist transportation security officers in ascertaining their identity.

This new procedure will not affect passengers that may have misplaced, lost or otherwise do not have ID but are cooperative with officers. Cooperative passengers without ID may be subjected to additional screening protocols, including enhanced physical screening, enhanced carry-on and/or checked baggage screening, interviews with behavior detection or law enforcement officers and other measures.

Note my emphasis in the above quote. This reads that you are required to show identification when requested, but not if you have lost your ID and cooperate with officers.

So basically this has nothing at all to do with security. Let’s also not forget that the alleged 9/11 hijackers had valid, legally-issued credentials when they boarded those planes. They did so within perfectly legal guidelines, without violating any laws or regulations.

What would stop someone else from doing the same? Answer: NOTHING!

Incidentally, you can’t “show identification”, because “identification” is an act or process. Showing “credentials” would have been a proper way to express that… but perhaps these are more examples of “Doublespeak” from US.gov.

In his bestselling book Doublespeak, William Lutz notes that doublespeak is not an accident or a “slip of the tongue.” Instead, it is a deliberate, calculated misuse of language.

Lutz provides several defining attributes of doublespeak:

• misleads
• distorts reality
• pretends to communicate
• makes the bad seem good
• avoids or shifts responsibility
• makes the negative appear positive
• creates a false verbal map of the world
• limits, conceals, corrupts, and prevents thought
• makes the unpleasant appear attractive or tolerable
• creates incongruity between reality and what is said or not said

Sound familiar?

This is yet another example of “Security Theater” from a corrupt government that continues to propagate lies to uphold their agenda.

There is even one detailed account from travel author Edward Hasbrouck that explains how he was asked to present his ID from neither an airline representative or a member of the TSA, and nearly arrested for simply asking the question “Who are you?” to the person demanding he present his credentials.

In fact, the 9th Circuit Court of Appeals ruled that you don’t have to present ID if you are willing to subject yourself to a more-thorough search at the security checkpoint. This was part of the Gilmore v. Gonzales ruling.

But it seems that the TSA is going back on their own documented regulations, by making it a requirement to present photo ID when asked, even though you are legally not required to do so.

And lastly, does this banner, emblazened on many TSA webpages seem a bit ominous?

“Behavior Detection Officers are Looking Out for You”:

It almost seems… familiar.

Don’t they realize that the book 1984 by George Orwell almost 60 years ago was meant to be a warning, not a guidebook on how to run this country?

The TSA shouldn’t be allowed to use the eagle (representing freedom) and the stars and stripes (representing the sacrifice to achieve that freedom) in their logo.

I woke up this morning to very slow response time on my server, and decided to check the statistics. I graph these things with a great deal of detail so I can see precisely when it happened and begin narrowing down where I need to go to fix it or report it upstream.

In this case, my incoming connections went from under 500/second to well over 3,000/second. Owch!

You can see the “wall” of traffic growing from our normal traffic rate to this enormously-increased rate:

I checked all of the services, logs and protocols and didn’t see anything out of the ordinary. I started shutting down services one at a time and regenerated the graphs, to see if I could see any change.

One thing I noticed was that I had poppassd open on the public port. Not a huge problem, but it was something that was unnecessary on the public interface. I locked that down with iptables:

$IPT -A INPUT -s ! 127.0.0.1 -d ! 127.0.0.1 -p tcp -m tcp --dport 106 -j DROP

But as I looked further, I noticed even more:

netstat -tulpn | grep LISTEN

This showed that I had Squid listening on the public interface as well (0.0.0.0:3128). I jumped to the squid logs and was shocked to see that they were scrolling so fast that I couldn’t even read them. Ut oh!

Apparently some enterprising young spammer found my squid instance and decided to try to hijack it for his own needs. It was already locked down internally in my squid.conf to restrict use from only my block of IPs, but he was hammering it with 8,466 separate IPs trying to use it to send spam on port 25.

# cat access.log* | cut -b20-300 | grep ':25' | perl -lne 'print /((?:\d+\.){3}\d+)/' | sort | uniq  | wc -l
8464

Damn! There goes a few gigabytes of bandwidth that were eaten in the last 11 hours while I was sleeping.

I locked that down in a similar fashion:

$IPT -A INPUT -s ! 127.0.0.1 -d ! 127.0.0.1 -p tcp -m tcp --dport 3128 -j DROP

A bit more poking around with nmap, netstat, Webmin, HotSanIC and other tools allowed me to lock down some other services that incorrectly bind to the public interface and not the internal interface.

The result is that we’re back to normal:

One last piece needed my attention. Because this was an active spam attack, propagated using the IP of my server as a vector, I had to make sure to check my mail logs and delist myself from the various RBLs who had listed me as a spammer for sending out 43,745 separate spam attempts through my IP in a matter of hours.

SpamCop originally listed me, but I corrected that, and a few others. I also reported it to my provider so they can be sure to keep a closer eye on it.

You can see the drop-off on the far right of the last two graphs above and in the traffic graph below.

Problem solved.

This is another case of yak shaving that all started with trying to implement imapproxy to proxy internal IMAP connections between Dovecot and SquirrelMail on my public servers.

Implementing imapproxy was a simple drop-in. All that was required was some server-side configuration to get Dovecot to listen to the server port that imapproxy uses, and then get imapproxy to listen on the public (external) port for clients to connect to.

In my /etc/dovecot/dovecot.conf, I set up the following:

protocols = imap imaps
protocol imap {
        listen = 127.0.0.1:14300
        ssl_listen = *:993
}
...
ssl_cert_file = /etc/ssl/certs/dovecot-ssl.crt
ssl_key_file = /etc/ssl/private/dovecot-ssl.key

In /etc/imapproxy.conf, I configured it as follows:

server_hostname 127.0.0.1
listen_port 143
listen_address 127.0.0.1
server_port 14300
...
tls_cert_file /etc/ssl/certs/dovecot-ssl.crt
tls_key_file /etc/ssl/private/dovecot-ssl.key

Restarting both, and now IMAP connections are proxied and kept open for the duration of the session. It is visibly faster now when interacting with IMAP over that connection.

For SquirrelMail, I had to tweak accordingly as well to listen on port 14300 on host 127.0.0.1. Under SquirrelMail’s config (Option 2 → A → 5 under the configure script), I changed the port to 14300. That now gets SquirrelMail talking to imapproxy, speeding up webmail by several orders of magnitude.

But it was still in the clear. Unfortuntely, there’s no easy way to just plug SquirrelMail into IMAP over SSL… so I had to use stunnel to do that:

/usr/bin/stunnel -P/var/run/ -c -d 1430 -r 127.0.0.1:993

Now I went back into SquirrelMail’s config and changed the port to 1430 from 14300. Now SquirrelMail is talking to the local imapproxy → Dovecot over SSL instead of plain text.

But now my Dovecot certs needed to be regenerated because they were close to expiring, and with the recent Debian PRNG problem, it was better to just re-gen all certs and keys anyway.

To do that, I had to do the following:

$ openssl genrsa -out dovecot-ssl.key 4096

$ openssl req -new -key dovecot-ssl.key -out dovecot-ssl.csr

I pasted the contents of that final CSR (dovecot-ssl.csr above) into the form at CACert and had them generate a new server certificate for my mail host: mail.gnu-designs.com, where my Dovecot instance resides. With that, I put those keys in their proper location and configured /etc/dovecot/dovecot.conf accordingly:

ssl_cert_file = /etc/ssl/certs/dovecot-ssl.crt
ssl_key_file = /etc/ssl/private/dovecot-ssl.key

Restarted Dovecot and now I’m properly secured with stronger, less vulnerable keys and certs.

But what about locking down SquirrelMail behind SSL as well?

To do that, I had to update my DNS to point mail.gnu-designs.com to a separate physical IP on the same machine. With Apache, you can’t have more than one SSL VirtualHost behind the same physical IP. Each new SSL host you want to deploy has to be on its own physical IP address.

So I had to change my DNS to point mail.gnu-designs.com from its present IP to a new IP on the same host. Now comes the tricky part… configuring Apache.

Since I run Debian, the Apache configuration is a bit… non-standard. In /etc/apache2/ports.conf, I had to change the Listen directive to listen on port 443 of that new IP.

Listen 72.36.135.43:443
Listen 72.36.135.43:80

And a VirtualHost stanza for that new SSL vhost had to be created..

Now my regular non-SSL stanza can be changed to look like this:

<VirtualHost *:80>
        ServerName mail.gnu-designs.com
        Redirect permanent / https://mail.gnu-designs.com/
</VirtualHost>

This will redirect non-SSL clients to the SSL version of the site, so their session is secured behind SSL on port 443. One last poke to make it possible to use the SSL VirtualHosts without having to import the upstream Root CA Certificate:

SSLCACertificateFile ssl.certificates/cacert-root.crt

From the Apache 2.x documentation:

This directive sets the all-in-one file where you can assemble the Certificates of Certification Authorities (CA) whose clients you deal with. These are used for Client Authentication. Such a file is simply the concatenation of the various PEM-encoded Certificate files, in order of preference.

I duplicated the same process for my other SSL vhost; spam.gnu-designs.com, for the DSPAM web interface.

If you’re not using dspam to reduce your spam by 99.9%, you should be. It runs circles around every OSS and commercial product I’ve tried, and I’ve been running it for years (see my previous posts on dspam for more background and hard data).

Conclusion:

I did a few things here:

1. Set up an IMAP proxy in front of Dovecot, my IMAP server which dramatically increased the responsiveness of the IMAP server
2. Configured that proxy to speak SSL (imaps on port 993) as well as plain imap (port 143)
3. Configured SquirrelMail to talk to the IMAP proxy over SSL only, using stunnel
4. Locked down two of my public-facing Apache vhosts with SSL (webmail and dspam)
5. Regenerated all SSL certificates and keys with stronger encryption using CACert
6. Imported the CACert root certificate and made it global within all of my Apache SSL vhosts

Now everything is a bit more secure than it was before… for now.

Last note: As I was writing this post, I realized that Wordpress was eating some characters in my <code> … </code> blocks. I looked around for a plugin to try to alleviate that, and found several, none of which worked properly.

I tried Code Auto-Escape which at first glance looked promising, but all it did was encode my code blocks into a single-line base64 string, and output that. Blech.

Then I tried one called Code Markup which had a very detailed explanation and several ways to use it. It too failed miserably on the most basic of code blocks (the Apache stanzas above).

It referenced several other markup and syntax highlighting plugins (geshi, highlighting with Enscript, etc.), none of these worked as advertised either.

What I finally found that DID work, was a a Java-based tool called Code Format Helper for Wordpress. Basically you paste your code block into the small java applet, and it converts all of the entities to encoded entities. You then paste that into your Wordpress post and submit that. You can see in the above post that it works perfectly.

Voila!