First off, this is a very very very specific issue which I think not many people will run in to. But as I found some forum posts here and there which look like the same I thought I'd post it nevertheless.

A while ago I was troubleshooting a situation where we seemed to experience some kind of delay in an application startup. More specific whenever we used Xming to connect to an OpenWindows desktop session on a Solaris server, we were seeing a delay of about 3 minutes before actually seeing the desktop. This delay was only seen when connecting to this specific Solaris server. Other servers did not posed this problem.

Very soon we found out that if we'd set all Windows Firewall Profiles to "off" on the Windows 7 client, we didn't saw the issue. Now one could think we needed to open some specifics port. We thought we had them all covered, but still no luck. In the end we let the firewall on, but for both in and outbound we built rules which were supposed to allow all traffic. The so called any rules ;) And we were still seeing the issue. Now what is that?!

So in comes the tracing...

Below is an excerpt from a trace on the client to the server when the Windows Firewall is ON:

In this trace I’ve filtered all other traffic than the one to port 2000. So in the background there’s more (client-server) traffic, such as regular X11 traffic. What we are seeing here is that the server(.10) is trying to reach the client (.227) on port 2000. The client does not respond to these queries. After +- 3 minutes the server continues X11 traffic and the user gets his desktop. Now this is quit odd... It's the client which is contact the server. Why is the server initiating traffic to the client?!

If we compare this with the trace to the server (.10) when the Windows Firewall is OFF:

Here we clearly see that the same traffic is sent by the server (.10), but the client (.227) immediately answers with RST, ACK response. Basically telling the server that there’s nothing there. After this entry the server/client communication continues. The users gets his desktop more or less instantly.

In the Solaris configuration there must be a configuration option which makes the server poll the client on port 2000 when launching an OpenWindows desktop from that client. The problem lies in the fact that the server waits for an answer, or times out after about 3 minutes, until he decides communication can go on. To be precise, on the client there’s nothing listing on port 2000, in a situation without a firewall, the client would answer with a RST stating that nothing is there and that communication can continue. A windows firewall however is by default working in “stealth mode”  (http://technet.microsoft.com/en-us/library/dd448557(WS.10).aspx ). As such the client doesn’t send the RST answer and the server waits for about 3 minutes before continuing and showing the desktop.

[First thought]: The Windows 7 firewall stealth mode is causing the server to keep retrying for a number of times

Now if we compare this with the trace where we connect to another server:

Here the server does NOT contact the client on port 2000 (or another port) and the desktop starts promptly.

[Conclusion 2]: That kind of traffic should hit the client on the first place!

Lucky a colleague which is more experienced in Solaris then me had a golden hunch. When he connected using Xming he started toying around with the client settings. In one of his attempts he tried connecting with another font selected. And voila! So it seems we are trying to connect to a server where we say we want to use a specific font which the server hasn't. As such it tries search for this font and even contacts the client for it. I've no idea what the places are it searches, but this was definitely the culprit!

[Final conclusion]: If you are seeing this behavior, check your fonts!

Just for completeness: here’s the exact same issue also discussed:

• http://blog.mbless.de/ubuntu-xming-windows-und-die-ports
• http://www.sevenforums.com/network-sharing/47190-xming-xdmcp-blocked-windows-7-firewall.html
• http://www.linuxmisc.com/3-solaris/5d97e592d7a39016.htm

One of my colleagues was having troubles accessing an HTTPS site. The site is secured with a certificate coming from an Active Directory Certificate Authority. Now I know of a bug where if you have a pinned website on your taskbar, and from that browser instance you open an HTTPS site with an untrusted certificate, there’s no "continue anyway” button…

Now this wasn’t the case today. He had the “continue anyway” option, where you typically click on, load the site and check the certificate. However, after clicking, it didn’t go trough, it just remained at the same page. We installed the root CA manually in the trusted root authorities, but still no improvements. When verifying the root certificate in the MMC we also saw it mentioned that the digital signature was invalid.. odd!

Using that as a query for google we quickly came across this:

• RSA keys under 1024 bits are blocked
• Blocking RSA Keys less than 1024 bits (part 2)
• How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)

If you read those first two carefully you’ll see the update will be released as a critical non-security update on august 14th for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

An example of a bad certificate:

Now how come he was having this issue now already?! Ahah, now comes the clue! He was using Windows 8! Now I am too, and I’m not having that problem with that specific site, but here’s the difference:

• Windows 8 with issue: Windows 8 Release Preview: build 8400
• Windows 8 without issue: Windows 8 Consumer Preview: build 8250

So it seems they’ve included this update somewhere in the build process of Windows 8.

Having certificates with an RSA key < 1024 is probably not really the case for most of us, but be sure to double check those certificates and their (intermediate) roots! Especially for those customer facing sites where you can’t control what updates hit the clients and thus potentially might be denied access to your sites.