Dela via

TDS 8.0

gäller för: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

SQL Server 2022 (16.x), Azure SQL Database och Azure SQL Managed Instance stöder TDS (Tabular Data Stream) 8.0.

TDS- protokollet (Tabular Data Stream) är ett protokoll på programnivå som används av klienter för att ansluta till SQL Server. SQL Server använder TLS (Transport Layer Security) för att kryptera data som överförs över ett nätverk mellan en instans av SQL Server och ett klientprogram.

TDS är ett säkert protokoll, men i tidigare versioner av SQL Server kan kryptering inaktiveras eller inte aktiveras. För att uppfylla standarderna för obligatorisk kryptering vid användning av SQL Server introducerades en iteration av TDS-protokollet: TDS 8.0.

TLS-handskakningen föregår nu alla TDS-meddelanden och omsluter TDS-sessionen i TLS för att framtvinga kryptering, justera TDS 8.0 med HTTPS och andra webbprotokoll. Den här förbättringen bidrar avsevärt till TDS-trafik hanterbarhet, eftersom standardnätverksenheter nu kan filtrera och på ett säkert sätt skicka SQL-frågor.

En fördel med TDS 8.0 jämfört med tidigare TDS-versioner är dess kompatibilitet med TLS 1.3 och TLS-standarder framöver. TDS 8.0 är också helt kompatibelt med TLS 1.2 och tidigare TLS-versioner.

Så här fungerar TDS

TDS-protokollet (Tabular Data Stream) är ett protokoll på programnivå som används för överföring av begäranden och svar mellan klienter och databasserversystem. Klientsystemet upprättar vanligtvis en långvarig anslutning till servern. När anslutningen har upprättats med hjälp av ett protokoll på transportnivå utbyts TDS-meddelanden för att kommunicera mellan klienten och SQL Server.

Under TDS-sessionens livslängd finns det tre faser:

  • Initiering
  • Autentisering
  • Datautbyte

Kryptering förhandlas under den inledande fasen, men TDS-förhandling sker över en okrypterad anslutning. SQL Server-anslutningen ser ut så här för tidigare versioner av TDS 8.0:

TCP handshake ➡️ TDS prelogin (klartext) och svar (klartext) ➡️ TLS handshake ➡️ autentisering (krypterad) ➡️ datautbyte (kan vara krypterad eller okrypterad)

Med introduktionen av TDS 8.0 är SQL Server-anslutningarna följande:

TCP-handskakning ➡️ TLS-handskakning ➡️ TDS prelogin (krypterat) och svar (krypterat) ➡️ autentisering (krypterad) ➡️ datautbyte (krypterat)

Kompatibilitetsmatris för alternativ för TDS, TLS, OPERATIVSYSTEM och kryptering

Du kan aktivera både TLS 1.2- och TLS 1.3-versioner på OS-nivå, vilket gör att klientanslutningar till SQL Server kan använda flera TDS-protokollversioner (TDS 7.x och 8.0). Beroende på operativsystemversionen kan TLS 1.2 och TLS 1.3 vara aktiverade som standard.

Endast TDS 7.x stöder icke-krypterad (valfri) kommunikation, TDS 8.0 stöder inte detta. TDS 7.x stöder kryptering med TLS upp till version 1.2. TDS 8.0 kräver kryptering – allt krypteras alltid med TDS 8.0 (Encrypt=Strict). TDS 8.0 har inget minimikrav på TLS-version och stöder TLS 1.3. TLS 1.3-stöd är beroende av operativsystemversionen. I följande tabell sammanfattas olika scenarier med krypteringsalternativen och motsvarande TLS- och TDS-versioner.

Kryptera
option		 TLS-versionen är aktiverad OS-version Förväntad
connection
utfall		 Noteringar
Sträng Endast TLS 1.3 (eller senare) Windows 11

Windows Server 2022 och senare		 Success TLS 1.3 förhandlat; TDS 8.0 utlöses (Encrypt=Strict)
Sträng TLS 1.2 och TLS 1.3 Windows 11

Windows Server 2022 och senare		 Success TLS 1.3 förhandlat; TDS 8.0 utlöses (Encrypt=Strict)
Sträng Endast TLS 1.2 (eller tidigare) Windows 11

Windows Server 2022 och senare		 Success TLS 1.2 förhandlat; TDS 8.0 utlöses (Encrypt=Strict)
Sträng Endast TLS 1.2 (eller tidigare) Windows 10

Windows Server 2019 /2016		 Success TLS 1.2 förhandlat; TDS 8.0 utlöses (TLS 1.3 är inte tillgängligt)
Mandatory Endast TLS 1.3 (eller senare) Windows 11

Windows Server 2022 och senare		 Failure Encrypt=Mandatory är inte kompatibelt med TLS 1.3 för TDS 8.0
Mandatory TLS 1.2 och TLS 1.3 Windows 11

Windows Server 2022 och senare		 Success TLS 1.2 förhandlat; TDS 8.0 utlöses inte (Encrypt=Mandatory)
Mandatory Endast TLS 1.2 (eller tidigare) Windows 11

Windows Server 2022 och senare		 Success TLS 1.2 förhandlat; TDS 8.0 utlöses inte (Encrypt=Mandatory)
Mandatory Endast TLS 1.2 (eller tidigare) Windows 10

Windows Server 2019 /2016		 Success TLS 1.2 förhandlat; TDS 8.0 stöds inte i det här operativsystemet (använder TDS 7.x)
Valfritt Endast TLS 1.3 (eller senare) Windows 11

