MySQL - zusätzlicher port mit ssl?

Seite 1 von 1 - Forum: Applications, Apps & Drivers auf overclockers.at

URL: https://www.overclockers.at/applications/mysql-zusaetzlicher-port-mit-ssl_254652/page_1 - zur Vollversion wechseln!

Umlüx schrieb am 05.11.2019 um 13:24

ich habe einen standard MySQL server auf Debian im intranet laufen, wo mehrere services daten ablegen und austauschen.
jetzt möchte ich aber mit einem zusätzlichen server per PHP ebenfalls darauf zugreifen dürfen, allerdings solls verschlüsselt sein (firewall wäre dazwischen). ist es möglich, MySQL irgendwie mit einem zweiten port mit ssl zu betreiben?
oder gäbe es eine elegantere lösung dafür?

Punisher schrieb am 05.11.2019 um 13:37

reverse proxy über apache/nginx wär imho die einfachste lösung

(ich rate mal du verwendest mariadb, ist aber für die problemstellung egal)

Umlüx schrieb am 05.11.2019 um 13:57

ok, leider gibts eine planänderung.
aufgrund der vorraussetzungen eines wichtigen internen services der ebenfalls darauf zugreifen muss, muss ich auf MSSQL setzen. wird also wohl ein Windows Server mit SQL-Express werden denke ich.
der rest würde gleich bleiben. die internen services sollen normal und unverschlüsselt zugreifen können, der zusätzliche server aber nur verschlüsselt.

edit: Thrawn meinte, ich soll das ganze einfach per stunnel erledigt. wäre eventuell eine möglichkeit.

GrandAdmiralThrawn schrieb am 06.11.2019 um 15:10

stunnel ist die billige Variante von dem was Punisher vorgeschlagen hat. Hat auch einen kleineren Disk/RAM Footprint.

Allerdings habe ich mir das jetzt nochmal angeschaut, und auch MSSQL unterstützt kein implizites TLS, damit ist stunnel eventuell vom Tisch, weil es keinen initialen Support für das Aushandeln von TLS mit einem MSSQL Server hat, das geht aktuell nur für PostgreSQL. MySQL scheint "irgenwie" auch implizit zu funktionieren, wobei ich nicht weiß ob alle Clients damit klarkommen, weil MySQL TLS normal auch innerhalb einer bereits aufgebauten Klartextverbindung aushandelt.

Das verkompliziert die Lage gegebenenfalls. Im simplen Fall sähe ein stunnel Config auf der Serverseite so aus:

Code:

[mssqls-server]
accept  = 192.168.0.1:1434
connect = 127.0.0.1:1433
cert    = myservercert.pem
key     = myservercert-privatekey.pem

Das klappt nur, falls der Client der verschlüsselt kommunizieren soll implizites TLS kann. Wenn NICHT, brauchst stunnel auf Client und Server. Der Server sähe dann gleich aus wie oben zu sehen, der Client hätte ca. sowas als Config:

Code:

[mssqls-client]
client = yes
accept = 127.0.0.1:1433
connect = 192.168.0.1:1434
verifyChain = no
CAfile = ca-certs.pem

In dem Fall ist das TLS vollends transparent für MSSQL. Du connectest lokal auf 127.0.0.1:1433, und alles schaut aus wie plain SQL. stunnel connected für dich mit implizitem TLS zum Server, dort wird's wieder ausgepackt und plaintext an den MSSQL Server weitergereicht. verifyChain=no hatte ich denke ich drin, weil er sonst wegen der CA's schreit oder so, müßtest testen, ob du das echt brauchst, bzgl Trust...

Hoffe Mal ich habe da jetzt nicht irgendwas vergessen.