Назад | Перейти на главную страницу

Веб-сайт внезапно не открывается в 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-адреса, очевидно.

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

Вот список вещей, которые я проверил:

Вот что я пробовал до сих пор:

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

ИЗМЕНИТЬ 1: Я хочу высказать здесь случайную мысль. Я действительно не знаю о продвинутых сетях, но, возможно, что-то из брандмауэров цензуры Ирана вмешивается в соединение SSL и приводит к тому, что устройства Apple не устанавливают соединение. Я слышал, что Apple по-своему строга и требует определенного SSL-соединения, в отличие от Chrome и Firefox. эти 2 могут игнорировать небольшую ошибку, но устройства Apple - нет.

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

РЕДАКТИРОВАТЬ 3: Я пробовал использовать другой SSL (используя 3-месячную бесплатную пробную версию ssl от comodo), и проблема все еще существует ... Я читал, что некоторые люди говорили, что они решили некоторые похожие проблемы после изменения своего SSL. Не знаю, почему у меня это не работает.

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

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

РЕДАКТИРОВАТЬ 6: Я начинаю думать, что это не проблема с сетью или конфигурацией сервера с моей стороны. Это действительно похоже на вмешательство третьей стороны в запрос. Я не знаю об Apple и о том, как она обрабатывает сети, но я думаю, что переговоры Apple о подключении / пакетировании вызывают своего рода красный флаг, так сказать, и заставляют иранскую цензуру / брандмауэр разрывать клиентское соединение.

РЕДАКТИРОВАТЬ 7: Я даже изменил центр обработки данных сервера, с новым новым IP-адресом. проблема все еще существует :(

РЕДАКТИРОВАТЬ 8: Это /var/log/nginx/error.log вывод, когда он установлен на debug. Эти строки отображаются, когда я инициирую запрос от клиента Safari.

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

РЕДАКТИРОВАТЬ 9: Я заменил Nginx на Apache2, чтобы проверить, не проблема ли это веб-сервера. Ну не было.

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

Например, выполните это на своем рабочем столе: ssh -L 2222: 127.0.0.1: 443 user@mywebsite.com

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

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

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

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

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

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

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

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

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