Kategorien
Dienste des ZIM Lehren und Lernen Sicherheit Software

Von Ende zu Ende – Zoom verschlüsselt auf Wunsch!

Update 2022: Aktualisierte hinsichtlich Einschränkungen und Voraussetzungen.

Für die an der Bergischen Universität genutzten Video-Konferenzlösung Zoom ist es ab sofort möglich, Meetings Ende-zu-Ende (E2EE) zu verschlüsseln.

Benutzer*innen können dieses Feature in den persönlichen Einstellungen auf der Webseite von Zoom unter https://uni-wuppertal.zoom.us/profile/setting selber aktivieren.

Voraussetzungen

  • Der Host muss das Feature aktiviert haben, um ein E2EE Meeting starten zu können und
  • alle Teilnehmer benötigen mind. den Zoom Client in Version 5.4.0.

Einschränkungen

Aus technischen Gründen stehen folgende Funktionen in einem E2EE Meeting nicht zur Verfügung :

  • Beitritt vor Moderator
  • Livestreaming
  • Live-Transkription
  • Konferenzräume / Breakout Rooms
  • Umfragen
  • Zoom Apps
  • Meetingreaktionen*
  • Private Einzelchats*

*Hinweis: Ab Version 5.5.0 für Desktop, Mobile und Zoom Rooms werden diese Funktionen in E2EE-Meetings unterstützt. 

E2EE-Meetings sind auf 200 Teilnehmer begrenzt.

Wie aktiviere ich die Verschlüsselung?

Sie können die Verschlüsselung sehr einfach über die Kontoeinstellungen in Ihrem Zoom Profil aktivieren. Hier finden Sie den Eintrag „Durchgehend verschlüsselte Meetings“, den sie entsprechend einschalten und die „End-to-end encryption“ aktivieren. Bitte beachten Sie, dass diese Einstellungen für ihren persönlichen Meetingraum und für bereits geplante Meetings gegebenenfalls gesondert vorgenommen werden müssen.

Wie kann ich die Verschlüsselung überprüfen?

Wenn in einem Meeting E2EE verwendet, erscheint in der oberen linken Ecke des Bildschirms ein Logo mit einem grünen Schild und einem Vorhängeschloss in der Mitte. Zusätzlich können die Teilnehmer*innen sich den Sicherheitscode anzeigen lassen (Verify/Verifizieren), abgleichen und so überprüfen, ob ihre Clients den gleichen Code benutzen.

Wie funktioniert das?

Wir zitieren den offiziellen Zoom Blog, in dem es heisst:

In einem typischen Meeting generiert die Zoom-Cloud die Encryption Keys und verteilt sie mit Hilfe der Zoom-Apps an die Teilnehmer, sobald sie beitreten. Bei E2EE generiert der Gastgeber die Schlüssel und verteilt diese mithilfe von Public-Key-Kryptographie an die anderen Meeting-Teilnehmer. Die Server von Zoom werden zu „blinden“ Relays (Oblivious Relays) und haben keinerlei Zugriff auf die Schlüssel, die zum Entschlüsseln der Meeting-Inhalte erforderlich sind.

Wie unterscheidet sich E2EE von der erweiterten GCM-Verschlüsselung von Zoom?

Zoom-Meetings und -Webinare verwenden standardmäßig AES-256-Bit-GCM-Verschlüsselung für die Übertragung von Audio- und Videoinhalten sowie gemeinsam genutzten Apps (z. B. Bildschirmfreigabe, Whiteboarding) zwischen Apps, Clients und Connectors. In einem Meeting ohne E2EE-Aktivierung werden Audio- und Videoinhalte, die zwischen den Zoom-Apps der Teilnehmer fließen, erst entschlüsselt, wenn sie die Geräte der Empfänger erreichen. Die Encryption Keys für jedes Meeting werden jedoch von den Zoom-Servern generiert und verwaltet. Bei einem Meeting mit aktivierter E2EE-Funktion hat niemand außer den einzelnen Teilnehmern – auch nicht die Server von Zoom – Zugriff auf die Encryption Keys.

Quelle: https://blog.zoom.us/de/zoom-rolling-out-end-to-end-encryption-offering/

Kategorien
Sicherheit WebTech

Hitch, der TLS Doktor

Ein Einblick tief in den Maschinenraum unserer Webserver – Obacht es wird technisch:

Bis heute wurden fast alle Webseiten der Bergischen Universität über das nicht verschlüsselte Protokoll HTTP ausgeliefert. Nur bei Seiten, welche sensible Daten erheben und von denen wir darüber hinaus Kenntnis hatten, wurden verschlüsselt per HTTPS an die Anwender gebracht. Das ist nun anders – alle Webseiten, welche durch das zentrale CMS TYPO3 ausgeliefert werden und auf eine Domain mit der Endung .uni-wuppertal.de hören, werden standardmäßig verschlüsselt. Siehe hierzu unsere Meldung von Heute.

Damit das funktioniert, haben wir eine neue Software im Einsatz, welche die notwendigen Zertifikate verwaltet und gleichzeitig unseren Webbeschleuniger varnish beliefert: Hitch!

Nicht der Date-Doktor, sondern eher der TLS Doktor. Hitch ist ein sogenannter terminierender SSL-Proxy. Das bedeutet, er nimmt SSL-Verbindungen entgegen, entschlüsselt diese, reicht das ganze weiter an unseren Webproxy varnish, wartet auf Antwort, verschlüsselt diese wieder und liefert die Webseite an den Kunden aus. Hitch ist ein sogenannter “dummer” Proxy, kann also im Gegensatz zu HAProxy keinerlei Manipulationen vornehmen oder gar regelbasiert Unterscheidungen treffen, sondern nur “auspacken-weiterleiten-einpacken-ausliefern” betreiben 😉

Nachfolgend unsere Config dazu, da ist nahezu Standard und nix besonderes:

frontend = {
  host = "*"
  port = "443"
}
backend = "[127.0.0.1]:6086"    # 6086 is the default Varnish PROXY port.
workers = 2                    # number of CPU cores

daemon = on
user = "nobody"
group = "nogroup"
syslog-facility = "daemon"

# Enable to let clients negotiate HTTP/2 with ALPN. (default off)
#alpn-protos = "http/2, http/1.1"

# run Varnish as backend over PROXY; varnishd -a :80 -a localhost:6086,PROXY ..
write-proxy-v2 = on             # Write PROXY header

# List of PEM files, each with key, certificates and dhparams
pem-file = "/path/to/pemfile.pem"

# Which ciphers do we support:
ciphers = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

Hitch lauscht auf 443, leitet intern alles an varnish auf Port 6086 weiter. Dazu verwendet er das PROXY V2 Protokoll. Damit nun alle Seiten der Universität aus TYPO3 verschlüsselt werden, weisen wir varnish an, alle auf Port 80 einkommenden Verbindungen für die Domains, welche auf uni-wuppertal.de enden, auf HTTPS, also Port 443, weiterzuleiten:

import std;

sub vcl_recv {
    if (std.port(local.ip) == 80 && req.http.host ~ "(?i)uni-wuppertal.de$" ) {
        if (req.http.host !~ "^(www.)?(ausnahmen|kommen|hierhin).uni-wuppertal.de$" ) {
            set req.http.x-redir = "https://" + req.http.host + req.url;
            return(synth(301));
        }
    }
}

Hier gibt es allerdings im zweiten if-Statement einen Ausnahmeblock, da wir für einige Domains im Namensraum uni-wuppertal.de derzeit keine Umleitung vornehmen. Diese lassen sich aber an zwei Händen abzählen.
Die eigentliche Umleitung wird dann in sub vcl_synth vorgenommen:

sub vcl_synth {
    if (resp.status == 301) {
        set resp.http.Location = req.http.x-redir;
        return (deliver);
    }
}

Wer also einen leistungsfähigen SSL Proxy benötigt, dem sei der leichtgewichtige Hitch durchaus an’s Herz gelegt. Das er aus dem selben Hause wie varnish kommt, ist für uns natürlich noch ein weiterer Vorteil.

Kategorien
Sicherheit

Cryptomator für Android oder: Private Daten in der Cloud ablegen cont’d

Über die Software cryptomator habe ich ja schon an dieser Stelle geschrieben. Damals hieß es in meinem Artikel, dass

Es existieren Varianten für alle gängigen Betriebssysteme, lediglich für Android ist erst eine frühe Betaversion erschienen. Hier wird aber der Funktionsumfang auch in den nächsten Monaten den Versionen für Windows, OS X oder iOS angeglichen werden.

Das hat sich mittlerweile geändert. So existiert zwar noch kein offizielles Release für Android, aber eine erstaunlich gute Beta-Version derzeit in der Version 0.5. Diese kann nicht nur gängige Clouddienste wie Google Drive oder Onedrive anbinden, sondern auch Sciebo sprechen! Und das geht wie folgt:

Kategorien
Sicherheit

Private Daten in der Cloud ablegen

Kennen wir alle: Wir legen privaten Daten (Bilder, Dokumente etc.) in die Cloud. Laden das bei Dropbox hoch, oder besser, nutzen den Dienst Sciebo. Nun liegen die Daten dort zwar relativ sicher, trotzdem kann theoretisch jeder die Daten einsehen. Sei es der Sciebo-Admin, ein unberechtigter Dritter, der mein Passwort gehackt hat, oder oder oder. Aus diesem Grund dürfen dienstliche Daten mit hohem oder sehr hohem Schutzbedarf dort gar nicht abgelegt werden – bitte hier die Handlungsempfehlung zu Sciebo beachten.

Nun ist Ihr Umgang mit privaten Daten natürlich grundsätzlich Ihnen überlassen. Ich speichere beispielsweise Fotos, die ich mit meinem Smartphone mache, auf Sciebo. Um ein zentrales “Backup” zu haben, damit ich sie nicht Google geben muss und um die Bilder auf verschiedenen Geräten synchron und damit zugreifbar zu halten. Aber ich möchte nicht, dass diese dort im Klartext liegen. Lange Rede, kurzer Sinn: Verschlüsselung muss her! Und da gibt es nun seit einiger Zeit das wirklich gute Tool Cryptomator.

Die Software ist Open Source, wird aktiv weiterentwickelt und ist einfach zu handhaben.

Um unter Windows einen neuen Tresor anzulegen, erstellen Sie einfach einen neuen Ordner in Sciebo, wählen diesen in Cryptomator aus, legen ein sicheres (!) Passwort fest (niemals vergessen, Sie können das nicht wiederherstellen – Ihre Daten wären verloren) und schon bindet die Software Ihnen ein neues Netzlaufwerk ein.

Ansicht Windows ExplorerAuf diesem können Sie nun all ihre sensiblen Daten abspeichern, die Verschlüsselung übernimmt Cryptomator transparent im Hintergrund vor. Innerhalb Ihrers Cloud-Speichers können Sie nun sehen, wie in dem als “Tresor” gekennzeichneten Ordner Ihre Dateien, bzw. deren verschlüsselte Varianten, abgelegt werden. Rückschlüsse auf Dateinamen oder Ordnerstrukturen sind nicht möglich.

Es existieren Varianten für alle gängigen Betriebssysteme, lediglich für Android ist erst eine frühe Betaversion erschienen. Hier wird aber der Funktionsumfang auch in den nächsten Monaten den Versionen für Windows, OS X oder iOS angeglichen werden.