Hallo zusammen

OwnCloud http://owncloud.org ist im Kern ein Daten Cloud System, ähnlich Dropbox, Googel Drive, Skydrive, UbuntuOne, etc.
Im Gegensatz zu den genannten kommerziellen Systemen/Dienstleistungen ist es vollumfänglich Opensource und man hat die Möglichkeit den Server auf einer eigenen Maschine zu hosten.
Grundsätzlich bieten ja alle Data-Cloud Anbieter eine gewisse Menge Speicherplatz (meist 2-10GB) gratis, was auf den ersten Blick grosszügig erscheint. Für das Wichtigste reicht das zwar sicher aus, aber man muss schon wider priorisieren. Was ist Sync würdig, was nicht. Ein privater Datenstamm mit Office Dokumenten, Bilder Gallery und Videos hat schnell mal 50-100 GB. Wer diese Speichermenge anmieten will, muss ordentlich in die Tasche greifen. Bei Dropbox kosten 100 GB z.B. 10$/Monat. Andere Anbieter bewegen sich ähnlich auch im Bereich 8-12$/Monat. Das sind 20% der Kosten eines entry Level Root Servers der 30x mehr Speicherplatz bietet und noch diverse Zusatznutzen hat. Daneben kommt noch die Frage der Datensicherheit und die Rechtssituation. Die meisten Anbieter werben zwar mit "Encryption" was aber meist bedeutet dass die Daten zwar verschlüsselt übertragen und allenfalls verschlüsselt gespeichert werden, jedoch erfolgt die Ablageverschlüsselung Serverseitig (wie z.B. bei Dropbox) womit einzig der Anbieter den Master-Key kennt. Grundsätzlich gibt es zwar Zusatz Tools wie Cloudfogger http://www.cloudfogger.com die lokal verschlüsseln und erst dann hoch laden. Solche Lösungen sind aber kompliziert im Handling und man kann ausschliesslich von entsprechend ausgerüsteten Endgeräten effektiv auf die Daten zugriffen.

Es gibt auch kommerzielle Alternativen die den Betrieb eines eigenen Servers erlauben bzw. anbieten z.B. http://www.teamdrive.com. Jedoch wird auch hier durchwegs auf eine jährlich anfallende Lizenzgebühr gesetzt, was auch wieder einer Miete entspricht. Zudem muss man neben dem Server pro Client auch nochmals eine beachtliche Jahresgebühr bezahlen.
Ich persönlich habe kein Problem für eine Server Lizenz zu bezahlen und auch gelegentlich mal für eine neue Version zu kaufen. Der Miet Gedanke widerspricht mir hier aber völlig, da ich eben genau nicht von einem Unternehmen abhängig sein möchte, dass das Produkt ggf. einstellt, und die Lizenz dann einfach ausläuft. Zudem möchte ich keine Client Limitierungen haben, wenn ich schon die Infrastruktur bereitstelle.

Anforderungen an Alternativen
- Betrieb auf eigenem Server
- Verschlüsselung der Daten beim Transfer und bei der Ablage mit User spezifischem Key.
- Unlimitierte Clients
- Kauf Lösung oder Opensource/Freeware
- Lösung wird aktuell weiterentwickelt.

Betrachtete Lösungen die den Betrieb eines eigenen servers erlauben
Tool / Haupt Nachteil - Stand Januar 2012
DataOnDemand / Projekt eingestellt, Anbieter pleite.
iFolder (Novel) / Opensource, wird aber nicht mehr aktiv weiterentwickelt.
Syncany / Alpha Status, Bescheidener Funktionsumfang.
SparkleShare / Beta Status, Sicherheitsfeatures noch nicht in gewünschtem Umfang implementiert (aber angekündigt).
OwnCloude / Grundanforderungen erfüllt.
TeamDrive / Kommerziell, hohe jährliche Lizenz Kosten.
GoodSync / Keine serverseitige Verschlüsselung.
SME / Sicherheits features nur rudimentär erläutert.

Ich habe mich dann vor gut einem Jahr dazu entschieden, OwnCloud näher anzuschauen und habe mir auch eine Testinstallation der Version 3 aufgesetzt. Leider zeigte sich schnell dass noch diverse Probleme und Bugs vorhanden waren, und das Handling noch alles andere als idiotensicher war. Die im Mai 2012 erschienene Version 4 brachte einige neue Features und war allgemein eine grosse Verbesserung. Nach zahlreichen Updates im Sommer habe ich im Herbst mit der Version 4.0.7 eine weitere Versuchsreihe gestartet. Jedoch zeigten sich einerseits Probleme bei der Synchronisation grosser Dateien mit langsamen Internet Anbindungen sowie auch Konzeptionelle Mängel bei der Anwendung der Verschlüsselung und der Versionierung in Multi User Umgebungen.
http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-1618 / https://github.com/owncloud/mirall/issues/192
rund einen Monat später folgte die Version 4.5 bei der die Möglichkeit der Verschlüsselung von gespeicherten Daten kurzerhand entfernt wurde. Da dies eine Kernanliegen von mir ist, habe ich keine weiteren versuche mehr gefahren. Entsprechend einer Mitteilung soll dieses Feature auf die Version 5 komplett überarbeitet werden.
Auf Grund dieser Ausgangslage habe ich mir die damaligen Alternativen nochmals angeschaut. Dabei habe ich gesehen, dass vor allem SparkleShare im Bereich Sicherheit scheinbar einige Schritte nach vorne gemacht hat. Für einen konkreten Test fehlte mir aber die Zeit.

Die OwnCloud Version 5.0 soll am kommenden Donnerstag 07.03.2013 erscheinen. Ich bin gespannt.

Ein Kollege von mir betreibt eine OwnCloud Instanz auf seinem NAS. Diese Implementation basiert aber aktuell auf den 4.5.x Versionen welche wie gesagt keine Verschlüsselung der abgelegten Daten erlaubt und somit für mich aus Prinzip nicht für den produktiv betrieb in Frage kommt.

Zudem macht der Betrieb einer solchen Lösung auf einem lokalen NAS (mindestens für meine geplante Nutzung) nur bedingt Sinn.
Klar kann man z.B. die Synchronisation eines Desktop und eines Laptop auf diesem Weg realisieren. Im LAN ist auch alles anständig schnell.
Wenn man von einem externen Standort auf die Daten zugreifen will oder einen extern platzierten PC einbinden will, leidet man unter dem limitierten Upload.

Nach dem die OwnCloud Version 5.0.0 die schlussendlich am 14. März erschienen ist dann doch noch kein neues Encryption App enthielt, habe ich weiter abgewartet.

Anfang Monat, am 06. Juni ist die OwnCloud Version 5.0.7 erschienen, welche nun erstmals seit den 4.0.x Versionen wieder ein Encryption App integriert hat.
Allerdings ist die integrierte Version "Encryption App 0.4" noch explizit als "preview release" gekennzeichnet.

Zitat

Encryption 0.4
WARNING: This is a preview release of the new ownCloud 5 encryption system. Testing and feedback is very welcome but don't use this in production yet. Encryption is not yet compatible with LDAP

.

Das neue Konzept macht einen durchaus durchdachten Eindruck. Eine detaillierte Beschreibung des Funktionsprinzip gibt es hier

Zitat

Quelle: http://blog.schiessle.org/2013…-owncloud-encryption-app/

Last weekend we released a first preview version of the new encryption app. This wouldn’t be possible without the work done by Sam Tuke and Florin Peter. Thanks a lot for all your work! Let me take the opportunity to tell you some details about the app, what it does and how it works.

The encryption app for ownCloud 5 was a complete re-write. We moved from the relatively weak blowfish algorithm to the more secure AES algorithm. The complete encryption is built on top of OpenSSL a well-known and tested encryption library. Further, the encryption app is integrated into ownCloud seamlessly. This means that the encrypt and decrypt happens transparently so that you can still use all the other features from ownCloud like sharing, different viewer apps, WebDAV access etc.

To make this possible, we decided to perform the encryption server-side. Still the architecture allows us to implement client-side encryption as an additional option later. Server-side encryption is especially interesting for users who also use the external storage app. Combining the external storage app with the encryption app allows you to use external storage without giving any 3rd-party provider access to your data.

ownCloud uses the users log-in password for encryption. This means that you should choose a strong password in order to protect your data. It is important to know that by default a user will lose access to his data if he loses his log-in password. As an additional feature the administrator can generate a recovery key which allows him to recover user data. Once this feature is activated in the administrator settings every user can enable the recovery key in his personal settings. By default the recovery key is disabled. Every user can decide for himself whether he wants this additional protection against password loss or not. Since we are using server-side encryption this feature does not reduce the security. Keep in mind that your ownCloud administrator will always be able to intercept your data because everything gets encrypted and decrypted at the server. Since ownCloud is Free Software you can choose a trustworthy administrator freely or decide to be your own administrator if you wish.

Let’s talk about some technical details and how the encryption works. The encryption is based on three different keys: every user has a private/public key-pair, every file has a file-key and to give multiple users access to a file we have share-keys.

Every user has an asymmetric 4096-bit strong key-pair which consists of a private and a public key. The private key is encrypted with the users log-in password, for the encryption AES-128 is used. Additionally there are up to two system-wide key-pairs: One for public link shares which allows ownCloud to decrypt files which are shared as public link and if enabled the recovery-key-pair.

In order to not always have to encrypt and decrypt large files we have introduced the file-keys which are 183 byte strong ASCII keys. The file-key is used to encrypt the users file symmetrically with AES-128. Than the file-key gets encrypted with the public keys from all users with access to the file. This means that if a user gets added or removed from a file we only have to re-encrypt the small file-key instead of the whole file.

Every time a file-key gets encrypted to multiple users OpenSSL generates for each user an additional share-key. Only the combination of the users private key with the corresponding share-key enables the user to decrypt the given file again.

Everybody is welcome to test the new encryption app and report issues on our mailing list or preferable directly on GitHub. But keep in mind that this is a preview version, you should always have a backup of your unencrypted data!

Alles anzeigen

Grundsätzlich erfolgt die Datenübertragung vom Client zum Server verschlüsselt via HTTPS. Zur Ablage werden die Daten dann aber erst serverseitig verschlüsselt. Der Paranoide sieht hier sicher bereits das erste grosse Sicherheits-Risiko, dass ein Administrator die Möglichkeit hätte, die Daten im Klartext abzugreifen. Da man den Server und den Administrator aber selber wählen kann, relativiert sich dies aber.

Das gewählte System bietet den Vorteil, dass die Daten im Web Interface transparent zur Verfügung gestellt werden könne. Auch ist es so möglich verschlüsselte Date mit anderen Benutzern auf dem gleichen Server zu teilen. Bei einer Client seitigen Verschlüsselung wären einige dieser Möglichkeiten nicht mehr oder nur noch eingeschränkt verfügbar. Auch hier sehen wir wieder das übliche Konfliktfeld; Sicherheit vs. Benutzerkomfort. Wobei ich denke dass hier ein akzeptabler Mittelweg begangen wird.
Wie aber von den Entwicklern bereits beschrieben wird, ist die Option einer Client seitigen Verschlüsselung möglich und wird ggf. später implementiert.

Bei den Versuchen mit einem Test Datenstamm konnte ich bisher keine Probleme im Bereich Handling entdecken. Wenn man die Bug Issues durchgeht, schienen aber schon noch einige Kinderkrankheiten vorhanden zu sein.
Das einzige was mich bisher gestört hat, ist die Tatsache, dass auf dem Server der Dateiname im Klartext ersichtlich ist. Sollte der Server kompromittiert werden sind aus diesen sichtbaren Informationen bereits weit reichende Rückschlüsse auf das Benutzerverhalten möglich.

Die Installation hat sich mittlerweile ebenfalls stark vereinfacht, da nun für die bekannteren Linux Distributionen Pakete zur Verfügung stehen die wie z.B. unter Debian mit apt-get installiert und aktualisiert werden können.

Nach einigen weiteren Tests habe ich mich dazu entschlossen, nun endgültig produktiv zu gehen d.H. es werden nun auch weitere (unerfahrene) User eingebunden.

Die Installation selber geht mittlerweile dank Debian Paketen eigentlich absolut problemlos. Bei der Installation der 6.x Versionen (Auf einem Debian 7.4.0 Host) hatte ich aber dennoch kleinere Probleme.

Dein Web-Server ist noch nicht für Datei-Synchronisation bereit, weil die WebDAV-Schnittstelle vermutlich defekt ist. Bitte prüfe die Instalationsanleitungen.

Dieser Fehler wird einem gleich nach der Installation auf der Login Seite angezeigt. Die Webseite ist zwar voll funktionsfähig. allerdings ist es dem Desktop Client in diesem Zustand nicht möglich über eine HTTPS Verbindung Dateien zu übertragen.

Nach einigem Googlen habe ich HIER gelesen, dass das Problem die verwendete PHP Funktion curl ist. Diese akzeptiert in der Standardkonfiguration keine selbst signierten Zertifikate.
Bemerkung: Ich habe ein solches selbst signiertes Zertifikat bei der Einrichtung von Apache erstellt und in die Apache Konfiguration eingebunden.

Die aufgezeigte Lösung, in der entsprechenden Konfigurationsdatei einfach die Überprüfung zu deaktivieren hat mir nicht unbedingt zugesagt.

Da auch andere Anwendungen dieses Problem mit curl kennen bin ich darauf gestossen, dass man dieses Problem lösen kann, wenn man das selbst signierte Zertifikat vom Apache zusätzlich dem Zertifikatsstore des OS hinzufügt und diesem vertraut.
Ich habe mich an DIESER Anleitung orientiert.

Man muss das Apache Zertifikat (*.pem Datei) in den Ordner /usr/share/ca-certificates kopieren und in *.crt umbenennen.
Mit dem Befehl "dpkg-reconfigure ca-certificates" startet man den Assistenten in dem man das selbst signierte Zertifikat als vertrauenswürdig akzeptieren kann.
Danach funktioniert das Ganze problemlos.

Interessanterweise erscheint die Warnung auch weiterhin unter den "Einrichtungswarnung" auf dem Webinterface.

Bezüglich Plugins so nutze ich aktuell nur das Encryption Modul.
Was ich mir aber definitiv noch anschauen werde ist das "Mozilla Sync" Modul.
Interessant würennatürlich auch die AntiVirus Module allerdings scheinen die aktuell nicht wirklich aktiv gepflegt zu werden.

Beim erstellen der ersten Benutzer ist mir schon gelungen einen zu "korrumpieren"... Das Problem war vermutlich, dass das versucht wurde das Passwort zu ändern, während dem die Initiale Verschlüsselung noch nicht abgeschlossen war. Bei einem leeren Account dauert das zwar nicht sehr lange ... aber scheinbar hat es trotzdem gereicht.
Beim Login versuch mit dem betroffenen User bekommt man folgende Fehlermeldung:

Zitat

Initial encryption running... Please try again later.

Ein Login ist nicht möglich. Andere Accounts sind davon aber nicht betroffen.

Da der Account sowieso noch leer war habe ich ihn gelöscht und neu erstellt, was aber das Problem auch nicht gelöst hat, da vermutlich auch nach dem Löschen noch irgendwas in der Datenbank zurück bleibt.
Im OwnCloud Forum gibt es HIER auch einen Hinweis der das Problem möglicherweise lösen kann.

Dieser Lösungsansatz führte aber gleich zum nächsten Problem... Datenbank editieren - Wie?
Bisher habe ich OwnCloud immer mit einer SQLite Database (sqlite3) eingerichtet, weil dies die standard Auswahl ist. Es ist soweit auch die einfachste Möglichkeit, da diese als voll integriert Lösung eingebunden ist, und keine weitere Konfiguration bzw. Installation erfordert. Als Alternativen stehen MySQL und PostgreSQL zur Auswahl, welche aber vorgängig separat eingerichtet werden müssen.

Ich habe dann also begonnen mich über SQLite schlau zu machen... Ein Kollege den ich bezüglich SQLite Kenntnissen angefragt habe, hat mich dann relativ umgehend auf DIESE Manual Seite verwiesen wo steht.

Zitat

Because SQLite handles multiple users very badly SQLite is only recommended for single user ownCloud installations.

Ok, jetzt weiss ich das auch ...

Ich habe dann Anweisungen zur Migration von SQLite zu MySQL gefunden, diese sahen aber sehr nach Bastelstunde mit zahlreichen manuellen Anpassungen aus. Eine Neuinstallation von OwnCloud mit MySQL war von dem her sicher einfacher und sauberer. Da ich sämtliche Daten eh noch auf einer anderen VM auf dem Server zwischengespeichert hatte, ist auch die Neubefüllung recht schnell da ich nicht alles neu hochladen muss.

Nach dem ersten Eindruck ist der MySQL Unterbau einiges performanter. CPU und auch Ram Auslastung sind etwas kleiner und das System arbeitet schneller. Bei der ersten Befüllung erfolgte im Schnitt mit etwa 2 MB/s. Aktuell bin ich eher bei 3 MB/s. Ein weiterer Plusspunkt für MySQL ist natürlich, dass mit phpMyAdmin eine komfortable Datenbank editing Plattform zur Verfügung steht, falls das zukünftig dann doch nochmal notwendig sein sollte.

Also der Umstieg auf mySQL hat sich absolut gelohnt! Performance und Handling sind um längen besser. Wie ich gelesen habe soll Maria DB im ein oder anderen Fall nochmals etwas performanter laufen als mySQL ... Aufs letzte Prozent kommt es mir hier aber auch wieder nicht an.

Meine zitierte Aussage bezieht sich auf die Verarbeitungs-Geschwindigkeit beim "Befüllen" des Servers mit dem Initialen Datenstamm. Dieser Prozess war dann mit mySQL (3 MB/s) fast 50% schneller im Vergleich zu SQLite (2 MB/s). Die Daten habe ich wie beschrieben zuvor auf eine VM hochgeladen, womit der Transfer auf dem Server lokal erfolgte und so einzig die Performance der Software (bei gleicher Hardware) zum tragen kommt, nicht aber die Upload Bandbreite die sonst bei mir das limitierende Glied gewesen wäre..