Poojan (Wagh) Blog

Part of the reason I used Thematic at CircuitDesign.info was because of its ability to do a child theme (See: How I used a WordPress Child Theme To Redesign My Blog The Smart Way).

Recently, I upgraded Thematic, and some of my custom RSS feeds disappeared. (I have 3 different RSS feeds at circuitdesign.info depending on the clientele.) Unfortunately, I didn’t take advantage of this function, so I lost the two custom feeds.

This time, I finally made a custom child theme to support these RSS feeds. The important thing I needed to do was add a couple RSS link to the wp_head function. Read the rest of this entry »

I often find myself trying to read articles, when it’s not appropriate. No: I don’t mean porn. I mean that I stumble across something at work, or I see something that I want to look into more while zeroing out my inbox. The worst-case scenario is that I start skimming the article, giving myself a headache, and not really understanding what’s in the article.

When a digression occurs at work for something other than a web site, I write it down in my Hipster PDA. This habit keeps me focused on work and I can continue to move on. However, it’s quite difficult to write down a Web article and URL.

I came across (likely when I didn’t have time for it) a Firefox extension called Read it Later. This is very simple: you install the extension. Then, you get a little book button in your upper right corner (next to the search bar). You’ll also get a check mark in your URL bar.

When you find something you want to read later, you simply click the check mark. The cool thing is that this extension automatically creates an anonymous user key and password that can be used to sync between multiple computers. (I only use this to tag things that are public.)

If you go to another computer, you can select it to use the same user key and password and it will sync your list of web sites to read later. That’s especially good for me, because I tend to encounter things at work that I can read at home.

Clicking the Read it Later button alone will bring up a page that you said you wanted to read later (I think it picks the oldes page).

There was  apost over at wikidpad-devel | Google Groups, where someone talked about using Drop Box to sync WikidPad databases. The person used the original_sqlite database format of WikidPad.

I personally like the “Original SQLite” format for storage. This internal database has the following properties:

The data for your wiki is stored in plain text under the data
directory of the directory your Wiki config is stored in. There is one
file per wiki word. The database to index the wiki is stored in the
file “wikiovw.sli”.

Which is great, because I get all the features of SQLite search/indexing, but all my pages are in a text format.

The great thing about this setup is that I can use version-control to keep them in sync. I originally thought about using SubVersion. However, I decided to go with a distributed version control system instead. I took a hard look at both Mercurial and Git. I decided on Git since it does implicit renames rather than explicit renames. This means that I don’t have to write any hooks in WikidPad for when there is a rename/copy of a page. Of course, I could do without this feature in Mercurial, and it would still work. It’s just nice that Git does provide the benefit of diff-based storage without the need for explicit copies/renames/moves.

So, I keep two WikidPad notebooks going: a Work one, and a Personal one. The Personal one is on all the computers at home (Windows Laptop, Windows Desktop, FreeBSD server). It is also on a USB thumb drive. One of the features of git is that the entire repository comes along with a working copy. Let’s say I’m editing a WikidPad page at home that I already edited on another computer. I don’t have to worry about syncing. I can check in both changesets and merge later. This is a feature that Mercurial also has.

That’s the great thing about text files: they work very well with version-control systems.

I also use the ScrapBook extension from Firefox to archive/annotate pages from the web. The extension saves an index of the pages in RDF format. RDF is a form of XML, which was touted as a better way to save data because it is text-based. Curiously, XML doesn’t work well with any merge tool I’ve come across. I’ll post about my descent down this rat-hole (and how I got around it) later.

I use WikidPad at work (and at home) to keep logs/notes on tasks that I’m doing (or want to do). One nice feature of WikidPad is that it has an “always on top” setting which keeps the WikidPad window on top while another window (behind it) is active.

I use this feature with my VNC session (most of my work is on Linux) so that I can copy/paste results and snippets. Unfortunately, a lot of time the result itself (due to its placement within the VNC session) is right behind the WikidPad window. It would be nice to have WikidPad be transparent.

