☰

Веб-сайт внезапно не открывается в Safari и на устройствах iOS

tag-icon • tag-icon nginx ssl lets-encrypt ios safari
Веб-сайт внезапно не открывается в Safari и на устройствах iOS

У меня есть этот сайт, который работал нормально до недавнего времени. Теперь пользователи сообщают, что он не открывается на их iPhone и iPad.

Неважно, какой браузер вы попробуете на iOS, он просто не будет работать. Также он не открывается в Safari при просмотре на компьютере Mac. Другие браузеры работают нормально (только Mac OSX, не iOS).

Вот конфигурация сервера:

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3 (Laravel) + Let's Encrypt SSL + HTTP2 активирован

Прежде чем я объясню дальше, я хочу упомянуть, что используя тот же тип конфигурации, что и выше, у меня есть другой сервер, который работает нормально и доступен со всех устройств. Они почти идентичны (с точки зрения конфигурации и настройки), за исключением доменного имени и IP-адреса, очевидно.

Еще одна небольшая дополнительная информация, которую, я думаю, стоит упомянуть, заключается в том, что мои пользователи находятся в Иране.

Вот список того, что я проверил:

  • Доступ к домену возможен с помощью команды ping с iOS и Mac.
  • Сам IP-адрес также доступен и может быть использован для просмотра сайта, просто будет показано предупреждение «недействительный сертификат SSL».
  • Все DNS, которые использовались для домена, пингуются с iOS и Mac.
  • Если использовать VPN-подключение, то на сайт можно зайти. Что действительно странно, потому что технически все доступно: домен, IP и DNS.
  • Помимо использования VPN, сайт также может быть доступен, если SSL полностью отключен/деактивирован.
  • Все остальные публичные веб-сайты, использующие Let's Encrypt SSL, доступны. Так что это не может быть проблемой Let's Encrypt.

Вот что я уже попробовал:

  • Тонны гугления. Я даже столкнулся с пользователем с такой же проблемой наздесьиздесьиздесь
  • Я пробовал отключить HTTP2.
  • Я дважды проверил настройки брандмауэра и даже пробовал его отключить.
  • Я пробовал отключить GZIP.
  • Я провел тест SSL на ssllabs.com, и он не выявил никаких проблем, и он идентичен моему рабочему серверу.
  • Попробовал использовать keepalive_disable "safari"в конфигурации nginx
  • Я пробовал менять ssl_protocolsзначения, например принимать только TLSv1.3 или отключать TLSv1.0.
  • Пробовал использоватьssl_session_cache
  • Попробовал изменить ssl_ecdh_curveна autoиsecp384r1
  • Попробовал изменить ssl_ciphersна HIGH:!aNULL:!MD5;иEECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
  • Попробовал изменить ssl_session_ticketsна onиoff
  • Пробовал использоватьStrict-Transport-Security
  • Попробовал комментировать /etc/letsencrypt/options-ssl-nginx.conf, что используется certbot
  • Пробовал разные настройки перенаправления с HTTP на HTTPS
  • Я обязательно использовал приватную вкладку при тестировании, чтобы убедиться, что я не сталкиваюсь с какой-то ошибочной кэшированной попыткой доступа к сайту.
  • Я перезапускал и перезагружал службу nginx каждый раз после внесения изменений в файлы конфигурации.
  • Я сделал многое, sudo rebootsчтобы убедиться, что это не простая проблема перезагрузки.

В качестве последнего средства я даже переустановил ОС с нуля и настроил сервер заново. Все равно не работает.И нет, я не копировал свои файлы конфигурации, я выполнил каждую команду вручную и тщательно изменил файлы конфигурации, чтобы убедиться, что я не привнесу никаких проблем из предыдущей настройки. Это также означает, что я сделал новый запрос SSL от Let's Encrypt (используя cerbot). Хотя я не знаю, сгенерировали ли они новый или отправили вам тот, что был в прошлый раз.

ПРАВКА 1: Хочу высказать случайную мысль. Я действительно не разбираюсь в продвинутых сетях, но, возможно, что-то из иранских брандмауэров с цензурой вмешивается в SSL-соединение, и это приводит к тому, что устройства Apple не могут установить соединение. Я слышал, что Apple по-своему строга и требует определенного SSL-соединения, в отличие от Chrome и Firefox. Эти 2 устройства могут игнорировать небольшую ошибку, но устройства Apple этого не делают.

ПРАВКА 2: Я проверил Safari, пока Wireshark прослушивает. Кажется, что обменивается только несколько пакетов, независимо от того, что я делаю. Также кажется, что Safari использует TLSv1.0, хотя я отключил его в конфигурации nginx. Я действительно не знаю, как полностью отключить его, чтобы Safari даже не пытался использовать его для связи с сервером.

ПРАВКА 3: Я попробовал использовать другой SSL (используя бесплатную пробную версию SSL на 3 месяца от Comodo), и проблема все еще осталась... Я читал, что некоторые люди говорили, что решили некоторые похожие проблемы, изменив свой SSL. Я не знаю, почему это не работает для меня.

