Dela via

Lösa problemet med TLS 1.0, andra utgåvan

  • Artikel

Det här dokumentet innehåller uppdaterad information som hjälper dig att snabbt identifiera och ta bort beroenden för version 1.0 av TLS-protokollet (Transport Layer Security) i programvara som byggts på Microsoft-operativsystem. Det innehåller även detaljer om produktändringar och nya funktioner från Microsoft som skyddar dina kunder och onlinetjänster. Dokumentet är tänkt att fungera som utgångspunkt för att skapa en migreringsplan för en nätverksmiljö med TLS 1.2+. Även om lösningarna som beskrivs här kan fungera för att ta bort TLS 1.0-användning i andra operativsystem än Microsofts eller i kryptobibliotek, är dessa inte i fokus i det här dokumentet.

TLS 1.0 är ett säkerhetsprotokoll som först definierades 1999 och som upprättar krypteringskanaler över datornätverk. Microsoft stöder det här protokollet sedan Windows XP/Server 2003. Även om det inte längre är standardsäkerhetsprotokollet i moderna operativsystem, stöds TLS 1.0 fortfarande för att ge bakåtkompatibilitet. På grund av nya krav och säkerhetsrisker i TLS 1.0 vill vissa organisationer inaktivera TLS 1.0 helt och hållet.

Microsoft rekommenderar kunder att lösa det här problemet genom att ta bort TLS 1.0-beroenden i sina miljöer och inaktivera TLS 1.0 på operativsystemnivå då det är möjligt. Med tanke på hur lång tid TLS 1.0 har använts i programvaruindustrin är det viktigt att alla TLS 1.0-utfasningsplaner omfattar följande:

  • Kodanalys för att hitta/åtgärda hårdkodade instanser av TLS 1.0 eller äldre säkerhetsprotokoll.

  • Genomsökning av nätverksslutpunkter och trafikanalys för att identifiera operativsystem som använder TLS 1.0 eller äldre protokoll.

  • Fullständig regressionstestning i hela programstacken med TLS 1.0 inaktiverat.

  • Migrering av äldre operativsystem och utvecklingsbibliotek/ramverk till versioner som kan förhandla om TLS 1.2 som standard.

  • Kompatibilitetstestning mellan operativsystem som används av ditt företag för att identifiera eventuella problem med TLS 1.2-stöd.

  • Samordning med dina egna affärspartner och kunder för att informera om utfasningen av TLS 1.0.

  • Förståelse för vilka klienter som kanske inte längre kan ansluta till dina servrar när TLS 1.0 har inaktiverats.

Målet med det här dokumentet är att ge rekommendationer som kan hjälpa dig att eliminera de tekniska hindren med att inaktivera TLS 1.0 samtidigt som du får bättre kunskap om hur den här ändringen påverkar dina kunder. Sådana undersökningar kan bidra till att minska de konsekvenser för verksamheten som nästa säkerhetsrisk i TLS 1.0 kan orsaka. I det här dokumentet innehåller referenserna till utfasningen av TLS 1.0 även TLS 1.1.

Utvecklare av företagsprogram har ett strategiskt behov av att implementera fler framtida och smidiga lösningar (kallas även flexibel kryptografi) för att hantera risker med framtida säkerhetsprotokoll. Det här dokumentet föreslår smidiga lösningar för att eliminera hårdkodning av TLS-versioner, men beskriver inte mer generella lösningar inom flexibel kryptografi.

Det aktuella tillståndet för Microsofts TLS 1.0-implementering

Microsofts TLS 1.0-implementering har inga kända säkerhetsproblem. På grund av risken för framtida attacker via protokollnedgradering och andra TLS 1.0-sårbarheter som inte är specifika för Microsofts implementering rekommenderar vi att beroenden för alla säkerhetsprotokoll som är äldre än TLS 1.2 tas bort om möjligt (TLS 1.1/1.0/SSLv3/SSLv2).

Utvecklare och systemadministratörer som planerar för den här migreringen till TLS 1.2+ bör vara beredda på att protokollversionen kan vara hårdkodad i program utvecklade av deras anställda eller partner. Hårdkodning här innebär att TLS-versionen är hårdkodad till en version som är inaktuell och mindre säker än nyare versioner. TLS-versioner som är nyare än den hårdkodade versionen kan inte användas utan att programmet i fråga ändras. Den här typen av problem kan inte åtgärdas utan källkodsändringar och distribution av programuppdateringar. Hårdkodning av protokollversionen var vanligt tidigare för testnings- och kompatibilitetsändamål eftersom många olika webbläsare och operativsystem hade olika nivåer av TLS-stöd.

