Hi!
Transparent squid, amire most lőttem volna rá a https-t. Mivel nem volt benne https támogatás, így forrásból befordítottam, beállítások megvoltak és forgalomátirányítás is működött.
A puding kóstolásánál - jogosan - szólt a cliens, hogy valaki közbeékelődött, egyes esetekben lehetett volna tanúsítványt telepíteni, míg másoknál nem.
Első olvasatra a WPAD beállítását javasolták több helyen. Kérdésem az lenne a tapasztalattal rendelkezőkhöz, hogy ez valóban megoldja a problémát és ezzel a cliens nem panaszkodik, vagy ez a "panaszkodás" elkerülhetetlen?
Amennyiben nem megoldható, úgy kérdezném a nagyérdeműt, hogy https forgalom szabályozására (időbeli korlát, esetleg teljes tiltás) mit használtok?
Előre is köszönöm a segítséget, javaslatokat!
- 1982 megtekintés
Hozzászólások
Mindenki "simán" kiengedi a https-t, esetleg zorp-ot használ?
- A hozzászóláshoz be kell jelentkezni
Miért türelmetlenkedsz? Ha majd ráér valaki hozzáértő, és van is kedve, akkor válaszol.
- A hozzászóláshoz be kell jelentkezni
Elnézést a türelmetlenségért, de a jót könnyű megszokni, hogy itt a HUP-on egy jó fél nap alatt legalább egy válasz, iránymutatás összejön.
- A hozzászóláshoz be kell jelentkezni
Szerintem a WPAD-nek semmi köze ahhoz, hogy a kliens elfogad-e egy új tanúsítványt, vagy sem. Ha a squid-eden levő tanúsítvány self-signed, akkor jogos, hogy néhány kliens nem hajlandó azt telepíteni. Ha pedig van egy CA, aki kiállította, akkor az adott CA tanúsítványát a kliens nem fogadja el megbízhatónak.
Egyébként kellenének még OS- és böngészőverziók is.
http://stackoverflow.com/help/how-to-ask
- A hozzászóláshoz be kell jelentkezni
Jogos!
Debian etch, squid 2.6.
Igen, elavult, régi, de csak forgalom megy át rajta, mást nem kell csinálnia, azt meg eddig szépen tette.
Persze most, ha kell akkor cserélünk, és ezért is indult a topik, hogy https-hez mit?
Igen, self-signed.
- A hozzászóláshoz be kell jelentkezni
[off]
shellshock és társai kapcsán mindent kézzel frissítgettél?
[/off]
- A hozzászóláshoz be kell jelentkezni
Ugye nem a Lenovónak dolgozol?
- A hozzászóláshoz be kell jelentkezni
A témában én is érintett vagyok: van egy hasonló problémám, de idő szűkében a megoldás még nincs meg.
Az első dolog, amit mindenképpen tudni kell, hogy a transzparens-proxy máshogy működik, mint a dedikált proxy. Transzparens proxy esetén például nem kérhető proxy-auth, hiszen a böngésző szempontjából nincs is proxy, ha pedig ezt megkerülendő a proxy eljátssza azt, hogy a weboldal kér authentikációt, akkor a továbbiakban nem lehet belépni a jelszóval védett oldalakra.
A másik dolog, hogy a proxy mindenképpen egy közbeékelt dolog lesz. Egy titkosítatlan kapcsolat ezt minden különösebb nélkül kiheveri - egy titkosított viszont azonnal ideges lesz, mert a közbeékelődés ténye kiderül.
A megoldási lehetőségek, amiket látok - de nem mindegyikről tudom, hogy mennyire jó, mennyire működőképes:
1) ha dedikált proxyról van szó, akkor a kliens _tudja_ hogy történik közbeékelődés, éppen ezért viszont ezt akár le is kezelheti. A WPAD arról szólna, hogy a kliens automatikusan kapja kapja meg a proxy paramétereit, így ott külön ne kelljen bűvészkedni proxy beállításokkal. A gond csak annyi, hogy nem tudom, igaz-e a tündér mese...
2) a proxyn van egy CA privát kulccsal, mindennel. A CA a kliensen importált. Ekkor egy új kapcsolathoz a proxy vihar gyorsan generál egy temporáris certet, az eredeti tanúsítvány CN mezejével és a saját CA-jával aláírva. Ekkor a kliens a tanúsítványt élből hitelesnek fogja látni - de ezt proxy oldalon meglehetőst macera elkövetni, illetve security problémákat is érzek ennek a megoldásnak a kapcsán.
- A hozzászóláshoz be kell jelentkezni