Squid + https

 ( sipiatti | 2006. szeptember 12., kedd - 13:58 )

Sziasztok,

A problémám a következő:
Adott egy vállalati háló, ahol egy proxy engedi ki az internet forgalmat, a 8080-as porton figyeli a http és https kéréseket, megy minden rendben. Én egy cég a cégben helyen csücsülök a központi proxyra semmiféle ráhatásom nincsen, sajna, viszont az egyik user nevében proxyt kell összeraknom, hogy az ő autentikációjával ketten tudjanak netezni.

Egy uhu 1.1 gép adott, amin squid 2.5 van. Átolvastam az irodalmat és összeállítottam egy squid.conf-ot. A http böngészés megy, a https nem. A hibaüzenet a cache.log-ban:
2006/09/12 11:46:23| clientNegotiateSSL: Error negotiating SSL connection on FD 14: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request

A konfig az alábbi:
##############################################################
http_port 3128
https_port 3129 cert=/var/squid/cert/cert.pem key=/var/squid/cert/key.pem

icp_port 0
htcp_port 0

cache_peer proxy.gep.neve parent 8080 3130 proxy-only default no-query no-digest no-netdb-exchange allow-miss login=user:pass

maximum_icp_query_timeout 500

#hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
acl QUERY1 urlpath_regex .php \?
no_cache deny QUERY
no_cache deny QUERY1

refresh_pattern . 0 20% 4320

acl all src 0.0.0.0/0.0.0.0
acl human src 10.1.0.0/16
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 8080 # http
acl Safe_ports port 21 8080 # ftp
acl Safe_ports port 443 563 8080 # https, snews
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 CONNECT method CONNECT

http_access allow manager localhost
http_access allow human
http_access allow localhost
http_access deny !Safe_ports
#http_access deny CONNECT !SSL_ports
http_access allow CONNECT Safe_ports
http_access deny all
http_reply_access allow all

never_direct allow all

miss_access allow all

#icp_access allow all

coredump_dir /var/cache/squid
###############################################################

Teljesen képzetlen vagyok SSL ügyben, csak amit magamra szedtem az van, az meg elég kevés... megcsináltam a kulcspárokat egy guglizott paranccsal, miután amit a manpage szerint összeállítottam nem tetszett a squidnek ;-) de ezzel már elindult.

Ha a böngészőket az eredeti központi proxykra állítom, akkor simán megy a https, az én proxymon keresztül meg nem, a Firefox azt mondja:
"A kiszolgálóhoz való kapcsolat alaphelyzetbe állt az oldal letöltése közben."
Gondolom ez a "Connection reset by peer" akar lenni...

Szétgugliztam magam, persze lehet hogy nem jóra kerestem rá, de nem találtam erre megoldást, viszont láttam hogy más is érdeklődött már ilyen hiba miatt, de sajnos épkézláb választ nem adott senki nekik sem.

Plz segítsen vki mert a két kolléga már lassan leszedi a fejemet, és a főnőkkel fenyegetőznek ;-)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nekem ilyen SSL-es dolgok vannak a squid.conf-ban:

acl          SSL_ports  port    443 563  # Standard SSL ports
acl          SSL_ports  port    18180    # KSH SSL port, vazze!!!
acl          SSL        method  CONNECT
http_access  deny       CONNECT !SSL_ports

Úgy nézem, neked a harmadik nincs. A második csak akkor kell, ha KSH-t is el kell tudni érni. ;-)

"az ő authentikációjával ketten..." Gondolom ezt a céges LAN-policy teljes mértékben megengedi. Ha meg nem, akkor nyugodtan menjenek a főnökhöz, az adja írásba, hogy Gipsz jakab azonosítójával kell egyszerre Ló Bélának is...

"Gondolom ezt a céges LAN-policy teljes mértékben megengedi. Ha meg nem, akkor nyugodtan menjenek a főnökhöz, az adja írásba, hogy Gipsz jakab azonosítójával kell egyszerre Ló Bélának is..."
Ebben tökéletesen igazad van, de nem ez volt a kérdés. ;-) Ez a része a dolognak legyen az ő problémájuk. :-)

A "főnökkel való fenyegetés" elhárítására sokszor igencsak alkalmas a vonatkozó szabályzat lobigtatása, és a felhasználó szépszóval történő felhívása arra nézve, hogy az áthágására a főnök adjon írásos utasítást.

hehe, mint írtam volt cég a cégben vagyunk, és mivel újabb user/pass igénylése az "anyacégtől" fizetős, ezért az egész a főnök tudtával és beleegyezésével történik :-)

az egész vállalatcsoport csaknem 10 000 ember ebből legalább 2500-nak van munkaállomása, szóval nem kicsi a háló

amúgy már pár hónapja tologatom a kérést, de mivel más kis cég is létezik a nagy cégben, drága júzereim az egyik ilyen kiscégben lévő barátaiktól szereztek tudomást a megoldás létezéséről. mivél én elhajtottam őket, meggyőzték a főnököt ötletük briliáns voltáról, és olcsóságáról
GIGALOL... mert amúgy forgalmi díj is van nemcsak user díj, úgyhogy sokat nem nyernek vele, nameg így egyiküknek csak free emailcíme van, mert a userhez csak 1 jár... télleg briliáns nem? ;-) gmailről intézni a céges levelezést, hehe...

mind1, amúgy sikerült a dolog, 1 ötlettől vezérelve kivettem a https figyelést és maradt a never_direct allow all, és csodák-csodája megy... ráéreztem valahogy, de a lényeggel nem vok tisztában, csak halvány lila gőzöm van...

szóval most a 3128-ra továbbítja a böngésző a https kérést is, és a squid a never_direct allow all miatt tovább zúzza a központi proxynak, az meg lerendezi a többit és visszahányja az eredményt

amúgy a 3.0-ás squid már a cache_peer beállításoknál konfigolható "rendes" ssl-https továbításra de asszem az meg még nem stable úgyhogy ejtettem a dolgot, na meg nem volt kedvem az uhu 1.1 alá fordítgatni, fő a lustaság