ИЗМЕНИТЬ 4: Я решил сменить DNS-серверы домена, чтобы проверить, не проблема ли это в DNS. Я не знаю, почему и как, но после того, как я их поменял, Safari смог загрузить сайт на короткое время. Но через некоторое время он снова перестал работать.

ПРАВКА 5: Не удалось отключить внешние скрипты на моем сайте, например, Google Analytics (потому что их сервис как бы заблокирован для иранцев). Опять же, я читал сообщения людей, подразумевающие, что некоторые исправили свою проблему, отключив внешние скрипты.

ИЗМЕНИТЬ 6: Я начинаю верить, что это не проблема с сетью или конфигурацией сервера с моей стороны. На самом деле это выглядит так, будто третья сторона вмешивается в запрос. Я не знаю, как Apple справляется с сетями, но я думаю, что согласование соединения/пакетирования Apple вызывает своего рода красный флаг, так сказать, и это заставляет иранскую цензуру/брандмауэр сбрасывать клиентское соединение.

ПРАВКА 7: Я даже сменил дата-центр сервера, на новый IP-адрес. Проблема все еще существует :(

ИЗМЕНИТЬ 8: Это /var/log/nginx/error.logвывод, когда он установлен на debug. Он показывает эти строки, когда я инициирую запрос из клиента Safari.

nginx error.log вывод

Я пытался отключить php fpm, чтобы убедиться, что это не проблема узкого места php. Также я пытался настроить некоторые случайные параметры, например, поднять net.core.somaxconnили 1024увеличить backlogфайлы конфигурации php fpm. Также, когда я смотрю, как система использует htopeverythingthink, все выглядит нормально, никаких скачков использования процессора и никаких переходов определенного процесса наверх списка.

ИЗМЕНИТЬ 9: Я поменял Nginx на Apache2, чтобы проверить, не проблема ли это с веб-сервером. Ну, это не так.

решение1

Поскольку вы сомневаетесь в прокси между вами и веб-сайтом, можете ли вы обойти его, используя опцию -L в ssh? Это обеспечит безопасный туннель между вами и вашим веб-сайтом, который не может быть изменен прокси.

Например, выполните на рабочем столе: ssh -L 2222:127.0.0.1:443[email protected]

После того, как эта команда войдет на ваш сервер, запустите браузер на том же рабочем столе, чтобыhttps://127.0.0.1:2222

Если теперь вы видите свой сайт и его SSL-сертификат, все настроено правильно — кто-то посередине изменяет ваше SSL-соединение, когда вы не используете туннель.

решение2

янайденныйвременное решение моей проблемы. Я просто перенес сервер на другой хостинг/датацентр!

Обновлять:На самом деле проблема возникла снова через несколько месяцев... Я действительно не знаю, какая техническая проблема вызывает ее и как ее исправить.

Обновление 2:Я поговорил с экспертом по ИТ-сетям, и он сказал мне, что проблема на самом деле связана с правилами государственного брандмауэра, которые реагируют на мое доменное имя (ложная/ошибочная цензура), и неважно, какую конфигурацию веб-сервера или веб-хостинг я использую, все равно оно блокируется брандмауэрами вне моей досягаемости.

решение3

Это может быть просто сертификат, правильно ли настроен SubjectAlternativeName? Использование только SubjectName для имени DNS устарело. Используете ли вы закрепление сертификата, сшивание OSCP, HSTP и другие относительно новые настройки TLS? Это может вызвать проблемы в регулируемых сетях.

Некоторым интернет-пользователям необходимо использовать прокси с проверкой SSL. Многие корпоративные среды используют продукты, похожие на IronPort или Bluecoat, для обнаружения скрытых каналов и вредоносного ПО в рамках своей политики безопасности. Способ сделать это возник из статьи в подпольном журнале Phrack 76. Он сводится к простой настройке, где у каждого клиента есть дополнительный корневой сертификат CA прокси-сервера, которому он доверяет, прокси-сервер в свою очередь повторно инициирует соединения от имени каждого клиента, «открывая SSL» MIT, такие страны, как Иран и Китай, контролируют интернет в целом. Из-за этого нет PFS, и несколько вещей могут выйти из строя, что зависит от проверки клиентом криптографии серверов, потому что она изменена или ssl даже полностью удален. Если вас это не волнует, вы можете понизить настройки сертификата сервера до «экспортного качества», удалив упомянутые параметры.

решение4

Ответ @austin-dixon на правильном пути. Этот тест должен быть сделан из той же страны, где находятся пользователи, что может быть невозможным, если вы еще не находитесь в этой стране.

Вы можете, по крайней мере, проверить конфигурацию, используя тест Qualys SSL по адресуhttps://www.ssllabs.com/ssltest/. В данном случае буквенная оценка не имеет значения, просто прокрутите вниз до раздела «Моделирование рукопожатия» и посмотрите, как устройства Apple будут работать в обычных условиях.

В любом случае это просто подтверждает то, что вы уже подозреваете, что между этими пользователями и сайтом что-то есть. У разработчика не так много способов обойти эту ситуацию, кроме как полностью отключить HTTPS. Возможно, человеку посередине требуются некоторые из более слабых наборов шифров или более низкие версии TLS, чем настроен сервер, но я не знаю, какие из них предложить в этом случае.

Связанный контент