Dela via


Översikt över TLS – SSL (Schannel SSP)

Det här avsnittet för IT-proffs beskriver ändringarna i funktionerna för Schannel Security Support Provider (SSP), som inkluderar autentiseringsprotokollen Transport Layer Security (TLS), transportlayer-säkerhet, Secure Sockets Layer (SSL) och Datagram Transport Layer Security (DTLS), för Windows Server 2012 R2, Windows Server 2012, Windows 8.1 och Windows 8.

Schannel är en SSP (Security Support Provider) som implementerar standardautentiseringsprotokollen SSL, TLS och DTLS Internet. SSPI (Security Support Provider Interface) är ett API som används av Windows-system för att utföra säkerhetsrelaterade funktioner, inklusive autentisering. SSPI fungerar som ett gemensamt gränssnitt för flera SSP:er (Security Support Providers), inklusive Schannel SSP.

Mer information om Microsofts implementering av TLS och SSL i Schannel SSP finns i TLS/SSL Technical Reference (2003).

TLS/SSL-funktioner (Schannel SSP)

Följande beskriver funktionerna i TLS i Schannel SSP.

Återupptagande av TLS-session

TLS-protokollet (Transport Layer Security), en komponent i Schannel Security Support Provider, används för att skydda data som skickas mellan program i ett ej betrott nätverk. TLS/SSL kan användas för att autentisera servrar och klientdatorer och även för att kryptera meddelanden mellan de autentiserade parterna.

Enheter som ansluter TLS till servrar behöver ofta återansluta på grund av att sessionen upphör att gälla. Windows 8.1 och Windows Server 2012 R2 stöder nu RFC 5077 (återupptagande av TLS-session utan Server-Side tillstånd). Den här ändringen tillhandahåller Windows Phone- och Windows RT-enheter med:

  • Minskad resursanvändning på servern

  • Minskad bandbredd, vilket förbättrar effektiviteten för klientanslutningar

  • Kortare tid som ägnas åt TLS-handskakningen på grund av återupptagningar av anslutningen.

Note

Implementeringen på klientsidan av RFC 5077 lades till i Windows 8.

Information om tillståndslös återupptagning av TLS-sessioner finns i IETF-dokumentet RFC 5077.

Förhandlingar om programprotokoll

Windows Server 2012 R2 och Windows 8.1 stöder förhandlingar med TLS-programprotokoll på klientsidan så att program kan utnyttja protokoll som en del av HTTP 2.0-standardutvecklingen och användarna kan komma åt onlinetjänster som Google och Twitter med hjälp av appar som kör SPDY-protokollet.

Hur det fungerar

Klient- och serverprogram aktiverar programprotokollförhandlingstillägg genom att ange listor över programprotokoll-ID:er som stöds, i fallande prioritetsordning. TLS-klienten anger att den stöder förhandlingar med programprotokoll genom att inkludera ALPN-tillägget (Application Layer Protocol Negotiation) med en lista över protokoll som stöds av klienten i ClientHello-meddelandet.

När TLS-klienten skickar begäran till servern läser TLS-servern sin protokolllista som stöds för det mest föredragna programprotokollet som klienten också stöder. Om ett sådant protokoll hittas svarar servern med det valda protokoll-ID:t och fortsätter med handskakningen som vanligt. Om det inte finns något gemensamt programprotokoll skickar servern en avisering om allvarligt handskakningsfel.

Hantering av betrodda utfärdare för klientautentisering

När autentisering av klientdatorn krävs med SSL eller TLS kan servern konfigureras för att skicka en lista över betrodda certifikatutfärdare. Den här listan innehåller den uppsättning certifikatutfärdare som servern litar på och är ett tips till klientdatorn om vilket klientcertifikat som ska väljas om det finns flera certifikat. Dessutom måste certifikatkedjan som klientdatorn skickar till servern verifieras mot listan med konfigurerade betrodda utfärdare.

Före Windows Server 2012 och Windows 8 kan program eller processer som använde Schannel SSP (inklusive HTTP.sys och IIS) tillhandahålla en lista över de betrodda utfärdare som de har stöd för för klientautentisering via en lista över betrodda certifikat (CTL).

