Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

HTTPS proxy - open source rjesenje?

[es] :: Linux/UNIX serveri i servisi :: HTTPS proxy - open source rjesenje?

[ Pregleda: 3868 | Odgovora: 18 ] > FB > Twit

Postavi temu Odgovori

Autor
Pretraga teme: Traži
Markiranje Štampanje RSS

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon HTTPS proxy - open source rjesenje?07.08.2010. u 22:14 - pre 166 meseci

Da li je neko uspio primjeniti neko open source rjesenje (ili kombinaciju postojecih rjesenja) za inspekciju HTTP-a unutar SSL-a? Ideja je "man-in-a-middle" napad na SSL sesiju gdje bi HTTPS sadrzaj bio dekriptovan na (transparentnom) proksiju, ispitan/filtriran i potom HTTP ponovo spakovan u drugu SSL sesiju (opet pomocu proksija/akceleratora) i tako serviran klijentu.

Postoji vise komercijalnih rjesenja sto govori u prilog tome da je takva tehnologija u sirokoj upotrebi. U open source svijetu u sustini postoje sve komponente za proces uspostavljanja HTTPS sesije sa serverom na jedonoj i klijentom na drugoj strani samo ih treba uvezati u neko pouzdano rjesenje. Svaka ideja je dobro dosla, a ne bi izostao ni neki materijalni vid podrske za razvoj ovakvog rjesenja, sve dok bi sav razvoj ostao open source.

Vrlo bih cijenio da se svi moralni aspekti inspekcije HTTPS-a ostave po strani, kao i cinjenica da je smisao HTTPS-a da eliminise inspekciju saobracaja izmedju klijenta i servera.
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 09:22 - pre 166 meseci
Pogledaj kombinaciju dsniff, dnsspoof i webmitm.
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 12:11 - pre 166 meseci
Upotrebom navedenih alata dobijem pristup HTTP sadrzaju unutar SSL konekcije, bez znanja klijenta, sto je idealna situacija. Pitanje je kako sad taj HTTP sadrzaj predati na inspekciju, odnosno propustiti kroz (neki postojeci) HTTP content/antivirus filter prije nego sto bude predat klijentu u okviru nove SSL sesije?
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 12:37 - pre 166 meseci
Citat:
Aleksandar Olujic: Upotrebom navedenih alata dobijem pristup HTTP sadrzaju unutar SSL konekcije, bez znanja klijenta, sto je idealna situacija. Pitanje je kako sad taj HTTP sadrzaj predati na inspekciju, odnosno propustiti kroz (neki postojeci) HTTP content/antivirus filter prije nego sto bude predat klijentu u okviru nove SSL sesije?


Nakon ovog tvog pitanja, sledi moje: Zasto bi to radio u corporate okruzenju?
Koriscenjem HTTPS mitm attack-a, ti moras da prezentujes self-signed (lazirane) sertifikate klijentu, a sve u svrhu skeniranja antivirus filterom?
Bojim se da ces sve custom filter-e morati rucno da odradis svojim code-om.
 
Odgovor na temu

mulaz
Ljubljana

Član broj: 47602
Poruke: 2239
*.dial-up.dsl.siol.net.

Jabber: mulaz@elitesecurity.org
Sajt: www.mulaz.org


+184 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 12:48 - pre 166 meseci
A i svaki iole dostojan browser, ce ti pokazati warning, da self-signed certifikat za recimo gmail.com nije potpisan sa strane puzdanog lica (verisign i sl.).

Bolje ispasti glup nego iz aviona
http://www.mulaz.org/
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 13:29 - pre 166 meseci

Zelio sam izbjeci diskusiju o tome koliko je korisno (i nemoralno) u korporate okruzenju imati HTTPS filtering ali vidim da je to bitan dio citavog koncepta pa bih izlozio svoje argumente:

U pitanju je policy enforcement - ako organizacija zabranjuje pristup korisnicima web sadrzaju koji smatra neprikladnim za korporativno okruzenje, onda takvi sadrzaji trebaju biti zaustavljeni i kada putuju u SSL-u. Takodje, ako postoji polisa koja regulise data leak prevention, da bi mogla da se primjeni, nepohodno je filtrirati i HTTPS, zar ne? Treci i manje bitan slucaj je namjerno ili slucajno stavljanje na raspolaganje trecim licima resursa organizacije - vecina programa koji to rade (remote desktop, skype, etc) koriste HTTPS.

