Privoxy über Stunnel ?

  • Unsere Website ist morgen von 07:00 bis 12:00 UTC aufgrund von Wartungsarbeiten nicht verfügbar. Wir entschuldigen uns für etwaige Unannehmlichkeiten.

D00mhammer

Mitglied
Mitglied seit
24 Feb 2008
Beiträge
329
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich bastel gerade etwas mit den ganzen Paketen von freetz rum. Bisher habe ich den Browserverkehr von der Arbeit immer über ein SSH-Tunnel über die Box geleitet. Nachdem ich die STunnel Anleitungen durchgearbeitet habe , kahm mir die Idee den Privoxy über SSL ins Internet freizugeben und dann darüber zuzugreifen. Ist sowas generell möglich oder ist Priovy hier das falsche Tool (ist es ein reiner HTTP proxy oder unterstützt er auch SOCKS?). Wie sähe dabei die konfig für STunnel aus?

Hier meine Konfig

Code:
[HTTPS Privoxy]
client = no
verify = 3
CAfile = /tmp/flash/.stunnel/certs.pem
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
accept = 8181
connect = 127.0.0.1:8118

Funktioniert eigentlich der Proxy mit Zertifikaten? ich habe es auch ohne probiert, bekomme aber bei allen Einstellungen nur den Fehler

Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.

Die Konfiguration des Proxys ohne STunnel funktioniert und STunnel für die anderen Dienste (zb. Push und Weboberfläche) auch.

Vielleicht bin ich auch auf dem falschen Dampfer, über Meinung und Hilfe wäre ich dankbar!

Grüße

Doom
 
hey,

testest du das von innen oder außen? wenn außen, denn an das portforwarding nicht vergessen.

Unterstützt denn dein Client diese Art von SSL-verschlüsslung? Wenn nein kannst ja auch mal auf dem client stunnel installieren und dann den tunnel über stunnel realisiren und dann halt mit deinem Browser auf localhost connecten.
 
Hi! Danke für Deine Antwort. Ich versuche momentan von intern bzw. SSH Tunnel.
Ich benutze Firefox. Die Zertifikat Verschlüsselung funktioniert zumindest auf das Webinterface. Ob es überhaupt üeber Proxys funktioniert weiß ich leider nicht. Dazu habe ich auch nicht viel bei Google heraufinden können. Bei den Browsereinstellungen gibt es ja zumindest die Einstellung SSL Proxy , allerdings wird da wohl nur die SSL Verbindung über den Proxy geleitet. Das klappt auch für Privoxy aber nicht über den SSL Tunnel.

Danke für den Tip mit dem client, ich werde es mal austesten :)
 
Damit du dich zum Stunnel Server verbinden kannst, muss der Client sich per SSL verbinden. D.h. du müsstest auch einen Stunnel auf der Client-Seite installieren, der sich dann zu dem Stunnel auf deiner Fritz!Box verbindet.
Wenn du bspw. in Firefox als Proxy Server IP und Port angibst, auf dem der Stunnel Server lauscht, funktioniert das damit logischerweise nicht. Weil ja dann der Client (Firefox) nach wie vor versucht sich unverschlüsselt mit dem Server zu unterhalten.


Generell kannst du übrigens folgendermassen testen, ob die Stunnel-Verbindung zum Server (deiner Fritz!Box) klappt, vorausgesetzt du hast OpenSSL auf deinem System:
Code:
openssl s_client -connect MEINE-IP:8181


Ansonsten ist deine bisherige Lösung mit SSH als SOCKS-Server (dynamischer Tunnel) der dir den Traffic verschlüsselt über deine Fritz!Box leitet meiner Meinung nach die beste und flexibelste.
 
Hmm dann scheint es wohl nicht so funktionieren, wie ich mir das vorgestellt habe... okay die Lösung mit SSH ist ja auch am besten, ich hatte nur an Szenarien gedacht, wo einem nur der Browser zur Verfügung steht.

Ich habe jetzt STunnel auf meinem Windows Rechner installiert und dann verschiedene Dienste die auf der Fritze laufen als Client eingestellt. Für die Anwendungen (Web Interface und SSH) bekam ich jedoch keine funktionierende Verbindung zur Fritzbox. Ich bekomme entweder die Meldung

Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket

oder Connection reseted by peer. Leider schaffe ich es nicht eine funktionierende Verbindung herzustellen.

Die Konfig auf dr Client Seite sah so aus

[SSH over SSL]
verify = 3
CAfile = /tmp/flash/.stunnel/certs.pem
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
accept = 22
connect = fritz.box:7222
sslVersion = TLSv1

entsprechend lauscht die Box auf 7222 SSL und verbindet das nach 127.0.0.1 auf den SSH Port.



Ziel ist es dieses Szenario zu erreichen.

KAnn gerne bei Bedarf noch weitere logs posten.
 
Du solltest Schritt für Schritt vorgehen, um herauszufinden woran es hängt.

1.) Stell sicher, dass Port 7222 auf deiner Fritz!Box auch wirklich erreichbar ist. Das kannst du einfach mit telnet oder dem OpenSSL Client (für SSL gesicherte Verbindungen) testen:
Code:
telnet fritz.box 7222
openssl s_client -connect fritz.box:7222
Erst wenn das einwandfrei klappt weitermachen.

2.) Stell zum Testen die Client-Authentifikation per Zertifikate ab und aktiviere sie erst zum Schluss, wenn alles andere funktioniert. Ein auskommentieren der "verify" und "CAfile" Zeilen auf der Server-Seite müsste dafür reichen.

3.) Teste die Verbindung mit Stunnel auf der Client-Seite im Client-Modus (client = yes). Hier darfst du Stunnel natürlich nicht im Server-Modus betreiben.
Zum Verständnis: im Client-Modus wird eine unverschlüsselte Verbindung von Stunnel entgegengenommen und dann verschlüsselt weitergeleitet. Im Server-Modus ist das umgekehrt, da wird eine SSL Verbindung entgegengenommen und diese dann unverschlüsselt weitergeleitet.

4.) Wenn du so weit gekommen bist und es nicht funktioniert, dann versuch den Verbosity-Level von Stunnel auf "debug" zu setzen und poste die Fehlermeldungen hier bzw. google danach ;)


Ergänzung: Unter Umständen ist der in freetz verfügbare HTTPtunnel für dich auch interessant. Der Ansatz hier ist zwar etwas anders, aber u.U. auch passend. Anstatt dass du wie beim Stunnel Ansatz deine SSH-Verbindung per SSL tunnelst, kann man mit httptunnel die SSH-Verbindung über HTTP ablaufen lassen.
Da SSH Traffic selbst schon verschlüsselt ist (und auch authentifiziert), ist das kein Sicherheitsproblem. Der Aufwand den du zum Einrichten brauchst, ist in etwa der selbe. Sprich: httptunnel auf Client und Server-Seite einrichten.

Vorteil an diesem Ansatz ist aber, dass du Verbindungen über einen Firmen-Proxy leiten kannst. Hier gibt's eine FAQ dazu.
 
Zuletzt bearbeitet:
ARGHS
mit openSSL bekam ich folgenden Fehler:

Loading 'screen' into random state - done
connect: Bad file descriptor
connect:errno=10061

Nachdem ich ein paar Änderungen gemacht habe und den Dienst neustarten wollte bekomme ich den Fehler (wenn ich über den Befehl stunnel in SSH starte)

2008.07.28 22:48:56 LOG3[2194:1024]: SSL_CTX_use_RSAPrivateKey_file: B080074: error:0B080074:lib(11):func(128):reason(116)
Selbst ein Neustart hilft nicht weiter, nur ein wiederaufspielen der freetz config?
Wo liegen die Logs für Stunnel ? Was ist das für ein Fehler (google findet nichts)?

¤dit: Telnet auf den Port 7222 sagt fehlgeschlagen. Mit dem HTTP Tunnel ist auch eine Idee jedoch sollte HTTP Packete lesbar sein und somit vom firmenproxy als unzulässige Packete identifiziert werden könnten, daher die idee das ganze in ein TLS tunnel zu packen...
 
Zuletzt bearbeitet:
Schau mal in der syslog unter der Weboberflsche von freetzt dort wirst du auch was über stunnel finden. Ich nutze selber stunnel und bei mir funktioniert es ohne Probleme ich leite zb. Port von 4220 auf Port 81 um das sollte mit die Funktion Privoxy auch gehen aber nicht beide auf 8181 umlenken.

