apache, webdav und Authentifizierung

ralze

ralze

Foren As
Hallo Leute,

ich hab gerade nach (etwas) längerem lesen von:

http://tldp.org/HOWTO/Apache-WebDAV-LDAP-HOWTO/index.html
http://www.latenightpc.com/blog/arc...dap-authentication-provider-for-apache-today/
und letztendlich
http://bitworking.org/news/Problems_with_HTTP_Authentication_Interop

feststellen müssen, dass es keine Möglichkeit gibt, einen webdav Ordner mit apache bereitzustellen, der die Authentifizierung vernünftig verschlüsselt.

Stimmt das? Hat sich seit dem was getan? Oder irre ich mich?

Meine Motivation ist folgende:
Ich habe auf meinem Webserver (Debian Etch, Apache2.2) ein paar Seiten mit Typo3 (4.1) für mich, Freunde und Verwandte laufen. Ich wäre gerne in der Lage mit meinen bevorzugten Editoren beispielsweise html, css, typoscript oder Bilddateien direkt zu bearbeiten ohne sie per erst herunterzuladen und wieder hochzuladen.

Meine Gedanken bisher:
Natürlich kann man den Ordner per SSHFS direkt einbinden, aber leider nicht als www-data. Das macht die sache dann nutzlos, weil alle Dateien mit 755 erstellt werden. Damit kann ich sie dann wunderbar laden aber natürlich nicht abspeichern.
Als root würde es theoretisch funktionieren, ... solange man keine neuen Dateien erstellt... aber ich krieg schon Bauchschmerzen wenn ich das nur Tippe...
Dann hab ich in /etc/apache2/apache2.conf folgendes gefunden:
Code:
User www-data
Group www-data
Ich dachte mir, ich könnte ja einen neuen user "apache2" erstellen, dem ich dann ein pw gebe. Leider hab ich auch hier das gefühl, dass das keine gute Idee ist. Den www-data Account wird es ja erstens nicht umsonst geben und weiterhin bin ich mir nicht sicher, wie es typo3, mysql, php usw finden würden, wenn apache mit nem anderen user läuft...

Schließlich kam ich natürlich auf webdav. Das klang eben für meine Zwecke erstmal genau richtig.

Kennt jemand vielleicht weitere Techniken, die mich zu meinem Ziel bringen würden?

ich würd mich freuen!
 
feststellen müssen, dass es keine Möglichkeit gibt, einen webdav Ordner mit apache bereitzustellen, der die Authentifizierung vernünftig verschlüsselt.

Ich kenne mich mit webdav wenig bis gar nicht aus, aber kann man das was du willst nicht ganz einfach erreichen mittels SSL / TLS?

Aus wiki:

Technisch gesehen ist WebDAV eine Erweiterung des Protokolls HTTP/1.1, die bestimmte Einschränkungen von HTTP aufhebt. Bisher kennt man aus Online-Formularen meist nur die Möglichkeit, einzelne Dateien hochzuladen (HTTP-POST). Mit WebDAV können ganze Verzeichnisse übertragen werden. Zudem ist eine Versionskontrolle implementiert.

Dann müsste das doch auch genauso über SSL getunnelt funktionieren.

Also einfach beim Apache SSL einschalten, Zertifikat generieren, evtl. noch entsprechenden vhost usw. -> fertig.

Bitte um Korrektur wenn ich hier gerade Müll erzähle.
 
Man kann WebDAV über eine SSL-verschlüsselte Verbindung nutzen. In Versionsverwaltungen über Subversion (z.B. bei Sourceforge.net) wird das oft eingesetzt. Der Zugriff auf das Verzeichnis erfolgt dann über eine https-URL.
 
Also einfach beim Apache SSL einschalten, Zertifikat generieren, evtl. noch entsprechenden vhost usw. -> fertig.

Das Ding mit diesen Zertifikaten ist, dass man immer noch kein mitm-Angriff ausschließen kann, wenn man sie selbst erzeugt und nicht kauft. Und wenn man sie kauft, muss man denen vertrauen, die diese Zertifikate offensichtlich mehr oder weniger zuverlässig erstellen. Außerdem ist dann die Privatshpäre und Datenintegrität auch von der Gesetzgebung/Wirtschaftslobby abhängig :oldman

Ne Host Key Protection für SSL wie bei SSH wäre toll... :hilfe2:

Leider kann ich das Risiko eines mitm-Angriffs bei nicht-zertifizierten SSL-Zertifikaten überhaupt nicht abschätzen. Jemand von euch vielleicht?
 
Leider kann ich das Risiko eines mitm-Angriffs bei nicht-zertifizierten SSL-Zertifikaten überhaupt nicht abschätzen. Jemand von euch vielleicht?

Das Risiko ist relativ gering, wenn man einige Sachen beachtet. Die meisten Clients bieten ja die Möglichkeit sich ein Zertifikat als bekannt zu speichern. Man muss daher nur beim erstmaligen Verbinden darauf achten, dass der Fingerprint des empfangenen Zertifikats identisch zum Fingerprint des generierten Zertifikats ist. Alternativ verwendest du ein Root-Zertifikat, das man sich vorher installieren muss, so dass das vom Server gesendete Zertifikat als vertrauenswürdig eingestuft wird.
 
ähmm, erstellt du nicht selbst das zertifikat? dieses zertifikat kannst du im vorfeld auch den leuten schicken, die das DAV-Verzeichnis nutzen sollen

ein ssl-zertifikat für den apache kannst du selber erstellen, dann kannste dav auch über ssl benutzen
 
ähmm, erstellt du nicht selbst das zertifikat? dieses zertifikat kannst du im vorfeld auch den leuten schicken, die das DAV-Verzeichnis nutzen sollen

ein ssl-zertifikat für den apache kannst du selber erstellen, dann kannste dav auch über ssl benutzen

Das Problem der selbst signierten Zertifikate ist, dass sie von Browsern nicht als vertrauenswürdig erkannt werden, da das Root-Zertifikat nicht bekannt ist und damit die Validität des Zertifikats nicht sichergestellt werden kann. Ich denke, dass ralze in dieser Hinsicht Bedenken hat. Wenn da nämlich bei der Verbindung nicht darauf geachtet wird, dass wirklich das korrekte Zertifikat vom Server kommt, kann sich theoretisch jemand mittels einer MITM-Attacke in die Verbindung einklinken. Das Zertifikat, das man dann den Leuten zuschickt ist üblicherweise das Root-Zertifikat, das die Validität des vom Server gelieferten Zertifikats sicherstellt. Die Root-Zertifikate der meisten offiziellen Signer sind aber in den meisten Browsern schon drin, so dass die Browser Zertifikate von denen automatisch validieren kann.
 
Die Root-Zertifikate der meisten offiziellen Signer sind aber in den meisten Browsern schon drin, so dass die Browser Zertifikate von denen automatisch validieren kann.

Da gab's ja diesen Fall, dass ein paar Leute sich als Microsoft-Mitarbeiter ausgegeben haben um so ein Zertifikat zu bekommen...
http://www.verisign.com/support/advisories/authenticodefraud.html

Aber Danke auf jeden Fall für deine Einschätzung! Ich denke, dass mir das dann sicher genug ist!
 
Das Problem der selbst signierten Zertifikate ist, dass sie von Browsern nicht als vertrauenswürdig erkannt werden, da das Root-Zertifikat nicht bekannt ist und damit die Validität des Zertifikats nicht sichergestellt werden kann.

Aber wenn man die Zertifikate vorab an die User schickt und diese die Zertifikate in den Browser-Truststore importieren, hat sich dieses Problem auch erledigt......
 
Aber wenn man die Zertifikate vorab an die User schickt und diese die Zertifikate in den Browser-Truststore importieren, hat sich dieses Problem auch erledigt......

Da ich alle leute, die sich per https authentifizieren sollen so ziemlich persönlich kenne, geht das echt.
 

Ähnliche Themen

Problem mit apache und 2 Virtuellen hosts

Probleme mit FFmpeg / PHP/ 70 Load / iowait

Apache zu langsam ?

Server-Monitoring mit RRDTool

Zurück
Oben