Proxy wirklich nötig?
mlangguth opened this issue · comments
Ich weiß nicht, ob diese Diskussion schon geführt wurde. Wenn ja, gerne Verweis auf die "Protokolle / Notizen" ☺
Ausgelöst durch die Diskussion in der letzten Sprechstunde, dass auf Grund verschlüsselter Kommunikation der Proxy Anforderungen nicht prüfen kann, möchte ich die Frage stellen, wofür wir den Proxy eigentlich zwingend brauchen?
Nach einem Verständnis dient er zwei Zielen:
- Absicherung der "Blase" - nur TIM-eigene Domänen dürfen untereinander timmen (Stufe 1)
- Berechtigungsprüfung Freigabeliste (Stufe 2)
Wenn ich keine weiteren Ziele übersehen habe, dann können beide Ziele mit "Boardmitteln" erreicht werden.
Mir ist nicht bekannt, dass der Bundeswehrmessenger oder die Behördenlösung Frankreichs einen Proxy benötigt, damit die Matrix-Kommunikation ausschließlich in der eigenen Blase stattfindet. Das Filtern auf bekannte TIM-Domänen könnte auch in den Clients und den Homeservern umgesetzt werden. Beide durchlaufen auch das Zulassungsverfahren und können daher Kommunikationseinschränkungen verlässlich durchsetzen.
Hinsichtlich der Berechtigungsprüfung haben wir auch in der letzten Sprechstunde (und über einige Tickets) darüber gesprochen, dass die harte Einschränkung und insbesondere die Vorgabe, dass ein Anfragender vom Angefragten vor der Kontaktaufnahme in eine Whiteliste eingetragen werden muss, den Anwendern nicht zu vermitteln ist.
Eventuell (!!) vom Nutzer gewünschte Einschränkungen der Erreichbarkeit, sollten in account_data gespeichert und durch die Clients durchgesetzt werden, wie dies derzeit bei m.ignored_user_list bereits der Fall ist.
Habe ich ein drittes Ziel übersehen?
Was spricht dagegen, auf den Proxy zu verzichten?
Ausgelöst durch die Diskussion in der letzten Sprechstunde, dass auf Grund verschlüsselter Kommunikation der Proxy Anforderungen nicht prüfen kann
Das stimmt so nicht. Es ist möglich und wir haben das so auch umgesetzt (siehe auch Diskussion hier).
Unabhängig davon stimme ich zu, dass nicht vorgeschrieben werden müsste, wo die Föderationsprüfung stattfindet, da dies in einem Homeserver direkt, aber auch in einem Proxy geschehen kann.
Danke für den Link zur anderen Diskussion. Der dortige Fachaustausch zeitig mir aber, dass es ohne Proxy einfacher ginge... 😉
Kann ja jeder Hersteller für sich entscheiden. Für uns war es keine Woche Arbeit zur Umsetzung (davon größenteils Einarbeitung, was überhaupt benötigt wird).
Ich sehe zwei Probleme:
- Wenn die gematik einen Proxy beschreibt, werden die Prüfer nach einem Proxy schauen. Setzt man es ohne um, produziert das unnötig Aufwand. Da hilft, wenn nur die fachlich/technischen/sicherheitstechnischen Ziele an der Außenschnittelle des Fachdienstes durch die gematik festgelegt würden und so etwas wie ein Proxy dann nur eine Beschreibung einer möglichen Umsetzung wäre
- Das aktuell spezifizierte Berechtigungskonzept welches am Proxy hängt ist fachlich zu eng (siehe anderes Issue)
Eine Umsetzung mit Boardmitteln in Synapse ist meiner Meinung nach in der Form nicht möglich. Ich stimme aber zu, dass einer Umsetzung im Homeserver, zum Beispiel mit einem Plugin in Synapse, durchaus machbar ist, und eine Auslagerung der vorgeschriebenen Prüfungen in einen Proxy nicht notwendig ist.
Hi @benkuly ! Welchen Matrix server nimmt ihr dafür?
Wie bereits @ jcgruenhage beschrieben hat unterstützt der Referenz Matrix-Homeserver die Domainprüfung nicht. In wie weit die Matrix Foundation an einen MSC arbeitet ist uns aktuell nicht bekannt. Weitere Funktionen neben den genannten sind die TLS-Terminierung und die Prüfung auf zugelassene TI-Messenger-Clients.
Kurzer Reminder: Wie bereits angekündigt wird im CR_006 noch eine Anpassung am Server-Server Proxy durchgeführt. Bei der Föderationszugehörigkeit wird am Server-Server Proxy der durch den Matrix-Homeserver hinzugefügte Authorization-Header die "origin" bei eingehender und "destination" bei ausgehender Kommunikation geprüft.
Synapse ist eine "Blackbox" unter der Governance der Matrix Foundation. Der Messenger Proxy setzt gematik Anforderungen zusätzlich zum Matrix-Kern um.
Es wurde uns vor einem Jahr zu Beginn der Entwicklung mitgeteilt, dass es möglich und erlaubt ist, den Messenger Proxy in den Matrix-Server zu integrieren. Aufgrund der obigen Tatsache sehr schwer dauerhaft mit Synapse umsetzbar.
U.a. aus Gründen der Governance, Security und der Wartbarkeit sowie der Erfordernis, Zehntausende von Matrix-Servern für Praxen effizient bereitzustellen haben wir uns vor einiger Zeit entschieden, einen Matrix-Server selbst from scratch zu entwickeln.
Diesen erstellen wir in zwei Varianten:
Ein purer Matrix-Server sowie eine gematik-Variante mit einem Interceptor-Layer für die Messenger-Proxy Funktionalitäten sowie im Kern umgesetzten Regeln der gematik Spezifikation, um auch Fehlkonfigurationen schon im Kern auszuschliessen (keine Gastzugänge, Registrierung von Matrix-Usern auf dem Server nur mit OrgAdmin-Rechten etc.).