# [OT] "Tunneln" von http über https?

## slick

Ich weiß, der Thread-Titel ist komisch, aber ich weiß nicht wie es besser beschreiben soll. 

Also ich sitze desöfteren in einem unsicherem LAN möchte aber auch hier auf bestimmte Seiten zugreifen. Dem LAN traue ich wirklich null. Habe nur 80  und 443 nach draußen über einen Proxy offen. SSH-over-Proxy scheidet aus. Also würde ich gern auf einem Root-Server "draußen" eine Art Proxy aufsetzen, welcher mir die angeforderten Seiten über HTTPS ausliefert. Leider kann ich jedoch keinen "normalen" Proxy im Browser benutzen, da dort bereits der Proxy steht den ich überhaupt fürs Internet benötige. Also suche ich ein Script welches auf einem Root-Server installiert wird und die Seiten onthefly vom orginalen Webserver holt, die Links in der Seite auf sich selbst mit entsprechenden Parametern umbiegt und die Seite dann über Apache mit SSL ausliefert. Also soll so etwa funktionieren wie die Übersetzungsservices einiger Suchdienste. Verkompliziert wird es jedoch dadurch das es nicht nur GETs sein sollten, sondern auch POSTs möglich sein müssten.

Schematisch: Browser <--HTTPS--> Rootserver <--HTTP--> Orginalseite

Jemand einen Tipp oder eine Idee wie ich das hinbekommen könnte? Alternative Ideen gern willkommen.

----------

## Anarcho

Genau sowas möchte ich auch schon länger haben, aber ich habe noch nicht danach gesucht. 

Zur not müsste man sowas vielleicht mal schreiben. 

Aber wenns sowas schon gibt, dann mal her damit!

----------

## slick

Also ich sage mal für GETs auf normale reine HTML-Seiten sowas zu schreiben wäre sicher nicht so schwerr. Schwerr wirds  mit Cookies und POSTs.

----------

## Anarcho

Ich hab was gefunden:

http://sourceforge.net/projects/php-proxy/

Leider habe ich wohl nicht genug erlaubt in meinen PHP Einstellungen und man muss die Seite fest codieren. Daher muss man das ganze sowieso noch modifizieren. Dürfte aber leicht sein.

Anhand der Release-daten kann man sehen das es seit 3 Jahren nicht mehr weiterentwickelt wird.

Vielleicht versuch ich das gleich mal.

Aber keine Ahnung ob das POST kann.

----------

## Marlo

 *slick wrote:*   

> 
> 
> ...Dem LAN traue ich wirklich null. Habe nur 80  und 443 nach draußen...
> 
> 

 

Das wird oft und gerne von Sysadmins behauptet, die für viele tausend ros eine externe Firewall eingekauft haben und nun ihrem Chef sagen müssen, warum es sich gelohnt hat, das viele Geld zum Fenster ... usw. 

 *slick wrote:*   

> 
> 
> ...Alternative Ideen gern willkommen.

 

Als erstes würde ich versuchen mit jap zu tunneln. Nicht besonders bizarr, ehen schlicht, aber von innen kann man damit durch (fast) jede kommerzielle Feuerschutzwand durchdringen.

Wie sachte noch mien Omma. "Versuch macht kluch". Wenn nicht, haben wir es mit einem Profi zu tun und müssen auch an nessus im entsprechendem niceness denken.

Gruß

Ma

----------

## De Beukelaer

http://www.deruwe.de/browser.html

"PHP-Browser ist eine in PHP realisierte Klasse die einen Web-Browser simuliert. (Genau genommen sind es zwei Klassen.) Damit ist es einfach möglich HEAD-, GET- und POST-Requests auszuführen. Bei POST-Requests werden auch Fileuploads unterstützt."

Das könnte ein Ansatz sein.

----------

## Fauli

 *slick wrote:*   

> SSH-over-Proxy scheidet aus.

 

Was spricht dagegen, über einen SSH-Tunnel auf einen HTTP(S)-Proxy (z. B. Squid) auf dem externen Server zuzugreifen?

----------

## mkr

Schau Dir mal CGIProxy an, der ist schnell eingerichtet und kann auf Wunsch auch gleich Werbung und Cookies filtern:

http://www.jmarshall.com/tools/cgiproxy/