Turns out, AutoHotkey already has this feature. The following script does the trick:

    #T::
    DetectHiddenWindows, on
    WinGet, curtrans, Transparent, A
    if ! curtrans
        curtrans = 255
    newtrans := curtrans - 64
    if newtrans > 0
    {
        WinSet, Transparent, %newtrans%, A

    }
    else
    {
        WinSet, Transparent, 255, A
        WinSet, Transparent, OFF, A
    }
    return

    #w::
    DetectHiddenWindows, on
    WinSet, TransColor, Black 128, A
    return

    #o::
    WinSet, Transparent, 255, A
    WinSet, Transparent, OFF, A
    return

    #g::  ; Press Win+G to show the current settings of the window under the mouse.
    MouseGetPos,,, MouseWin
    WinGet, Transparent, Transparent, ahk_id %MouseWin%
    WinGet, TransColor, TransColor, ahk_id %MouseWin%
    ToolTip Translucency:`t%Transparent%`nTransColor:`t%TransColor%
    return

Key codes:

<Win>+T: Increments transparency by 25% (with wrap-around)
<Win>+W: Set black color to be 50% transparent (also does click-through)
<Win>+O: Reset transparency settings

Here’s a screenshot of a partially transparent WikidPad hovering over a full-screen VNC session; Ion3 is my window manager:

I was a little worried about WordPress login’s, and about whether the data was sent in cleartext. Besides this point, was it possible for snoop on my traffic, steal my session cookie, and then impersonate me? It turns out the answer is yes. So, I wanted to lock down my blog to prevent traffic snooping and to encrypt the login.

This class of problems has been solved. The preferred method to do this would be SSL.

To use SSL, you need two things: a unique IP and an SSL certificate. Dreamhost charges around $4/month for a unique IP. You can get an SSL certificate for around $10/year. I don’t mind paying these charges. However, I have serveral blogs at different domains. I didn’t really want all the blogs to be SSL. However, I did want to protect my logins from being sniffed/hijacked.

Note that there were a couple of ways I was accessing my blog. I use the regular WordPress web interface (which calls for a method to encrypt traffic through FireFox) and I use Winodws Live Writer (WLW). Firefox lets you use either a SOCKS proxy or an HTTP proxy. WLW allows you to specify only an HTTP proxy. However, I found that Privoxy can act as an adaptor, converting HTTP proxy traffic into SOCKS traffic.

I came up with several solutions. In chronological order:

SSH

By far the easiest and best way to get security without paying for SSL is SSH. This has been well-documented elsewhere. You can tunnel your web (http) traffic in SSH. Your traffic then inherits the encryption and authentication features of SSH.
The best way to tunnel SSH is to set up a dynamic tunnel; this is the same as a SOCKS proxy. If you’re using the command-line on UNIX/Linux, this can be done with a:

ssh -D :1080 -N @.dreamhost.com

This will only listen for connections on the current machine. (The machine in which you type the above command). If you want to set up this machine as a secure SOCKS server for other machines to connect to, you type:

ssh -D *:1080 -N @

I did this on my FreeBSD machine once. I can then connect to it from other machines on my network (Windows machines for example).
I use this SSH-based SOCKS proxy in combination with the Firefox Add-On FoxyProxy. FoxyProxy lets you set pattern-based rules to determine whether to send traffic through a proxy (and which proxy).

HTTP-Tunnel

The SSH method works very well from home. Unfortunately, my employer doesn’t allow SSH traffic through its firewall. In fact, the only traffic that is allowed is HTTP traffic, through their own HTTP proxy.
I found a very promising and powerful program called HTTP-Tunnel. This program lets you set up a SOCKS server that translates all your traffic into HTTP requests.
The program is composed of a client (a Perl script running on your machine at work) and a server (which can be a perl script or a PHP script). Since the only access Dreamhost gives is FTP/SSH/telnet/HTTP, I ran the PHP version (which runs as a PHP CGI script). (The perl version listens for traffic on a specific port.)
To get this to work on Windows, I installed CygWin. I tried ActiveState Perl. However, I found the necessary packages for encryption (MCrypt & OpenSSL::RSA::Crypt, available from CPAN) difficult to find & install using ActiveState.
It was difficult to get the parameter sets (& Perl modules) set up correctly for HTTP-Tunnel to work. However, in th end, it did work. I was able to get data from firefox (once again with FoxyProxy) through the tunnel to DreamHost. Note that once I was in DreamHost’s network, I wasn’t as worried. At some level, you have to trust DreamHost not to spy on your traffic. In my case, there’s not a a lot of interesting stuff to look at. I just want unauthorized users getting access to my blog.
The main difficulty with HTTP-Tunnel is that it seems to be unmaintained for quite a while. In addition, I’m not qualified (nor do I have the time) to analyze the code to verify its security (and uncover any vulnerabilities).
One final note: I wasn’t able to use HTTP-Tunnel as a SOCKS server for SSH. (Don’t be confused with using SSH to create a SOCKS tunnel.) What I was trying to do here is run an SSH session which used the SOCKS tunnel (created by HTTP-Tunnel) as a communications channel. I tried both OpenSSH and PuTTY. Both failed because they for some reason, the HTTP-Tunnel program just stalled during SSH key negotiation.

WordPress Plugins

I found two excellent plugins that took care of web logins to WordPress.

Restrict WordPress cookies by IP

One thing about TCP/IP is that due to the 3-way handshake, you cannot spoof an IP. (You can send a SYN packet, but you can’t negotiate a link from a bogus IP address.) So, if we restrict the cookie to come from a specific address (by encoding the IP address in the cookie), we can verify that the person making a request using this cookie is the real person (i.e. has the correct IP address).
In fact, w-shadow wrote a WordPress plug-in that does exactly this. It’s even up-to-date for WordPress 2.6. Note, however, that this plug-in won’t prevent man-in-the-middle attacks. I’ve concluded that such attacks are pretty difficult to to orchestrate, since you need to be upstream from the victim.

Use OpenID

The WP-OpenID plugin allows you to associate a WordPress user with an OpenID account. I have an OpenID provider. Associating with OpenID allows me to login (using SSL) to OpenID first. Then, I automatically get access to my blog account.
Unfortunately, this scheme does nothing to help with hijacking the session. So, it should be used in combination with w-shadow’s plugin.

Encrypt the login

I found another jewel of a plug-in: Semisecure Login Reimagined. This plugin sends a public RSA key to the client (via Javascript). It encrypts (using Javascript in the client) the username/password using this public key. The server (and only the server) can decrypt the username/password.
So, merely logging in does not send your username/password in the clear.

Summary

Obviously none of the above is as good as SSL. Pretty much everything supports SSL (including the HTTP proxy at my work). However, given the cost of SSL (unique IP & certificate), I feel that the WordPress plugins (when I am not at home) and tunneling over SSH (when I am at home) give my username/password & cookies fairly sufficient protection from being sniffed/hijacked.