Versioner av TLS som stöds i Windows

Tänk på att många operativsystem har föråldrade TLS-versioner eller saknar stöd för nyare versioner.

Bild 1: Stöd för säkerhetsprotokoll efter os-version

Windows OS SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista Aktiverat Aktiverat Aktiverat Stöds inte Stöds inte Stöds inte
Windows Server 2008 Aktiverat Aktiverat Aktiverat Inaktiverad* Inaktiverad* Stöds inte
Windows 7 (WS2008 R2) Aktiverat Aktiverat Aktiverat Inaktiverad* Inaktiverad* Stöds inte
Windows 8 (WS2012) Inaktiverat Aktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows 8.1 (WS2012 R2) Inaktiverat Aktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows 10 Inaktiverat Aktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows 11 Inaktiverat Aktiverat Aktiverat Aktiverat Aktiverat Aktiverat
Windows Server 2016 Stöds inte Inaktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows Server 2016 Stöds inte Inaktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows Server 2019 Stöds inte Inaktiverat Aktiverat Aktiverat Aktiverat Stöds inte
Windows Server 2019 GS-utgåva Stöds inte Inaktiverat Inaktiverat Inaktiverat Aktiverat Stöds inte
Windows Server 2022 Stöds inte Inaktiverat Inaktiverat Inaktiverat Aktiverat Aktiverat

Windows Server 2019 GS Edition är Microsoft SDL-kompatibel, TLS 1.2 endast med en begränsad uppsättning chiffersviter.

Windows Server 2022-utgåvan är endast Microsoft SDL-kompatibel, TLS 1.2 och TLS 1.3 med en begränsad uppsättning chiffersviter.

TLS 1.1/1.2 kan aktiveras på Windows Server 2008 via det här valfria Windows Update-paketet.

Mer information om TLS 1.0/1.1-utfasningen i IE/Edge finns i avsnittet om att modernisera TLS-anslutningar i Microsoft Edge och Internet Explorer 11, i avsnittet om ändringar i Microsoft Edge som påverkar webbplatskompatibiliteten och avsnittet om att inaktivera TLS/1.0 och TLS/1.1 i den nya Edge-webbläsaren

Ett snabbt sätt att avgöra vilken TLS-version som kommer att krävas av olika klienter när du ansluter till dina onlinetjänster är att referera till handskakningssimuleringen i Qualys SSL Labs. Den här simuleringen täcker kombinationer av klientoperativsystem/webbläsare mellan tillverkare. Se bilaga A i slutet av det här dokumentet för ett detaljerat exempel som visar de TLS-protokollversioner som förhandlas av olika simulerade kombinationer av klientoperativsystem/webbläsare när du ansluter till www.microsoft.com.

Om du inte redan har gjort det rekommenderar vi starkt att du utför en inventering av de operativsystem som används av ditt företag, dina kunder och dina partner (de två sistnämnda via kontakt/kommunikation eller åtminstone insamling av HTTP-användaragentsträngar). Den här inventeringen kan kompletteras med en trafikanalys vid företagets nätverksgräns. I så fall kommer trafikanalysen att visa de TLS-versioner som har förhandlats av kunder/partner som ansluter till dina tjänster, men själva trafiken förblir krypterad.

Microsofts tekniska förbättringar för att eliminera TLS 1.0-beroenden

Sedan v1-versionen av det här dokumentet har Microsoft levererat ett antal programuppdateringar och nya funktioner för att underlätta utfasningen av TLS 1.0. Dessa kan vara:

  • IIS-anpassad loggning för att korrelera klientens IP/användaragentsträng, tjänst-URI, TLS-protokollversion och chiffersvit.

    • Med den här loggningen kan administratörer kvantifiera sina kunders exponering för svag TLS.

  • SecureScore – För att hjälpa Office 365-klientadministratörer att identifiera egen svag TLS-användning har SecureScore-portalen skapats för att dela den här informationen då supporten för TLS 1.0 upphörde i Office 365 i oktober 2018.

    • Den här portalen förser Office 365-klientadministratörer med värdefull information som de behöver för att kunna nå kunder som kanske inte vet vilka TLS 1.0-beroenden de har.

    • Besök https://securescore.microsoft.com/ om du vill ha mer information.

  • .NET Framework-uppdateringar som eliminerar hårdkodning på appnivå och förhindrar ramverksöverförda TLS 1.0-beroenden.

  • Utvecklarvägledning och programuppdateringar har släppts för att hjälpa kunder att identifiera och eliminera .Net-beroenden på svaga metodtips för TLS: Transport Layer Security (TLS) med .NET Framework

    • FYI: Alla appar som är avsedda för .NET 4.5 eller senare måste förmodligen ändras för att stödja TLS 1.2.

  • TLS 1.2 har bakåtporterats till Windows Server 2008 SP2 och XP POSReady 2009 för att underlätta för kunder med äldre åtaganden.

  • Mer information kommer i början av 2019 och kommuniceras i efterföljande uppdateringar av det här dokumentet.

