Home / server / Questions / 231036
Accepted
Niklas B
Asked: 2011-02-04 23:54:43 +0800 CST

SSL connection hangs as client hello (curl, openssl client, apt-get, wget, everything)

  • 772

I've run into a problem on my Debian VPS (a xen domU) regarding SSL. Namely almost all SSL connections hangs at client hello. For example:

# curl -vI https://graph.facebook.com

  • About to connect() to graph.facebook.com port 443 (#0)
  • Trying 66.220.146.48... connected
  • Connected to graph.facebook.com (66.220.146.48) port 443 (#0)
  • successfully set certificate verify locations:
  • CAfile: none CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):

It's the same when using the openssl client. However, some of the SSL traffic works (for example https://www.nordea.se).

Server

#uname -a

Linux server.com 2.6.26-1-xen-amd64 #1 SMP Fri Mar 13 21:39:38 UTC 2009 x86_64 GNU/Linux

It does however work on my Dom 0 (the main xen host).

Apt-get

I can't even run apt-get update with the debian security sources (hangs on reading headers)

Open SSL

At the begining I thought I had an old openssl client (0.9.8o-4) since I appeared to have a newer on the Dom 0 (0.9.8g-15+lenny8) but doing a manuanl update on the openssl deb didn't help.

Open SSL Client

This is the full output of when the openssl client hangs: http://pastebin.com/PAjwMap9

Closing thoughts

I've Googled the crap out of this, and I'm not getting any further. I've seen problems with curl, apt-get etc. but they are all specific relating to the very application - not general for the system. Any thoughts?

xen debian apt openssl tls

5 Answers

  1. Best Answer

    After some discussions back and forth with my hostingprovider it turned out that they had a MTU problem with the IP Chains that my DomU was using (but not the Dom0). I wanted to thank everyone who helped me out in the process, your help was invaluable :)

    • 11

  2. This is old and already answered, but we suffered the same exact issue and the cause was related, but different.

    The key was to sniff traffic on our edge router, where we saw ICMP messages to the server (GitHub.com) asking for fragmentation. This was messing the connection, with retransmissions, duplicated ACKs and so.

    enter image description here

    The ICMP packet had a field, MTU of next hop with a weird value, 1450. The usual value is 1500.

    enter image description here

    We checked our router and one of the interfaces (an Ethernet tunnel) had this value as MTU, so the router was taking the minumun MTU of all interfaces as next hop. As soon as we removed this interface (it was unused), the SSH handshake started to work again.

    • 2

  3. Try:

     $sudo apt-get --reinstall install openssl libssl0.9.8
    • 0

  4. Sounds like a problem with the guest's /dev/urandom or /dev/random .. or maybe another device. Run your hanging process under strace, and see if it is hanging trying to read.

    • 0

  5. I would try using openssl s_client and giving it a random file ("any" file) just to check if the problem is related to /dev/random|urandom as Ben said:

    openssl s_client -state -connect graph.facebook.com:443 -rand anyfile

    Be aware that using a file this way is very dangerous cryptography-wise so be sure to find another solution before pushing that in production.

    • 0