Проблема при открытии 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

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

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