Hitta och åtgärda TLS 1.0-beroenden i kod

För produkter som använder kryptografiska bibliotek som tillhandahålls av Windows-operativsystem följer du dessa steg för att identifiera hårdkodad TLS 1.0-användning i dina program:

  1. Identifiera alla instanser av AcquireCredentialsHandle(). Detta hjälper granskaren att ringa in de kodblock där TLS kan vara hårdkodad.

  2. Granska alla instanser av SecPkgContext_SupportedProtocols- och SecPkgContext_Anslut ionInfo-strukturerna för hårdkodad TLS.

  3. I intern kod ställer du in alla grbitEnabledProtocols-tilldelningar som inte är noll till noll. Detta gör att operativsystemet kan använda sin TLS-standardversion.

  4. Inaktivera FIPS-läge om det är aktiverat eftersom det kan skapa konflikt med inställningar som krävs för att explicit inaktivera TLS 1.0/1.1 i det här dokumentet. Mer information finns i bilaga B.

  5. Uppdatera och kompilera om alla program som använder WinHTTP i Server 2012 eller äldre.

    1. Hanterade appar – återskapa och dirigera om mot den senaste .NET Framework-versionen

    2. Program måste lägga till kod för att ge stöd för TLS 1.2 via WinHttpSetOption

  6. För att vara helt säker bör du gå igenom all källkod och alla konfigurationsfiler för onlinetjänster och leta efter mönstren nedan som motsvarar de uppräknade typvärden som ofta används med hårdkodning av TLS:

    1. SecurityProtocolType

    2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL eller PROTOCOL_TLS

Den rekommenderade lösningen i samtliga fall ovan är att ta bort den valda hårdkodade protokollversionen och byta till operativsystemets standardinställning. Om du använder DevSkimklickar du här för att se regler som täcker ovanstående kontroller som du kan använda med din egen kod.

Windows PowerShell använder .NET Framework 4.5, där TLS 1.2 inte är ett tillgängligt protokoll. Du kan komma runt detta med någon av två lösningar:

  1. Ändra skriptet i fråga så att det innehåller följande:

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

  2. Lägg till en systemomfattande registernyckel (t.ex. via en grupprincip) till alla datorer som behöver upprätta TLS 1.2-anslutningar från en .NET-app. Detta gör att .NET använder TLS-versionerna i ”systemstandardinställningen” så att TLS 1.2 läggs till som ett tillgängligt protokoll, och gör även att skripten kan använda framtida TLS-versioner när operativsystemet har stöd för dem. (t.ex. TLS 1.3)

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

Lösningarna (1) och (2) kan inte implementeras samtidigt.

Återskapa/dirigera om hanterade program med den senaste versionen av .NET Framework

Program som använder .NET Framework-versioner som är äldre än 4.7 kan begränsa stödet till TLS 1.0 oavsett operativsystemets underliggande standardinställningar. Mer information finns i nedanstående diagram och metodtips för Transport Layer Security (TLS) med .NET Framework .

Återskapa hanterade program

SystemDefaultTLSVersion har företräde framför TLS-versioner som har mål på appnivå. Rekommenderade bästa praxis är att alltid gå över till TLS-versionen i operativsystemets standardinställning. Det är också den enda kryptografiskt flexibla lösningen som gör att dina appar kan dra nytta av framtida stöd för TLS 1.3.

Om du riktar in dig på äldre versioner av .NET Framework såsom 4.5.2 eller 3.5 använder ditt program som standard äldre protokoll som ej rekommenderas, till exempel SSL 3.0 eller TLS 1.0. Vi rekommenderar starkt att du uppgraderar till nyare versioner av .NET Framework såsom .NET Framework 4.6 eller anger lämpliga registernycklar för "UseStrongCrypto".

Testa med TLS 1.2+