Sonder versuch es doch mal so:

Code:
[HTTPS Privoxy]
client = no
verify = 3
CAfile = /tmp/flash/.stunnel/certs.pem
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
accept = 8181
connect = 3128
delay = yes
sslVersion = TLSv1

Die beiden letzten Zeilen kannste auch evtl. weg lassen.
 
Hi,

ich werde es gerne probieren, nur habe ich das Problem, dass sobald ich den dienst neustarten will, das Starten fehlschlägt.

in der /var/log/mod.log steht nur "Starting stunnel...done." (allerdings nur, wenn ich das backup aufspiele), sonst bekomm ich oben genannte Fehler.


Auf der Windows seite steht ja in der stunnel.conf

Code:
debug = 7
output = stunnel.log

wo wird bei der freetz Version protokolliert? es steht ja nicht in der configurationsdatei im web-frontend, wird es als startparameter übegeben ?.
 
ARGHS
mit openSSL bekam ich folgenden Fehler:
Dieser Fehler bedeutet, dass du diesen Port unter dieser Adresse nicht ansprechen kannst (oder dass du dich vertippt hast). Wenn telnet auch fehlschlägt, stimmt was grundsätzlich nicht bei dir.

Wieso versuchst du eigentlich 7222 wenn Stunnel bei dir auf 8181 läuft ? Wenn Privoxy bei dir auf 7222 läuft und du ihn da nicht ansprechen kannst, ist das ein Problem mit Privoxy und nicht mit Stunnel.

ich werde es gerne probieren, nur habe ich das Problem, dass sobald ich den dienst neustarten will, das Starten fehlschlägt.
Das bedeutet normalerweise, dass du in der Stunnel-Config was falsch eingetragen hast.

Stunnel logged standardgemäß auf der Fritz!Box ins syslog. Wenn du in Freetz das syslogd CGI mit ausgewählt hast, kannst du dort alle log Nachrichten sehen.
 
ich versuche 7222, weil ich dort eine STunnel auf den SSH dienst gleitet habe (und weil Du es in #6 gesagt hast :)). Werde es nachher mal auf dem anderen Port probieren.

ich habe die config geleert und dann versucht den Dienst neuzustarten, leider auch fehlgeschlagen.

zum syslog, ich habe natürlich den syslogd nicht mitausgewählt, mein erstes freetz image, sorry.

daher auch nur
Code:
logread -f
logread: can't find syslogd buffer: No such file or directory
bekommen.
ich habe jetzt mal syslogd -C gestartet und logread -f , aber leider kommt nichts.

Nachtrag: ich habe jetzt die log auf debug gesetzt und dann übernommen. daraufhin wurde der dienst neugestartet und es wurde folgendes geloggt (komischerweise startet der dienst normal)

Code:
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: RAND_status claims sufficient entropy for the PRNG
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: PRNG seeded successfully
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Configuration SSL options: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL options set: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL context initialized for service dyndns-update
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Configuration SSL options: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL options set: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Certificate: /tmp/flash/.stunnel/key.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Certificate loaded
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Key file: /tmp/flash/.stunnel/key.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Private key loaded
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Loaded verify certificates from /tmp/flash/.stunnel/certs.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Loaded /tmp/flash/.stunnel/certs.pem revocation lookup file
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL context initialized for service HTTPS Web-Interface
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Configuration SSL options: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL options set: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Certificate: /tmp/flash/.stunnel/key.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Certificate loaded
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Key file: /tmp/flash/.stunnel/key.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Private key loaded
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Loaded verify certificates from /tmp/flash/.stunnel/certs.pem
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Loaded /tmp/flash/.stunnel/certs.pem revocation lookup file
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL context initialized for service HTTPS Privoxy
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Configuration SSL options: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL options set: 0x00000FFF
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SSL context initialized for service Push Email
Jul 29 17:09:20 fritz daemon.notice stunnel: LOG5[2688:1024]: stunnel 4.24 on mipsel-unknown-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007
Jul 29 17:09:20 fritz daemon.notice stunnel: LOG5[2688:1024]: Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6
Jul 29 17:09:20 fritz daemon.info stunnel: LOG6[2688:1024]: file ulimit = 1024 (can be changed with 'ulimit -n')
Jul 29 17:09:20 fritz daemon.info stunnel: LOG6[2688:1024]: poll() used - no FD_SETSIZE limit for file descriptors
Jul 29 17:09:20 fritz daemon.notice stunnel: LOG5[2688:1024]: 500 clients allowed
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 4 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 5 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 6 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SO_REUSEADDR option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: TCP_NODELAY option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: dyndns-update bound to 127.0.0.1:9201
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 7 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SO_REUSEADDR option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: TCP_NODELAY option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: HTTPS Web-Interface bound to 0.0.0.0:7448
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 8 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SO_REUSEADDR option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: TCP_NODELAY option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: HTTPS Privoxy bound to 0.0.0.0:8181
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: FD 9 in non-blocking mode
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: SO_REUSEADDR option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: TCP_NODELAY option set on accept socket
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2688:1024]: Push Email bound to 0.0.0.0:25
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2690:1024]: Created pid file /var/run/stunnel.pid
Jul 29 17:09:20 fritz daemon.debug stunnel: LOG7[2690:1024]: Cleaning up the signal pipe


