Freigeben über

TDS 8.0

  • Artikel

Gilt für: SQL Server 2022 (16.x) Azure SQL-Datenbank Azure SQL Managed Instance

SQL Server 2022 (16.x), Azure SQL-Datenbank und Azure SQL Managed Instance unterstützen Tabular Data Stream (TDS) 8.0.

Das TDS-Protokoll (Tabular Data Stream) ist ein Anwendungsebeneprotokoll, das von Clients zum Herstellen einer Verbindung mit SQL Server verwendet wird. SQL Server verwendet Transport Layer Security (TLS), um Daten zu verschlüsseln, die über ein Netzwerk zwischen einer Instance von SQL Server und einer Clientanwendung übertragen werden.

Der TDS ist ein sicheres Protokoll, aber in früheren Versionen von SQL Server konnte die Verschlüsselung deaktiviert oder nicht aktiviert werden. Um die Standards der obligatorischen Verschlüsselung bei der Verwendung von SQL Server zu erfüllen, wurde eine Iteration des TDS-Protokolls eingeführt: TDS 8.0.

Der TLS-Handshake erfolgt nun vor allen TDS-Nachrichten, um die TDS-Sitzung in TLS zu umschließen und somit die Verschlüsselung zu erzwingen, wodurch TDS 8.0 mit dem HTTPS und anderen Webprotokollen konform ist. Dies trägt wesentlich zur Verwaltbarkeit von TDS-Datenverkehr bei, da Standard-Netzwerkappliances jetzt in der Lage sind, SQL-Abfragen zu filtern und sicher zu übergeben.

Ein weiterer Vorteil von TDS 8.0 im Vergleich zu früheren TDS-Versionen ist die Kompatibilität mit TLS 1.3 und zukünftigen TLS-Standards. TDS 8.0 ist auch vollständig mit TLS 1.2 und früheren TLS-Versionen kompatibel.

Funktionsweise des TDS

Das TDS-Protokoll (Tabular Data Stream) ist ein Anwendungsebenenprotokoll, das für die Übertragung von Anforderungen und Antworten zwischen Clients und Datenbank-Serversystemen verwendet wird. In solchen Systemen richtet der Client in der Regel eine langfristige Verbindung mit dem Server ein. Sobald die Verbindung mithilfe eines Transportebenenprotokolls hergestellt wurde, werden TDS-Nachrichten für die Kommunikation zwischen dem Client und dem Server verwendet.

Die TDS-Sitzungsdauer umfasst drei Phasen:

  • Initialisierung
  • Authentifizierung
  • Datenaustausch

Die Verschlüsselung wird während der ersten Phase ausgehandelt, aber die TDS-Aushandlung erfolgt über eine nicht verschlüsselte Verbindung. Die SQL Server-Verbindung wird bei Versionen vor TDS 8.0 wie folgt hergestellt:

TCP-Handshake ➡️ TDS-Voranmeldung (Klartext) und Antwort (Klartext) ➡️ TLS-Handshake ➡️ Authentifizierung (verschlüsselt) ➡️ Datenaustausch (verschlüsselt oder nicht verschlüsselt)

Mit der Einführung von TDS 8.0 werden die SQL Server-Verbindungen wie folgt hergestellt:

TCP-Handshake ➡️ TLS-Handshake ➡️ TDS-Voranmeldung (verschlüsselt) und Antwort (verschlüsselt) ➡️ Authentifizierung (verschlüsselt) ➡️ Datenaustausch (verschlüsselt)

Strenge Verbindungsverschlüsselung

Um TDS 8.0 nutzen zu können, wurde in SQL Server 2022 (16.x) strict als zusätzlicher Verbindungsverschlüsselungstyp für SQL Server-Treiber (Encrypt=strict) hinzugefügt. Um den strict-Verbindungsverschlüsselungstyp zu verwenden, laden Sie die aktuelle Version der .NET-, ODBC-, OLE DB-, JDBC-, PHP- und Python-Treiber herunter.

Um einen Man-in-the-Middle-Angriff mit strict-Verbindungsverschlüsselung zu verhindern, haben Benutzer*innen nicht die Möglichkeit, die TrustServerCertificate-Option auf true festzulegen und alle beliebigen, vom Server bereitgestellten Zertifikate als vertrauenswürdig einzustufen. Stattdessen verwenden Benutzer*innen die HostNameInCertificate-Option, um das Zertifikat ServerName anzugeben, das vertrauenswürdig sein sollte. Das vom Server bereitgestellte Zertifikat muss die Zertifikatüberprüfung bestehen.