I Windows Server 2012 och Windows 8 gjordes ändringar i den underliggande autentiseringsprocessen så att:

  • CTL-baserad listhantering för betrodda utfärdare stöds inte längre.

  • Beteendet att skicka listan över betrodda utfärdare är som standard inaktiverat: Standardvärdet för registernyckeln SendTrustedIssuerList är nu 0 (inaktiverat som standard) i stället för 1.

  • Kompatibilitet med tidigare versioner av Windows-operativsystem bevaras.

Note

Om System Mapper är aktiverat av klientprogrammet och du har konfigurerat SendTrustedIssuerskommer systemmapparen att lägga till CN=NT Authority i listan med utfärdare.

Vilket värde lägger detta till?

Från och med Windows Server 2012 har användningen av ctl ersatts med en certifikatarkivbaserad implementering. Detta möjliggör mer välbekant hanterbarhet via powerShell-providerns befintliga certifikathanteringskommandon, samt kommandoradsverktyg som certutil.exe.

Även om den maximala storleken på listan över betrodda certifikatutfärdare som Schannel SSP stöder (16 KB) förblir densamma som i Windows Server 2008 R2 finns det i Windows Server 2012 ett nytt dedikerat certifikatarkiv för utfärdare av klientautentisering så att orelaterade certifikat inte ingår i meddelandet.

Hur fungerar det?

I Windows Server 2012 konfigureras listan över betrodda utfärdare med hjälp av certifikatarkiv. ett standardarkiv för globalt datorcertifikat och ett som är valfritt per plats. Källan till listan bestäms på följande sätt:

  • Om det finns ett specifikt autentiseringsarkiv som konfigurerats för platsen används det som källa

  • Om det inte finns några certifikat i det programdefinierade arkivet kontrollerar Schannel lagringsplatsen för klientautentiseringsutfärdare på den lokala datorn och använder det arkivet som källa om det finns certifikat. Om inget certifikat hittas i något av lagren kontrolleras lagret Betrodda rötter.

  • Om varken de globala eller lokala arkiven innehåller certifikat använder Schannel-providern arkivet Betrodda rotcertifikatutfärdare som källa för listan över betrodda utfärdare. (Det här är beteendet för Windows Server 2008 R2 .)

Om arkivet Betrodda rotcertifikatutfärdare som användes innehåller en blandning av rotcertifikat (självsignerade) och certifikatutfärdare (CA) skickas endast CA Issuer-certifikaten till servern som standard.

Så här konfigurerar du Schannel för att använda certifikatarkivet för betrodda utfärdare

Schannel SSP-arkitekturen i Windows Server 2012 använder som standard butikerna enligt beskrivningen ovan för att hantera listan Betrodda utfärdare. Du kan fortfarande använda befintliga certifikathanteringskommandon för PowerShell-providern samt kommandoradsverktyg som Certutil för att hantera certifikat.

Information om hur du hanterar certifikat med hjälp av PowerShell-providern finns i CMDletar för AD CS-administration i Windows.

Information om hur du hanterar certifikat med hjälp av certifikatverktyget finns icertutil.exe.

Information om vilka typer av data, inklusive det applikationsdefinierade lagret, som definieras för en Schannel-kredential finns i SCHANNEL_CRED struktur (Windows).

Standardvärden för förtroendelägen

Det finns tre förtroendelägen för klientautentisering som stöds av Schannel-providern. Förtroendeläget styr hur verifieringen av klientens certifikatkedja utförs och är en systemomfattande inställning som styrs av REG_DWORD "ClientAuthTrustMode" under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Value Förtroendeläge Description
0 Maskinförtroende (standard) Kräver att klientcertifikatet utfärdas av ett certifikat i listan Betrodda utfärdare.
1 Exklusivt rotförtroende Kräver att ett klientcertifikat kopplas ihop med ett rotcertifikat som finns i det användarspecificerade betrodda utfärdarlagret. Certifikatet måste också utfärdas av en utfärdare i listan betrodda utfärdare
2 Exklusivt CA-förtroende Kräver att en klientcertifikat kedjar sig till antingen ett mellanliggande CA-certifikat eller rotcertifikat i anroparens specificerade betrodda utfärdararkiv.

