* Heiko Degenhardt wrote on Tue, Feb 01, 2000 at 06:50 +0100:

...

Hat jemand eine bessere Idee? Eine bessere vielleicht nicht, aber schau Dir doch mal TIS FWTK (www.fwtk.org) an. Dabei insbesondere http://www.fwtk.org/fwtk/patches/patches.html#3.9.

(Scheint ne sehr interessante Seite zu sein!!) Meinst Du: 3.11: Proxy for ssh to the firewall The ssh-gw proxy allows you to have encrypted ssh connections from a ssh client to the firewall. From your firewall into your internal network the traffic is not encrypted. internal not encrypted. Das ist mein Problem. Ich hab's jetzt in ner Bastelumgebung anders am Laufen. Scheint mir keine schlechte Idee, bitte Feedback! Ich hab squid ein bißchen gehackt. Wenn proxy_auth gefordert wird, und kein Proxy-Auth: im HTTP Header steht, wird dem Browser PROXY_AUTHENTICATION_NEEDED oder sowas gesendet, der macht sein Fenster auf, und schickt den Mist im Klartext (base64, siehe RFC). Authtype Digest macht MD5, wird aber nur von IE5 unterstützt, reicht nicht. Jetzt macht der patch folgendes: Wenn proxy_auth, aber kein Name im Header, wird die IP Addresse als "user" name gesetzt. Daraufhin wird dann das authenticate_program gestartet, was die IP Addresse nicht kennt, also "ERR" liefert. Nun sendet er nicht "Authentication needed" sondern "HTTP_DENIED". Kein Browserfenster :). Das Doc, das Squid damit sendet, enthält ein FORM mit ACTION="https://...", also SSL. Die requested URL steht in einem Hiddenfeld. Der User gibt Namen, PW ein, das CGI Script wird über SSL gestartet (verschlüsselt also). Das CGI prüft das Passwort (über einen sicheren Kanal, das Script kann ja machen, was es will, in unserem Falle im Prinzip das, was das SMB_AUTH modul von Squid macht, nur ohne PDC etc, also schnell :)), wenns richtig ist, wird den authenticate_program die IP über ne FIFO (lokal im Filesystem, sicher genug) gesendet. Das CGI antwortet mit einem Refresh Header auf die im Hiddenfeld gespeicherte URL, das der Browser in 3 Sekunden holt. Das CGI Script generiert Das authenticate program (welches über select(2) loopt, klar) holt sich die IP, packt sie mit einem Timestamp in einen Hash. Dann sind die 3 Sek. um. Der Browser fragt Squid, der setzt (durch den Patch) wieder die IP als Namen ein, fragt das authenticate program. Dieses hat inzwischen die IP im hash (timestamp neu genug), und gibt "OK", erneuert timestamp. Und: ES FUNKTIONIERT! :) :) Hab ich was vergessen? Den Patch werde ich vermutlich auch mal in squid-dev oder sowas posten, vielleicht kann man da einen hook im Stil von authenticate program draus machen, ist jedenfalls flexibler also so. Und: Sicher! Mit der Bitte um Kommentare! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

* Heiko Degenhardt wrote on Tue, Feb 01, 2000 at 19:54 +0100:

Hallo Steffen!

Steffen Dettmer wrote:

...

Nee, ich meinte eigentlich 3.9: Proxies for NNTP, POP3, Squid, and other services ... (em-gw)

Ok, ich hab das unklar formuliert: es geht um HTTP/HTTPS/FTP Proxy-Authentifikation, also mod_proxy (Apache) oder eben Squid (und was es da noch alles geben mag). Jedenfalls scheint die im letzten Posting beschriebene Idee gut zu funktionieren! Für die Bastelösung waren nur ein paar Bytes Squid-Patch und zwei Perl-Scripte notwendig. Das ging bis jetzt ganz zügig. Sieht sehr gut aus, vermutlich praxistauglich - aber Probleme kommen ja generell unerwartet - im Test laufen nur vier Clients, das ist noch nicht so sehr aussagekräftig ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com