----------

## think4urs11

Ich kann mich Fauli nur anschließen.

Mittels SSH-Tunnel durch den dortigen Proxy durch auf eine externe Maschine die unter deiner Kontrolle steht; dort dann z.B. einen transparenten Squid laufen lassen und es sollte funktionieren.

Aus der Sicht eines Firewall/Proxyadmins sind solche Tunnel zwar nicht gerade gerne gesehen nur leider auch praktisch nicht zu verhindern (außer vielleicht durch Einsatz von Whitelists, was aber den administrativen Aufwand explodieren läßt).

@Marlboro:

jaaa man könnte auch noch auf Browserkennung und dergleichen auf dem Proxy filtern - trotzdem Kinderkram.

Von innen nach außen durch eine Firewall geht (fast) immer irgendwie mit genügend Kreativität  :Rolling Eyes: 

----------

## Marlo

 *Think4UrS11 wrote:*   

> 
> 
> @Marlboro:
> 
> jaaa man könnte auch noch auf Browserkennung und dergleichen auf dem Proxy filtern - trotzdem Kinderkram.
> ...

 

Klar bin ich kein Experte, gleichwohl geht es bei jap nicht um "...Browserkennung und dergleichen...", sonden um ein tunneln, welches auch über jeden xbeliebigen Port geht, wie 80 oder 443; es muß ja nicht 4001 oder 3128 sein. Und je stärker der getunnelte Port frequentiert ist, desdo mehr gehen die getunnelten Daten im "Rauschen" unter.  Um nicht mißverstanden zu werden, ich halte jap keinesweg für eine Lösung, eher für ein nonbizzares Experiment, für das von slick dargestellt Problem.

Ma

----------

## psyqil

 *De Beukelaer wrote:*   

> http://www.deruwe.de/browser.html

  :Laughing:  Prust! Dat is ja cool! Hallo Uwe, übrigens! Long time no see...  :Very Happy: 

----------

## slick

 *De Beukelaer wrote:*   

> http://www.deruwe.de/browser.html
> 
> "PHP-Browser ist eine in PHP realisierte Klasse die einen Web-Browser simuliert. (Genau genommen sind es zwei Klassen.) Damit ist es einfach möglich HEAD-, GET- und POST-Requests auszuführen. Bei POST-Requests werden auch Fileuploads unterstützt."
> 
> Das könnte ein Ansatz sein.

 

 *psyqil wrote:*   

>  *De Beukelaer wrote:*   http://www.deruwe.de/browser.html  Prust! Dat is ja cool! Hallo Uwe, übrigens! Long time no see... 

 

 :Laughing:  YMMD! *KaffeevomBildschirmwisch* </insider>

 *Quote:*   

> Was spricht dagegen, über einen SSH-Tunnel auf einen HTTP(S)-Proxy (z. B. Squid) auf dem externen Server zuzugreifen?

 

Weils ein blöder Win-Client ist, auf dem nix laufen darf.   :Crying or Very sad: 

----------

## think4urs11

 *slick wrote:*   

> Weils ein blöder Win-Client ist, auf dem nix laufen darf.  

 

Auch kein Putty?

Oder suchst du sowas in der Art?

CGIProxy

----------

## Anarcho

Thanx at mkr und Think4UrS11:

CGIProxy scheint zumindest das zu sein was ich suche. Das ganze noch auf nen SSL Apache mit Username/Passwort und schon kann kein Admin mehr feststellen auf welchen Sites man unterwegs ist...ausser per Videoüberwachung.

----------

## slick

 *Anarcho wrote:*   

> Thanx at mkr und Think4UrS11:
> 
> CGIProxy scheint zumindest das zu sein was ich suche. Das ganze noch auf nen SSL Apache mit Username/Passwort und schon kann kein Admin mehr feststellen auf welchen Sites man unterwegs ist...ausser per Videoüberwachung.

 

Dito! Werds auch mal testen... sieht ganz gut aus.

----------

## slick

Also habs ausprobiert... ist genau das was ich suchte. Hat nur noch einen kleinen kosmetischen Fehler... könnte man die URL nicht base64 encodieren... sieht in den Logs besser aus.  :Wink:  Aber von Perl ich habe leider null Plan  :Sad: 

----------

## mkr

 *slick wrote:*   

