Another letter to Steve Gibson that I'm reposting here in case it's not read on Security Now.

Hey Steve,

Just finished SN200. That was a good one. Just wanted to add a bit of info that you've never mentioned and might be valuable to your listeners.

Leo mentioned that his port 22222 is forwarded to his Skype machine and Skype is listening on that port so he feels it's safe about that hole. What may not be known to some listeners is that good-behaving programs will not bind to a port on which another process is already bound. In other words, if Skype is listening on 22222 then other, possibly exploitable, processes like Windows service host will not be listening on 22222.

It is possible for malware or security tools to listen in on bound ports which is why I said "good-behaving programs" but if you've got malware it's already too late.

Update 2009/07/07

I realized later that I neglected protocols. It's possible to have one process listening on TCP 22222 while another process listens on UDP 22222. Forwarding both TCP and UDP ports 22222 to your local IP when only one is "bound" by a known process is a security risk since the other could be open to exploits.

I often write in to Steve Gibson to ask questions, provide feedback, or just rant about a security topic. While I have received responses a few times, most go unnoticed due to the volume of feedback Steve receives so I've decided to repost all my feedback to Steve here on my blog.

In response to a comment by Shawn Polson of Middletown, Delaware, Steve and Leo revisit the idea of encrypting all network connections. Shawn states that SSL shouldn't be used everywhere for efficiency reasons since SSL connections are not cached locally nor by proxies. While he makes a good point, Shawn's is not a technical limitation but just an economical issue of bandwidth. Steve and Leo continue on by clarifying their point that it's more of a general wish that all connections for email, web etc are encrypted, not specifically SSL. I agree that all connections should be secure, and Shawn is also right that there will be a bandwidth hit if content is not cached. With that said, I think it should be noted that there is also a technical reason why you can't enable SSL on every site and it has to do with a limitation of name based virtual hosts.

My last post focused on SEO drawbacks of framed URL shorteners which is mostly a concern for content creators. I later realized that URL shorteners which frame entire pages, like the Diggbar and BurnURL, are even worse than I originally though. These services are not only stealing page rank points (and arguably stealing content) they are shifting the third-party distrust to the target site and essentially become a man-in-the-middle.

Tokyo is one of the greatest places to live but once in a while I find sites or services that prohibit connections from outside the US such as Pandora, Hulu, and some books on Audible. Fortunately I have a server in the US so I set about trying to get around these international restrictions by proxying certain connections through the server. Unfortunately my server's connection is not very fast and it's also asynchronous so needed to test proxying methods to determine which, if any, might be able to support streaming content. There may be other ways to proxy but I chose to test an SSH tunnel and a basic Squid proxy. Results below the break.

Let me start, as always, by saying that Security Now! is great podcast that I look forward to listening every week. In episode 154 Steve answers a question to a listeners who says he noticed a virus warning about "Wizmo", Steve's Windows tweaking tool. Steve answers by basically saying that Wizmo is safe and known to trigger false positives by some AV software so the warning can be ignored. That's some bad advice.

While I have no doubt that the Wizmo.exe file compiled by Steve is completely safe, the question is "is the copy of Wizmo.exe the listener downloaded exactly the same as the one Steve compiled?".

When considering where to place encrypted container files, many people recommend creating dummy files like "my_hawaii_vacation.avi" or creating deep subdirectories to hide your encrypted files. The AVI idea is nice because you can make a large container but it's easy to see it's fake since it won't play and deep directories are a hassle. Sure, Truecrypt has plausible deniability but any extra security/deniability that does not incur additional inconvenience is always a good thing.

According to the Truecrypt docs

This is my crazy password creation scheme. Using this method you will be able to create ridiculously strong passwords like Wh++2b$3,+@m@c3 yet still be able to remember the password after only a few tries. As far as I know, this scheme is not vulnerable to weaknesses in other password schemes. Read on to find out more.

I've been stumbling onto blogs that provide "tips" for installing a WiFi network. Unfortunately several of these sites suggest disabling SSID broadcast, enabling MAC address filtering and other terrible suggestions as security tips. This is utter nonsense so I'm going to show you why NOT doing this is a better decision.

Take this analogy. Everyone knows banks have cash. If I take down the "Bank" sign in front of the bank it doesn't make the bank any more secure because bank robbers still know it's a bank. Removing the sign only makes it harder for customers to find. This is analogous to hiding your SSID. It decreases usability for legit users but has no impact on bad guys.

Lets use the bank again but this time the bank has a guard who will only allow entry to people wearing a simple sticker with a valid account number. A robber could watch any customer enter, copy their account number and walk right in. On the other hand, if you forgot your account number you'd have to refer to your statements to look it up. This guard is about as ineffective as MAC address filtering.

Security Now! Episode 134

For those who are not familiar with Security Now!, I highly recommend it.  It's a great podcast and I have certainly learned a thing or two but it's not without it's flaws, some of which go uncorrected.  This is one of those uncorrected yet important flaws that I've mentioned to Steve using his feedback form but sadly got no mention on the air...