LINUX.ORG.RU

Squid3.4 + ssl_bump. Ошибка сертификата, Доступ запрещён

 , ,


1

3

Выражаю благодарность двум формучанам blind_oracle и leg0las,читая топики которых, я немного разобрался в теме.
Тем не менее, безуспешно бьюсь над этим вопросом, в котором прощу помощи:
HTTP работает нормально, а при попытке, например, зайти на Гугл, пишет «Ошибка сертификата» ---> «Доступ запрещён»..
ОС: Debian 7.8
В Debian стоит старая версия squid, у которой есть трудности с https. Ставить новую версию из исходников не хотелось, поэтому, временно подключив тестовый репозиторий, качнул оттуда библиотеки и исходники squid3.4.8 для создания .deb-пакета.
Если кому интересно - подробности:

apt-get install libecap2-dev libnetfilter-conntrack-dev nettle-dev
...
cd /usr/src
apt-get source squid3

Отрубил тестовый репозиторий.
Делаю squid. Ставлю пакеты для сборки (из обычного репозитория):

apti-get install dpkg-dev squid-langpack devscripts build-essential fakeroot
Стандартные шаги по сборке:
apt-get  build-dep squid3
apt-get  build-dep openssh
apt-get  build-dep openssl
Дабавки:
nano debian/rules
--enable-ssl \
--enable-ssl-crtd \
--with-openssl \
Ещё добавки:
nano src/ssl/certificate_db.cc
#include <unistd.h>
Собрал и установил:
./configure
...
debuild -us -uc -b
...
cd ..
dpkg -i squid3_3.4.8-6_i386.deb squid3-common_3.4.8-6_all.deb squid3-dbg_3.4.8-6_i386.deb squid-cgi_3.4.8-6_i386.deb squidclient_3.4.8-6_i386.deb squid-purge_3.4.8-6_i386.deb
Squid собран с поддержкой SSL:
squid3 -v
Squid Cache: Version 3.4.8
Debian linux
configure options:  '--build=i486-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--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,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' '--enable-ecap' '--enable-ssl' '--enable-ssl-crtd' '--disable-translation' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-openssl' '--with-default-user=proxy' '--enable-build-info=Debian linux' '--enable-linux-netfilter' 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'
Сделал сертификаты:
mkdir /etc/squid3/ssl && cd /etc/squid3/ssl
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squid.pem -out squid.pem
openssl x509 -in squid.pem -outform DER -out squid.der
rm -rf /var/lib/ssl_db && /usr/lib/squid3/ssl_crtd -c -s /var/lib/ssl_db && chown -R proxy:proxy /var/lib/ssl_db
В squid прописал настройки для HTTPS:
http_port 3128
http_port 3129 intercept
https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/squid.pem key=/etc/squid3/ssl/squid.pem
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all
always_direct allow all
ssl_bump client-first all
ssl_bump server-first all
ssl_bump none all
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB
Отключил IPv6, включил маршрутизацию и завёл всех на squid:
$IPT -t nat -A PREROUTING -i $LAN -p TCP --source $LAN_NET --dport 80 -j DNAT --to-destination $LAN_IP:3129
$IPT -t nat -A PREROUTING -i $LAN -p TCP --source $LAN_NET --dport 443 -j DNAT --to-destination $LAN_IP:3130
На клиенты добавил сгенерированный сертификат squid.der. В итоге HTTP работает нормально, а при попытке, например, зайти на Гугл, пишет «Ошибка сертификата» ---> «Доступ запрещён».

На клиенты доверенный сертификат добавил?

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от Vovka-Korovka

Угу, только нифига он не доверенный - браузеры ему не доверяют

Alpha789 ()

squid то в логи что-то пишет?

В /var/lib/ssl_db/certs появляются сгенеренные сертификаты?

На ветке 3.4 встречался мне баг, при котором в сгенеренном сертификате было запорчено одно из полей

Сейчс у меня 3.4.10 собран с этим патчем.

Kuzz ★★★ ()

А броузер то какой? А то в хром встроены сертификаты гугля и он, даже если доверяет твоему CA, будет ругаться на то, что сертификат неправильный т.к. не совпадает с тем что у него встроен (т.н. certificate pinning).

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

в фф начиная с 32-й версии такое тоже есть.

maloi ★★★★★ ()
Ответ на: комментарий от blind_oracle

