Hallo Heiko,
Heiko Schlittermann (Sun, Feb 14, 2021 at 10:55:08PM +0100):
> bert schulze <[email protected]> (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