So nach erstem Test über bestehende SSH-Verbindung von außen bekomme ich

Code:
Jul 29 17:15:35 fritz daemon.debug stunnel: LOG7[2690:1024]: HTTPS Privoxy accepted FD=10 from 192.168.178.1:3649
Jul 29 17:15:35 fritz daemon.debug stunnel: LOG7[2747:1026]: HTTPS Privoxy started
Jul 29 17:15:35 fritz daemon.debug stunnel: LOG7[2747:1026]: FD 10 in non-blocking mode
Jul 29 17:15:35 fritz daemon.notice stunnel: LOG5[2747:1026]: HTTPS Privoxy accepted connection from 192.168.178.1:3649
Jul 29 17:15:35 fritz daemon.debug stunnel: LOG7[2747:1026]: SSL state (accept): before/accept initialization

werde das ganze mal nachher aus dem intranet testen. muss man denn hierfür den port auch in der ar7.cfg freigeben ?

¤dit Nr2.
Das ganze scheint jetzt auf einmal zu klappen! ich habe nichts geändertaber irgendwie läuft es.

Muss ich jetzt auf jedem Rechner auf dem ich das nutzen will stunnel installieren? da fahr ich ja mit puttyy portable besser :) ist es möglich,dass der firefox selbstständig eine SSL verbindung zum proxy herstellt und darüber dann den traffic laufen lässt?
 
Zuletzt bearbeitet:
So neuer Versuch:

ich versuche mit der config :

Code:
connect = xxx.selfip.org:80
protocol = connect
protocolHost = 10.0.2.1:8080
sslVersion = TLSv1

mittels STunnel eine Verbindung zu meiner auf port 443 lauschenden Box zu bekommen.

Leider wird die Verbindung zurückgesetzt.

Log beim Client

Code:
2008.07.30 10:39:22 LOG7[3256:5164]: SSH over SSL accepted FD=308 from 127.0.0.1:2342
2008.07.30 10:39:22 LOG7[3256:5164]: Creating a new thread
2008.07.30 10:39:22 LOG7[3256:5164]: New thread created
2008.07.30 10:39:22 LOG7[3256:644]: SSH over SSL started
2008.07.30 10:39:22 LOG7[3256:644]: FD 308 in non-blocking mode
2008.07.30 10:39:22 LOG5[3256:644]: SSH over SSL accepted connection from 127.0.0.1:2342
2008.07.30 10:39:22 LOG7[3256:644]: FD 364 in non-blocking mode
2008.07.30 10:39:22 LOG7[3256:644]: SSH over SSL connecting fritzbox.ip-adresse:443
2008.07.30 10:39:22 LOG7[3256:644]: connect_wait: waiting 10 seconds
2008.07.30 10:39:22 LOG7[3256:644]: connect_wait: connected
2008.07.30 10:39:22 LOG5[3256:644]: SSH over SSL connected remote server from 10.0.11.12:2343
2008.07.30 10:39:22 LOG7[3256:644]: Remote FD=364 initialized
2008.07.30 10:39:22 LOG5[3256:644]: Negotiations for connect (client side) started
2008.07.30 10:39:22 LOG7[3256:644]:  -> CONNECT 10.0.2.1:8080 HTTP/1.1
2008.07.30 10:39:23 LOG7[3256:644]:  -> Host: 10.0.2.1:8080
2008.07.30 10:39:23 LOG7[3256:644]:  -> 
2008.07.30 10:39:23 LOG3[3256:644]: readsocket (fdgetline): Connection reset by peer (WSAECONNRESET) (10054)
2008.07.30 10:39:23 LOG5[3256:644]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2008.07.30 10:39:23 LOG7[3256:644]: SSH over SSL finished (0 left)