> Hat nur noch einen kleinen kosmetischen Fehler... könnte man die URL nicht base64 encodieren... sieht in den Logs besser aus.  Aber von Perl ich habe leider null Plan 

 

Ist die URL bei SSL nicht auch verschlüsselt? Der Client baut doch zuerst eine verschlüsselte Verbindung mit dem Server auf, über die er dann den GET-Request absetzt. Bin mir aber nicht ganz sicher, bitte korrigieren, falls es nicht stimmt!

----------

## slick

Nein, die URL ist dann noch in den Logs vom Proxy (für den Internetzugang). Und falls nach typischen URL-Teilen gesucht wird nützt mirs evt. auch nix.

Die aufgerufene URL ist im Format https://server/nph-proxy.cgi/$irgendeinwert/http/example.com/pfad/file.html

----------

## think4urs11

Naja da kommst du aber langsam in den bedenklichen Bereich.

Eine Firma hat normalerweise ja (mehr oder minder) (nachvollziehbare) Gründe wenn/ob/warum bestimmte URI zugreifbar sein dürfen oder nicht.

Das eine ist für Vertraulichkeit der Daten zu sorgen - das hast du mit CGIProxy wenns auf einem https-Server läuft. Ist zwar auch nicht die ganz feine Art aber zumindest ggf. tolerierbar -das andere ist aber schon fast Verschleierung.

Du versuchst faktisch zu verhindern das der legitime Anspruch des Anschlußinhabers zu kontrollieren wer/wann/wohin Verbindungen aufbaut auch praktisch durchgesetzt werden kann.

Ich will dir ja nichts unterstellen aber mich als Admin hättest du schnell am Hals wenn mir sowas auffällt - wenns suspekt wird erfolgt im Zweifelsfall eine Abschaltung des Switchports.

Wenn wir hier von einem 'unsafe' privat LAN reden sieht es natürlich etwas anders aus...

Und ... wieso nur Base64 und nicht gleich AES im Punnycode?   :Wink: 

----------

## slick

 *Think4UrS11 wrote:*   

> Naja da kommst du aber langsam in den bedenklichen Bereich.
> 
> Eine Firma hat normalerweise ja (mehr oder minder) (nachvollziehbare) Gründe wenn/ob/warum bestimmte URI zugreifbar sein dürfen oder nicht.
> 
> Das eine ist für Vertraulichkeit der Daten zu sorgen - das hast du mit CGIProxy wenns auf einem https-Server läuft. Ist zwar auch nicht die ganz feine Art aber zumindest ggf. tolerierbar -das andere ist aber schon fast Verschleierung.

 

In kommerziellen Umgebungen gebe ich Dir vollkommen Recht. Das base64 bei ernsthaftem Interesse keine Hürde ist, ist mir auch vollkommen bewußt. Ich kann mit der jetzigen Lösung auch problemlos leben. Wollte aber mal vollständigkeitshalber gefragt haben...

----------

## think4urs11

 *slick wrote:*   

> In kommerziellen Umgebungen gebe ich Dir vollkommen Recht. Das base64 bei ernsthaftem Interesse keine Hürde ist, ist mir auch vollkommen bewußt. Ich kann mit der jetzigen Lösung auch problemlos leben. Wollte aber mal vollständigkeitshalber gefragt haben...

 

Ich weiß ja das ich paranoid bin, das war hier Einstellungsvoraussetzung   :Cool: 

Das zusätzliche Verpacken als Base64 sollte aber wirklich kein allzu großes Problem darstellen. Auf die Schnelle und als Perl-Laie würde ich sagen MIME::Base64::decode(URL) 'irgendwie' in CGI-Proxy einbauen und die ein- wie ausgehenden URLs zuerst dort durchscheuchen und das Ergebnis an die normalen weiteren Prozeduren weiterleiten.

Featurevorschlag für Upstream? Es sieht so aus als wäre irgendetwas in der Richtung sogar mindestens angedacht

 *Quote:*   

> sub proxy_encode {}, proxy_decode {}
> 
> (Requires minor programming.) You can customize the encoding of destination URLs by modifying these routines. The default is a simple unobscured URL, but sample obscuring code is included in the comments. Note: If you're not removing scripts, then you also need to change _proxy_jslib_proxy_encode() and _proxy_jslib_proxy_decode()-- see the comments.

 