Sto se tice prezentiranja "laznog" ili bolje reci drugog sertifikata, tu postoji problem samo ako je korisnik u sustini u stanju da razlikuje sertifikat potpisan od strane javnog autoriteta od onog koji je potpisan "svojerucno". Zanemarljivo mali broj ljudi ce odreagovati ako se pravi sertifikat zamijeni nekim drugim, a prompt koji se pojavljuje u browseru moze biti eliminsan ubacivanjem sopstvenog CA u browser.

Naravno, postoji sigurnosni drawback a to je da ako korisnik pristupa sajtu koji je vec zrtva mitm napada, nema nikakve sanse da to prepozna. Microsoft to rjesava time sto kroz svoj HTTPS filter ne propusta sajtove sa self-signed sertifikatima, a postoji i mogucnost da se klijentu preda i originalni sertifikat nakon skeniranja, ali to je vec izvan dometa ove teme.

Nekako mi nije logicno da treba uloziti vrijeme u pisanje custom filtera kada filteri za HTTP vec postoje i siroko su rasprostranjeni. Postoji mogucnost da se bez znanja korisnika tj. real-time i transparentno, od HTTPS-a dobije HTTP koji moze da se filtrira i potom vrati u HTTPS radi sigurnosti.

Po toj logici webmitm, dsniff bi trebali da iz HTTPS-a izdvoje HTTP i klijentu, odnosno njegovom HTTP proksiju koji vrsi filtriranje, predaju HTTP saobracaj i da se ne bave ponovnim pakovanjem u SSL. Pravi klijent (browser) bi razgovarao sa nekim HTTPS akcelratorom (na koji ga je naveo dnsspoof) koji bi sve opet pakovao u SSL. Meni to sve izgleda izvodljivo ali zaista ne znam kako bi moglo da se primjeni.

Da pisem kod nisam u stanju jer nisam programer. Ali rado bih saradjivao sa programerima koji su voljni da se pozabave ovom temom i stavio bih, za pocetak, u tu svrhu na raspolaganje server na kome moze da se radi razvoj.
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 15:55 - pre 166 meseci
Evo ovako...

Razlog zasto sam pitao tj. pokrenuo pitanje HTTPS filtering-a je taj sto mislim da imas pogresan pristup.
Slazem se da moze da se uvede policy enforcement:
1. blokiranje sadrzaja koji nisu prikladni za korporativno okruzenje
2. data leak prevention
3. ??? nisam siguran sta podrazumevas pod "namjerno ili slucajno stavljanje na raspolaganje trecim licima resursa organizacije - vecina programa koji to rade (remote desktop, skype, etc) koriste HTTPS". Btw, skype i remote desktop ne koriste https. Mozda si mislio na "Remote Desktop Web Connection" tj. pristup RDC preko web-a.

Problem prezentiranja laznog sertifikata klijent-u (browseru) nije samo sto ce ti neki korisnik primetiti promenu(lazni) sertifikat, nego mozes TI licno da "stradas" u slucaju bilo kakve kontra "akcije" sprovedene od strane drugih lica (npr. policije). Ako zaista zelis da radis HTTPS filtering obezbedi OBAVEZNO potpis svog nadredjenog da je on to licno odobrio. Verovatno taj sto to odobri nema predstavu sta je PKI i cemu HTTPS sluzi.

Toliko i kritici pomenutog resenja, a sada predlog.
Sto se tice iznesenog requirement-a (1 i 2, ne znam sta si mislio pod 3.), evo jednog resenja za to iz kompanije Example.com koja ima slican policy:
a. uvodjenjem restriktivnog outbound firewall rule set-a i koriscenje proxy servera: Za sve user-e (user vlan) svi outbound portovi moraju biti blokirani (za inbound se podrazumeva). I za koriscenja HTTP i HTTPS je neophodan proxy server.
b. physical security (LAN i WLAN) koriscenjem port security mehanizma ili 802.1x. Niko ne sme da ti se zakaci na internu kompanijsku mrezu.
c. USB/removable disk control: spreciti koriscenje removable diskova
d. URL filtering, black lists i proxy reporting: neophodno je raditi URL filtering na bazi black lista. Black liste su malo problem, pa se u vecini slucajave svodi na rucno odrzavanje prema kompanijskim potrebama. Reporting-om postizes da dodjes do odgovarajucih "kandidata" za black liste. Obicno svi URL-ovi koji nisu prikladni za korporativno okruzenje se nalaze na samom vrhu sto se tice koriscenja.
e. javni mail servisi moraju biti blokirani

E da, zaboravih da napomenem, security dosta kosta. Nije jeftin iako se nekoriste M$ alati. :-)

Mozda sam nabrzaka nabacao neke cinjenice, ali stogod nije jasno slobodno pitaj.
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 17:41 - pre 166 meseci
Ne vidim zasto je filtriranje sadrzaja kod HTTPS-a drugacije od filtriranja HTTP-a s obzirom da se jednako osjetljive informacije mogu naci i u jednom i u drugom. Ako je korisnik vec obavijesten da ne raspolaze kompjuterskim resursima u potpunosti vec na nacin koji uredjuje organizacija, ukljucujuci pravo organizacije da filtrira i posmatra sve akcije korisnika, mislim da nema mnogo administrativnih prepreka da se takav mehanizam stavi u upotrebu, narocito ako biznis to zahtjeva. Ali, to je sasvim druga tema, vazna ali ipak sekundarna u odnosu na samo tehnicko rjesenje kome ovdje tezimo.

Nisam se dobro izrazio kad sam napisao "remote desktop", mislio sam na servise tipa logmein koji omogucavaju nekome ko nije authenticated na mrezi da koristi resurse unutar mreze, preko HTTPS-a. Ako polisa ogranicava pravo koristenja kompjuterskih resursa na odredjenu grupu zaposlenih i definise kao prekrsaj stavljanje tih resursa na raspolaganje trecim licima (onim koji nisu zaposleni ili nisu authenticated) onda bi policy enforcement bio vezan za zaustavljanje takve komunikacije. Isto vazi i za Skype koji nazalost funkcionise kao peer-to-peer softver i svaki aktivan Skype je potencijalni relej za tudje razgovore, bez kontrole korisnika. Korsinici naravno toga nisu svjesni pa je to nesvjesno stavljanje na raspolaganje... Skype protokol moze u cjelosti da se tunnel kroz HTTP, samim tim i HTTPS i ne zahtjeva da na firewall-u bude dozvoljen outbound traffic vec koristi proxy.

Blacklisting je tricky business i neko stalno mora da azurira te liste cime one gube smisao. Sa druge strane malo koja blacklista ce uhvatiti virus koji sretno uploaduje povjerljive informacije preko HTTPS-a ili korisnika koji zaobilazi filter upotrebom javnog HTTPS "tunneling" proksija. To je neverending story. Blacklists i IPS sistemi lose izlaze na kraj sa takvim problemima. Zato bih HTTPS povjerio programima koji dobro razumiju HTTP. Ako je to moguce.

Motiv za upotrebu open source nije samo cijena. Isto vazi i za izbjegavanje upotrebe Micorosfta. Komercijalne alternative su BlueCoat, Stongate, Ironport (Cisco), Netronome.

A sad da vidimo da li je to moguce na linuxu sa open source alatima :)
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 21:29 - pre 166 meseci
Evo redom...

Oko razlike i pravnog aspekta filtriranja HTTP i HTTPS, kao sto kazes bi mogli raspravljati, ali to nije tema. Bottom line je da u oba slucaja moraju korisnici biti obavesteni o tome, kao i da imas na umu lokalne zakone koji vaze u zemlji u kojoj to sprovodis. Obrati paznju na to!
Sto se tice tehnickih detalja, nemogu da se tacno sada setim niti da tvrdim, ali mislim da postoje situacije kada je to neizvodljivo tj. kada ti odgovarajuce aplikacije nece raditi u slucaju HTTPS mitm atack-a ili bolje reci HTTPS inspection-a.

Sto se tice logmein-a i slicnih remote admin alata, to se lako sredjuje URL filteringom kao i nekim od End point resenja.
Sto se tice Skype, to je stvarno prica za sebe. On je nazalost postao neki standard cak i u poslovnoj komunikaciji.
Elem, sva ta "gamad" se ubija nekim od End Point security resenja. Jedno od tih resenja nudi i Symantec (SEP) koji se pokazao kao mocna stvar, mada ga ja licno nevolim.

Blackliste jesu malo tricky business, ali su dosta uspesne. Svi public anonym. proxy serveri se odmah nadju na listi tako da je koriscenje public proxy servera brzo eliminisano. Sa druge strane blackliste je neophodno odrzavati. Nije jeftino, kao sto sam pre spomenuo. Nemoj se nadati da ces naci gotovo open source resenje koje ce sve samo da radi. :-) Ili ces platiti ljude koji ce to odrzavati (liste) ili ces placati gotove liste.
Ako pogledas i komercijalna resenja, sva se ona zasnivaju na non-stop azuriranju svoje baze. Svojevremeno sam imao jednu Barracuda Spam firewall 300. Zver, stvarno mocna stvar. Znas sta se desilo kada je istekao subscruption period? Posle 1-2 meseca, kao da je nije ni bilo, jer je sve prolazilo kroz nju.

Sto se tice virusa koji sretno upload-uje poverljive informacije preko HTTPS, bojim se da ti tu bilo sta moze pomoci na proxy filtering-u. Moze virus da ti upload-uje i preko HTTP-a pa ti URL filtering engine nece tu moci nista. Takve stvari se resavaju na client-u (user PC-u).

Voleo bi i ja da cujem neka druga resenja.


Mozda bi moderator mogao temu da prebaci u Enterprise networking.
 
Odgovor na temu

mulaz
Ljubljana

Član broj: 47602
Poruke: 2239
*.dial-up.dsl.siol.net.

Jabber: mulaz@elitesecurity.org
Sajt: www.mulaz.org


+184 Profil

icon Re: HTTPS proxy - open source rjesenje?08.08.2010. u 21:33 - pre 166 meseci
Moze virus i preko dns tunela, pa i bez https-a :)
Bolje ispasti glup nego iz aviona
http://www.mulaz.org/
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
217.24.241.*



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?09.08.2010. u 10:45 - pre 166 meseci

Za filtriranje HTTP-a koristim dansguardian - ne zahtijeva azuriranje blacklist-a jer su one u sustini samo dodatni mehanizam za filtriranje. Glavni mehanizam je regex filtriranje stranica i davanje odredjene vrijednosti pojedinim frazama i kad njihov zbir dosegne odabranu granicu, ta stranica biva blokirana. I taj princip "just works". Naravno ne postize idealne rezultate ali sprjecava da najgori junk dodje do korisnika i pri tom podsjeca korisnika na to da se njegove aktivnosti posmatraju. Broj sajtova koje treba izuzeti od filtriranja (false positives) je 5-10 godisnje.

Nesto slicno vazi i za spam. Open source rjesenja koja koristim (uobicajena kombinacija amavis, postfix, spamassassin+razor+dspam), bez nekih posebnih podesavanja, jednostavno rade i cine da je spam non-issue, iako se setovanja mogu smatrati vrlo relaksiranim. Svakih par godina pravimo istrazivanje trzista za anti-spam rjesenja i nista do sada nije uspjelo da prevazidje ovu kombinaciju (cijena/skalabilnost/odrzavanje/features). Prosto ne mogu da vjerujem da ljudi mogu da imaju probleme sa spamom ili da zavise od pretplate na komercijalne servise.

Crna rupa u citavoj prici je HTTPS. Ako postoji mogucnost da se isti filtrira kao HTTP onda ne moram investirati u neke dodatne mehanizme (e.g. blacklists) i povecavati administative overhead jer sve sto mi treba je vec tu. Onda mi nije bitno ako korisnici koriste anonymizer dokle god kroz njega ne pristupaju neprikladnom sadrzaju. Takodje ne bih prepustio inspekciju HTTPS-a IPS/IDS sistemu (nek se bavi DNS-om i ostalim stvarima) niti nekom out-of-band monitoringu jer prosto ne moze da pruzi rezultate koje postize pravi HTTP filter (ili vise njih). U citavoj prici imamo squid, apache, dansguardian dsniff/webmitm - sve su open source programi sposobni da urade od HTTP-a i HTTPS-a svasta :) Da li ima sanse da se pomocu njih vrsi efikasna inspekcija HTTPS-a?
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?09.08.2010. u 17:35 - pre 166 meseci
Citat:
Aleksandar Olujic: Za filtriranje HTTP-a koristim dansguardian - ne zahtijeva azuriranje blacklist-a jer su one u sustini samo dodatni mehanizam za filtriranje. Glavni mehanizam je regex filtriranje stranica i davanje odredjene vrijednosti pojedinim frazama i kad njihov zbir dosegne odabranu granicu, ta stranica biva blokirana. I taj princip "just works". Naravno ne postize idealne rezultate ali sprjecava da najgori junk dodje do korisnika i pri tom podsjeca korisnika na to da se njegove aktivnosti posmatraju. Broj sajtova koje treba izuzeti od filtriranja (false positives) je 5-10 godisnje.