När de rekommenderade korrigeringarna i avsnittet ovan har utförts bör produkterna regressionstestas för att bekräfta det inte uppstår några protokollförhandlingsfel eller kompatibilitetsproblem med andra operativsystem på företaget.

  • Det vanligaste problemet i den här regressionstestningen är ett TLS-förhandlingsfel på grund av ett klientanslutningsförsök från ett operativsystem eller en webbläsare som inte stöder TLS 1.2.

    • En Vista-klient kommer till exempel inte att kunna förhandla om TLS med en server som har konfigurerats för TLS 1.2+ eftersom Vista inte stöder senare versioner än TLS 1.0. Klienten bör antingen uppgraderas eller inaktiveras i en TLS 1.2+-miljö.

  • Produkter som använder certifikatbaserad ömsesidig TLS-autentisering kan kräva ytterligare regressionstestning eftersom koden för certifikatval som är associerad med TLS 1.0 var mindre uttrycklig än för TLS 1.2.

    • Om en produkt förhandlar om MTLS med ett certifikat från en annan plats än standardplatsen (utanför de namngivna certifikatarkiven som är standard i Windows) kan den koden behöva uppdateras för att säkerställa att certifikatet har hämtats korrekt.

  • Tjänstberoenden bör granskas för att säkerställa att de är felfria.

    • Tjänster som kommunicerar med tjänster från tredje part bör testas ytterligare med dessa tredjepartstjänster.

    • Andra program eller serveroperativsystem som inte är Windows-program eller Windows-serveroperativsystem måste undersökas och testas för att säkerställa att de stöder TLS 1.2. Genomsökning är det enklaste sättet att bekräfta detta.

En enkel mall för att testa dessa ändringar i en onlinetjänst består av följande:

  1. Utför en genomsökning av system i produktionsmiljön för att identifiera operativsystem som inte stöder TLS 1.2.

  2. Genomsök källkoden och konfigurationsfiler för onlinetjänster och leta efter hårdkodad TLS på det sätt som beskrivs i ”Hitta och åtgärda TLS 1.0-beroenden i kod”

  3. Uppdatera/kompilera om program efter behov:

    1. Hanterade appar

      1. Återskapa mot den senaste versionen av .NET Framework.

      2. Kontrollera att all användning av SSLProtocols-uppräkningen har angetts till SSLProtocols.None så att operativsystemets standardinställningar kan användas.

    2. WinHTTP-appar – återskapa med WinHttpSetOption för TLS 1.2-stöd

  4. Börja testa i en förproduktions- eller mellanlagringsmiljö med alla säkerhetsprotokoll som är äldre än TLS 1.2 inaktiverade via registret.

  5. Åtgärda eventuella återstående instanser av hårdkodad TLS när de påträffas under testningen. Distribuera om programvaran och utför ett nytt regressionstest.

Meddela partner om dina planer på att fasa ut TLS 1.0

Om du väljer att fasa ut TLS 1.0 när du har åtgärdat problemet med hårdkodad TLS och uppdaterat operativsystem/utvecklingsramverk måste du samordna arbetet med kunder och partner:

  • Tidig kontakt med partner/kunder är viktigt för en lyckad utfasning av TLS 1.0. Detta bör åtminstone innefatta blogginlägg, faktablad eller annat webbinnehåll.

  • Varje partner behöver utvärdera sin egen TLS 1.2-beredskap med de operativsystems-, kodgenomsöknings- och regressionsteståtgärder som beskrivs ovan.

Slutsats

Att ta bort alla TLS 1.0-beroenden på ett heltäckande sätt kan vara svårt. Microsoft och branschpartner arbetar med det här problemet idag för att se till att hela produktstacken är säkrare som standard, från våra OS-komponenter och utvecklingsramverk till de program/tjänster som bygger på dem. Rekommendationerna i det här dokumentet hjälper ditt företag genom processen och förbereder er på de utmaningar som ni kan vänta. Informationen hjälper även dina egna kunder att förbereda sig inför övergången.

Bilaga A: Handskakningssimulering för olika klienter som ansluter till www.microsoft.com, med tillstånd SSLLabs.com

Resultat av simulering av handskakning

Bilaga B: Inaktuell TLS 1.0/1.1 vid kvarhållning av FIPS-läge

Följ stegen nedan om ditt nätverk kräver FIPS-läge, men du även vill fasa ut TLS 1.0/1.1:

  1. Konfigurera TLS-versioner via registret genom att ange ”Aktiverad” till noll för de oönskade TLS-versionerna.

  2. Inaktivera Curve 25519 (endast Server 2016) via Grupprincip.

  3. Inaktivera alla chiffersviter som använder algoritmer som inte tillåts av den relevanta FIPS-publikationen. För Server 2016 (förutsatt att standardinställningarna är aktiva) innebär detta att du inaktiverar RC4-, PSK- och NULL-chiffer.

Medarbetare/Tack till

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson