[gelöst] Proxy mit ssh für TLS

Gemeinsam ins Internet mit Firewall und Proxy.
Antworten
Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

[gelöst] Proxy mit ssh für TLS

Beitrag von Tintom » 08.10.2020 13:48:39

Hallo zusammen,
ich habe einen managed vServer, bei dem eine Nextcloud-Instanz läuft. Auf die Software des Servers und dessen Konfiguration habe ich keinen Einfluss und muss das nehmen was angeboten wird. Ich nutze den vServer u.a. zur Synchronisation meiner Termine und Kontakte auf dem Smartphone. Mein Smartphone ist relativ alt (Android-Version 4.3), ich benutze es nur noch zum Telefonieren und eben die Synchronisation von Terminen und Kontakten.
Nun gab es ein Systemupgrade des vServers und in Folge dessen wurde die Unterstützung für unsichere Protokolle rausgekickt. In der Folge heißt das, der vServer aktzeptiert nur noch TLS ≥ v. 1.2. Damit hat mein Smartphone aber Probleme, ich bekomme bei der Synchronisierung mit der Nextcloud-Instanz Fehler beim SSL-Handshake (Fehlermeldung kann ich bei Bedarf nachliefern). Zur Synchronisation verwende ich auf dem Telefon die App davdroid (heißt heute Davx5 soweit ich weiß) in der Version 1.9.2 (neue Versionen lassen sich nicht mehr installieren).
Ich möchte beides, also Telefon und vServer, gerne weiter nutzen und habe mir nun überlegt, den Datenverkehr des Smartphones über einen Debian-Rechner (home) zu leiten. Ich will dazu dem Telefon einen chroot verpassen und dann mittels ssh eine Verbindung an den heimischen Rechner herzustellen, der als Proxy fungieren soll. So stelle ich mir das vor:

Code: Alles auswählen

# [vServer] #
# TLS ≥ 1.2 #<‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒
      |                                            |
      ⚡                                            |
      |                                            |
      |                                            ∇
#[Android 4.3]#                               # [home] #
#  TLS < 1.2  # ‒‒ ssh -D <Port> user@home ‒‒ # Debian #
Meine Frage: Kann ich das wie dargestellt mit ssh so umsetzen, dass die unterschiedlichen Protokollversionen zwischen Telefon und vServer „übersetzt“ werden? Oder brauche ich einen „richtigen“ Proxyserver? Oder gar ganz etwas anderes?
Zuletzt geändert von Tintom am 02.11.2020 20:53:20, insgesamt 2-mal geändert.

uname
Beiträge: 12045
Registriert: 03.06.2008 09:33:02

Re: Proxy mit ssh für TLS

Beitrag von uname » 09.10.2020 12:18:24

Also SSH hat mit HTTPS gar nichts zu tun. Was du brauchst wäre eher ein HTTP-Proxy wie Squid, wobei
a.) ich nicht weiß ob dein Termine- und Kontakte-App damit überhaupt klar kommt (eher nicht)
b.) TLS ist eigentlich Ende-zu-Ende (Client über Proxy zum Server) und damit ist das Problem immer noch da

Ich schlag mal folgendes vor:
a.) neues Smartphone
b.) neue Software auf den Smartphone, welche mit dem TLS-Standard umgehen kann (freies Android-Release)
c.) Zugriff auf die Nextcloud ohne HTTPS also nur mit HTTP erlauben (kannst du irgendwo konfigurieren, sofern du die Nextcloud konfigurieren darfst)

c.) ist sehr komisch. Etwas veraltete TLS-Protokolle werden mit aller Gewalt verboten, unverschlüsselte Verbindungen jedoch nicht.
Wegen der Sicherheit würde ich mir weniger Sorgen machen. Dein Smartphone ist so alt, da kommt es auf die unverschlüsselte Verbindung auch nicht mehr an.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Proxy mit ssh für TLS

Beitrag von eggy » 09.10.2020 15:58:25

@Tintom: könnte sein, dass man das mit haproxy hinbekommt, hab ich aber noch nicht versucht und kann dazu keine weiteren sachdienlichen Hinweise geben. Und mitmproxy wäre wohl das nächste Tool, dem ich sowas mit überschaubarem Aufwand zutrauen würde. Gib mal bitte Bescheid, was funktioniert hat und was nicht, das Thema interessiert mich auch, hab aber grade nicht die Zeit mich da selbst nochmal in Ruhe umzusehen. Machbar ist das alles sicher, ob sinnvoll, steht auf nem anderen Blatt.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 13.10.2020 03:52:46

Android 4.3 kann prinzipiell TLS 1.2 es muss lediglich eingeschaltet werden.
Das müsste etwa so aussehen:

Code: Alles auswählen

 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP_MR1) {
socket.setEnabledProtocols(new String[]{TLS_v1_1, TLS_v1_2});
}
Ich weiß nicht, was das für ne App ist, mit der du syncronisierst. Aber wenn die OpenSource ist, kannst du eventuell mal fragen, ob sie die 3 Zeilen einbauen um Android 4.X zu supporten.
Sonst würde mich die Fehlermeldung intersessieren.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 13.10.2020 23:25:57

Danke für eure Antworten!
c.) Zugriff auf die Nextcloud ohne HTTPS also nur mit HTTP erlauben (kannst du irgendwo konfigurieren, sofern du die Nextcloud konfigurieren darfst)
c.) ist sehr komisch. Etwas veraltete TLS-Protokolle werden mit aller Gewalt verboten, unverschlüsselte Verbindungen jedoch nicht.
Mit der Nextcloud-Instanz kann ich nur per https kommunizieren, unverschlüsselte http-Verbindungen werden automatisch auf https umgeleitet. Das passiert anscheinend auf Serverebene, die .htaccess im Webroot sowie die .htaccess der Nextcloud haben da keine Weiterleitungen eingebaut.

Bevor ich es mit Proxies versuche will ich erstmal versuchen vielleicht doch noch die App zum Funktionieren zu überreden.

Ich verwende davdroid in der Version 1.9.2. Die nächsthöhere Version braucht mind. API-Level 19 (Android 4.4), aktuell verlangt die App Level 21 (Android 5). Ich unterstelle jetzt einfach mal der Entwickler weiß was er tut und setzt den String minSDKVersion nicht aus blinder Versionitis hoch. Ich erwarte daher wenig Interesse seitens des Entwicklers um sich auf eine veraltete Version, die auf einem veralteten Telefon läuft zu fokussieren, daher möchte ich versuchen das hier zu lösen.

Nach wannes Hinweis habe ich mir mal den Quellcode angeschaut (https://gitlab.com/bitfireAT/davx5-ose/-/tree/v1.9.2). Da finde ich in der Datei SSLSocketFactoryCompat.kt Hinweise, dass TLS 1.2 eigentlich unterstützt werden sollte (https://gitlab.com/bitfireAT/davx5-ose/ ... .kt#L58-74). Ich habe darauf den Support des vServer-Anbieters angeschrieben und um Info hinsichtlich der eingestellten Parameter für SSL gebeten. Die Antwort war folgende:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
ssl_ecdh_curve secp384r1:prime256v1


Wenn ich das nun mit der o.g. Datei vergleiche sehe ich da ein paar Übereinstimmungen, Server und Client sollten also die gleiche Sprache sprechen. Sie tun es aber anscheinend nicht, das Log habe ich auf nopaste geladen: NoPaste-Eintrag41165


Habt ihr noch Ideen?

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 14.10.2020 08:47:52

Die android logs sind leider nicht aussagefähig. Lustigerweise sendet der Client eine ausführlichere Fehlermeldung an den Server. (Die man mit Wireshark abfangen kann.)
Wenn ich das nun mit der o.g. Datei vergleiche sehe ich da ein paar Übereinstimmungen, Server und Client sollten also die gleiche Sprache sprechen.
Nein. Der Server kann entweder SHA256 oder SHA384 als MAC. Du kannst nur MD5 und SHA1.
Leider wird man da vermutlich wenig machen können. Support gibt sofort ne schlechte Note bei Qualys obwohl es die Sicherheit für neue Clients nicht verschlechtert. (Die Aushandlung welcher MAC und welche Verschlüsslung genommen wird passiert, wie die Aushandlung der Keys per RSA-Signatur wer die fälschen kann um den Cipher zu ändern kann auch die Keys ändern und jede noch so gute Verschlüsslung ist nutzlos wenn man bestimmen kann, welcher Key genutzt wird...)

Die Argumentation von Qualys ist, dass du als Serverbetreiber keinen sicheren Betrieb garantieren kannst, wenn du auch grottige Clienten zulässt. Und das man die deswegen ausschließen muss.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 18.10.2020 13:49:18

Kurzes Zwischenfazit: Android und ich werden keine dicken Freunde mehr.
Ich dachte, bevor ich mit wireshark auf die Suche gehe, versuche ich die App selbst zu bauen. Meine Vermutung ist, wenn ich hier hier "TLS" mit "TLSv1.2" ersetze, könnte der Verbindungsaufbau funktionieren. Aber nach zwei Tagen mit Android Studio bekomme ich die App immer noch nicht gebaut. Ich muss dazu sagen, dass ich vom Android Bauprozess für Apps oder Java absolut keine Ahnung habe. Nun breche ich meine Versuche mit Android Studio ab, die Fehlermeldungen geben keine passenden Treffer mehr bei der Suchmaschine zurück.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 20.10.2020 17:37:19

Tintom hat geschrieben: ↑ zum Beitrag ↑
18.10.2020 13:49:18
Meine Vermutung ist, wenn ich hier hier "TLS" mit "TLSv1.2" ersetze, könnte der Verbindungsaufbau funktionieren.
Nein. Damit würdest du nur TLS1.0 und TLS1.1 abschalten, wenn ich das richtig sehe.
Tintom hat geschrieben: ↑ zum Beitrag ↑
18.10.2020 13:49:18
Ich muss dazu sagen, dass ich vom Android Bauprozess für Apps oder Java absolut keine Ahnung habe.
Die Anwendung ist in Kotlin nicht (wie die meisten anderen Android-Apps) in Java.
Die scheinen sich da aber schon ziemlich Arbeit zu machen, für ältere Handys. (Da läuft wahrscheinlich TLS 1.2. Du kannst da mal mit adb im Log nachschauen.) Problem bleibt, dass dein Handy halt kein SHA2 kann. Dein Serveranbieter aber ausschließlich ciphers mit SHA2 supported.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 20.10.2020 22:44:00

Danke für deine Rückmeldung!
Ich denke, dass ich da etwas falsch verstanden habe. Wenn du sagst
wanne hat geschrieben: ↑ zum Beitrag ↑
20.10.2020 17:37:19
Problem bleibt, dass dein Handy halt kein SHA2 kann. Dein Serveranbieter aber ausschließlich ciphers mit SHA2 supported.
Wo siehst du das?
Wenn ich mir die Ciphers von Serverkonfiguration und Quellcode anschaue, dann sehe ich z.B.:
Server: ECDHE-RSA-AES256-GCM-SHA384
Client: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

oder
Server: ECDHE-RSA-AES128-GCM-SHA256
Client: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Sind die dann nicht identisch?

Mein Eindruck war dann, wenn Server und Client die gleichen Ciphern beherrschen, gibt es beim Aushandeln der TLS-Version anscheinend einen Fehler. Deshalb wollte ich im Quellcode TLSv1.2 erzwingen. Vielleicht ist mein Gedanke aber auch komplett abwegig. Ich werde jetzt eine VM aufsetzen und versuchen die Situation dann nachzustellen. Die Logs von adb geben übrigens keine weiteren Informationen als die bislang bekannten.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 21.10.2020 00:08:37

Wo siehst du das?
Wenn ich mir die Ciphers von Serverkonfiguration und Quellcode anschaue, dann sehe ich z.B.:
Im Quellcode mag der Name wohl stehen. Dein Android lernt das deswegen noch lange nicht... Die haben da eine Whiteliste von Ciphern, die sie aktivieren, wenn sie vorhanden sind.
Android 4.3 kann wohl:

Code: Alles auswählen

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)  
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) 
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA (0xc022)  
TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA (0xc021) 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)  
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) 
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)  
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) 
TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA (0xc01c) 
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA (0xc01b) 
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) 
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) 
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d) 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003) 
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) 
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA (0xc01f) 
TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA (0xc01e) 
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) 
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) 
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) 
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)  
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)  
TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)  
TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)  
TLS_RSA_WITH_RC4_128_SHA (0x5)  
TLS_RSA_WITH_RC4_128_MD5 (0x4)
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x87)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x44)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
Kruzt du das mit der List von davdroid bleibt da das übrig:

Code: Alles auswählen

TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) 
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 21.10.2020 08:53:03

Alles klar, danke!

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 31.10.2020 17:43:44

Ich bin ein wenig weiter. In der Zwischenzeit habe ich dem Telefon ein chroot mit Debian verpasst [1] und mit ssh und Debianmitmproxy experimentiert. Ich habe dazu das chroot soweit eingerichtet, dass es über die WLAN-Verbindung des Telefons ins Internet kommt.

Variante mit ssh
Ich habe dazu mit der App Connectbot eine ssh-Verbindung zum sshd, der auf dem chroot installiert ist, hergestellt und dynamische Portweiterleitung auf Port 12345 aktiviert (entspricht dem Äquivalent zu ssh -D 12345 user@localhost)

Dann habe ich mich mit adb shell auf das Telefon verbunden:

$ curl https://google.com --proxy 127.0.0.1:12345 -v
* About to connect() to proxy 127.0.0.1 port 12345 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 12345 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.21.3 (arm-unknown-eabi) libcurl/7.21.3 OpenSSL/1.0.1e zlib/1.2.7.f-linuxfoundation-mods-v1
> Proxy-Connection: Keep-Alive
>
^C

$ curl http://google.com --proxy 127.0.0.1:12345 -v
* About to connect() to proxy 127.0.0.1 port 12345 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 12345 (#0)
> GET http://google.com HTTP/1.1
> User-Agent: curl/7.21.3 (arm-unknown-eabi) libcurl/7.21.3 OpenSSL/1.0.1e zlib/1.2.7.f-linuxfoundation-mods-v1
> Host: google.com
> Accept: */*
> Proxy-Connection: Keep-Alive
>
^C


Es wurden keine Daten übertragen, daher habe ich die Verbindung abgebrochen. Ich wurde zudem durch curl limitiert, weil ich die Version auf dem Telefon nehmen musste und die halt nur max. TLSv1 kann. Ich habe dann zusätzlich auch noch mit der App davdroid probiert auf den Nextcloud-Server zuzugreifen, leider ohne Erfolg.


Variante mit mitmproxy
Hier stand ich etwas auf dem Schlauch. Sofern ich das richtig verstanden habe, wäre ein normaler Proxy hier nicht angebracht, stattdessen sollte man einen transparenten Proxy oder einen Reverse-Proxy nehmen. Ich habe beides probiert:
  1. Reverse-Proxy:

    Server:
    # mitmdump -p 443 --reverse http://localhost:80/
    127.0.0.1:39765: HTTP protocol error in client request: Invalid HTTP request form (expected: relative, got: absolute)
    127.0.0.1:39765: clientdisconnect


    Client
    $ curl http://google.com --proxy 127.0.0.1:443 -v
    * About to connect() to proxy 127.0.0.1 port 443 (#0)
    * Trying 127.0.0.1... connected
    * Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
    > GET http://google.com HTTP/1.1
    > User-Agent: curl/7.21.3 (arm-unknown-eabi) libcurl/7.21.3 OpenSSL/1.0.1e zlib/1.2.7.f-linuxfoundation-mods-v1
    > Host: google.com
    > Accept: */*
    > Proxy-Connection: Keep-Alive
    >
    < HTTP/1.1 400 Bad Request
    < Content-Length: 213
    < Content-Type: text/html
    < Connection: close
    < Server: mitmproxy 0.18.2
    <
    <html>
    <head>
    <title>400 Bad Request</title>
    </head>
    <body>HttpException('Invalid HTTP request form (expected: relative, got: absolute)',)</body>
    * Closing connection #0
  2. Transparenter Proxy

    Server:
    # sysctl -w net.ipv4.ip_forward=1
    # sysctl -w net.ipv6.conf.all.forwarding=1
    # sysctl -w net.ipv4.conf.all.send_redirects=0
    # iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 8080
    # iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080
    # mitmproxy -T -p 8080


    Client:
    $ curl http://google.com --proxy 127.0.0.1:8080 -v
    * About to connect() to proxy 127.0.0.1 port 8080 (#0)
    * Trying 127.0.0.1... connected
    * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
    > GET http://google.com HTTP/1.1
    > User-Agent: curl/7.21.3 (arm-unknown-eabi) libcurl/7.21.3 OpenSSL/1.0.1e zlib/1.2.7.f-linuxfoundation-mods-v1
    > Host: google.com
    > Accept: */*
    > Proxy-Connection: Keep-Alive
    >
    < HTTP/1.1 400 Bad Request
    < Content-Length: 213
    < Content-Type: text/html
    < Connection: close
    < Server: mitmproxy 0.18.2
    <
    <html>
    <head>
    <title>400 Bad Request</title>
    </head>
    <body>HttpException('Invalid HTTP request form (expected: relative, got: absolute)',)</body>
    * Closing connection #0
Ich bekomme immer einen Error 400. Hat jemand noch Ideen?
Auch hier:
Ich habe dann zusätzlich auch noch mit der App davdroid probiert auf den Nextcloud-Server zuzugreifen, leider ohne Erfolg.



[1] Auf http://whiteboard.ping.se/Android/Debian ist ganz grob die Vorgehensweise beschrieben

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Proxy mit ssh für TLS

Beitrag von eggy » 31.10.2020 18:32:37

Ohne es ausprobiert zu haben und ohne zu wissen, ob das überhaupt mit Deinem Problem zu tun hat:
Ich hab die Fehlermeldung "Invalid HTTP request form (expected: relative, got: absolute)" mal gegen $suchmaschine geworfen und die warf einiges zurück, u.a.
https://github.com/mitmproxy/mitmproxy/issues/2321
vielleicht mal das "--set keep_host_header" ausprobieren?
Tintom hat geschrieben: ↑ zum Beitrag ↑
31.10.2020 17:43:44
Hier stand ich etwas auf dem Schlauch. Sofern ich das richtig verstanden habe, wäre ein normaler Proxy hier nicht angebracht, stattdessen sollte man einen transparenten Proxy oder einen Reverse-Proxy nehmen.
Die Grafik zu den Betriebsmodi auf https://docs.mitmproxy.org/stable/concepts-modes/ kennst Du schon?

Benutzeravatar
habakug
Moderator
Beiträge: 4313
Registriert: 23.10.2004 13:08:41
Lizenz eigener Beiträge: MIT Lizenz

Re: Proxy mit ssh für TLS

Beitrag von habakug » 31.10.2020 20:43:52

Hallo,

ich hatte bis jetzt gedacht, dass TLS 1.2 seit API LEVEL 16 (Android 4.1) unterstützt wird [1][2]. ;-)
Es ist nur nicht "enabled by default", das ist es erst ab API Level 20 (Android 4.4W).

Gruss, habakug

[1] https://developer.android.com/reference ... ocket.html
[2] https://developer.android.com/studio/releases/platforms
( # = root | $ = user | !! = mod ) (Vor der PN) (Debianforum-Wiki) (NoPaste)

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 01.11.2020 10:43:44

In der Zwischenzeit habe ich dem Telefon ein chroot mit Debian verpasst und mit ssh und mitmproxy experimentiert.
Wenn du so weit gehst, dass du eh nen Debian hast kannst du auch einfach nen richtigen Reverse Proxy hinsetzen und gut ist.

Code: Alles auswählen

apt install nginx
/etc/nginx.conf dadurch ersetzen:

Code: Alles auswählen

server {
        listen [::1]:80;
        location / {
                    proxy_pass https://server.name;
  }
}

Code: Alles auswählen

systemctl start nginx
systemctl enable nginx
Dann kannst du im davdroid http://[::1]/remote.php/dav/... (also den Servername durch [::1] ersetzen) als URL eintragen und fertig.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 01.11.2020 14:58:15

Hallo zusammen und danke für euer Feedback!
habakug hat geschrieben: ↑ zum Beitrag ↑
31.10.2020 20:43:52
Hallo,

ich hatte bis jetzt gedacht, dass TLS 1.2 seit API LEVEL 16 (Android 4.1) unterstützt wird [1][2]. ;-)
Es ist nur nicht "enabled by default", das ist es erst ab API Level 20 (Android 4.4W).

Gruss, habakug

[1] https://developer.android.com/reference ... ocket.html
[2] https://developer.android.com/studio/releases/platforms
Der Thread ist eine gute Doku für "bekomme ich nicht hin" :(
Im Ernst: Ich habe das so verstanden, dass der Client (in diesem Fall die App) dafür zuständig ist, TLS1.2 zu implementieren. Hier sind mir die Hände gebunden. Daher der Umweg über einen Proxy. Neben der o.g. App hat z.B. auch der androideigene Browser keine Chance mehr sich auf https-Seiten zu verbinden. Ich musste als Abhilfe dafür Fennec installieren.
eggy hat geschrieben: ↑ zum Beitrag ↑
31.10.2020 18:32:37
Ohne es ausprobiert zu haben und ohne zu wissen, ob das überhaupt mit Deinem Problem zu tun hat:
Ich hab die Fehlermeldung "Invalid HTTP request form (expected: relative, got: absolute)" mal gegen $suchmaschine geworfen und die warf einiges zurück, u.a.
https://github.com/mitmproxy/mitmproxy/issues/2321
vielleicht mal das "--set keep_host_header" ausprobieren?
Danke, über den Link bin ich gestern schon gestolpert, aber der hat bei mir auch nicht weiter geholfen. Ich habe noch einmal von vorn angefangen.

Mit mitmproxy als Reverseproxy hab ich nach ein paar Stunden und selbst signierten Zertifikaten es geschafft, dass curl per https-Anfrage an den Proxy eine Seite ausgeliefert bekommen hat. Für davdroid hat das aber nicht funktioniert.

Also weiter mit nginx, mit dem ich gefühlt besser zurecht komme.
wanne hat geschrieben: ↑ zum Beitrag ↑
01.11.2020 10:43:44
Wenn du so weit gehst, dass du eh nen Debian hast kannst du auch einfach nen richtigen Reverse Proxy hinsetzen und gut ist.

Code: Alles auswählen

apt install nginx
/etc/nginx.conf dadurch ersetzen:

Code: Alles auswählen

server {
        listen [::1]:80;
        location / {
                    proxy_pass https://server.name;
  }
}

Code: Alles auswählen

systemctl start nginx
systemctl enable nginx
Dann kannst du im davdroid http://[::1]/remote.php/dav/... (also den Servername durch [::1] ersetzen) als URL eintragen und fertig.
Mit der Config bekomme ich HTML 500 Errors auf dem Client und im Log von nginx. Bei proxy_pass habe ich die Nextcloud-Domain eingetragen. Richtig oder Falsch?

Wenn ich jetzt schon den nginx habe, wie müsste denn die Konfiguration aussehen, wenn ich sämtlichen https-Verkehr über den nginx laufen lasse?
Sprich: Normale http requests laufen von Android aus, Requests mit https würde ich (ggf. auch manuell) über den Proxy schicken, der auf localhost lauscht.

Nachtrag, sofern das weiterhilft: Requests mit https bekommen einen HTTP400 error.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Proxy mit ssh für TLS

Beitrag von wanne » 01.11.2020 19:58:40

Bei proxy_pass habe ich die Nextcloud-Domain eingetragen. Richtig oder Falsch?
Richtig.
Kannst du mal mit slash am Ende probieren?
Alose

Code: Alles auswählen

                    proxy_pass https://server.name/;
Sprich: Normale http requests laufen von Android aus, Requests mit https würde ich (ggf. auch manuell) über den Proxy schicken, der auf localhost lauscht.
Die Idee ist, dass davdroid per http mit dem nginx spricht. (Das sollte ja problemlos funktionieren) Der spricht dann https mit dem nextcloud Server.
Das ist dann btw sogar sicher. Weil http mit localhost selber reden ist unproblematisch.
Deswegen auch im Davdroid auch http statt https und [::1] statt der nextcloud domain:
http://[::1]/remote.php/dav/...
Das soll nie mitbekommen, dass es die Originale Domain gab.
Eventuell willst du auch noch ein paar Header entfernen die davdroid auf https umsteigen lassen:

Code: Alles auswählen

proxy_hide_header Alternate-Protocol;
proxy_hide_header Strict-Transport-Security;
proxy_hide_header  Public-Key-Pins;
Eventuell willst du doch mal verraten, was das für ein Server ist. Dann können andere hier nach gucken was schief geht.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Proxy mit ssh für TLS

Beitrag von Tintom » 02.11.2020 20:52:14

Hallo zusammen,
zuerst einmal sorry für meinen Post gestern mit den spärlichen Infos. Ich war frustriert, weil ich nach dem erfolgreichen chroot dachte „cool, jetzt noch einen Proxy und in 5 Minuten läuft das Ding wieder“ und zwei Tage später war ich immer noch nicht weiter.

Ich habe mich heute noch einmal mit frischem Kopf daran gemacht, das Loglevel des nginx auf debug gesetzt und versucht Anfragen von http://google.de auf https://google.de weiterzuleiten. Dann fiel mir im Log folgendes auf:

<...>
2020/11/02 09:05:47 [alert] 7045#7045: *7 socket() failed (13: Permission denied) while connecting to upstream, client: 127.0.0.1, server: google.de, request: "GET http://google.de/ HTTP/1.1", upstream: "https://[2a00:1450:4001:817::2003]:443/", host: "google.de"
<...>


nginx darf keinen Socket aufmachen. Grund ist das restriktive Android-System, das erlaubt sowas nur, wenn der Nutzer in der Gruppe inet ist. Diese muss man im Debian chroot erst anlegen:
addgroup --gid 3003 inet
Anschließend fügt man den Benutzer www-data hinzu (unter dem wird nginx bei Debian ausgeführt):
adduser www-data inet
Nach einem Neustart von nginx konnte ich meine Anfragen auf https://google.de weiterleiten.

Nun also weiter mit davdroid. Davdroid und nginx meldeten 404er Fehlermeldungen im Zusammenhang mit PROPFIND. Dafür muss man noch ein paar dav-spezifische Optionen (dav_methods und dav_ext_methods) in die Config schreiben [1]

Nachdem ich die Config angepasst habe, konnte ich mich mit der Nextcloudinstanz verbinden, allerdings konnte ich keine Daten verändern, die App wurde instabil, startete ständig neu und das Log war mit HTTP400-Fehlern gespickt. Zudem war das Log voll mit Einträgen wie:

2020/11/02 13:10:01 [info] 2302#2302: *99 client sent invalid method while reading client request line, client: 127.0.0.1, server: <SERVER>, request: "qm_�)k3�/*WF���ya�ARt޳"

Letzteres konnte ich mit der Option ignore_invalid_headers on; abstellen, bei der instabilen App war ich allerdings ein wenig ratlos. In meiner Verzweiflung habe ich dann die add_header Optionen [2] in die Config eingearbeitet und hatte zu meiner Verwunderung sofort einen stabilen davdroid Clienten.

Blieb noch das Problem der nicht veränderbaren Daten. Ich bemerkte, dass sobald ich im Webinterface oder in der App auf dem Telefon Termine anlegte, diese nur manchmal übertragen wurden. Im Log fielen mir zudem solche Verbindungsabbrüche auf:

2020/11/02 19:03:32 [info] 26706#26706: *23 client 127.0.0.1 closed keepalive connection (104: Connection reset by peer)

Die Ursache der Abbrüche konnte ich nicht nachvollziehen (Internetverbindung scheint okay), aber die Synchronisation funktioniert zumindest dann zuverlässig, wenn man mit einem Cache arbeitet. Ich habe also mit mkdir -p /var/cache/nginx/temp && chown www-data /var/cache/nginx/temp zwei Ordner angelegt und die Optionen root und client_body_temp_path in die Config hinzugefügt.

Jetzt funktioniert alles so wie ich es will: davdroid spricht mit dem Proxy im chroot unverschlüsselt, der Proxy leitet alles brav an die Nextcloud-Instanz weiter.

Puuh, fünf Minuten können manchmal ganz schön lang sein :wink:

Bleibt mir nur noch zu sagen: Vielen Dank an alle Beteiligten für eure Beiträge, insbesondere an wanne!

Noch einmal alles zusammengefasst:

Konfiguration Server:

Code: Alles auswählen

# addgroup --gid 3003 inet
# adduser www-data inet
# mkdir -p /var/cache/nginx/temp
# chown www-data /var/cache/nginx/temp

# cat <<EOF > /etc/nginx/conf.d/01_reverse.conf
server {
	listen 127.0.0.1:443;
	server_name <SERVER>;
	ignore_invalid_headers on;
	location / {
		proxy_pass https://<SERVER>/;
		dav_methods PUT DELETE MKCOL COPY MOVE;
		dav_ext_methods   PROPFIND OPTIONS;
	        add_header Referrer-Policy                      "no-referrer"   always;
	        add_header X-Content-Type-Options               "nosniff"       always;
	        add_header X-Download-Options                   "noopen"        always;
	        add_header X-Frame-Options                      "SAMEORIGIN"    always;
	        add_header X-Permitted-Cross-Domain-Policies    "none"          always;
	        add_header X-Robots-Tag                         "none"          always;
	        add_header X-XSS-Protection                     "1; mode=block" always;
		root /var/cache/nginx;
		client_body_temp_path /var/cache/nginx/temp;
	}
}
EOF

Konfiguration Client:

URL: http://localhost:<PORT>/remote.php/dav/
Benutzername <USER>
Passwort: <PASSWD>


<PORT> kann ein beliebiger Port sein, <SERVER> ist die Adresse der Nextcloud-Instanz, <USER> und <PASSWD> je nach Benutzer anpassen.


[1] https://wiki.archlinux.org/index.php/WebDAV#Nginx
[2] https://docs.nextcloud.com/server/stabl ... t-of-nginx

Antworten