.....
.....

Crna rupa u citavoj prici je HTTPS. Ako postoji mogucnost da se isti filtrira kao HTTP onda ne moram investirati u neke dodatne mehanizme (e.g. blacklists) i povecavati administative overhead jer sve sto mi treba je vec tu. Onda mi nije bitno ako korisnici koriste anonymizer dokle god kroz njega ne pristupaju neprikladnom sadrzaju. Takodje ne bih prepustio inspekciju HTTPS-a IPS/IDS sistemu (nek se bavi DNS-om i ostalim stvarima) niti nekom out-of-band monitoringu jer prosto ne moze da pruzi rezultate koje postize pravi HTTP filter (ili vise njih). U citavoj prici imamo squid, apache, dansguardian dsniff/webmitm - sve su open source programi sposobni da urade od HTTP-a i HTTPS-a svasta :) Da li ima sanse da se pomocu njih vrsi efikasna inspekcija HTTPS-a?



Ne bi da ispadnem pametan, ali ...

filtriranje samo na bazi regex je "nista". "Nista" u smislu da ti samo ono najgore djubre stvarno nece proci, sto si i sam rekao. To sto "just works" je OK, jedino je pitanje da li je to sto radi uopste svrsishodno.

Da se malo nasalim: Ako se oslanjas samo na regex onda ti HTTPS filtering ni ne treba. :-)
Isto vazi i za anon. proxy-je... dozvoliti user-ima da koriste anon. proxy-je je velika rupa u sistemu u kojem zelis da nametnes neki policy.
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?09.08.2010. u 19:14 - pre 166 meseci
Shvatam i prihvatam koncept blacklist ili "nista" :)

Evo probacu ovu listu http://www.shallalist.de/helpers.html

No i dalje necu znati sta prolazi kroz HTTPS i da li neko ili nesto uploaduje gigabajte ili pak radi nesto drugo sto ne treba.
 
Odgovor na temu

igor.vitorac

Član broj: 144858
Poruke: 483



+13 Profil

icon Re: HTTPS proxy - open source rjesenje?09.08.2010. u 20:54 - pre 166 meseci
Citat:
Aleksandar Olujic: Shvatam i prihvatam koncept blacklist ili "nista" :)

Evo probacu ovu listu http://www.shallalist.de/helpers.html

No i dalje necu znati sta prolazi kroz HTTPS i da li neko ili nesto uploaduje gigabajte ili pak radi nesto drugo sto ne treba.



Salu na stranu, blackliste nisu univerzalan koncept.
Blackliste jesu donekle dobre, ali su njihove mane upravo same liste. Uh, koja misao...

Alatka bez koje bilo koja prica o internet policy usage-u ima malo smisla je reporting. Ako nemas nista trenutno, obavezno probaj SARG. http://sarg.sourceforge.net
Sa njime ces tacno znati sta, ko i koliko prenosi podataka!

Najbolja kombinacija kada se koriste liste je imati jednu (ili vise) public update-ova + jednu (ili vise) custom made. Custom made pravis na bazi SARG (ili nesto drugo) report-ova, tj. kada procenis da korisnici suvise koriste neki URL koji nije u kompanijske svrhe, a ne nalazi se u javnim black listama. Primer za to mogu biti online dnevne novine, naravno ako je policy firme takav da se to zabranjuje.
Public liste su dobre jer se azuriraju (skoro) na dnevnoj bazi sa anon. proxy-ijima.
Btw, anon. proxy se odmah uoci preko SARG reporta.

E da, setih se gde bi bio problem kod HTTPS inspection-a. To je situacija kada imas obostrano auth. preko PKI-a, tj. kada i client i server koriste PKI da bi jedno drugo autentikovali. Primer toga su sve veci broj web aplikacija koje koriste auth. i potpisivanje dokumenata preko ID card-a na kojem se nalazi privatni kljuc osobe koja koristi web aplikaciju. Korisnik mozda i moze da primi self-signed sertifikat generisan od HTTPS filtering servera, ali application server nece prihvatiti u drugom smeru, tj. auth. i signed dokument sa laznim selfsigned kljucem.
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?10.08.2010. u 10:04 - pre 166 meseci
Taj administrative overhead koji donosi odrzavanje blacklists (na nivou da imaju smisla) je upravo razlog za upotrebu regex skeniranja. Filtering je posao za masinu ili treba obezbijediti jos jedno radno mjesto za odrzavanje blacklists. Slazem se da nema koristi od polisa ako nema dobrog reportinga.

Mislim da se PKI (neopravdano) malo koristi i da pravljenje izuzetaka u HTTPS scan-u za te potrebe nije veliki posao. U svakom slucaju, dobro je to imati na umu.

Iako smatram da je ovako kompetentna diskusija vrlo korisna, nekako mi je krivo sto se ne javljaju ljudi koji su probali da primjene HTTPS proxy u svom okruzenju :(

Anyone?
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.verat.net.



+1365 Profil

icon Re: HTTPS proxy - open source rjesenje?10.08.2010. u 10:13 - pre 166 meseci
Mozda niko to nije radio :)
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
*.dynamic.xdsl-line.inode.at.



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?10.08.2010. u 12:45 - pre 166 meseci
Nemoguce :)

Ocigledno postoji trziste za takav proizvod inace se Cisco, Blue Coat, Stonegate i ostali ne bi bavili time. Cak i Microsoft koji obicno zaostaje 5-6 godina na polju mreznih tehnologija ima takav proizvod (u okviru Forefront TMG).

Osim toga mislim da se ne moze postici compliance sa odredjenim sigurnosnim standardima bez virenja u HTTPS.
 
Odgovor na temu

gandalf
Goran Raovic
senior network engineer
Belgrade

Član broj: 52
Poruke: 248
*.adsl-3.sezampro.yu.

Jabber: goran.raovic@gmail.com


+44 Profil

icon Re: HTTPS proxy - open source rjesenje?26.08.2010. u 21:18 - pre 166 meseci
Slozio bi se sa Aleksandrom vezano za ovu problematiku. Interesantno da nema kompletnog resenja razvijenog pod opensource-om, a da ima potrebe .. ima.
Ja sam zainteresovan da pomognem u projektu u smislu programerskog i iskustva u oblasti network security-a da se napravi komad software-a koji bi odradi prebacivanje sesije iz dsniff-a/sslstrip-a na squid. Dogovor oko razvoja mozemo da nastavimo na pp.
CCIE #22192 )
https://pulsarpoint.rs
 
Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
84.119.107.*



+15 Profil

icon Re: HTTPS proxy - open source rjesenje?28.09.2010. u 21:43 - pre 164 meseci
Poslije velikog nedostatka slobodnog vremena konacno sam na preporuku gandalfa probao sslBump - feature u aktuelnim verzijama squid-a http://wiki.squid-cache.org/Features/SslBump
koji omogucava da se desifrovani HTTPS preda na filtriranje kroz ICAP.

Squid 3.1.6-r1 (gentoo) dovoljno je napraviti self-signed cert (u /etc/squid):

openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 900 -in request.pem -signkey key.pem -out certificate.pem

dodati sljedece linije u squid.conf:

http_port 3128
http_port 3129 sslBump cert=/etc/squid/certificate.pem key=/etc/squid/key.pem
always_direct allow all
ssl_bump allow all

Podesiti browser da koristi HTTP proxy na port-u 3128 i HTTPS proxy na 3129

Na zalost ispostavilo se da je dansguardian samo ICAP klijent tako da dekriptovani saobracaj nije moguce propustiti kroz njega.

Naisao sam na c-icap http://c-icap.sourceforge.net/ koji bar omogucava da se dekriptovani HTTPS propusti kroz clam.

Ostavio sam i feature request na dansguardian stranici, a raspitacu se jos da li ima neko voljan da doda icap server funkcionalnost u dansguardiana.

Ako neko ima jos neku ideju kako se moze iskoristiti ovaj novi feature u squid-u - nek' se javi :)
 
Odgovor na temu

[es] :: Linux/UNIX serveri i servisi :: HTTPS proxy - open source rjesenje?

[ Pregleda: 3868 | Odgovora: 18 ] > FB > Twit

Postavi temu Odgovori

Srodne teme
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.