pinning не работает, если цепочка ведет к сертификату, добавленному пользователем вручную. По крайней мере, в хромиуме точно так

А как нынче модно прозрачно MITM-ить SSL? (комментарий)

Думаю, в лисе точно также.

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от Kuzz

Да, в /var/lib/ssl_db/certs появляются сгенеренные сертификаты.

На сайте Debian нет пакетов squid старше 3.4.8 даже в sid. Зато на офсайте есть 3.5.2. Попробую собрать новый .deb пакет из этих исходников, имея в виду этот патч.

Если не получился, отчаяние подтонёт меня пилить модуль ядра, как научили здесь.

А до Chrom'а ещё не добрался, разбираюсь с IE и FireFox.

Alpha789 ()
Ответ на: комментарий от Kuzz

Логи пишет:

tail /var/log/squid3/cache.log
2015/03/18 10:29:16 kid1|         0 Objects expired.
2015/03/18 10:29:16 kid1|         0 Objects cancelled.
2015/03/18 10:29:16 kid1|         0 Duplicate URLs purged.
2015/03/18 10:29:16 kid1|         0 Swapfile clashes avoided.
2015/03/18 10:29:16 kid1|   Took 1.11 seconds (327.02 objects/sec).
2015/03/18 10:29:16 kid1| Beginning Validation Procedure
2015/03/18 10:29:16 kid1|   Completed Validation Procedure
2015/03/18 10:29:16 kid1|   Validated 362 Entries
2015/03/18 10:29:16 kid1|   store_swap_size = 4308.00 KB
2015/03/18 10:29:17 kid1| storeLateRelease: released 0 objects

tail /var/log/squid3/access.log
1426665248.377     13 192.168.1.115 TCP_MISS/302 1012 GET http://mc.yandex.ru/watch/722545? - ORIGINAL_DST/87.250.251.119 -
1426665248.684     18 192.168.1.115 TCP_MISS/200 586 GET http://mc.yandex.ru/watch/722545/1? - ORIGINAL_DST/87.250.251.119 application/javascript
1426665248.740     20 192.168.1.115 TCP_MISS/200 534 GET http://www.tns-counter.ru/V13a**c99e6850664c422902edc103206e9c6c**yandex_ru/ru/CP1251/tmsec=yandex_main/0 - ORIGINAL_DST/217.73.200.219 image/gif
1426665252.649     12 192.168.1.115 TCP_MISS/200 1720 GET http://yastatic.net/browser-cookie/_fc.js? - ORIGINAL_DST/178.154.131.215 application/x-javascript
1426665253.433    143 192.168.1.115 TCP_MISS/200 802 GET http://yandex.ru/yandcache.js - ORIGINAL_DST/87.250.250.11 application/javascript
1426665258.135     22 192.168.1.115 TCP_MISS/200 599 POST http://mc.yandex.ru/watch/722545? - ORIGINAL_DST/87.250.251.119 image/gif
1426665274.299     26 192.168.1.115 TCP_MISS/302 722 GET http://mail.ru/ - ORIGINAL_DST/217.69.139.200 text/html
1426665280.240      3 192.168.1.115 TCP_DENIED/403 3891 GET https://mail.ru/ - HIER_NONE/- text/html
1426665282.028    255 192.168.1.115 TCP_REFRESH_UNMODIFIED/304 255 GET http://www.squid-cache.org/Artwork/SN.png - ORIGINAL_DST/92.223.231.190 -
1426665282.067      2 192.168.1.115 TCP_DENIED/403 3924 GET https://mail.ru/favicon.ico - HIER_NONE/- text/html

Alpha789 ()
Ответ на: комментарий от Alpha789

В 3.5 этот патч как раз попал.

в /var/lib/ssl_db/certs появляются сгенеренные сертификаты.

Тогда можно прямо их просмотреть (какой гуглу сгенерило - в индексе выяснится)

Именно у меня ломалось поле Extended Key Usage. Оно присутствовало, но было пустым.

Kuzz ★★★ ()
Ответ на: комментарий от Alpha789

А, еще одно. Новые браузеры не доверяют сертификатам c SHA-1.

М.б. так пройдет?

https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/squid.pem key=/etc/squid3/ssl/squid.pem version=4 cipher=TLSv1:!AES128:!CAMELLIA

