Roy's musings

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.

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...