Wednesday, January 23, 2008

Monitoring TCP connection open/close in Ethereal

I found the following filter expression to be useful when I need to monitor only the TCP connection open/close.
(tcp.flags.syn == 1 || tcp.flags.fin == 1 || tcp.flags.reset == 1)

For e.g. when you wish to monitor all the SSL connections opened and closed, the following Filter is good:
(tcp.port == 443) && (tcp.flags.syn == 1 || tcp.flags.fin == 1 || tcp.flags.reset == 1)
You can also combine the IP address of the server you are interested in, like:
(tcp.port == 443) && (tcp.flags.syn == 1 || tcp.flags.fin == 1 || tcp.flags.reset == 1) && (ip.addr == X.X.X.X)
Monitoring the connection open/close activity helps in understanding the client behavior. For e.g. generally Firefox and IE both open multiple (I have seen three or four at the max) https connections and reuse the same SSL session ID. These connections are concurrently open and most of them don't get closed from the browser side until the web server closes them.

Thursday, January 17, 2008

SSL session reuse - how to find if supported?

Before I delve deeper, its a good idea to be clear about SSL session reuse. Every time when a client (browser, curl, etc.) connects to a server over SSL, the server creates a session for that connection. This session ID is sent as a part of the Server Hello message. This is to make things efficient, in case the client has any plans of closing the current connection and reconnect in the near future. Most of the servers have a time out for these sessions (I think 24 hours is a common value, unless pressed for space).

When the client connects to the same server again, it can send the same session ID as a part of the Client Hello. The server will first look up if it can find any sessions with that ID. If found, the same session will be reused. Thus the time spent in verifying the certs and negotiating the keys is saved. If the server cannot find a matching session, then it responds with a new session ID and its certificate in Server Hello message. The client knows that it has to verity the cert and negotiate the key again.

Considerable amount of time is spent in validating server certs. Reusing SSL session will save this time.

But when there is more than one server behind a load balancer, and the client connects only to the load balancer, there is a likelihood that the load balancer forwards second connection to a different server. But luckily, most of the load balancers today can be configured to provide the SSL session stickiness, and hence they will forward the request properly. From my understanding, most of the load balancers achieve SSL session stickiness through IP stickiness.

The question is: how to find out if a server supports SSL session reuse? Or, if you are hitting load balancer, how to find out if the load balancer maintains SSL session stickiness?

OpenSSL has a useful application called "s_client" which can be used to find out if SSL session is supported. The following command will do the magic:
openssl s_client -reconnect -state -prexit -connect ServerURL
The important option here is "-reconnect". It will disconnect and reconnect to the server 5 times using the same SSL session ID, that came in the first Server Hello message. It will print each time if the same session ID is reused or a new session ID is sent in the Server Hello message.

Friday, January 11, 2008

Learning Perl - ebooks & resources

I ventured into brushing up my Perl knowledge, as its really a long time since I read a book on Perl. I found the following resources useful:
  1. Beginning Perl by Simon Cozens. I think this is one of the best books to begin Perl programming.
  2. The perldoc website. This is not really book or a cogent order of tutorials, but an excellent reference once you are familiar with the basics.
  3. A collection of resources to learn Perl from the www.freeprogrammingresources.com website.
And there is always perldoc, to refer to topics/functions/modules off line.

Monday, January 07, 2008

Wierd error while setting up SFTP

Recently I had to set up SFTP access in my RedHat Linux box. After uncommenting the "Subsystem sftp ..." in the /etc/ssh/sshd_conf file, I restarted the sshd. When I tried to login, I am prompted for password but immediately I was getting this error message:
Received message too long 1214606444
Hmm ... I couldn't make out what could be the reason. Then when I Googled I cam across this page. I had the same issue in my .bashrc file where I had echoed a welcome message :-(. I confirmed that by taking the hex value of the number above (which is 0x48656C6C) which are the ASCII values of 'H', 'e', 'l' and 'l' respectively. The actual message was "Hello, have a great session!".

Moral of the story: Don't have any unnecessary echo messages in your .bash_profile or .bashrc files.