TLS und mysql

[ServiceLinuxStart]

Aktuell gegeben:
- Debian 10 Host
- VM1 (Debian 10, apache2, php7.4, mysql/mariadb) mit WP-Seite, externer Zugriff 24/7 über 443.

Hallo,
plane eine VM2 für Datenbanken. Mysql/mariadb wir aus VM1 fliegen und wird mit VM2 über 3306 kommunizieren (mysql).
Meine Frage:
- TLS unbedingt
- TLS eventuell
- TLS nicht notwendig, wenn keine Schnüffler Lokal
- port ändern sinnvoll?

Vielen Dank

[hec_tech]

Das kann man generell nicht sagen.
Verschlüsselung kostet CPU - das sollte man bedenken.
Ich habe meist eigene Netze für sowas wie auch zwischen rev-proxy und application Server.
Ports ändern und sonst noch was halte für absolut sinnbefreit. Ich sehe beim Portscan den anderen Port auch...

[wanne]

Im Zweifelsfall schadet es nie. Wenn du nur mit dir selbst kommunizierst kannst du ja problemlos Self-Signed-Zertifikate nehmen, die die nächsten 100 Jahre halten. Dann hast du nie wieder Ärger mit.
Wenn es wirklich nur über kontrollierte Infrastruktur geht braucht man es eigentlich nicht. Aber gerade bei VMs passiert es ratz fatz, dass die mal in ein anderes RZ umzieht und dann läuft das halt übers Internet.
Google hatte das Problem, dass sie ihr Frontend irgend wann Lastenverteilt über die ganze Welt ausgerollt haben. Die Verbindung zu den backends wurde aber natürlich nicht geändert und blieb ohne TLS.
Aufgefallen ist es durch die Snowden Leaks wo dokumentiert war, wie die NSA an google-Mails drankommt. – Indem sie die zwischen Front und Backend abgreift.
Seither ist da policy, dass aus Prinzip immer verschlüsselt wird.


https://www.sueddeutsche.de/digital/att ... -1.1807864

[wanne]

Verschlüsselung kostet CPU - das sollte man bedenken.

Der hat PHP am laufen...
Ich finde das immer wieder Lächerlich, dass die gleichen Webleute, die http sprechende Revers-Proxys haben, Datenbaken als Backend nehmen und in PHP schreiben am Ende meinen man müsste an der Crypto rum optimieren. Sorry, nein. Das ist einfach nur Lächerlich und macht beim üblichen Websetup irgend was im promillbereich aus.

[hec_tech]

Es ist immer eine Frage der Zugriffe. Wenn du auf jedem Backend 10k Connections hast dann hat der rev-proxy ganz schön was zu tun.
Es hat ja niemand geredet oder gesagt dass Verschlüsselung die CPU komplett auslastet - aber es kostet doch CPU Zeit. Mehr habe ich auch nicht gesagt.

Was stört dich an dem Setup? rev-proxy und dahinter die ganzen Backends. Ich finde das ein optimales Setup - oder wie willst du ohne rev-proxy zwischen den Backends umschalten wenn ein Backend wegbricht?
Wo habe ich irgendwas von PHP geschrieben? Sind meist Java Anwendungen auf den Backends.

[wanne]

Was stört dich an dem Setup? rev-proxy und dahinter die ganzen Backends.

Nichts. Habe das genau so. Ist bequem. Aber eben ineffizient und vor allem Langsam. Du hast zwei http-Verbindungen die du aufrecht erhalten musst und die Latenz fressen.

Ich finde das ein optimales Setup - oder wie willst du ohne rev-proxy zwischen den Backends umschalten wenn ein Backend wegbricht?

Routing anpassen. Z.B mit Pacemaker. Tut weh aber du sparst dir den rev-proxy der Ressourcen frisst und vor allem hast du keinen single-point of failure und damit keinen single-Point, der alle Arbeit abbekommt.

Wenn du auf jedem Backend 10k Connections hast dann hat der rev-proxy ganz schön was zu tun.

Das ist genau das was ich meine: Du hast 20 Server einen verschenkst du für ein vollständig unnötiges Frontend, dass nur der Bequemlichkeit dient. Und dann meckerst du dass auf der Komponente die du nur zur Bequemlichkeit eingeführt hast, die Last zu hoch ist und killst dafür die Crypto. WTF!
Oder anders gesagt: Üblicherweise frisst auch bei Java-Backends die Crypto deutlich weniger als 1% der Leistung. Das liegt btw. nicht daran, dass das die wenigste Arbeit ist, sondern dass der Code halt vernünftig optimiert ist. Selbst ohne Hardware Support schafft jede crypot lib ~1GBit/s pro Core. Noch nie irgend eine Webanwendung gesehen, die das macht. Obwohl die meist nur immer die selben Strings zusammenkleistern. Aber das ist völlig unproblematisch. Blech ist billiger als Arbeitszeit! Das einzige wo Webentwickler optimieren wollten ist genau an diesem einen % zu Lasten der Sicherheit da ist dann plötzlich Blech gaaaaaaz teuer.

Schon wenn du deinen haproxy auf tcp statt http stellst (und dann musst du zum Backend TLS fahren) hast du um Größenordnungen mehr Performancegewinn wie wenn du die Crypto raus schmeißt. Aber sowas ist absolut unmöglich, weil defakto jede Anwendung ausreichend unvollständig ist, dass man nochmal nachträglich irgend welche Header setzen muss und ausreichend kaputt, dass man sie kein TLS nach draußen sprechen lasen will. Aber keine Chance das zu fixen. Lieber nochmal an 5 Stellen die Crypto raus optimieren.

[ServiceLinuxStart]

Herzlichen Dank. Man lernt hier wahnsinnig viel