Features, die das Erzwingen strenger Verschlüsselung nicht unterstützen

Die mit TDS 8.0 in der SQL Server-Netzwerkkonfiguration hinzugefügte Option Force Strict Encryption zwingt alle Clients, strict als Verschlüsselungstyp zu verwenden. Clients oder Features ohne die strict Verbindungsverschlüsselung können keine Verbindung mit SQL Server herstellen.

Die folgenden Funktionen oder Tools verwenden noch frühere Versionen von Treibern, die TDS 8.0 nicht unterstützen und funktionieren daher möglicherweise nicht mit der strict-Verbindungsverschlüsselung:

  • Always On-Verfügbarkeitsgruppen
  • Always On-Failoverclusterinstanz (FCI)
  • SQL Server-Replikation
  • Protokollversand
  • sqlcmd-Hilfsprogramm
  • bcp-Hilfsprogramm
  • SQL Server-CEIP-Dienst
  • SQL Server-Agent
  • Datenbank-E-Mail
  • Verbindungsserver
  • Polybase Connector zu SQL Server

Zusätzliche Änderungen an Eigenschaften für die Verbindungszeichenfolgenverschlüsselung

Die folgenden Ergänzungen werden zu Verbindungszeichenfolgen für die Verschlüsselung hinzugefügt:

Schlüsselwort Default Beschreibung
Encrypt false Aktuelles Verhalten

Bei Festlegung auf true verwendet SQL Server die TLS-Verschlüsselung für alle zwischen Client und Server gesendeten Daten, sofern auf dem Server ein Zertifikat installiert ist. Erkannte Werte sind true, false, yes und no. Weitere Informationen finden Sie unter Verbindungszeichenfolgensyntax.

Änderung des Verhaltens

Bei Festlegung auf strict verwendet SQL Server nun TDS 8.0 für alle zwischen dem Client und dem Server gesendeten Daten.

Wenn diese Einstellung auf mandatory, true oder yes festgelegt ist, verwendet SQL Server TDS 7.x mit TLS-/SSL-Verschlüsselung für alle zwischen dem Client und dem Server gesendeten Daten, sofern auf dem Server ein Zertifikat installiert ist.

Bei Festlegung auf optional, false oder no verwendet die Verbindung TDS 7.x und ist nur dann verschlüsselt, wenn SQL Server dies erfordert.
TrustServerCertificate false Aktuelles Verhalten

Bei Festlegung auf true überprüft der Treiber das TLS-/SSL-Serverzertifikat nicht. Bei true wird dem TLS-/SSL-Serverzertifikat automatisch vertraut, wenn die Kommunikationsebene über TLS verschlüsselt ist.

Bei false überprüft der Treiber das TLS-/SSL-Serverzertifikat. Wenn bei der Überprüfung des Serverzertifikats ein Fehler auftritt, löst der Treiber einen Fehler aus und trennt die Verbindung. Der Standardwert ist false. Vergewissern Sie sich, dass der an serverName übergebene Wert für eine erfolgreiche TLS-/SSL-Verbindung exakt dem allgemeinen Namen (Common Name (CN)) oder dem DNS-Namen im alternativen Antragstellernamen (Subject Alternate Name) im Serverzertifikat entspricht.

Verhaltensänderung für Microsoft ODBC-Treiber 18 für SQL Server

Wenn diese Einstellung auf strict Encrypt festgelegt ist, gibt diese Einstellung den Speicherort des Zertifikats an, das für die Serverzertifikatüberprüfung verwendet werden soll (genaue Übereinstimmung). Der Treiber unterstützt die Dateierweiterungen PEM, DER und CER.

Wenn Encrypt die Eigenschaft auf true oder false, und die TrustServerCertificate Eigenschaft nicht angegeben oder auf null, trueoder falsefestgelegt ist, verwendet der Treiber den ServerName Eigenschaftswert für die Verbindungs-URL als Hostname, um das SQL Server TLS/SSL-Zertifikat zu überprüfen.
HostNameInCertificate null Der Hostname, der beim Überprüfen des TLS/SSL-Zertifikats von SQL Server verwendet werden soll. Wenn die HostNameInCertificate Eigenschaft nicht angegeben oder festgelegt nullist, verwendet der Treiber den ServerName Eigenschaftswert als Hostname, um das SQL Server TLS/SSL-Zertifikat zu überprüfen.

Zugehöriger Inhalt