Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid

Всё чаще стали проявляться проблемы у пользователей при открытии HTTPS сайтов в Chrome (версия 29.0.1547.66 m) с использованием прокси сервера Squid (Basic и NTLM аутентификация), при чём даже на одинаковых аппаратных конфигурациях у одних пользователей всё исправно работало, у других нет. В браузерах — Opera, Firefox всё работало без проблем.

Симптомы следующие: при переходе на любой HTTPS сайт, например, на https://dropbox.com https://twitter.com страница не загружалась (но если и загружалась, то с 10-ой попытки обновления, и не полностью). Также при открытии появлялись ошибки ERR_TIMED_OUT и ERR_TUNNEL_CONNECTION_FAILED.

UPD: Проблема также (если не в основном) кроется в том, что проверка сертификатов в CRL или с помощью OCSP различными браузерами выполняется по-разному — кто то использует указанные настройки Proxy или внутренний механизм проверки (Firefox, например), а кто то (Chrome) использует встроенный в Windows механизм проверки, который зачастую идёт «напрямик» (возможно, необходимо «корректно» указать настройки системного прокси) через шлюз по-умолчанию, на котором нет выхода в Интернет. Для решения данной проблемы я запустил на шлюзе прозрачный прокси на порт 80 и разрешаю обработку URL по правилам:

/etc/squid/acls/without_any_restrictions_dstdom_regex.acl
...
(^|\.)certum.pl$
(^|\.)digicert.com$
(^|\.)verisign.com$
(^|\.)globalsign.com$
(^|\.)ocsp.comodoca.com$
(^|\.)ocsp.comodoca4.com$
(^|\.)ocsp.usertrust.com$
(^|\.)thawte.com$
(^|\.)letsencrypt.org$
(^|\.)ocsp-responder.com$
(^|\.)ocsp.godaddy.com$
(^|\.)ocsp.sca1b.amazontrust.com$
...
acl without_any_res_dstdom_regex dstdom_regex -i "/etc/squid/acls/without_any_restrictions_dstdom_regex.acl"
http_access allow all without_any_res_dstdom_regex
acl cert_file_ext urlpath_regex -i \.crl$ \.crt$
http_access allow all cert_file_ext

END

Испробовали всё, что можно: указание в Chrome прокси сервера вручную, указание конкретного типа аутентификации (так как по логам Squid было видно, что Chrome не всегда пытается аутентифицироваться, во всяком случае реже, чем при открытии просто HTTP сайтов), далее убрали все ограничения Squid и аутентификацию в том числе, но это не помогло решить проблему. Также было замечено, что Internet Explorer имеет аналогичные проблемы при доступе на HTTPS сайты.

В итоге решено было посмотреть «диалог» между клиентом и прокси сервером, используя анализатор сетевого протокола Wireshark (http://wireshark.org). Wireshark запускался на стороне клиента. Проходящие пакеты были записаны и отфильтрованы по адресу прокси ip.addr==192.92.92.100. И тут обнаружилось следующее — пакеты, отправляемые клиентом, имели некорректную (нулевую) контрольную сумму (скриншот приведён ниже). После чего было решено в настройках сетевого адаптера отключить всё, что касается «разгрузок протоколов», энергосбережения, контроля трафика и прочих функций, которые берёт на себя сетевая карта вместо ОС. Пакеты стали отправляться с правильной контрольной суммой заголовка и Chrome стал открывать HTTPS узлы мгновенно, без нареканий, с использованием аутентификации на прокси сервере Squid. На остальных проблемных компьютерах данные манипуляции также помогли решить проблему (сетевая карта была такая же). Возможно также помогает обновление драйвера сетевой карты, но данный метод не испробован.

Сетевая карта: Realtek PCIe GBE Family Controller
Драйвер: Realtek 21/03/2011, version 7.43.321.2011

Пакеты с некорректной контрольной суммой заголовка:
wireshark_chrome

Окно с настройками сетевой карты:
settings

8 комментариев on "Проблема при открытии HTTPS сайтов в Chrome через прокси сервер Squid"


  1. У меня была похожая проблема! Есть шлюз под линуксом (сквид3), с клиентской машины не могу зайти по https (причем 50 на 50, на некоторые сайты зайти можно, на некоторые выдает ERR_TUNNEL_CONNECTION_FAILED )
    Думал, что дело в сквиде (очищал кэш, менял конфигурацию, отключал блэклист и пр.), не помогло. А потом увидел в настройках сетевой карты клиентской машины прописаны два каких-то левых ДНС (62.109.12.227 и 162.211.228.130). Прописал днс своего сервака и вуаля, все заработало. Потом прошелся троянремувером и удалил «потенциально нежелательную прогу» и все ОК.

    Ответить

    1. Спасибо за сообщение!
      У нас были проблемы на различных машинах без вредоносного ПО с правильным DNS и другими настройками, в том числе и NTLM протокола, по-этому ситуацию удалось разрешить только после применения снифера.

      Ответить

  2. Не могу зайти в Google Crome. Прочитала статью, в итоге решила посмотреть «диалог» между клиентом и прокси сервером, используя анализатор сетевого протокола Wireshark (http://wireshark.org). Выдал ошибку » Uh-oh, something went wrong! Error Code: 403″, что это значит?

    Ответить

  3. Подскажите,
    Uh-oh, something went wrong! Error Code: 403 отсутствует сетевой адрес . Посмотрела и верно, отсутствует сетевой адрес, в строке, Значение, если её активировать сплошные нули, а сразу выдаёт Значение: Отсутствует. Как задать сетевой адрес? Может я не установила правильно Браузер?

    Ответить

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

      Ответить

  4. Спасибо большое за заметку! При подключении компов к интернету через прокси криво работали отдельные сайты, очень нужные для работы. Отдел страдал долгое время, а в итоге выполнение данных манипуляций полностью решило проблему.

    Ответить

  5. Сетевой адаптер Интел, подобные действия не привели к нужному результату. Подозреваю что проблема не на стороне клиента, и если уж в сетевой карте дело то на стороне сквида. Так как если не использовать маршрутизацию через сквид то интернет работает нормально со всеми сайтами, как только пишу в свойствах браузера проксю — не работают некоторые сайты (я проверял на youtube.com). Теперь осталось понять как все эти управления Rx/Tx отключить в линуксе на стороне сквида.
    PS: небольшая ремарка — сквид у меня крутится на виртуалке Hyper-V.

    Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *