Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Here is the structure we have, 3 servers in location A (172.22.25.X) and 3 servers in location B (192.168.140.X). One of the 3 servers in each location creates an SSL connection to the other 4 servers, like this:

A1 connects to A2, A3, B2 and B3 B1 connects to A2, A3, B2 and B3

When A1 connects to any of the servers, the SSL Handshake takes less than 300ms.

When B1 connects to A2 and A3, the SSL Handshake takes less than 300ms.

But when B1 connects to B2 or B3, the first time it takes around 9 seconds for the handshake to be finished. Following requests again take less than 300ms for a short while (a minute or two), and then back to the 9 seconds issue.

All 6 servers have the same software on them, running on the same OS (Windows Server 2008 R2 64 bit).

We tried all kinds of changes (enabling and disabling Windows Firewall, removing the antivirus software, changing the switch) but still the same issue continues, and we are out of ideas what it could be causing it.

Any ideas?

share|improve this question

closed as off-topic by Lucas Kauffman, Xander, TildalWave, NULLZ, Terry Chia Jul 20 '13 at 3:12

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about general computing hardware and software are off-topic here, but can be asked on Super User." – Lucas Kauffman, Xander, TildalWave, NULLZ, Terry Chia
If this question can be reworded to fit the rules in the help center, please edit the question.

The first thing you should do is perform a network capture. Even if you don't decrypt, you can still see if the number of packets exchanged at negotiation is higher. And if you can access a server key, you can use a tool like ssldump to see what negotiations are going on. In other words, you need to gather more data so that you can ask the right questions (e.g., "why does it negotiate algorithm A on the WAN but algorithm B on the LAN?") Good luck. – gowenfawr Jul 19 '13 at 21:03

Usual suspects for overlong SSL handshake are rebuilding of certificate chains and CRL checks. A SSL client will validate the certificate from the server, which may entail obtaining the issuing CA certificate and/or downloading a CRL which covers the said certificate; both operations follow URL found in the certificates themselves. When a certificate has a local-only URL in it (e.g. an ldap:// URL which makes sense only in a given site), the relevant machine may need some time before noticing that the URL cannot be used, and, in particular, it may stall on a DNS lookup.

I suggest you run a network monitor tool (e.g. Microsoft Network Monitor) on both client and server, to see what happens during one of the overlong handshakes. This tool will be able to show you the individual handshake messages, but also other network activity -- DNS queries which fail after two or three seconds would appear there. (Knowing how a SSL handshake works can help; see this answer for a primer.)

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.