https átirányítása http -re

Security-all

Szevasztok,

adva van egy hely, amit ki kell tiltani cégen belül. A squidben be van állítva, hogy mit szabad, mit nem. A kitiltás működik is. Azonban ragaszkodnának ahhoz, hogy kitiltáskor egy bizonyos üzenet jelenjen meg a t. felhasználónak (ez is érthető). A squid megfelelő részén változtatva csilivili saját hibaüzenet van.
A probléma ott kezdődik hogy adott oldal https re IS hallgat, így a kliens böngészője válaszol hogy nem sikerült a biztonságos csatornát létrehozni. Ez alapbeállításként erősebb mint hogy mit kap választ a squidtől.
Biztos vagyok benne hogy ti itt már megoldottatok ilyet :)
Szóval az ötlet az lenne, hogy a DNS ben állítanám be az "új" elérési útját az adott oldalnak (belső saját hely), ahol a https-> http
ahol is a megadott oldalt jelenítené meg, amiben tájékoztatja a felhasználót hogy ez tiltott oldal.

Azt kipróbáltam, hogy a hvg.hu ne kintre mutasson, hanem belső saját helyre, és működik. Https nél nyilván ez nem csak ennyi.
xampp van belül, ott kellene a .htaccess ben mókolni. ilyet találtam a neten erről:
RewriteCond %{HTTP_HOST} ^www [NC]
RewriteRule ^(.*)$ https://domainem.hu/$1 [L,R=301]

RewriteCond %{ENV:HTTPS} !=1 [NC]
RewriteRule ^(.*)$ https://domainem.hu/$1 [L,R=301]

Mik a tapasztalatok? Hogy érdemes ezt megoldani?

  • 2522 megtekintés

( SzBlackY | 2015. 11. 18., sze – 09:14 )

Transzparens proxy?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( secretx v | 2015. 11. 18., sze – 09:18 )

