SSL-соединение зависает как клиент hello (curl, openssl client, apt-get, wget, все)

Я столкнулся с проблемой на моем Debian VPS (xen domU) в отношении SSL. А именно почти все SSL-соединения зависают при приветствии клиента. Например:

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

  • О подключении () к порту graph.facebook.com 443 (#0)
  • Попытка 66.220.146.48... подключена
  • Подключен к graph.facebook.com (66.220.146.48) порт 443 (#0)
  • успешно установлен сертификат, проверьте места:
  • CAfile: нет CApath: / etc / ssl / certs
  • SSLv3, рукопожатие TLS, клиент привет (1):

То же самое при использовании клиента openssl. Однако часть трафика SSL работает (например, https://www.nordea.se/).

сервер

#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

Однако он работает на моем Dom 0 (основной хост xen).

Кв-получить

Я даже не могу запустить обновление apt-get с источниками безопасности Debian (зависает при чтении заголовков)

Открыть SSL

Вначале я думал, что у меня есть старый клиент openssl (0.9.8o-4), так как у меня был более новый вариант на Dom 0 (0.9.8g-15+lenny8), но выполнение manuanl обновления на openssl deb не Помогите.

Открыть SSL-клиент

Это полный вывод, когда клиент openssl зависает: http://pastebin.com/PAjwMap9

Заключительные мысли

Я погуглил дерьмо из этого, и я не буду дальше. Я видел проблемы с curl, apt-get и т. Д., Но все они специфичны для самого приложения, а не для системы в целом. Какие-нибудь мысли?

Источник

5 ответов

Решение

После нескольких обсуждений с моим хостинг-провайдером выяснилось, что у них была проблема MTU с цепями IP, которые использовал мой DomU (но не с Dom0). Я хотел бы поблагодарить всех, кто помог мне в этом процессе, ваша помощь была неоценимой:)

Источник

Это старое и уже отвечено, но мы столкнулись с той же самой проблемой, и причина была связана, но другая.

Ключ был в том, чтобы прослушивать трафик на нашем пограничном маршрутизаторе, где мы видели ICMP-сообщения на сервер (GitHub.com) с просьбой о фрагментации. Это портило соединение, с повторными передачами, дублированными ACK и так далее.

ICMP-пакет имеет поле, MTU of next hop со странным значением 1450. Обычное значение 1500.

Мы проверили наш маршрутизатор, и один из интерфейсов (туннель Ethernet) имел это значение в качестве MTU, поэтому маршрутизатор принял минимальный MTU всех интерфейсов в качестве следующего перехода. Как только мы удалили этот интерфейс (он не использовался), SSH-рукопожатие снова заработало.

Источник

Пытаться:

 $sudo apt-get --reinstall install openssl libssl0.9.8
Источник

Звучит как проблема с гостевым /dev/urandom или /dev/random .. или, возможно, другим устройством. Запустите процесс зависания под strace и посмотрите, зависает ли он, пытаясь читать.

Источник

Я попытался бы использовать openssl s_client и дать ему случайный файл ("любой" файл), просто чтобы проверить, связана ли проблема с /dev/random|urandom, как сказал Бен:

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

Помните, что использование файла таким способом очень опасно с точки зрения криптографии, поэтому обязательно найдите другое решение, прежде чем отправлять его в производство.

Источник
Другие вопросы по тегам