Verbindung zu Amazon RDS mit TLSv1.2 nicht möglich

Verbindung zu Amazon RDS mit TLSv1.2 nicht möglich

Ich habe eine neue Maschine mit Ubuntu 20 eingerichtet und festgestellt, dass ich keine Verbindung mehr zu meinen RDS-Datenbanken herstellen konnte.

Die Spring-Boot-Anwendung, die eine Verbindung mit der Entwicklungsumgebung herstellen sollte, löst die folgende Ausnahme aus:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Also habe ich mySql Workbench ausgegraben und es damit versucht. Das Ergebnis war dieser Fehler:
ssl_choose_client_version:unsupported protocol

Bei der Suche danach erfuhr ich, dass bei Ubuntu 20 TLSv1.2 als Mindest-TLS-Version eingestellt war und dass dieser Fehler auftritt, wenn Ihr MySQL-Server dies nicht unterstützt (von hier:https://askubuntu.com/questions/1193629/warum-geht-mysql-workbench-8-x-errors-out-with-an-ssl-connection-error-choose-client-v). Ich habe Workbench bei deaktiviertem SSL ausprobiert und tatsächlich konnte die Verbindung hergestellt werden.

Das offensichtliche Problem dabei ist, dass es sich um Amazon RDS handelt. TLS 1.2 ist die einzige Version, diekippendeaktiviert werden, da es sich um die intern verwendete Version handelt, wie hier erläutert:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Ciphers.html

Eigentlich sollte es also kein Problem geben. Ich begann zu zweifeln, ob die TLS-Version wirklich das Problem war. Da ich aber keine anderen Hinweise hatte, folgte ich dem Kochbuch in der Antwort hier, um mein lokales OpenSSL so neu zu konfigurieren, dass mindestens TLS Version 1 zulässig ist, und stufte die Sicherheitsstufe herab:https://askubuntu.com/questions/1233186/ubuntu-20-04-wie-man-einen-niedrigeren-ssl-sicherheitslevel-einstellt

Und wer hätte das gedacht? Workbench ist jetzt verbunden und SSL ist auf erforderlich eingestellt. Spring-Boot tut das immer noch nicht. Ich schätze, ich muss das irgendwo anders konfigurieren, damit es das Memo bekommt. Aber anstatt Zeit damit zu verschwenden, würde ich lieber das Problem lösen.realProblem, nämlich dass ich keine Verbindung über TLSv1.2 herstellen kann, obwohl ich das eigentlich können sollte. Das wäre einer Herabstufung meiner Sicherheit weit vorzuziehen. Ich habe versucht, das Datenbankzertifikat zu erneuern, falls das das Problem sein könnte, aber die Verwaltungskonsole hat nichts Falsches am Zertifikat gefunden und lässt mich es anscheinend nicht ersetzen, wenn es nicht nötig ist. Mir gehen also die Ideen aus, was ich als Nächstes versuchen könnte.

Antwort1

Es stellte sich heraus, dass die TLS-Unterstützung von der genauen Version der Datenbank-Engine abhängt, die Sie auf RDS verwenden. Aurora mySQL 5.6 unterstützt TLSv1.0 nur bis Version 1.23.1, ab diesem Zeitpunkt sind TLSv1.1 und 1.2 verfügbar. Unsere Version war 1.22.irgendwas, also musste ich die Engine aktualisieren.

Sogar dannes wird jedoch nicht funktionieren, da Ubuntu 20 auch eine minimale DHE-Schlüssellänge von 2048 Bits erzwingt, die Aurora mysql 5.6 einfach nicht liefert, und soweit ich das beurteilen kann, kann dies nicht geändert werden. Sie finden Dokumentationen für Datenbankparameter, mit denen die Diffie-Hellman-Schlüssellänge geändert werden kann, aber es stellt sich heraus, dass diese nur für SqlServer gelten, nicht für MySQL. Sie müssen also immer noch Änderungen an Ihrer openssl.cnf vornehmen, wie in der akzeptierten Antwort hier beschrieben:https://askubuntu.com/questions/1233186/ubuntu-20-04-wie-man-einen-niedrigeren-ssl-sicherheitslevel-einstellt Dadurch wird Ihr SECLEVEL auf 1 geändert, sodass OpenSSL die kürzeren DHE-Schlüssel akzeptiert.

Sogar dannmeine Spring-Boot-Anwendungen konnten keine Verbindung herstellen, obwohl Workbench jetzt funktionierte. Das liegt daran, dass JDBC dem Server nicht mitteilt, dass es TLSv1.2 ausführen kann.obwohl es durchaus(das war eine komische Entscheidung), daher wird der Server nie versuchen, einen 1.2-Handshake zu senden, selbst wenn er könnte.

Um JDBC anzuweisen, tatsächlich TLSv1.2 zu verwenden, müssen Sie es an die Verbindungszeichenfolge anhängen:

jdbc:myslq://<host>/<db>?enabledTLSProtocols=TLSv1.2

Jetzt passt alles zusammen.

Ich hätte Aurora gerne dazu gebracht, einen längeren Schlüssel zu liefern, anstatt die Sicherheit von Ubuntu zu verringern, aber das scheint nicht möglich zu sein. Wenn jemand einen kennt, lassen Sie es mich bitte wissen.

verwandte Informationen