Technikailag erről van szó ( http://wiki.squid-cache.org/Features/SslBump ), de ez elég randa egy dolog na :)
(én maradnék dns + csili vili hibaüzenet megvalósításnál amit te is elkezdtél..)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( mindenesetre | 2015. 11. 19., cs – 09:18 )

Az ilyen .htaccess es próbálkozásból mindegyike kudarcba fulladt.
A kliens böngészője mindegyiknél megállította a megjelenítést, és felhívta a figyelmet hogy nem az történik aminek kéne.

nincs ötletem hogy lehetne kivitelezni ezt.

( hrgy84 | 2015. 11. 19., cs – 09:39 )

Nem tudom, mennyire vagy tisztaban a rendszer alatt levo protokollok mukodesevel, ugyhogy menjunk az alapoktol.

A legegyszerubben szerintem DNS-elteritessel tudnad ezt megcsinalni, felhuzol egy olyan webszervert, amely minden elteriteni kivant oldalhoz rendelkezik a kliensek altal elfogadott CA-tol szarmazo ervenyes tanusitvannyal (tipikusan ez egy belso CA lesz, kulsos CA az eletben nem fog neked olyan domainre tanusitvanyt kiadni, ami nem kotheto hozzad, plane nem egy popular oldalet), es a kert oldal helyett egy altalanos uzenet jon be. Ezt az elteritett DNS-t - ha nem transzparens a proxy - eleg csak a proxy gepen beloni, hiszen a DNS feloldasokat ugyis az vegzi.

Az a lenyeg, hogy eleg csunya dolog HTTPS-rol HTTP-re migralni a kapcsolatot, nem is szoktunk ilyet csinalni, inkabb akkor fakeld ki az oldalt.

Ami itt a buktato tud lenni, az a CA tanusitvanyanak terjesztese a kliensek gepere. Ha ez nincs meg, akkor a kliensek automatikusan zokogni fognak, es a bongeszo tanusitvanykopkodos oldala jon be a vagyott hibauzenet helyett. Hibauzenet lehet akkor is, ha a kiadott cert nem ervenyes az elteriteni kivant oldalra, illetve a www-re.

Szumma: nem tudod meguszni egy tisztesseges PKI infra es DNS mokolas nelkul ugy, hogy ez szep is legyen, meg jo is legyen. A rewrite eleg egyszeru, mindent az index.html-re irsz at, es NEM permanent redirecttel. Azert nem, mert ha valaki pl. a mobiljarol szeretne facebookozni, akkor elbokod neki a cache-t igy, es az lesz a siram, hogy otthon se mukodik neki a facebook, es hogy josz te ahhoz, hogy megmondd, hogy otthon mit csinalhat (btw teljesen jogos vad). A temporary redirect azonban megoldja ezeket a problemakat (R=302), az nem cachelodik.
--
Blog | @hron84
Üzemeltető macik

( zrubi v | 2015. 11. 19., cs – 09:52 )

átírányítani https-t nem fogsz tudni, és túl sok értelme sincs.

Squid-ben ha saját szabályok miatt nem elérhető valami, arra is lehet saját hibaoldalt csinálni, amin keresztül tájékoztathatod a felhasználókat. Sőt ott már akár egy auto redirect-et is tehetsz a kívánt oldalra, mert ezek a hibalapok dinamikusak is lehetnek.

A probléma ott kezdődik hogy adott oldal https re IS hallgat, így a kliens böngészője válaszol hogy nem sikerült a biztonságos csatornát létrehozni. Ez alapbeállításként erősebb mint hogy mit kap választ a squidtől.

Ez számomra érthetetlen, ugyanis ha proxy van beállítva, akkor már eleve a connect sem sikerül, amit szintén a squid fog kezdeményezni, ami a kliens számára azt jeleni, hogy az oldal nem elérhető. -> e-helyett KELL hogy megjelenjen a saját squid hibalap...

----
Ez eredeti terved megvalósításához amit tehetsz - bár véleményem szerint ez durva jogi problémákat vet fel - hogy egy fake, az átirányítandó címre szóló tanúsítványt állítasz ki, és felhúzol a segítségével egy webszervert. Persze tanúsítvány warning-ot biztosan kapnak majd a júzerek (hacsaknem a céges PKI-val teszed mindezt, amit ismernek a kliensek. Ezesetben a jogi probléma és az esetleges következmény persze mégnagyobb)

Szóval, ezt senkinek nem ajánlom.

--
zrubi.hu

A jogi hercehurca valóban elkerülendő, és nagyon is értem hogy miért van és mire jó ez a https dolog a böngészők részéről. Tökre igazad van a certtekkel kapcsolatban.

örülök, hogy így működnek a böngészők, mert ennek így kell lennie.

Tény, hogy a squid tiltogat, meg van neki hibaüzenete: a kliens böngészője arról tájékoztat, hogy a https csatorna nem jött létre. Csak ennyi a gondom. Végül is működik az oldal kitiltási eljárásom, csak a hivatalos blabla nem jelenik meg https esetén.
Többi esetben a squidben beállítgatott csillogásos hibaüzi jön.

( foci v | 2015. 11. 19., cs – 10:27 )

squidguard és egy kis php teljesen egyedi üzeneteket lehet tolni a felhasználónak!

( Fisher v | 2015. 11. 19., cs – 11:02 )

http://www.squid-cache.org/mail-archive/squid-users/200912/0316.html

Azaz az adott oldalakra tiltod a CONNECT metódust (de szép szó) és erre gyártasz egy megfelelő, céges, csilivili hibaoldalkát (ami nagyjából egy link a másikra).
A jelen esetben ha jól értem akkor az van hogy tiltod mindenhová, kiéve ahová nem, de ez már lényegtelen.

A fenti hihetően hangzik, de nem próbáltam ki.

sslbump leírása:

{X} WARNING: {X} HTTPS was designed to give users an expectation of privacy and security. Decrypting HTTPS tunnels without user consent or knowledge may violate ethical norms and may be illegal in your jurisdiction. Squid decryption features described here and elsewhere are designed for deployment with user consent or, at the very least, in environments where decryption without consent is legal. These features also illustrate why users should be careful with trusting HTTPS connections and why the weakest link in the chain of HTTPS protections is rather fragile. Decrypting HTTPS tunnels constitutes a man-in-the-middle attack from the overall network security point of view. Attack tools are an equivalent of an atomic bomb in real world: Make sure you understand what you are doing and that your decision makers have enough information to make wise choices.

Hát igen, a baj az, hogy eleve az ssl kapcsolat nem tud kiépülni, ezért nem fog működni semmiféle átirányítás, mert ahhoz, hogy az átirányítás adatait megkapja a kliens, egy már működő ssl kapcsolat kellene.

Ezért nincs igazándiból más megoldás, mint hogy bűvészkedsz a tanúsítványokkal, vagy hagyod a fenébe az egészet.

( rts | 2015. 11. 19., cs – 14:29 )

"adva van egy hely" => "a hvg.hu ne kintre mutasson"
;D