Ну и почистить (пересоздать) /var/lib/squid/ssl_db

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Посмотрел сгенерированный сертификат (их аж 4 для Гугла создаётся), там только два поля:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
Никакого поля «Extended Key Usage». Попробовал добавить в конфиг
...version=4 cipher=TLSv1:!AES128:!CAMELLIA
Так же ругается на HTTPS и сертификаты такие же.

Выходит, что что-то не то с сертификатами?

Alpha789 ()
Ответ на: комментарий от Alpha789

Посмотрел сгенерированный сертификат (их аж 4 для Гугла создаётся),

Генерироваться должен один. И смотреть нужно не на голый pem, а вот так

cat cert.pem | openssl x509 -text -noout

И смотреть на поле X509v3 Basic Constraints.

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от Alpha789

там только два поля:

/usr/bin/openssl x509 -text -in %f

Или смотреть в браузере.

Попробовал добавить в конфиг

После этого старые сертификаты удалялись?

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

После старые сертификаты не удалялись. Просто при новом заходе клиента на Гугл добавляется ещё один сертификат. Его и посмотрим:

/usr/bin/openssl x509 -text -in 6B73045802A12084BE9B83E5CBBFE259F22CEA2D.pem
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            6b:73:04:58:02:a1:20:84:be:9b:83:e5:cb:bf:e2:59:f2:2c:ea:2d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow, L=Moscow, O=Internet Widgits Pty Ltd, CN=***/emailAddress=***@***
        Validity
            Not Before: Mar 16 20:00:05 2015 GMT
            Not After : Mar 15 20:00:05 2016 GMT
        Subject: CN=173.194.122.247
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Не вижу поле X509v3 Basic Constraints. Что-то не так с сертификатом?

Alpha789 ()
Ответ на: комментарий от Alpha789

Не вижу поле X509v3 Basic Constraints.

Ну для генерируемого сертификата, по-идее, это не очень важно, главное, чтобы это поле было у сертификата, которым ты подписываешь. В вики сквида написано, что это поле не генерируется.

Vovka-Korovka ★★★★★ ()
Ответ на: комментарий от Alpha789
ertificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            66:e9:6a:97:55:60:77:66:15:5d:fd:5b:f6:ca:6b:ee:02:f2:bf:54
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=UA, ST=Dn, L=Dnipropetrovsk, O=DRPBK, OU=Proxy, CN=___________/emailAddress=_______________
        Validity
            Not Before: Mar 11 16:27:34 2015 GMT
            Not After : Jun  9 00:00:00 2015 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
-----
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:google.com, DNS:*.2mdn.net, DNS:*.android.com, DNS:*.appengine.google.com, DNS:*.au.doubleclick.net, DNS:*.cc-dt.com, 
------
DNS:google.uz, DNS:google.vg, DNS:google.vu, DNS:google.ws, DNS:googlecommerce.com, DNS:gstatic.com, DNS:urchin.com, DNS:youtu.be, DNS:youtube.com, DNS:youtubeeducation.com
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha1WithRSAEncryption

CN=173.194.122.247

ssl_bump client-first all
ssl_bump server-first all

Оу. Отрабатывает первая директива, а нужна вторая. client-first для пробы убрать.

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 1)
Ответ на: комментарий от Kuzz

Да, в самом сертификате squid'а есть это поле X509v3 Basic Constraints. Закоментировал ssl_bump client-first all. И это поле появилось и в генерируемом сертификате. Так же изменилось поле Subject - появилась куча всяких имён.

/usr/bin/openssl x509 -text -in 1A0D785A28ABD5A79AD68FE4A2A71D93AF34C8DF.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1a:0d:78:5a:28:ab:d5:a7:9a:d6:8f:e4:a2:a7:1d:93:af:34:c8:df
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow, L=Moscow, O=Internet Widgits Pty Ltd, CN=***/emailAddress=***@***
        Validity
            Not Before: Mar 11 16:27:34 2015 GMT
            Not After : Jun  9 00:00:00 2015 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:google.com, DNS:*.2mdn.net, DNS:*.android.com, DNS:*.appengine.google.com, ...
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha1WithRSAEncryption
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Но всё равно «Доступ запрещён» В логах:
tail /var/log/squid3/access.log
1426765478.922     72 192.168.1.115 TCP_MISS/302 653 GET http://www.google.ru/ - ORIGINAL_DST/173.194.122.248 text/html
1426765479.052      1 192.168.1.115 TCP_DENIED/403 4141 GET https://www.google.ru/? - HIER_NONE/- text/html
...
В моей голове звучит вопрос Чернышевского...

