Einer der Gründe dafür, dass die IP-Adresse der Instanz nicht im allgemeinen Namen des Serverzertifikats enthalten ist, liegt darin, dass sich diese IPs ändern können. Was heute die IP-Adresse von Instanz A ist, kann morgen die IP-Adresse von Instanz B sein, weil A gelöscht wurde oder A entschieden hat, dass es die IP-Adresse nicht mehr haben möchte. Daher wurde entschieden, dass der Instanzname eine eindeutigere Identifikation der Instanz ist.
Außerdem haben die mysql-Client-Bibliotheken standardmäßig die Überprüfung des Hostnamens deaktiviert. http://dev.mysql.com/doc/refman /5.7/de/ssl-optionen.html
In Bezug auf MITM-Angriffe ist es nicht möglich, eine Cloud SQL-Instanz mit MITM anzugreifen, da das Serverzertifikat und jedes der Clientzertifikate von eindeutigen selbstsignierten Zertifizierungsstellen signiert sind, die niemals zum Signieren von mehr als einem Zertifikat verwendet werden. Der Server vertraut immer nur Zertifikaten, die von einer dieser CAs signiert sind. Der Grund für die Verwendung eindeutiger Zertifizierungsstellen pro Client-Zertifikat war, dass MySQL 5.5 keine Zertifikatsperrlisten unterstützte und wir uns auch nicht mit CRLs befassen wollten, sondern das Löschen von Client-Zertifikaten unterstützen wollten.
Wir werden nach Möglichkeiten suchen, SSL für Clients zu unterstützen, die die Hostnamen-Validierung nicht deaktivieren können. Aber ich kann diesbezüglich keine voraussichtliche Ankunftszeit versprechen.
Cloud SQL-Team.
