Hallo Liste,
oder bei diesem Thema auch speziell an H.S. gerichtet…
Soweit RTFM mir geholfen hat besteht momentan keine Mögichkeit einen Exim4-Server mit einer Remote-SQL Datenbank zu koppeln und dabei eine TLS verschlüsselte Verbindung zu nutzen?!
Auch wenn die Abfagen gegen die Datenbank - im besten Fall - am Ende SHA512 Hashes mit 8-16 Byte Salz im Format $6$<SALZ>$HASH ausliefern, würde ich dieses Feature, für *paranoide* Nutzer als begrüßenswert erachten.
Wie groß wäre der Aufwand eine tls_mysql_servers Direktive zu implementieren und wenn niemand darauf Lust haben sollte, gibt es irgendwo eine Dokumentation für den Einstieg zu diesem Thema?
Danke, Gruß Bert
Hallo Bert,
bert schulze bs@bescit.de (Fr 12 Feb 2021 18:55:28 CET):
oder bei diesem Thema auch speziell an H.S. gerichtet…
Soweit RTFM mir geholfen hat besteht momentan keine Mögichkeit einen Exim4-Server mit einer Remote-SQL Datenbank zu koppeln und dabei eine TLS verschlüsselte Verbindung zu nutzen?!
Hm. Der Exim verwendet ganz normal die Mysql Client libraries. Soweit ich auf https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html verstanden habe, müsste mit ein, zwei weiteren Funktionsaufrufen auch eine Verbindung per TLS möglich sein.
Ein Workaround wäre sicher ein SOCAT Tunnel oder etwas ähnliches.
Wie groß wäre der Aufwand eine tls_mysql_servers Direktive zu implementieren und wenn niemand darauf Lust haben sollte, gibt es irgendwo eine Dokumentation für den Einstieg zu diesem Thema?
Ob als extra Direktive, oder in die mysql_servers option mit eingebaut, liesse sich noch diskutieren.
Vielleicht
mysql_servers = <; [tls://]localhost[:port]/DB/User/Passwort
Aber hm. Aufwand? 3600€. Oder wie meinst Du die Frage?
Wenn Du das selbst machen möchtest, gib Bescheid, ich unterstütze Dich gerne dabei.
Hallo Heiko,
Heiko Schlittermann (Fri, Feb 12, 2021 at 10:21:49PM +0100):
Hallo Bert,
bert schulze bs@bescit.de (Fr 12 Feb 2021 18:55:28 CET):
Hm. Der Exim verwendet ganz normal die Mysql Client libraries. Soweit ich auf https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html verstanden habe, müsste mit ein, zwei weiteren Funktionsaufrufen auch eine Verbindung per TLS möglich sein.
Das ist shonmal ein hilfreicher Startpunkt.
https://dev.mysql.com/doc/c-api/8.0/en/c-api-encrypted-connections.html
Wenn ein Aufruf von mysql_options() nach _init() und vor _connect() reicht, klingt das zunächst akzeptabel…
Ab 5.6.36 kann man MYSQL_OPT_SSL_MODE mit SSL_MODE_REQUIRED versehen und eine verschlüsselte Verbindung erzwingen, für Versionen davor ist es notwendig nach _connect() via mysql_get_ssl_cipher() zu prüfen ob eine verschlüsselte Verbindung ausgehandelt wurde.
Debian nutzt den MariaDB Fork, hier keine Spur von MYSQL_OPT_SSL_MODE zu finden, also wohl auch die Strategie mysql_get_ssl_cipher() prüfen.
https://mariadb.com/kb/en/mysql_optionsv/
(Weiter geht es unten).
Ein Workaround wäre sicher ein SOCAT Tunnel oder etwas ähnliches.
An ssh -NL localhost:3306:localhost:3306 mittels pubkey auth hatte ich auch schon gedacht, aber ja das ist wieder manueller Aufwand und ein weiteres vermeidbares Scheunentor.
Ob als extra Direktive, oder in die mysql_servers option mit eingebaut, liesse sich noch diskutieren.
Vielleicht
mysql_servers = <; [tls://]localhost[:port]/DB/User/Passwort
Das würde dann das Verhalten implizieren TLS zu erzwingen wenn tls:// als Protokoll angegeben wurde und darauf bestehen verschlüsselt zu kommuizieren?
Ich spinne mal weiter: Wir haben den UseCase das sowohl SQL als auch MTA in einem vertrauenswürdigem Netz betrieben werden, dann ist diese Option vollkommen OK.
Was aber wenn die Verbindung durch ein nicht vertrauenswürdiges Netz geroutet werden muss und es einen potentiellen MITM geben könnte?
Hier geht es dann weiter und man müsste mindestens prüfen ob das Server Zertifikat durch eine vertrauenswürdige CA ausgestellt wurde (und ggf. noch nicht revoked). Dafür brauchen wir:
MYSQL_OPT_SSL_CA || MYSQL_OPT_SSL_CAPATH MYSQL_OPT_SSL_CRL || MYSQL_OPT_SSL_CRLPATH
Worauf ich hinaus will: mit mysql_servers ist es bestimmt nicht getan.
tls_mysql_servers // für den connection string tls_mysql_servers_verify // default true, anderenfalls fallback unencrypted
tls_mysql_servers_ca // füttert CA PEM oder Pfad zu CA PEM(s)
Wie funktioniert das prüfen der Revocation Informationen? Kann hier bestehende Funktionalität von Exim4 verwendet werden?
Jetzt kommen noch die *paranoiden* Nutzer, die darauf bestehen ein Client Zertifikat zu nutzen:
MYSQL_OPT_SSL_CERT && MYSQL_OPT_SSL_KEY
tls_mysql_certificate // Pfad zum PEM Zertifikat tls_mysql_privatekay // Pfad zum PEM Zertifikat
Und das Sahnehäubchen, die Auswahl der zu nutzenden Cipher Suites
MYSQL_OPT_SSL_CIPHER
tls_mysql_require_ciphers
Was wiederum je nach Verwendung von GnuTLS oder openssl als Priority oder in der openssl Syntax erfolgen muss.
Aber hm. Aufwand? 3600€. Oder wie meinst Du die Frage?
Denke die Ausführungen erklären was ich meinte, es ging mir darum wie dreckig man sich die Finger machen müsste:)
Wenn Du das selbst machen möchtest, gib Bescheid, ich unterstütze Dich gerne dabei.
Zunächst habe ich mir mal darüber Gedanken gemacht, je nachdem wie komplex die Geschichte werden soll, würde ich mich daran beteiligen.
-- Heiko
Gruß Bert
Hallo Bert, noch ein paar weitere unsortierte Gedanken:
- Vewenden die MySQL/MariaDB Libraries nicht auch Konfigurationsfiles (mehr oder weniger implizit), in denen man dann solche Dinge erledigen könnte?
- Möchte MariaDB nicht API-kompatibel zu MySQL sein? Exim behandelt aktuell beide Libraries gleich (bis auf etwas Magie zum ermitteln der aktuellen Version, da gab es wohl unterschiedliche Defines in den beiden Libs)
An ssh -NL localhost:3306:localhost:3306 mittels pubkey auth hatte ich auch schon gedacht, aber ja das ist wieder manueller Aufwand und ein weiteres vermeidbares Scheunentor.
Na, als Scheunentor würde ich einen SSH-Tunnel jetzt nicht bezeichnen, aber Aufwand, ja, das wäre es.
Vielleicht mysql_servers = <; [tls://]localhost[:port]/DB/User/Passwort
Das würde dann das Verhalten implizieren TLS zu erzwingen wenn tls:// als Protokoll angegeben wurde und darauf bestehen verschlüsselt zu kommuizieren?
So war der Gedanke. Aber wie Du selbst weiter unten ausführst, wird es schnell unübersichtlich, wenn man da noch weitere Optionen mit einbauen möchte (CA, Client-Cert, Ciphers, …)
Hier geht es dann weiter und man müsste mindestens prüfen ob das Server Zertifikat durch eine vertrauenswürdige CA ausgestellt wurde (und ggf. noch nicht revoked). Dafür brauchen wir:
MYSQL_OPT_SSL_CA || MYSQL_OPT_SSL_CAPATH MYSQL_OPT_SSL_CRL || MYSQL_OPT_SSL_CRLPATH
Worauf ich hinaus will: mit mysql_servers ist es bestimmt nicht getan.
Full Ack.
tls_mysql_servers // für den connection string tls_mysql_servers_verify // default true, anderenfalls fallback unencrypted
Na, aber z.B. kann man den MySQL-Server auch direkt beim Lookup mitgeben
… = ${lookup mysql,servers=… {SELECT ...}} und ich glaube, auch so: … = mysql,servers=…;SELECT ...
Es wäre also gut, wenn man alle erforderliche Information in *einen* String bekäme.
mysql_servers = host[:port]/db/user/password/tls=required,ca=…,
Dann gäbe es nur ein Problem, wenn das Passwort einen Slash enthält, aber ich denke, das Problem haben wir jetzt schon (habe jetzt nicht in den Sourcen nachgeschaut, ob wir das mit Quting oder Escaping umgehen könnten.
Wenn also alle erforderliche Info in einem String steckt, könnten wir das auch problemlos bei der expliziten Verwendung unterbringen. Wird natürlich dann nicht mehr schön
… = ${lookup mysql,servers=localhost/db/user/password/tls=required,ca=…{SELECT …}}
Aber wir haben ja Macros.
Zur Zertifikatsprüfung: Ich würde jetzt mal unterstellen, dass die MySQL libs sich da mit irgendwelchen dazugenommen TLS libs auch selbst kümmern, oder? Wenn man an die Verbindungsdetails dran kommt, könnte man aber sicher auch Zertifikats-Prüfungs-Funktionen nutzen, die der Exim schon bringt (wobei auch der m.W. sich dort auf GnuTLS bzw. OpenSSL verlässt).
Denke die Ausführungen erklären was ich meinte, es ging mir darum wie dreckig man sich die Finger machen müsste:)
Ich glaube, es wird nicht soo schlimm.
Wenn Du das selbst machen möchtest, gib Bescheid, ich unterstütze Dich gerne dabei.
Zunächst habe ich mir mal darüber Gedanken gemacht, je nachdem wie komplex die Geschichte werden soll, würde ich mich daran beteiligen.
Es würde mich freuen. Pro-Tip: Wir können Leute gebrauchen, die sich gerne an OpenSource beteiligen.
Hallo Heiko,
Heiko Schlittermann (Sat, Feb 13, 2021 at 12:32:14PM +0100):
Hallo Bert, noch ein paar weitere unsortierte Gedanken:
- Vewenden die MySQL/MariaDB Libraries nicht auch Konfigurationsfiles (mehr oder weniger implizit), in denen man dann solche Dinge erledigen könnte?
Die Konfigurationsfiles stecken in den mariadb-server und mariadb-client Paketen, exim4-daemon-heavy hat nur ein Depends: libmariadb3.
- Möchte MariaDB nicht API-kompatibel zu MySQL sein? Exim behandelt aktuell beide Libraries gleich (bis auf etwas Magie zum ermitteln der aktuellen Version, da gab es wohl unterschiedliche Defines in den beiden Libs)
Anscheinend nicht ;) Die nutzen auch eine mysql_optionsv() Methode anstelle der mysql_options(). Und ja das Versionsschema ist schräg.
Vielleicht mysql_servers = <; [tls://]localhost[:port]/DB/User/Passwort
Das würde dann das Verhalten implizieren TLS zu erzwingen wenn tls:// als Protokoll angegeben wurde und darauf bestehen verschlüsselt zu kommuizieren?
So war der Gedanke. Aber wie Du selbst weiter unten ausführst, wird es schnell unübersichtlich, wenn man da noch weitere Optionen mit einbauen möchte (CA, Client-Cert, Ciphers, …)
Dann lege ich mal vor (siehe Patch im Anhang).
Folgende Umstände sind derzeit zu beachten:
- Connection String wird von links nach rechts geparsed und es werden 4 Argumente erwartet: Host Datenbank Username Passwort.
- Das Passwort mag auch Slashes enthalten, es wird einfach der Rest des Strings nach dem 3. Slash verwendet
- Doppelpunkte! Kann man nicht verwenden, der String aus der Konfiguration in "mysql_servers" ist komplett, als "server" in perform_mysql_search() kommt dann nur ein Substring bis zum ersten ":" an. (habe nicht in lf_sqlperform() geschaut, aber vermute das dort ein bisschen zuviel santized wird).
Ich gehe davon aus, dass ein Passwort mit ":" nicht funktioniert:)
Also tls:// ist eine schlechte Idee. Habe jetzt die Syntax auf tls@host definiert (finde ich lesbar: verbinde mit host via tls.)
Das sollte auch nicht zu Irritationen führen, man 7 hostname:
"Valid characters for hostnames are ASCII(7) letters from a to z, the digits from 0 to 9, and the hyphen (-)."
Hier geht es dann weiter und man müsste mindestens prüfen ob das Server Zertifikat durch eine vertrauenswürdige CA ausgestellt wurde (und ggf. noch nicht revoked). Dafür brauchen wir:
MYSQL_OPT_SSL_CA || MYSQL_OPT_SSL_CAPATH MYSQL_OPT_SSL_CRL || MYSQL_OPT_SSL_CRLPATH
Worauf ich hinaus will: mit mysql_servers ist es bestimmt nicht getan.
Full Ack.
tls_mysql_servers // für den connection String tls_mysql_servers_verify // default true, anderenfalls fallback unencrypted
Na, aber z.B. kann man den MySQL-Server auch direkt beim Lookup mitgeben
… = ${lookup mysql,servers=… {SELECT ...}}und ich glaube, auch so: … = mysql,servers=…;SELECT ...
Es wäre also gut, wenn man alle erforderliche Information in *einen* String bekäme.
mysql_servers = host[:port]/db/user/password/tls=required,ca=…,
Das wäre jetzt "mysql_servers = [tls@]host[:port]/db/user/password"
Dann gäbe es nur ein Problem, wenn das Passwort einen Slash enthält, aber ich denke, das Problem haben wir jetzt schon (habe jetzt nicht in den Sourcen nachgeschaut, ob wir das mit Quting oder Escaping umgehen könnten.
Das Problem würde sich erst ergeben, wenn man die TLS Optionen als 5. Argument einführen möchte und dann muss man die bisherige Logik unnötig verkomplizieren.
Wenn also alle erforderliche Info in einem String steckt, könnten wir das auch problemlos bei der expliziten Verwendung unterbringen. Wird natürlich dann nicht mehr schön
… = ${lookup mysql,servers=localhost/db/user/password/tls=required,ca=…{SELECT …}}
Sollte auch mit "…,servers=[tls@]host[:port]/db/user/password" klappen.
Aber wir haben ja Macros.
Zur Zertifikatsprüfung: Ich würde jetzt mal unterstellen, dass die MySQL libs sich da mit irgendwelchen dazugenommen TLS libs auch selbst kümmern, oder? Wenn man an die Verbindungsdetails dran kommt, könnte man aber sicher auch Zertifikats-Prüfungs-Funktionen nutzen, die der Exim schon bringt (wobei auch der m.W. sich dort auf GnuTLS bzw. OpenSSL verlässt).
Habe bisher nur ein Standard dpkg-buildpackage -uc -us mit GnuTLS getestet.
07:34:32 10541 MYSQL new connection: host=localhost port=0 socket=NULL database=mail user=mail 07:34:32 10541 GnuTLS<3>: ASSERT: ../../../lib/x509/common.c[_gnutls_x509_get_raw_field2]:1575 […] 07:34:32 10541 GnuTLS<2>: issuer in verification was not found or insecure; trying against trust list […] 07:34:32 10541 MYSQL connection: TLS negotiated cipher is DHE-RSA-AES256-SHA
Abgesehen von der "issuer in verification was not found or insecure" Meldung passiert hier erstmal nichts an Verifikation. Hier müsste man also Hand anlegen und schauen wie das in den transports mit host_require_tls funktioniert.
Denke die Ausführungen erklären was ich meinte, es ging mir darum wie dreckig man sich die Finger machen müsste:)
Ich glaube, es wird nicht soo schlimm.
Ja Hände waschen mit Seife hat zunächst gereicht;)
-- Heiko
Gruß Bert
bert schulze bs@bescit.de (So 14 Feb 2021 09:12:18 CET):
Hallo Heiko,
Heiko Schlittermann (Sat, Feb 13, 2021 at 12:32:14PM +0100):
Hallo Bert, noch ein paar weitere unsortierte Gedanken:
- Vewenden die MySQL/MariaDB Libraries nicht auch Konfigurationsfiles (mehr oder weniger implizit), in denen man dann solche Dinge erledigen könnte?
Die Konfigurationsfiles stecken in den mariadb-server und mariadb-client Paketen, exim4-daemon-heavy hat nur ein Depends: libmariadb3.
Na, aber es wäre ja trotzdem denkbar, dass diese Libraries auch die Configfiles lesen, wenn sie vorhanden sind. Noch weiss ich nicht, ob ich das eher gut oder schlecht finden sollte.
Bei LDAP, wo die Client-Libraries, die der Exim verwendet, dann _anscheinend_ auch gerne mal in der `ldap.conf` nachsehen (ohne das das im Exim explizit erwähnt würde), hat es mich schon geärgert, dass so magische-hinter-dem-Rücken-Abhängigkeiten da sind. Anderseits ist es aber auch cool, systemweit festlegen zu können, wie sich die diversen Clients an diversen Stellen verhalten.
Gut, aber das ist jetzt nicht der Diskussionspunkt.
- Möchte MariaDB nicht API-kompatibel zu MySQL sein? Exim behandelt aktuell beide Libraries gleich (bis auf etwas Magie zum ermitteln der aktuellen Version, da gab es wohl unterschiedliche Defines in den beiden Libs)
Anscheinend nicht ;) Die nutzen auch eine mysql_optionsv() Methode anstelle der mysql_options(). Und ja das Versionsschema ist schräg.
Dann lege ich mal vor (siehe Patch im Anhang).
Der patched mit etwas Fuzz und läßt sich mit den letzten Committs des Master-Branches sogar problemlos übersetzen. Danke.
Folgende Umstände sind derzeit zu beachten:
Connection String wird von links nach rechts geparsed und es werden 4 Argumente erwartet: Host Datenbank Username Passwort.
Das Passwort mag auch Slashes enthalten, es wird einfach der Rest des Strings nach dem 3. Slash verwendet
Doppelpunkte! Kann man nicht verwenden, der String aus der Konfiguration in "mysql_servers" ist komplett, als "server" in perform_mysql_search() kommt dann nur ein Substring bis zum ersten ":" an. (habe nicht in lf_sqlperform() geschaut, aber vermute das dort ein bisschen zuviel santized wird).
Ja, weil das diese Option als Liste von Servern geparsed wird, wo der Doppelpunkt per Default (aber änderbar) als Trenner verwendet wird.
Ich gehe davon aus, dass ein Passwort mit ":" nicht funktioniert:)Also tls:// ist eine schlechte Idee. Habe jetzt die Syntax auf tls@host definiert (finde ich lesbar: verbinde mit host via tls.)
Ich gucke mir mal an, wie das jetzt funktioniert. Danke schon mal.
Hallo Heiko,
Heiko Schlittermann (Sun, Feb 14, 2021 at 10:55:08PM +0100):
bert schulze bs@bescit.de (So 14 Feb 2021 09:12:18 CET):
Na, aber es wäre ja trotzdem denkbar, dass diese Libraries auch die Configfiles lesen, wenn sie vorhanden sind. Noch weiss ich nicht, ob ich das eher gut oder schlecht finden sollte.
Denke ich eher nicht. (Ich bin ein Freund die Dienste sauber zu trennen, bei mir läuft der Exim in einem LXC Container der mit debootstrap --varaint minbase installiert ist und in der apt.conf sowohl Recommends, als auch Suggests deaktiviert. Kann mir nicht vorstellen dort einen SQL Client zu installieren).
Bei LDAP, wo die Client-Libraries, die der Exim verwendet, dann _anscheinend_ auch gerne mal in der `ldap.conf` nachsehen (ohne das das im Exim explizit erwähnt würde), hat es mich schon geärgert, dass so magische-hinter-dem-Rücken-Abhängigkeiten da sind. Anderseits ist es aber auch cool, systemweit festlegen zu können, wie sich die diversen Clients an diversen Stellen verhalten.
Gut, aber das ist jetzt nicht der Diskussionspunkt.
Nur so so als Gedanke, wir haben schon jetzt MariaDB und MySQL (dann wären da noch postgres und evtl. Oracle).
Die Konfigurationsdateien haben keinen eindeutigen Pfad, liegen entweder in /etc/mysql/mariadb.conf.d oder /etc/mysql/mysql.conf.d. In Debian werden die als 50-{client|server}.cnf benannt. Andere Distris mögen andere Pfade nutzen oder gleich eine einzelne my.cnf nehmen und die Konfiguration in [server] und [client] Sections stellen.
Dann sind die Optionen wieder davon abhängig ob jetzt OpenSSL, GnuTLS, YaSSL oder wolfSSL gelinkt wurde…
Der patched mit etwas Fuzz und läßt sich mit den letzten Committs des Master-Branches sogar problemlos übersetzen. Danke.
Soll ich gegen https://git.exim.org/exim.git/shortlog/refs/heads/master weiter arbeiten?
Ja, weil das diese Option als Liste von Servern geparsed wird, wo der Doppelpunkt per Default (aber änderbar) als Trenner verwendet wird.
Ok, das war dann die "<;" Syntax, die ich nie verwenden musste :)
Ich gucke mir mal an, wie das jetzt funktioniert. Danke schon mal.
Bei vorhander Langeweile, würde ich weitermachen und (für MariaDB / MySQL) den gemeinsamen Nenner bezüglich Validierung von CA und Client Zertifikaten einpflegen.
Der Plan ist folgende Konfigurations Direktiven mit String Expansion einzuführen:
sql_tls_ca_cert = /pfad/zum/${sql_host}/ca.pem sql_tls_cert = /pfad/zum/${sql_host}/${sql_db}/${sql_user}-cert.pem sql_tls_key = /pfad/zum/${sql_host}/${sql_db}/${sql_user}-key.pem
Der prefix sql_* weil das für LOOKUPS_MYSQL / PGSQL und ORACLE nutzbar werden kann.
Die 3 Variablen müssen in den entsprechenden perform_*_search() Methoden befüttert werden.
Die Datenbankverbindung wird nur einmal wenn notwendig aufgebaut und dann mittels key "tls@host/db/user" gecached, damit funktioniert dann auch die explizite "mysql_servers =" und implizite "inline" Variante.
Die Konfiguration von MariaDB und MySQL ist komplett auseinander gedriftet. In MariaDB gibt es z.B. MYSQ_OPT_SSL_VERIFY_SERVER_CERT als einzelne Option um den Host gegen CN/SAN des Server Zertifikats zu validieren egal ob ich ein CA Zertifikat angebe oder nicht.
Bei MySQL wurde diese entfernt und durch MYSQL_OPT_SSL_MODE ersetzt.
SSL_MODE_REQUIRED // wie jetzt umgesetzt => TLS erzwingen SSL_MODE_VERIFY_CA // wie REQUIRED nur + CA Zertifikat prüfen SSL_MODE_VERIFY_IDENTITY // wie CA + Subject CN/SAN prüfen
Würde entsprechend wenn: "sql_tls_ca_cert" gesetzt ist für MariaDB auch VERIFY_SERVER_CERT aktivieren und bei MySQL dann auch gleich SSL_MODE_VERIFY_IDENTITY verwenden.
Client Zertifikate werden per User auf dem *SQL Server mittels "ALTER USER [..] REQUIRE SUBJECT 'cn=client…'" konfiguriert.
Das ist auch der Grund die "sql_tls_cert/key" Konfiguration granular bis zur Verwendung der ${sql_user} Variable zu gestalten.
In der *SQL Dokumentation wird von "one way/two way" TLS gesprochen, entsprechend bauen die Direktiven dann aufeinander auf:
- Wenn keine der "sql_tls_*" Optionen angegeben ist, wird nur eine eine TLS-Verbindung erzwungen.
- Wenn "sql_tls_cert/key" angegeben, muss auch "sql_tls_ca_cert" gesetzt sein.
Hast du Einwände, Kommentare, Verbessungsvorschläge?
-- Heiko
Gruß Bert
Am 13.02.21 um 10:04 schrieb bert schulze:
An ssh -NL localhost:3306:localhost:3306 mittels pubkey auth hatte ich auch schon gedacht, aber ja das ist wieder manueller Aufwand und ein weiteres vermeidbares Scheunentor.
Ich würde sagen, dass das gar nicht funktioniert, wenn MySQL/MariaDB auf 3306 hört, kann auch SSH dort nicht lauschen. Du müsstest also mindestens den Port ändern.
Warum willst Du Dich nicht mit der Datenbank über Unix Domain Sockets verbinden, wenn es dieselbe Maschine ist? Kann man den Sockets nicht sogar Berechtigungen mitgeben, so dass nur nur bestimmte Nutzer/Gruppen verbinden können?
Hallo Tobias,
Tobias Schlemmer (Sat, Feb 13, 2021 at 11:47:21PM +0100):
Am 13.02.21 um 10:04 schrieb bert schulze:
Ich würde sagen, dass das gar nicht funktioniert, wenn MySQL/MariaDB auf 3306 hört, kann auch SSH dort nicht lauschen. Du müsstest also mindestens den Port ändern.
Oder eben das Prinzip von STARTTLS aufgreifen, die Verbindung in plaintext inititieren und ein Upgrade auf TLS vollziehen (wie z.B. hier beschrieben https://testssl.sh/).
Warum willst Du Dich nicht mit der Datenbank über Unix Domain Sockets verbinden, wenn es dieselbe Maschine ist? Kann man den Sockets nicht sogar Berechtigungen mitgeben, so dass nur nur bestimmte Nutzer/Gruppen verbinden können?
Ich hatte die UseCases genannt und von vertrauenswürdigen und nicht vertrauenswürdigen Netzen zwischen SQL-Server und MTA gesprochen. Damit sind die Sockets außen vor und außerdem möchte ich nicht manuell eingreifen wenn mal der eine oder andere Server gebootet wird.
Gruß Bert
bert schulze (Sun, Feb 14, 2021 at 08:33:46AM +0100):
Hallo Tobias,
Tobias Schlemmer (Sat, Feb 13, 2021 at 11:47:21PM +0100):
Am 13.02.21 um 10:04 schrieb bert schulze:
Ich würde sagen, dass das gar nicht funktioniert, wenn MySQL/MariaDB auf 3306 hört, kann auch SSH dort nicht lauschen. Du müsstest also mindestens den Port ändern.
Oder eben das Prinzip von STARTTLS aufgreifen, die Verbindung in plaintext inititieren und ein Upgrade auf TLS vollziehen (wie z.B. hier beschrieben https://testssl.sh/).
Jetzt war ich falsch abgebogen. Die Server sind nicht auf dem gleichen Host. Wenn Sie das sind, dann in einem Container oder VM mit virtuellem Interface und dann hat der Tunneleingang natürlich auch einen freien 3306 Port zum lauschen.
Gruß Bert
lug-dd@mailman.schlittermann.de
-
bert schulze -
Heiko Schlittermann -
Tobias Schlemmer