Error negotiating ssl connection on fd error squid

I am trying to install squid 3.5.4 (on docker, running debian and run it in ssl-bump mode.
Compilation:

./configure --prefix=/opt/squid --srcdir=. --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules --enable-inline
--disable-arch-native --enable-async-io=8 
--enable-storeio=ufs,aufs,diskd,rock 
--enable-removal-policies=lru,heap --enable-delay-pools 
--enable-cache-digests --enable-icap-client 
--enable-follow-x-forwarded-for 
--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB 
--enable-auth-digest=file,LDAP 
--enable-auth-negotiate=kerberos,wrapper 
--enable-auth-ntlm=fake,smb_lm 
--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group 
--enable-url-rewrite-helpers=fake --enable-eui 
 --enable-esi --enable-icmp --enable-zph-qos 
--disable-translation --with-filedescriptors=65536 
--with-large-files --with-default-user=squid 
--enable-linux-netfilter 
CFLAGS="-g -O2 -fPIE -Wall" LDFLAGS="-fPIE -pie -Wl,-z,relro -Wl,-z,now" CPPFLAGS="-D_FORTIFY_SOURCE=2" 
CXXFLAGS="-g -O2 -fPIE " --enable-ssl --with-openssl --enable-ssl-crtd

Changed configuration (squid.conf) (rest is default):

# Squid normally listens to port 3128 
http_port 9090
sslcrtd_program /opt/squid/libexec/ssl_crtd -s /opt/squid/var/lib/ssl_db -M 4MB
https_port 8080 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB key=/opt/squid/certs/private.pem cert=/opt/squid/certs/public.pem

### New configuration for Squid version 3.5
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
### New config ends
sslproxy_capath /etc/ssl/certs
sslproxy_cert_error allow all
always_direct allow all
sslproxy_flags DONT_VERIFY_PEER

Generated certificates:

openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -keyout private.pem -out public.pem

Generate squid certs dir and change ownership:

/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db -M 4MB
chown -R squid:squid /opt/squid/var/lib/ssl_db

CA Root certs are present in the default path

squid@525f5d9c759a:/opt/squid/certs$ ls -lsthr  /etc/ssl/certs | wc -l
741

I am testing this configuration, using HTTP CONNECT, configuring the proxy directly in the browser.

ISSUE:

I get the following error when the browser request hits the proxy

8zjv9ksCWknblqfZ3rjWczvKNRboHpu940olZAbvSP0JWSXhFfRRTIsHIHD2/rt/
n5/qsURq/WLodLffFxuk+bLVTDZu
-----END PRIVATE KEY-----

2015/05/04 15:13:46.468 kid1| client_side.cc(3981) sslCrtdHandleReply: Certificate for 172.17.0.7 was successfully recieved from ssl_crtd
2015/05/04 15:13:46.468 kid1| client_side.cc(3664) httpsCreate: will negotate SSL on local=172.17.0.7:2222 remote=172.17.42.1:40686 FD 10 flags=33
2015/05/04 15:13:46.468 kid1| AsyncCall.cc(26) AsyncCall: The AsyncCall ConnStateData::requestTimeout constructed, this=0x7f0357a16c10 [call105]

2015/05/04 15:13:46.468 kid1| Error negotiating SSL connection on FD 10: Success (0)

2015/05/04 15:13:46.468 kid1| AsyncCall.cc(93) ScheduleCall: comm.cc(730) will call ConnStateData::connStateClosed(FD -1, data=0x7f03575d43b8) [call95]
2015/05/04 15:13:46.468 kid1| AsyncCallQueue.cc(55) fireNext: entering ConnStateData::connStateClosed(FD -1, data=0x7f03575d43b8)
2015/05/04 15:13:46.468 kid1| AsyncCall.cc(38) make: make call ConnStateData::connStateClosed [call95]
2015/05/05 10:00:25| pinger: Initialising ICMP pinger ...
2015/05/05 10:00:25|  icmp_sock: (1) Operation not permitted
2015/05/05 10:00:25| pinger: Unable to start ICMP pinger.
2015/05/05 10:00:25|  icmp_sock: (1) Operation not permitted
2015/05/05 10:00:25| pinger: Unable to start ICMPv6 pinger.
2015/05/05 10:00:25| FATAL: pinger: Unable to open any ICMP sockets.

Sending a curl request shows this:

curl --proxy https://localhost:8080 -w 'n' https://google.com -v
* Rebuilt URL to: https://google.com/
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.42.0
> Proxy-Connection: Keep-Alive
> 
* Proxy CONNECT aborted
* Connection #0 to host localhost left intact

curl: (56) Proxy CONNECT aborted

Can anyone help with this?

Рассмотрим как реализовать перехват пользовательских HTTPS-запросов в сеть интернет для дальнейшего анализа и учета их. Все ниже описанные действия производятся на Debian 9 Stretch с установленным прокси-сервером Squid 4.9.

Для работы с HTTPS трафиком необходимо, чтобы Squid был собран с следующими параметрами:

Для просмотра HTTPS трафика, прокси-сервер Squid должен иметь свой собственный СА сертификат, который используется для подписывания динамически генерируемых сертификатов для серверов, к которым пользователи посылают запросы.

Выполним генерацию CA сертификата и назначим права доступа для него, выполним команды:

Конвертируем сертификат в формат для импорта на пользовательские системы:

Далее необходимо инициализировать каталог для хранения кэша имитированных сертификатов и указать разрешения на этот каталог для прокси-сервера Squid, выполним команды:

В файле конфигурации (/etc/squid/squid.conf) указываем следующие параметры:

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

Перезапускаем Squid и проверяем работу:

На скриншоте выше видим что запрос к сайту https://yandex.ru был успешно перехвачен прокси-сервером, о чем свидетельствует имитированный сертификат и в лог-файле /var/log/access.log будут фиксироваться все действия на данном сайте.

В случае блокирования доступа какого либо сайта средствами прокси-сервера, будет корректно отрабатывать директива DENY_INFO. Пользователь при входе на заблокированный сайт будет видеть заглушку прокси-сервера, вместо не информативного сообщения о разрыве соединения…

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

День добрый.
Добился полностью прозрачного Squid’a, с генерацией самоподписанных SSL, которые вполне себе жуют большинство сайтов, работающих по HTTPS.
Примерно разобрался, как выпустить Squid через parrent proxy.
Вот кусок Squid.conf дочернего сервера (Squid1), отвечающий за parrent proxy:

cache_peer 192.168.0.162 parent 8080 0 ssl no-query default no-digest no-netdb-exchange originserver
cache_peer_access 192.168.0.162 allow all
never_direct allow all

К сожалению, пока не осилил, как подружить два Squid’a через SSl.
В cache.log дочернего Squid’a вылезает ошибка:

2014/09/25 06:25:00 kid1| fwdNegotiateSSL: Error negotiating SSL connection on FD 13: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0)
2014/09/25 06:25:00 kid1| TCP connection to 192.168.0.162/8080 failed