Information om autentiseringsfel på grund av problem med konfiguration av betrodda utfärdare finns i knowledge base-artikeln 280256.

TLS-stöd för SNI-tillägg (Server Name Indicator)

Funktionen För servernamnsindikator utökar SSL- och TLS-protokollen så att servern kan identifieras korrekt när flera virtuella avbildningar körs på en enda server. För att skydda kommunikationen mellan en klientdator och en server korrekt begär klientdatorn ett digitalt certifikat från servern. När servern svarar på begäran och skickar certifikatet undersöker klientdatorn den, använder den för att kryptera kommunikationen och fortsätter med det normala utbytet av begärandesvar. Men i ett virtuellt värdscenario finns flera domäner, var och en med sitt eget potentiellt distinkta certifikat, på en server. I det här fallet har servern inget sätt att veta i förväg vilket certifikat som ska skickas till klientdatorn. Med SNI kan klientdatorn informera måldomänen tidigare i protokollet, vilket gör att servern kan välja rätt certifikat korrekt.

Vilket värde lägger detta till?

Denna ytterligare funktion:

  • Gör att du kan vara värd för flera SSL-webbplatser på en enda IP- och portkombination

  • Minskar minnesanvändningen när flera SSL-webbplatser finns på en enda webbserver

  • Gör att fler användare kan ansluta till mina SSL-webbplatser samtidigt

  • Gör att du kan ge tips till slutanvändare via datorgränssnittet för att välja rätt certifikat under en klientautentiseringsprocess.

Hur det fungerar

Schannel SSP upprätthåller en minnesintern cache med klientanslutningstillstånd som tillåts för klienter. Detta gör att klientdatorer snabbt kan återansluta till SSL-servern utan att behöva utföra ett fullständigt SSL-handskakning vid efterföljande besök. Med den här effektiva användningen av certifikathantering kan fler platser finnas på en enda Windows Server 2012 jämfört med tidigare operativsystemversioner.

Användarens val av certifikat har förbättrats genom att du kan skapa en lista över troliga certifikatutfärdarnamn som ger slutanvändaren tips om vilken som ska väljas. Den här listan kan konfigureras med gruppolicy.

Säkerhet på datagramtransportnivå (DTLS)

DTLS version 1.0-protokollet har lagts till i Schannel Security Support Provider. DTLS-protokollet tillhandahåller kommunikationssekretess för datagramprotokoll. Protokollet gör det möjligt för klient-/serverprogram att kommunicera på ett sätt som är utformat för att förhindra avlyssning, manipulering eller förfalskning av meddelanden. DTLS-protokollet baseras på TLS-protokollet (Transport Layer Security) och ger likvärdiga säkerhetsgarantier, vilket minskar behovet av att använda IPsec eller utformar ett anpassat säkerhetsprotokoll på programnivå.

Vilket värde lägger detta till?

Datagram är vanliga i strömmande medier, till exempel spel eller säkra videokonferenser. Genom att lägga till DTLS-protokollet i Schannel-providern kan du använda den välbekanta Windows SSPI-modellen för att skydda kommunikationen mellan klientdatorer och servrar. DTLS är avsiktligt utformat för att likna TLS så mycket som möjligt, både för att minimera nya säkerhetsuppfinningar och för att maximera mängden återanvändning av kod och infrastruktur.

Hur det fungerar

Program som använder DTLS via UDP kan använda SSPI-modellen i Windows Server 2012 och Windows 8. Vissa chiffersviter är tillgängliga för konfiguration, ungefär som hur du kan konfigurera TLS. Schannel fortsätter att använda CNG-kryptografiprovidern som utnyttjar FIPS 140-certifieringen, som introducerades i Windows Vista.

Inaktuella funktioner

I Schannel SSP för Windows Server 2012 och Windows 8 finns det inga inaktuella funktioner.

Ytterligare referenser