beim server

Code:
Jul 30 10:39:23 fritz daemon.debug stunnel: LOG7[2225:1024]: SSH SSL accepted FD=11 from 62.154.209.4:2343
Jul 30 10:39:23 fritz daemon.debug stunnel: LOG7[2642:23554]: SSH SSL started
Jul 30 10:39:23 fritz daemon.debug stunnel: LOG7[2642:23554]: FD 11 in non-blocking mode
Jul 30 10:39:23 fritz daemon.notice stunnel: LOG5[2642:23554]: SSH SSL accepted connection from 62.154.209.4:2343
Jul 30 10:39:23 fritz daemon.debug stunnel: LOG7[2642:23554]: SSL state (accept): before/accept initialization
Jul 30 10:39:23 fritz daemon.err stunnel: LOG3[2642:23554]: SSL_accept: 1408F10B: error:1408F10B:lib(20):func(143):reason(267)
Jul 30 10:39:23 fritz daemon.notice stunnel: LOG5[2642:23554]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
Jul 30 10:39:23 fritz daemon.debug stunnel: LOG7[2642:23554]: SSH SSL finished (0 left)

ich lese hieraus 1408F10B: error:1408F10B:lib(20):func(143):reason(267) ist schuld. leider kann mir google da auch nicht helfen. ich habe es auch schon ohne zertifikate probiert, gleicher fehler.
öffne eine https seite über den firmenproxy ohne Stunnel-client auf meiner box (da wo ja der dropbear lauscht) kommt nach der SSL zertifikatsbestätigung folgende Seite angezeit

SSH-2.0-dropbear_0.51

liegt das problem an der stunnel config ?
 
ich lese hieraus 1408F10B: error:1408F10B:lib(20):func(143):reason(267) ist schuld. leider kann mir google da auch nicht helfen. ich habe es auch schon ohne zertifikate probiert, gleicher fehler.

Also Google liefert hier bei mir, dass man mit
Code:
openssl errstr 1408F10B
die Fehler-Beschreibung bekommt, nämlich
Code:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

öffne eine https seite über den firmenproxy ohne Stunnel-client auf meiner box (da wo ja der dropbear lauscht) kommt nach der SSL zertifikatsbestätigung folgende Seite angezeit

Ich verliere so langsam den Überblick, was bei dir jetzt wo läuft ...
Klar bekommst du die genannte Zeile angezeigt, wenn du eine Verbindung mit deinem Web-Browser zu deinem Dropbear aufbaust ! Aber was hat dein Dropbear mit der ganzen Geschichte zu tun :???


Ich habe gerade mal zum Test genau das bei mir eingerichtet, was du machen willst ... das hat mich 5 Minuten gekostet (länger als diesen Beitrag zu schreiben). Schreib dir doch einfach mal genau auf einem Zettel auf, was du machen willst und was wo lauscht und sich wohin verbindet, dann wird dir das vielleicht klarer.

Beispiel:
-CLIENT-
Firefox: (Proxy Einstellung 127.0.0.1:8119) <--> Stunnel: 127.0.0.1:8119
Stunnel: 127.0.0.1:8119 <--> Server: MeineIP:8119

-SERVER-
Stunnel: 0.0.0.0:8119 <--> PrivoxyIP:8118
Privoxy: PrivoxyIP:8118 <--> Internet


D.h. nach diesem Szenario konfigurierst du den Server (Fritz!Box) folgendermassen:

Privoxy:
lauscht auf "PrivoxyIP":8118 (also bspw: 192.168.178.1:8118 )

Stunnel:
Code:
[SSL Tunneled HTTP Proxy]
client = no
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
accept = 8119
connect = "PrivoxyIP":8118
sslVersion = TLSv1

Port-Freigabe:
Über die ar7.cfg den Port 8119 freigeben.


Und den Client:

Stunnel:
Code:
[SSL Tunneled HTTP Proxy]
accept = 127.0.0.1:8119
connect = "MeineExterneFritzBoxIP":8119
sslVersion = TLSv1

Firefox:
HTTP Proxy: 127.0.0.1:8119


Wenn jetzt was nicht funktioniert, testest du Schritt für Schritt alle Verbindungen.

1.) Erstmal im LAN deiner Fritz!Box "telnet PrivoxyIP:8118", wenn du Enter drückst kommt folgende Meldung:
Code:
HTTP/1.0 400 Invalid header received from client
Proxy-Agent: Privoxy 3.0.8
Content-Type: text/plain
Connection: close

Invalid header received from client.

Das heisst, Privoxy ist schonmal erreichbar.


2.) Verbindung zum Stunnel-Server deiner Fritz!Box testen (erstmal im LAN). "openssl s_client -tls1 -connect FritzBoxIP:8119"

Code:
Loading 'screen' into random state - done
CONNECTED(00000780)
...
---
SSL handshake has read 833 bytes and written 286 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
...
---

HTTP/1.0 400 Invalid header received from client
Proxy-Agent: Privoxy 3.0.8
Content-Type: text/plain
Connection: close

Invalid header received from client.
closed

Damit ist auch Privoxy über Stunnel erreichbar.
Und dann dasselbe nochmal mit deiner externen IP (bspw DynDNS) deiner Fritz!Box (um die Port-Freigabe zu testen).


3.) Wenn du soweit bist, stimmt alles auf der Server-Seite und du musst nur noch den Client testen. Das sollte nicht schwierig sein, den Proxy in Firefox/deinem Browser einzustellen ...
 
Hi DPR. Danke für Deine Geduld. ich schreib einfach nochmal was ich gerade tue und was ich erreichen möchte.

Szenario 1 : Privoxy über SSL-Tunnel aus der Firma

Firefox <-> Stunnel <-> Firmenproxy <-> fritzbox (ar7.cfg) <-> Stunnel <->Privoxy

(eigentliches Ziel war hier
Firefox <-> Firmenproxy <-> fritzbox (ar7.cfg) <-> Stunnel <->Privoxy , also ohne Stunnel auf der Client seite, Firefox scheint aber nicht den Webverkehr selbst tunneln zu können)

Firefox-Proxyeinstellung
Code:
127.0.0.1:8081

STunnel (client)
Code:
[SSL HTTP]
client = yes
accept = 8081
connect = fritzbox.selfip.org:443
protocol = connect
protocolHost = 10.0.2.1:8080
sslVersion = TLSv1
TIMEOUTclose = 0

ar7.cfg
Code:
"tcp 0.0.0.0:443 0.0.0.0:8022 0 #HTTPS Tunnel"

STunnel Server
Code:
[HTTPS Privoxy]
client = no
verify = 0
CAfile = /tmp/flash/.stunnel/certs.pem
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
sslVersion = TLSv1
accept = 8022
connect = 127.0.0.1:8118


Code:
Einstellungen
Der Privoxy Server ist gebunden an

IP Adresse: 0.0.0.0 Port: 8118


Ich bekomme

1. Im Firefox
Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Netzwerkverbindung wurde während des Verbindungsaufbaus unterbrochen. Bitte versuchen Sie es nochmals.


2. Im STunnel Client

2008.07.30 14:14:31 LOG7[5096:3364]: SSL HTTP accepted FD=316 from 127.0.0.1:1445
2008.07.30 14:14:31 LOG7[5096:3364]: Creating a new thread
2008.07.30 14:14:31 LOG7[5096:3364]: New thread created
2008.07.30 14:14:31 LOG7[5096:4484]: SSL HTTP started
2008.07.30 14:14:31 LOG7[5096:4484]: FD 316 in non-blocking mode
2008.07.30 14:14:31 LOG5[5096:4484]: SSL HTTP accepted connection from 127.0.0.1:1445
2008.07.30 14:14:31 LOG7[5096:4484]: FD 336 in non-blocking mode
2008.07.30 14:14:31 LOG7[5096:4484]: SSL HTTP connecting fritz.box.ip:443
2008.07.30 14:14:31 LOG7[5096:4484]: connect_wait: waiting 10 seconds
2008.07.30 14:14:31 LOG7[5096:4484]: connect_wait: connected
2008.07.30 14:14:31 LOG5[5096:4484]: SSL HTTP connected remote server from 10.0.1.1:1446
2008.07.30 14:14:31 LOG7[5096:4484]: Remote FD=336 initialized
2008.07.30 14:14:31 LOG5[5096:4484]: Negotiations for connect (client side) started
2008.07.30 14:14:31 LOG7[5096:4484]: -> CONNECT 10.0.2.1:8080 HTTP/1.1
2008.07.30 14:14:31 LOG7[5096:4484]: -> Host: 10.0.2.1:8080
2008.07.30 14:14:31 LOG7[5096:4484]: ->
2008.07.30 14:14:31 LOG3[5096:4484]: readsocket (fdgetline): Connection reset by peer (WSAECONNRESET) (10054)
2008.07.30 14:14:31 LOG5[5096:4484]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2008.07.30 14:14:31 LOG7[5096:4484]: SSL HTTP finished (0 left)


3. Server

Jul 30 14:24:04 fritz daemon.debug stunnel: LOG7[2190:1024]: HTTPS Privoxy accepted FD=10 from 62.154.152.8:1535
Jul 30 14:24:04 fritz daemon.debug stunnel: LOG7[2414:30722]: HTTPS Privoxy started
Jul 30 14:24:04 fritz daemon.debug stunnel: LOG7[2414:30722]: FD 10 in non-blocking mode
Jul 30 14:24:04 fritz daemon.notice stunnel: LOG5[2414:30722]: HTTPS Privoxy accepted connection from 62.154.152.8:1535
Jul 30 14:24:04 fritz daemon.debug stunnel: LOG7[2414:30722]: SSL state (accept): before/accept initialization
Jul 30 14:24:04 fritz daemon.err stunnel: LOG3[2414:30722]: SSL_accept: 1408F10B: error:1408F10B:lib(20):func(143):reason(267)
Jul 30 14:24:04 fritz daemon.notice stunnel: LOG5[2414:30722]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
Jul 30 14:24:04 fritz daemon.debug stunnel: LOG7[2414:30722]: HTTPS Privoxy finished (0 left)


Im LAN getestet und funktioniert mit und ohne Zertifikate. Ports sind auch freigeschaltet, da ich vorher 443 auf den dropbear umgebogen habe und es hat funktioniert. Zum testen habe ich im Firefox über den firmenproxy https://fritzbox.selfip.org aufgerufen. dort wird nach meinem Zertifikat gefragt und danach eine leere Seite gezeigt. (obwohl verify = 0)



Szenario 2: SSH über SSL-Tunnel aus der Firma


Putty <-> Stunnel <-> Firmenproxy <-> fritzbox (ar7.cfg) <-> Stunnel <->Dropbear

-- wird später behandelt, wenn Nr.1 läuft
 
Hi DPR. Danke für Deine Geduld.
Kein Problem :)

Firefox <-> Stunnel <-> Firmenproxy <-> fritzbox (ar7.cfg) <-> Stunnel <->Privoxy
Der "Firmenproxy" dürfte das Problem sein. Musst du über den Proxy raus ? Ich habe es nämlich noch nicht geschafft, Stunnel dazu zu bewegen einen Proxy (egal ob HTTP oder SOCKS) zu verwenden ... noch nichtmal mit FreeCap hat das geklappt. Vielleicht hat das netzwerktechnisch offensichtliche Gründe, die mir aber zumindest auf die schnelle nicht einfallen ...

Die beiden Stunnel Config-Einträge "protocol" und "protocolHost" sind glaube ich nicht für Proxy-Einstellungen da. Zumindest erschliesst sich das für mich nicht aus der Stunnel Hilfe.
Ich habe keine Ahnung was diese Einträge machen, aber bei mir führen diese Einträge zu keinerlei Traffic zu der angegebenen IP (mit Wireshark überprüft). Und in den Quelltext zu schaun bin ich jetzt zu faul ...

Ich kann dir deswegen leider nicht weiterhelfen. Wenn du herausfindest, wie man Stunnel dazu bewegt seine Verbindungen über einen Proxy laufen zu lassen, darfst du das natürlich gerne hier posten.

