Сайт внезапно не открывается в 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
• Я убедился, что использую приватную вкладку при тестировании, чтобы убедиться, что не смотрю на какую-то ошибочную кэшированную попытку доступа к сайту.
• Я выполнял service nginx reload & restart каждый раз, когда вносил изменения в конфигурационные файлы.
• Я сделал много sudo reboots, чтобы убедиться, что это не простая проблема перезагрузки.

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

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

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

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

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

EDIT 5:
Нет успеха по отключению внешних скриптов на моем сайте, таких как Google Analytics (потому что их сервис вроде бы заблокирован для иранцев). Снова читал отчеты людей, предполагая, что некоторые исправили свою проблему, отключив внешние скрипты.

EDIT 6:
Я начинаю верить, что это не проблема с сетевыми или серверными конфигурациями с моей стороны. Это действительно выглядит как вмешательство третьей стороны в запрос. Я не знаю, как Apple обрабатывает сети, но думаю, что переговоры по подключению/упаковке Apple вызывают своего рода тревожный сигнал, так сказать, и это заставляет иранские брандмауэры/цензуру разрывать соединение клиента.

EDIT 7:
Я даже изменил дата-центр сервера с новыми IP-адресом. Проблема все еще существует 🙁

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

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

EDIT 9:
Я заменил Nginx на Apache2, чтобы проверить, является ли это проблемой веб-сервера. Ну, это не было.

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

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

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

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

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

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

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

у меня есть эта проблема с включенным HTTP2 на другом виртуальном хосте с тем же IP:портом. Вернул другие конфигурации к HTTP/1.1 и заставил Safari/iOS работать.

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

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

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

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

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