Alpha789 ()
Ответ на: комментарий от Alpha789

1426765479.052 1 192.168.1.115 TCP_DENIED/403

Это ж уже кальмар не пропускает сам.
Порт 443 разрешен?
url_regex вида "http://..." нигде нет?

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

443 разрешён, и ничего такого вроде бы нет:

cat squid.conf | grep -v '^#'

acl audio_t rep_mime_type content-type audio
acl video_t rep_mime_type content-type video
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
acl localnet src 192.168.1.0/24

acl SSL_ports port 443          # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl icq_ports  port 5190        # ICQ
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow manager localhost
http_access allow localnet
http_access deny all
icp_access allow localnet
icp_access deny all

http_port 3128
http_port 3129 intercept
https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/squid.pem key=/etc/squid3/ssl/squid.pem version=4 cipher=TLSv1:!AES128:!CAMELLIA
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all
always_direct allow all
ssl_bump server-first all
ssl_bump none all
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB

hierarchy_stoplist cgi-bin ?
cache_mem 256 MB
cache_dir ufs /var/spool/squid3 512 16 256
access_log /var/log/squid3/access.log squid
cache_store_log none
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320
cache_mgr ***@***
icp_port 0
error_directory /usr/share/squid3/errors/Russian-1251
coredump_dir /var/spool/squid3/cache

Alpha789 ()
Ответ на: комментарий от Alpha789

http_access deny !Safe_ports

Первым же правилом)

Добавить 443 в Safe_ports

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Ахаха )) Поправил:

acl SSL_ports port 443          # https
acl Safe_ports port 443         # https
acl Safe_ports port 80          # http
acl CONNECT method CONNECT
...
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
IE8 (с импортированным сертификатом squid.der) на google.ru заходит без руганий на сертификат. На gmail.com ругается на сертификат, но после добавления исключения, пропускает дальше. Удалось даже скачать и установить Chrome.

Свежеустановленный Chrome 41.0 (в него я не импортировал сертификат squid.der) аналогичным образом всё пропускает, но при входе на gmail.com ругается на сертификат без возможности добавить исключение бузопасности.

NET::ERR_CERT_COMMON_NAME_INVALID
Firefox 36.0.1. (с импортированным сертификатом squid.der) ведёт себя подобно chrome: при входе на gmail.com ругается на сертификат без возможности добавить исключение.
gmail.com использует недействительный сертификат безопасности.
Сертификат действителен только для 74.125.143.19
(Код ошибки: ssl_error_bad_cert_domain)
Сам сертификат вроде бы нормальный:
/usr/bin/openssl x509 -text -in 106DCEF14E5163E371FE0B7390CFDF6F6663483B.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:6d:ce:f1:4e:51:63:e3:71:fe:0b:73:90:cf:df:6f:66:63:48:3b
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=RU, ST=Moscow, L=Moscow, O=Internet Widgits Pty Ltd, CN=***/emailAddress=***@***
        Validity
            Not Before: Mar 11 16:28:25 2015 GMT
            Not After : Jun  9 00:00:00 2015 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=mail.google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:mail.google.com, DNS:inbox.google.com
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha1WithRSAEncryption
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Alpha789 ()
Ответ на: комментарий от Alpha789

Сертификат действителен только для 74.125.143.19

Squid не связался с gmail.com
Вообще, с этого адреса приходит сертификат для mail.google.com и кальмар отклоняет его.

Для таких сайтов у меня конструкция:

acl mism_cert dstdomain -i "/etc/squid/lists/mism_ssl"
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch
В /etc/squid/lists/mism_ssl yadi.sk есть.

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 1)
Ответ на: комментарий от Kuzz

Я уже думал, что всё мои надежды рухнули: стал думать над покупкой сертификата (кстати, если купить, то проблема с gmail.com точно не будет?) или компиляции модуля ядра Shifter. И вот ещё возможности!

Добавил эти строки сразу после

https_port 3130...
Теперь Chrome и Firefox сайт узнают, но не пускают:
www.gmail.com использует недействительный сертификат безопасности.
Сертификат действителен только для следующих имён:
mail.google.com, inbox.google.com
(Код ошибки: ssl_error_bad_cert_domain)

Alpha789 ()
Ответ на: комментарий от Alpha789

стал думать над покупкой сертификата

Почти не реально.
Кто ж продаст сертификат промежуточного центра. Им же можно подписать сертификат для любого домена.

А на mail.google.com нормально заходит?

Можно попробовать в сквиде сделать редирект. А при использовании всяких squidGuard это сделать очень легко)

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

А это и был заход на mail.google.com, - он редирект делает на gmail.com/int/ru... и результат выдаёт по последнему.

Хотя в список всё добавил:

cat /etc/squid3/lists/mism_ssl
.mail.google.com
.gmail.com
.yadi.sk

А у Тебя на gmail.com заходит?

Alpha789 ()
Ответ на: комментарий от Alpha789

gmail.com и yadi.sk без точек в начале.

На mail.google.com - да, а на gmail.com - нет.

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Пробовал и без точек и потом уже точки дописал. Одно и тоже.

А Ты редирект с gmail.com на mail.google.com делаешь?

Если да, то как? Мне вот страшновато, что Гугл при очередном обновлении безопасности так же обезопасит и mail.google.com, и тогда редирет не поможет.

Alpha789 ()
Ответ на: комментарий от Alpha789

Нет, не делал.

И в mism_ssl у меня нет mail.google.com.

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Как Ты это всё настроил?

cat squid.conf | grep -v '^#'
acl mism_cert dstdomain -i "/etc/squid3/lists/mism_ssl"
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch

acl audio_t rep_mime_type content-type audio
acl video_t rep_mime_type content-type video
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
acl localnet src 192.168.1.0/24
acl SSL_ports port 443          # https
acl Safe_ports port 443         # https
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl icq_ports  port 5190        # ICQ
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow manager localhost
http_access allow localnet
http_access deny all
icp_access allow localnet
icp_access deny all

http_port 3128
http_port 3129 intercept
https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl/squid.pem key=/etc/squid3/ssl/squid.pem version=4 cipher=TLSv1:!AES128:!CAMELLIA
sslproxy_flags DONT_VERIFY_PEER
sslproxy_cert_error allow all
always_direct allow all
ssl_bump server-first all
ssl_bump none all
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB

hierarchy_stoplist cgi-bin ?
cache_mem 256 MB
cache_dir ufs /var/spool/squid3 512 16 256
access_log /var/log/squid3/access.log squid
cache_store_log none
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320
cache_mgr ***@***
icp_port 0
error_directory /usr/share/squid3/errors/Russian-1251
coredump_dir /var/spool/squid3/cache
cat lists/mism_ssl
gmail.com
yadi.sk
Alpha789 ()
Ответ на: комментарий от Alpha789

Так. Редирект не сработает.

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

конструкция

acl mism_cert dstdomain -i «/etc/squid/lists/mism_ssl»
acl redirq dst gmail.com
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName{'gmail.com'} redirq
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redirq

дает веселый результат:

gmail.com использует недействительный сертификат безопасности.
Сертификат действителен только для 'gmail.com'

С модификацией HSTS-заголовка еще можно поиграться, но сработает ли, не понятно.

Как Ты это всё настроил?

Не за один день.

Читая http://www.squid-cache.org/Doc/config/

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 1)
Ответ на: комментарий от Alpha789

И еще немного

acl redir dst gmail.com
acl noredir dstdomain mail.google.com
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName{gmail.com} redir !noredir
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redir

так сработало.

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Скопипастил - ругается на отсутствие mism_cert. Поэтому добавил так:

# head squid.conf
acl mism_cert dstdomain -i «/etc/squid3/lists/mism_ssl»
acl redir dst gmail.com
acl noredir dstdomain mail.google.com
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName{gmail.com} redir !noredir
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redir
Результат - переадресует на gmail.com и выдаёт прежнее:
www.gmail.com использует недействительный сертификат безопасности.
Сертификат действителен только для следующих имён:
mail.google.com, inbox.google.com
(Код ошибки: ssl_error_bad_cert_domain)

Alpha789 ()
Ответ на: комментарий от Alpha789

http://www.gmail.com

Ну да. Но без www работает.

Так попробовать:

acl redir dst gmail.com
acl noredir dstdomain mail.google.com
acl noredir2 url_regex mail\.google\.com
sslproxy_cert_adapt setCommonName{*.gmail.com} redir !noredir !noredir2
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redir !noredir2

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 2)
Ответ на: комментарий от Kuzz

Попробовал. Так же делает пересылку на gmail.com