Ohne Firmenproxy funktioniert es definitiv !
Code:
Firefox <-> Stunnel <-> fritzbox (ar7.cfg) <-> Stunnel <->Privoxy
 
arghs , da liegt wohl das Problem. ich habe es mir auch gedacht. naja zumindest ist keiner lei traffic bei mir nicht ganz richtig, weil ich eine anfrage an den server schicke und er auch antwortet. zumindest der kontakt ist da , auch wenn dann irgendwie die verbindung abgebrochen wird.

Ich habe das ganze mal jetzt versucht mit dem SSH-Szenario über den SSL -Tunnel. Da kommt folgendes raus :

komischerweise funktioniert das ganze, wenn ich auf SSL verzichte, also der Proxy leitet meine Anfragen zum SSH dienst auf 443.

Client-Seite
Code:
2008.07.30 17:49:42 LOG5[2668:5620]: Negotiations for connect (client side) started
2008.07.30 17:49:42 LOG7[2668:5620]:  -> CONNECT 10.0.2.1:8080 HTTP/1.1
2008.07.30 17:49:42 LOG7[2668:5620]:  -> Host: 10.0.2.1:8080
2008.07.30 17:49:42 LOG7[2668:5620]:  -> 
2008.07.30 17:49:42 LOG7[2668:5620]:  <- SSH-2.0-dropbear_0.51
2008.07.30 17:49:42 LOG3[2668:5620]: CONNECT request rejected

Server-Seite
Code:
Jul 30 17:49:42 fritz authpriv.info dropbear[1815]: Child connection from 62.154.209.4:4414
Jul 30 17:50:42 fritz authpriv.info dropbear[1815]: exit before auth: Timeout before auth

Die ganze Info über den Proxy habe ich von der Mailingliste
http://stunnel.mirt.net/pipermail/stunnel-announce/2005-November/000017.html
scheint direkt vom Autor zu sein.

Über google noch das hier http://web21c.bt.com/forums/40/topics/1207 .

Ursprünglich bin ich darüber gestolpert: http://shsc.info/SSHThroughHTTPProxy - leider seit zwei Tagen down.

¤dit: ich bin mir nicht sicher wie man das lesen soll, wo wird der proxy eingetragen ? bei connect oder bei protocolHost ?


Ich bekomme momentan eine Verbindung, ich weiß aber nicht ob durch den proxy. folgender Gehler tritt auf der server-seite auf
Code:
Jul 30 18:27:12 fritz authpriv.info dropbear[2621]: Child connection from 127.0.0.1:2746
 
Zuletzt bearbeitet:
Ok, ich konnte es nicht lassen und hab doch im Quelltext nachgesehen ... jetzt verstehe ich auch wie die "ProtocolHost" Optionen funktionieren.

Du musst folgende Client-Config verwenden, dann sollte es funktionieren - sofern euer Firmen-Proxy das CONNECT Kommando versteht:

Code:
[SSL tunnelled HTTP Proxy]
client = yes
accept = 8081
connect = 10.0.2.1:8080
protocol = connect
protocolHost = fritzbox.selfip.org:443
sslVersion = TLSv1

Edit:
¤dit: ich bin mir nicht sicher wie man das lesen soll, wo wird der proxy eingetragen ? bei connect oder bei protocolHost ?
Bei "connect" trägst du den HTTP Proxy ein, bei "protocolHost" den Server zu dem du dich über den Proxy verbinden willst (also deine Fritz!Box).
 
Zuletzt bearbeitet:
ja genau ! so habe ich es gestern auch nochmal probiert und bekam den fehler von dropbear mit der child connection, also SSH klappt irgendwie daher nicht. ich habe in putty folgendes angegeben:

host : fritz.box
Port :22
Proxy: 127.0.0.1
Port 8081
Proxy Type: HTTP

Leider kommt in putty selbst garnichts (schwarzer bildschirm) und die oben gennanten fehler erscheinen.

Privoxy funktioniert aber, dazu habe ich 127.0.0.1:8081 in Firefox angegeben und es klappt.

Also : Super erster schritt funktioniert! Zweiter Schritt scheitert wohl momentan an dropbear ?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.