----------

## slick

Danke... was mir noch aufgefallen ist, vielleicht kann mir das jemand erklären, was hat es mit dem "nph" auf sich? Also das Script muß nph-*.cgi heißen um zu funktioneren. Kann man da stattdessen was in die .htaccess schreiben um das beliebig umzubenennen? Würde mir das gern als index.cgi in ein Verzeichnis legen. (DirectoryIndex ist mir schon bekannt, es geht mir ums Prinzip.)

----------

## think4urs11

Hmm, ich muß sagen man lernt viel interessantes durchs Beantworten deiner Fragen  :Smile: 

NPH: Non-Parsed Header

 *Quote:*   

> The simple fact that the filename begins with nph- means that a CGI's output is sent stright to the clients browser without the server adding any headers of it's own.

 

Referenz: http://www.programatica.com/cgi5.html

----------

## mkr

 *slick wrote:*   

> Kann man da stattdessen was in die .htaccess schreiben um das beliebig umzubenennen? Würde mir das gern als index.cgi in ein Verzeichnis legen. (DirectoryIndex ist mir schon bekannt, es geht mir ums Prinzip.)

 

Soweit ich weiss kann man am Apache nichts konfigurieren bezüglich NPH. Die NPH-Scripts müssen mit "nph-" beginnen.

CGIProxy lässt sich aber umstellen, dass er auch ohne NPH auskommt. Die Option heisst "$NOT_RUNNING_AS_NPH ". Einfach von 0 auf 1 stellen, dann kannst Du das Script beliebig benennen. Es kann jedoch Probleme geben. Entweder einfach ausprobieren oder die Warnung im Sourcecode lesen.   :Smile: 

----------

## think4urs11

und damit könnts evtl. gehen...

http://apache.active-venture.com/rewriteguide3.html

----------

## Anarcho

Oder ganz simple ne index.php erstellen:

```
<%php

header('location:nph-cgiproxy.cgi');

%>
```

Über das Problem mit dem nph im Dateinamen habe ich auch längere Zeit gerätselt...

Aber das mit dem proxy_encode und _decode werde ich mir mal ansehen.

----------

## slick

Ich habe es mir mal wie folgt abgeändert, über den Sinn läßt sich sicher streiten ...

```
sub proxy_encode {

    my($URL)= @_ ;

   use MIME::Base64;

   $URL = encode_base64($URL,'');

   $URL=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;   

   # Encode ?# so they don't prematurely end PATH_INFO.  Don't remove this.

    $URL=~ s/=/=3d/g ; $URL=~ s/\?/=3f/g ; $URL=~ s/#/=23/g ; $URL=~ s/%/=25/g ;

    1 while $URL=~ s#//#/=2f#g ;    # work around Apache PATH_INFO bug

    return $URL ;

}
```

```
sub proxy_decode {

    my($enc_URL)= @_ ;

   # First, un-encode =xx chars.

    $enc_URL=~ s/=(..)/chr(hex($1))/ge ;

   use MIME::Base64;

   $enc_URL=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;

   $enc_URL = decode_base64($enc_URL);

    return $enc_URL ;

}
```

```
sub cookie_encode {

    my($cookie)= @_ ;

   use MIME::Base64;

   $cookie = encode_base64($cookie,'');

   $cookie=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;   

    return $cookie ;

}
```

```
sub cookie_decode {

    my($enc_cookie)= @_ ;

   use MIME::Base64;

   $enc_cookie=~ tr/a-zA-Z/n-za-mN-ZA-M/ ;  

   $enc_cookie = decode_base64($enc_cookie);

    return $enc_cookie ;

}
```

Den Javascript-Code habe ich versucht entsprechend anzupassen. Dafür habe ich die Funktionen  _proxy_jslib_encode64 und _proxy_jslib_decode64 eingebaut und die anderen entsprechend angepaßt. Bin mir aber bei dem Javascript-Code nicht sicher ob er korrekt ist und auch so funktioniert wie er soll. Brauche ich eigentlich nicht und wollte es daher auch nicht weiter testen.

```
$ENCODE_DECODE_BLOCK_IN_JS= <<'EOB' ;

function _proxy_jslib_encode64(decStr)

{

 var bits;

 var dual;

 var i = 0;

 var encOut = '';

var base64s = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';

while(decStr.length >= i + 3)

 {

  bits = (decStr.charCodeAt(i++) & 0xff) <<16 |

         (decStr.charCodeAt(i++) & 0xff) <<8  |

          decStr.charCodeAt(i++) & 0xff;

  encOut += base64s.charAt((bits & 0x00fc0000) >>18) +

            base64s.charAt((bits & 0x0003f000) >>12) +

            base64s.charAt((bits & 0x00000fc0) >> 6) +

            base64s.charAt((bits & 0x0000003f));

 }

 if(decStr.length -i > 0 && decStr.length -i < 3)

 {

  dual = Boolean(decStr.length -i -1);

  bits = ((decStr.charCodeAt(i++) & 0xff) <<16) |

         (dual ? (decStr.charCodeAt(i) & 0xff) <<8 : 0);

  encOut += base64s.charAt((bits & 0x00fc0000) >>18) +

            base64s.charAt((bits & 0x0003f000) >>12) +

            (dual ? base64s.charAt((bits & 0x00000fc0)

            >>6) : '=') +

            '=';

 }

 return(encOut);

}

function _proxy_jslib_decode64(encStr)

{

 var bits;

 var decOut = '';

 var i = 0;

 var base64s = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';

for(; i<encStr.length; i += 4)

 {

  bits = (base64s.indexOf(encStr.charAt(i))    & 0xff) <<18 |

         (base64s.indexOf(encStr.charAt(i +1)) & 0xff) <<12 |

         (base64s.indexOf(encStr.charAt(i +2)) & 0xff) << 6 |

          base64s.indexOf(encStr.charAt(i +3)) & 0xff;

  decOut += String.fromCharCode((bits & 0xff0000) >>16,

(bits & 0xff00) >>8, bits & 0xff);

 }

 if(encStr.charCodeAt(i -2) == 61)

 {

  return(decOut.substring(0, decOut.length -2));

 }

 else if(encStr.charCodeAt(i -1) == 61)

 {

  return(decOut.substring(0, decOut.length -1));

 }

 else {return(decOut)};

}

function _proxy_jslib_proxy_encode(URL) {

   URL=_proxy_jslib_encode64(URL);

    URL= URL.replace(/([a-mA-M])|[n-zN-Z]/g, function (s,p1) { return String.fromCharCode(s.charCodeAt(0)+(p1?13:-13)) }) ;

    // don't remove this

    URL= URL.replace(/\=/g, '=3d').replace(/\?/g, '=3f').replace(/\#/g, '=23').replace(/\%/g, '=25') ;

    return URL ;

}

function _proxy_jslib_proxy_decode(enc_URL) {

    // don't remove this

    enc_URL= enc_URL.replace(/\=(..)/g, function (s,p1) { return String.fromCharCode(eval('0x'+p1)) } ) ;

    enc_URL= enc_URL.replace(/([a-mA-M])|[n-zN-Z]/g, function (s,p1) { return String.fromCharCode(s.charCodeAt(0)+(p1?13:-13)) }) ;

   enc_URL= _proxy_jslib_decode64(enc_URL);

    return enc_URL ;

}

function _proxy_jslib_cookie_encode(cookie) {

   cookie=_proxy_jslib_encode64(URL);

    cookie= cookie.replace(/([a-mA-M])|[n-zN-Z]/g, function (s,p1) { return String.fromCharCode(s.charCodeAt(0)+(p1?13:-13)) }) ;

    cookie= cookie.replace(/(\W)/g, function (s,p1) { return '%'+p1.charCodeAt(0).toString(16) } ) ;

    return cookie ;

}

function _proxy_jslib_cookie_decode(enc_cookie) {

    enc_cookie= enc_cookie.replace(/%([\da-fA-F]{2})/g, function (s,p1) { return String.fromCharCode(eval('0x'+p1)) } ) ;

  enc_cookie= enc_cookie.replace(/([a-mA-M])|[n-zN-Z]/g, function (s,p1) { return String.fromCharCode(s.charCodeAt(0)+(p1?13:-13)) }) ;

  enc_cookie= _proxy_jslib_decode64(enc_cookie);

   return enc_cookie ;

}

EOB
```

----------