www.gmail.com использует недействительный сертификат безопасности.
Сертификат действителен только для следующих имён:
mail.google.com, inbox.google.com
(Код ошибки: ssl_error_bad_cert_domain)
Хотя в логах пишет, что заход был на mail.google.com:
tail /var/log/squid3/access.log

1426849723.338    131 192.168.1.115 TCP_MISS/200 750 GET https://mail.google.com/ - ORIGINAL_DST/64.233.162.19 text/html
1426849723.483     68 192.168.1.115 TCP_MISS/302 992 GET https://mail.google.com/mail/ - ORIGINAL_DST/64.233.162.19 text/html
1426849723.634    137 192.168.1.115 TCP_MISS/302 960 GET https://accounts.google.com/ServiceLogin? - ORIGINAL_DST/173.194.71.84 text/html

Alpha789 ()
Ответ на: комментарий от Alpha789

Вот тут обязательно нужно очищать базу сертификатов

rm -f /var/lib/squid/ssl_db/certs/*;echo -n > /var/lib/squid/ssl_db/index.txt; echo 00 > /var/lib/squid/ssl_db/size;service squid restart

И в mism_ssl добавить вариант с www

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 1)
Ответ на: комментарий от Kuzz

Тоже самое... Может ещё чего не доглядел? Добавил в конфиг:

head squid.conf
acl mism_cert dstdomain -i «/etc/squid3/lists/mism_ssl»
acl redir dst gmail.com
acl noredir dstdomain mail.google.com
acl noredir2 url_regex mail\.google\.com
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName{*.gmail.com} redir !noredir !noredir2
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redir !noredir2
В списке есть с www и без:
cat lists/mism_ssl
gmail.com
www.gmail.com
yadi.sk
Почистил базу сертификатов и перезапустил squid. Та же ошибка "http://www.gmail.com использует недействительный сертификат безопасности." и в логах тоже попытка зайти на mail.google.com.

Alpha789 ()
Ответ на: комментарий от Alpha789
acl redir dst gmail.com
acl redir dst www.gmail.com

Ничего лучше не предложу, т.к. различать эти запросы и так не легко)

Non-authoritative answer:
http://www.gmail.com canonical name = mail.google.com.
mail.google.com canonical name = googlemail.l.google.com.
Name: googlemail.l.google.com
Address: 216.58.209.165

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 3)
Ответ на: комментарий от Kuzz

Добавил:

# head squid.conf
acl mism_cert dstdomain -i «/etc/squid3/lists/mism_ssl»
acl redir dst gmail.com
acl redir dst www.gmail.com
acl noredir dstdomain mail.google.com
acl noredir2 url_regex mail\.google\.com
sslproxy_cert_error allow mism_cert
sslproxy_cert_adapt setCommonName{*.gmail.com} redir !noredir !noredir2
sslproxy_cert_adapt setCommonName ssl::certDomainMismatch !redir !noredir2
Всё равно перенаправляет на gmail.com. Зато все остальные HTTPS работают без нариканий, контакт можно банить как обычно )) Принимаешь благодарность на яндекс-кошелёк?

Я вот думаю: возможно ли gmail.com мимо squid'а пустить в iptables?

Alpha789 ()
Ответ на: комментарий от Alpha789

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

Я вот думаю: возможно ли gmail.com мимо squid'а пустить в iptables?

Да.

Принимаешь благодарность на яндекс-кошелёк?

Против не буду :) 41001375029238

Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 1)
Ответ на: комментарий от Kuzz

Чистил... Продолжаю тыкать. Иногда (не всегда!) squid после перезагрузки ругается на этот конфиг:

# /etc/init.d/squid3 restart
[ ok ] Restarting Squid HTTP Proxy 3.x: squid3[....]  Waiting.....................done.
2015/03/20 18:31:21| WARNING: (B) '173.194.122.245' is a subnetwork of (A) '173.194.122.245'
2015/03/20 18:31:21| WARNING: because of this '173.194.122.245' is ignored to keep splay tree searching predictable
2015/03/20 18:31:21| WARNING: You should probably remove '173.194.122.245' from the ACL named 'redir'
2015/03/20 18:31:21| WARNING: (B) '173.194.122.245' is a subnetwork of (A) '173.194.122.245'
2015/03/20 18:31:21| WARNING: because of this '173.194.122.245' is ignored to keep splay tree searching predictable
2015/03/20 18:31:21| WARNING: You should probably remove '173.194.122.245' from the ACL named 'redir'
2015/03/20 18:31:21| WARNING: (B) '173.194.122.246' is a subnetwork of (A) '173.194.122.246'
2015/03/20 18:31:21| WARNING: because of this '173.194.122.246' is ignored to keep splay tree searching predictable
2015/03/20 18:31:21| WARNING: You should probably remove '173.194.122.246' from the ACL named 'redir'
2015/03/20 18:31:21| WARNING: (B) '173.194.122.246' is a subnetwork of (A) '173.194.122.246'
2015/03/20 18:31:21| WARNING: because of this '173.194.122.246' is ignored to keep splay tree searching predictable
2015/03/20 18:31:21| WARNING: You should probably remove '173.194.122.246' from the ACL named 'redir'

У меня сейчас и с www и без проходят.

А какая у Тебя версия squid? Из исходников? Можешь свой конфиг squid'а скинуть?

Alpha789 ()
Ответ на: комментарий от Alpha789

3.4.10 с вышеупомянутым патчем. Пересобраран rpmbuild-ом на базе спека от дистрибутивной версии.

Конфиги: http://rghost.ru/8glZRTngp

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Благодарю! Буду изучать в прикуску с мануалами squid.

А пока надо организовать доступ к gmail.com. Подскажи, пожалуйста, как в iptables пропустить gmail.com момо прокси? Тут подсказывают так:

iptables -t nat -N to_squid
iptables -t nat -A PREROUTING -p tcp --dport 80 -j to_squid
for a in $(host -t a gmail.com | awk '/has address/ {print $4;}'); do
    iptables -t nat -A to_squid -j return
done
iptables -t nat -A to_squid --redirect --to-port 3128
Но у меня iptables ругается:
iptables v1.4.14: Couldn't load target `return':No such file or directory

Alpha789 ()
Ответ на: комментарий от Alpha789

-j RETURN

iptables -t nat -A to_squid -j REDIRECT --to-port 3128

Проблема в том, что у gmail много айпишников, но днс отдает один, а чуть позже - другой.

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

Убираю "-j return" и дописываю "-j REDIRECT --to-port 3128". Получаю:

iptables: Chain already exists.
iptables v1.4.14: Need TCP, UDP, SCTP or DCCP with port specification
Добавляю "-p tcp", имея такое правило:
$IPT -t nat -N to_squid
$IPT -t nat -A PREROUTING -p tcp --dport 80 -j to_squid
for a in $(host -t a gmail.com | awk '/has address/ {print $4;}'); do
    iptables -t nat -A to_squid
done
$IPT -t nat -A to_squid -j REDIRECT -p tcp --to-port 3128
Просто получаю:
iptables: Chain already exists.

Alpha789 ()
Ответ на: комментарий от Alpha789

Убираю "-j return" и дописываю "-j REDIRECT --to-port 3128"

iptables -t nat -N to_squid
iptables -t nat -A PREROUTING -p tcp --dport 80 -j to_squid
for a in $(host -t a gmail.com | awk '/has address/ {print $4;}'); do
    iptables -t nat -A to_squid -d ${a} -j RETURN
done
iptables -t nat -A to_squid -p tcp -j REDIRECT --to-port 3128
Kuzz ★★★ ()
Последнее исправление: Kuzz (всего исправлений: 2)
Ответ на: комментарий от Kuzz

Делаю так:

$IPT -t nat -N to_squid
$IPT -t nat -A PREROUTING -p tcp --dport 80 -j to_squid
for a in $(host -t a gmail.com | awk '/has address/ {print $4;}'); do
    iptables -t nat -A to_squid -d ${a} -j RETURN
done
$IPT -t nat -A to_squid -p tcp -j REDIRECT --to-port 3128
Получаю тоже:
iptables: Chain already exists.
Как я понимаю, смысл ругани в том, что первая строчка «$IPT -t nat -N to_squid» повторяется далее.

Alpha789 ()
Ответ на: комментарий от Alpha789

Не повторяется, но существует. С предыдущих запусков осталась.

Kuzz ★★★ ()
Ответ на: комментарий от Kuzz

С предыдущих запусков осталась.

Очищаю вроде бы все таблицы:

$IPT -F
$IPT -t nat -F
$IPT -t mangle -F
$IPT -X
На всякий случай, перезагрузил систему. В логах при старте системы та же ошибка:
iptables: Chain already exists.

Alpha789 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.