Аналогичная ошибка вылезает и в браузере:

(92) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
Handshake with SSL server failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

В связи в этим вопрос — какие сертификаты надо подсовывать родительскому Squid’у, если надо именно это?
Или настроить ему точно такую же SSL-генерацию как и дочернему?

На всякий случай, вот куски конфигов, описывающие генерацию SSL:
Дочерний squid (Squid1):

#HTTPS SECTION
https_port 127.0.0.1:3128 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/etc/squid/ssl/squid.pem key=/usr/local/etc/squid/ssl/root.key
http_port 127.0.0.1:3129 intercept
http_port 3130
ssl_bump server-first all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/local/libexec/squid/ssl_crtd -s /usr/local/etc/squid/ssl/ssl_db -M 4MB

Родительский squid (Squid2):

#HTTPS SECTION
http_port 8080 ssl-bump cert=/usr/local/etc/squid/root.cer key=/usr/local/etc/squid/root.key generate-host-certificates=on
ssl_bump client-first all
sslproxy_cert_error allow all

Из одинакового у них только ключевой сертификат root.key

Сорри, раньше с сертификацией особо сталкиваться не приходилось.

Пришло время задать один сложный вопрос. Форумчане, администраторы, кто хорошо знаком со сквидом в режиме ssl-bumb с подменой сертификата, подскажите:
работает система вроде как надо, новая установка: Centos 7.4, squid/3.5.27. Сертификаты в ssl_db создаются, несмотря на то что в cache.log’е

Проблема в том что не пускает на некоторые сайты, возьмём для примера habr.com/. Браузер сообщает, что владелец habr.com неправильно настроил свой веб-сайт и

Собственно эта информация содержится в графе «дополнительное имя субъекта» созданного на сервере сертификата:
DNS-имя=habrahabr.ru
DNS-имя=api.habrahabr.ru
DNS-имя=m.habrahabr.ru
DNS-имя=special.habrahabr.ru
DNS-имя=www.habrahabr.ru

Кусок конфигурации сквида:

Такие сайты ведь будут вылавливаться и в работе пользователей. Что с этим делать?

День добрый.
Настраивал прозрачное проксирование Squid, + каскадирование, + SSL.
Схема такая клиент====>Squid1=====>Squid2=====>Интернет.
Добился полностью прозрачного Squid’a, с генерацией самоподписанных SSL, которые вполне себе жуют большинство сайтов, работающих по HTTPS.
Примерно разобрался, как выпустить Squid через parrent proxy.
Вот кусок Squid.conf дочернего сервера (Squid1), отвечающий за parrent proxy:

cache_peer 192.168.0.162 parent 8080 0 ssl no-query default no-digest no-netdb-exchange originserver
cache_peer_access 192.168.0.162 allow all
never_direct allow all

К сожалению, пока не осилил, как подружить два Squid’a через SSl.
В cache.log дочернего Squid’a вылезает ошибка:

2014/09/25 06:25:00 kid1| fwdNegotiateSSL: Error negotiating SSL connection on FD 13: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0)
2014/09/25 06:25:00 kid1| TCP connection to 192.168.0.162/8080 failed

Аналогичная ошибка вылезает и в браузере:

(92) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
Handshake with SSL server failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

В связи в этим вопрос — какие сертификаты надо подсовывать родительскому Squid’у, если надо именно это?
Или настроить ему точно такую же SSL-генерацию как и дочернему?

На всякий случай, вот куски конфигов, описывающие генерацию SSL:
Дочерний squid (Squid1):

#HTTPS SECTION
https_port 127.0.0.1:3128 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/etc/squid/ssl/squid.pem key=/usr/local/etc/squid/ssl/root.key
http_port 127.0.0.1:3129 intercept
http_port 3130
ssl_bump server-first all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/local/libexec/squid/ssl_crtd -s /usr/local/etc/squid/ssl/ssl_db -M 4MB

Родительский squid (Squid2):

#HTTPS SECTION
http_port 8080 ssl-bump cert=/usr/local/etc/squid/root.cer key=/usr/local/etc/squid/root.key generate-host-certificates=on
ssl_bump client-first all
sslproxy_cert_error allow all
 

Из одинакового у них только ключевой сертификат root.key

Сорри, раньше с сертификацией особо сталкиваться не приходилось.