Windows Server 2022 och senare		 Failure Encrypt=Optional (false) är TDS 7.x, som är inkompatibel med TLS 1.3.
Valfritt TLS 1.2 och TLS 1.3 Windows 11

Windows Server 2022 och senare		 Success TLS 1.3 förhandlades; TDS 8.0 aktiverades inte (Kryptering=Valfritt)
Valfritt Endast TLS 1.2 (eller tidigare) Windows 11

Windows Server 2022 och senare		 Success TLS 1.2 förhandlades; TDS 8.0 inte aktiverad (Encrypt=Optional)
Valfritt Endast TLS 1.2 (eller tidigare) Windows 10

Windows Server 2019 /2016		 Success TLS 1.2 förhandlat; kryptering valfritt; anslutningen kan
lyckas utan kryptering
Vilken som helst Endast TLS 1.3 (eller senare) Windows 10

Windows Server 2019 /2016		 Failure TLS 1.3 stöds inte i det här operativsystemet

Mer information om hur klienter använder olika TDS-versioner finns i avsnittet nyckelordsanvändning i Avsnittet Om ändringar i egenskaper för anslutningssträngskryptering .

Stöd för SQL Server 2025

Förhandsversionen av SQL Server 2025 (17.x) introducerar TDS 8.0-stöd för följande kommandoradsverktyg och SQL Server-funktioner:

1TDS 8.0-stöd introducerar icke-bakåtkompatibla ändringar i dessa funktioner.

Strikt anslutningskryptering

Om du vill använda TDS 8.0 har SQL Server 2022 (16.x) lagts till strict som ytterligare ett alternativ för anslutningskryptering till SQL Server-drivrutiner (Encrypt=strict). Om du vill använda strict anslutningskrypteringstypen laddar du ned den senaste versionen av drivrutinerna .NET, ODBC, OLE DB, JDBC, PHP och Python:

För att förhindra en man-in-the-middle-attack med strict anslutningskryptering kan användarna inte ange TrustServerCertificate alternativet till true och tillåta något certifikat som servern har angett. I stället skulle användarna använda alternativet HostNameInCertificate för att ange certifikatet ServerName som ska vara betrott. Certifikatet som tillhandahålls av servern måste godkännas av certifikatverifieringen. Mer information om certifikatverifiering finns i Certifikatkrav för SQL Server

Funktioner som inte har stöd för att tvinga fram strikt kryptering

Alternativet Force Strict Encryption som lagts till med TDS 8.0 i SQL Server Network Configuration tvingar alla klienter att använda strict som krypteringstyp. Klienter eller funktioner utan strict anslutningskryptering kan inte ansluta till SQL Server.

Följande funktioner eller verktyg använder fortfarande tidigare version av drivrutiner som inte stöder TDS 8.0 och som sådana kanske inte fungerar med strict anslutningskryptering:

  • Databasmail

Ytterligare ändringar av krypteringsegenskaper för anslutningssträngar

Följande alternativ läggs till i anslutningssträngar för att kryptera kommunikationen:

Nyckelord Förvald Beskrivning
Encrypt falsk Tidigare alternativ för anslutningssträngar

Giltiga alternativ är
- trueeller yes
- false, eller no.
För mer information, se anslutningssträngssyntax. När trueanvänder SQL Server TLS 1.2-kryptering för alla data som utbyts mellan klienten och servern om servern har ett certifikat installerat.

De senaste alternativen för anslutningssträngar

Giltiga alternativ är
- strict
- mandatory, eller true, eller yes
- optional, eller false, eller no.

När värdet är inställt på strictanvänder SQL Server TDS 8.0 för alla data som utbyts mellan klienten och servern.

När det är inställt på mandatory, trueeller yesanvänder SQL Server TDS 7.x med TLS/SSL-kryptering för alla data som skickas mellan klienten och servern om servern har ett certifikat installerat.

När anslutningen är inställd på optional, falseeller noanvänder den TDS 7.x och krypteras endast om det krävs av SQL Server.
TrustServerCertificate falsk Alternativ för föregående anslutningssträng

När den är inställd true på (rekommenderas inte) validerar drivrutinen inte serverns TLS/SSL-certifikat. Om trueär serverns TLS/SSL-certifikat automatiskt betrott (kringgår valideringen) när kommunikationsskiktet krypteras med hjälp av TLS.

Om falsevaliderar drivrutinen serverns TLS/SSL-certifikat. Om verifieringen av servercertifikatet misslyckas genererar drivrutinen ett fel och stänger anslutningen. Standardvärdet är false. Kontrollera att värdet som skickas till serverName exakt matchar Common Name (CN)- eller DNS-namnet i Subject Alternate Name i servercertifikatet för att en TLS/SSL-anslutning ska lyckas.

Beteendeförändring för Microsoft SQL Server ODBC Driver 18 och senare

Om Encrypt är inställt på strictanger den här inställningen platsen för certifikatet som ska användas för verifiering av servercertifikat (exakt matchning). Drivrutinen stöder PEM-, DER- och CER-filtillägg.

Om Encrypt är inställt på true eller falseoch egenskapen TrustServerCertificate är ospecificerad eller inställd på null, trueeller falseanvänder drivrutinen egenskapsvärdet ServerName på anslutnings-URL:en som värdnamn för att verifiera SQL Server TLS/SSL-certifikatet.
HostNameInCertificate null Värdnamnet som ska användas för att verifiera SQL Server TLS/SSL-certifikatet. Om egenskapen HostNameInCertificate är ospecificerad eller inställd på nullanvänder drivrutinen egenskapsvärdet ServerName som värdnamn för att verifiera SQL Server TLS/SSL-certifikatet.

Relaterat innehåll