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

Det här dokumentet innehåller den senaste vägledningen om att snabbt identifiera och ta bort TLS-protokollversion 1.0-beroenden (Transport Layer Security) i programvara som bygger på Microsofts operativsystem och följa upp med information om produktändringar och nya funktioner som levereras av Microsoft för att skydda dina egna kunder och onlinetjänster. Den är avsedd att användas som utgångspunkt för att skapa en migreringsplan till en TLS 1.2+-nätverksmiljö. Även om lösningarna som beskrivs här kan överföras och hjälpa till med att ta bort TLS 1.0-användning i icke-Microsoft-operativsystem eller kryptobibliotek, är de inte i fokus för det här dokumentet.

TLS 1.0 är ett säkerhetsprotokoll som först definierades 1999 för att upprätta krypteringskanaler över datornätverk. Microsoft har stöd för det här protokollet sedan Windows XP/Server 2003. Även om standardsäkerhetsprotokollet inte längre används av moderna operativsystem stöds TLS 1.0 fortfarande för bakåtkompatibilitet. Nya regelkrav och nya säkerhetsrisker i TLS 1.0 ger företag incitament att inaktivera TLS 1.0 helt.

Microsoft rekommenderar att kunderna går före det här problemet genom att ta bort TLS 1.0-beroenden i sina miljöer och inaktivera TLS 1.0 på operativsystemnivå där det är möjligt. Med tanke på hur lång tid TLS 1.0 har stöd av programvaruindustrin rekommenderar vi starkt att TLS 1.0-utfasningsplanen innehåller 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 med TLS 1.0 eller äldre protokoll.

• Fullständig regressionstestning via hela programstacken med TLS 1.0 inaktiverad.

• 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 TLS 1.2-supportproblem.

• Samordna med dina affärspartner och kunder för att informera dem om ditt beslut att fasa ut TLS 1.0.

• Förstå 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 ta bort tekniska blockerare för att inaktivera TLS 1.0 samtidigt som du ökar insynen i effekten av den här ändringen för dina egna kunder. Genom att slutföra sådana undersökningar kan du minska affärspåverkan av nästa säkerhetsrisk i TLS 1.0. I det här dokumentet omfattar referenser till utfasningen av TLS 1.0 även TLS 1.1.

Utvecklare av företagsprogramvara har ett strategiskt behov av att införa mer framtidssäkra och flexibla lösningar (även kallat Crypto Agility) för att hantera framtida säkerhetsprotokollkomprometter. I det här dokumentet föreslås flexibla lösningar för att eliminera TLS-hårdkodning, men bredare Crypto Agility-lösningar ligger utanför det här dokumentets omfång.

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

Microsofts TLS 1.0-implementering är fri från kända säkerhetsrisker. På grund av risken för framtida protokollnedgraderingsattacker 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 där det är möjligt (TLS 1.1/1.0/ SSLv3/SSLv2).

Vid planeringen av den här migreringen till TLS 1.2+ bör utvecklare och systemadministratörer vara medvetna om risken för hårdkodning av protokollversioner i program som utvecklats av deras anställda och partner. Hårdkodning innebär att TLS-versionen är fast i 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 ändra programmet i fråga. Den här problemklassen kan inte åtgärdas utan ändringar i källkoden och distribution av programuppdateringar. Protokollversionshårdkodning var vanligt tidigare för testnings- och supportä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

Många operativsystem har inaktuella standardvärden för TLS-version eller stödtak som måste redovisas.

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

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-utfasning i IE/Edge finns i Modernisera TLS-anslutningar i Microsoft Edge och Internet Explorer 11, Webbplatskompatibilitetspåverkande ändringar som kommer till Microsoft Edge och 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 begäras av olika klienter när du ansluter till dina onlinetjänster är genom att referera till handskakningssimuleringen på Qualys SSL Labs. Den här simuleringen omfattar 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örhandlats fram av olika simulerade klientoperativsystem/webbläsarkombinationer när du ansluter till www.microsoft.com.

Om det inte redan är genomfört, rekommenderas det starkt att utföra en inventering av operativsystem som används av ditt företag, kunder och partners (de två senare genom uppsökande verksamhet/kommunikation eller åtminstone insamling av HTTP User-Agent-strängar). Den här inventeringen kan kompletteras ytterligare med trafikanalys vid företagets nätverksgräns. I sådana fall ger trafikanalysen de TLS-versioner som förhandlats fram 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 till stöd för TLS 1.0-utfasning. Dessa inkluderar:

• Anpassad IIS-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 slutligen kvantifiera sina kunders exponering för svag TLS.

• SecureScore – För att hjälpa Office 365-klientadministratörer att identifiera sin egen svaga TLS-användning har SecureScore-portalen skapats för att dela den här informationen eftersom TLS 1.0 avslutade supporten i Office 365 i oktober 2018.

  • Den här portalen ger Office 365-klientadministratörer den värdefulla information de behöver för att kontakta sina egna kunder som kanske inte känner till sina egna TLS 1.0-beroenden.

  • Besök https://securescore.microsoft.com/ för mer information.

• .Net Framework uppdateras för att eliminera hårdkodning på appnivå och förhindra ramverkärvda 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 TLS: Transport Layer Security (TLS) bästa praxis 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 backporterats till Windows Server 2008 SP2 och XP POSReady 2009 för att hjälpa kunder med äldre skyldigheter.

• Fler meddelanden kommer att göras i början av 2019 och meddelas 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 kryptografibibliotek och säkerhetsprotokoll som tillhandahålls av Windows OS bör följande steg hjälpa dig att identifiera all hårdkodad TLS 1.0-användning i dina program:

1. Identifiera alla instanser av AcquireCredentialsHandle(). Detta hjälper granskare att komma närmare kodblock där TLS kan vara hårdkodad.

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

3. I intern kod anger du alla tilldelningar som inte är noll för grbitEnabledProtocols till noll. Detta gör att operativsystemet kan använda sin standard-TLS-version.

4. Inaktivera FIPS-läge om det är aktiverat på grund av risken för konflikt med inställningar som krävs för att uttryckligen inaktivera TLS 1.0/1.1 i det här dokumentet. Mer information finns i bilaga B .

5. Uppdatera och kompilera om alla program med WinHTTP som finns på Server 2012 eller äldre.

   1. Hanterade appar – bygg om och rikta om mot den senaste versionen av .NET Framework

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

6. Om du vill täcka alla baser genomsöker du källkoden och onlinetjänstkonfigurationsfilerna efter de mönster nedan som motsvarar uppräknade typvärden som ofta används i TLS-hårdkodning:

   1. Securityprotokolltyp

   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 alla fall ovan är att ta bort valet av hårdkodad protokollversion och skjuta upp till standardinställningarna för operativsystemet. 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.

Uppdatera Windows PowerShell-skript eller relaterade registerinställningar

Windows PowerShell använder .NET Framework 4.5, som inte innehåller TLS 1.2 som ett tillgängligt protokoll. För att undvika detta finns det 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 grupprincip) till alla datorer som behöver göra TLS 1.2-anslutningar från en .NET-app. Detta gör att .NET använder TLS-versionerna "System Default" som lägger till TLS 1.2 som ett tillgängligt protokoll och gör att skripten kan använda framtida TLS-versioner när operativsystemet stöder 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) är ömsesidigt uteslutande, vilket innebär att de inte behöver genomföras tillsammans.

Ombygg/rikta om hanterade applikationer med den senaste .NET Framework-versionen

Program som använder .NET Framework-versioner före 4.7 kan ha begränsningar som effektivt begränsar stödet till TLS 1.0 oavsett de underliggande os-standardvärdena. Mer information finns i nedanstående diagram och metodtips för Transport Layer Security (TLS) med .NET Framework .

SystemDefaultTLSVersion har företräde framför app-nivåinriktning av TLS-versioner. Den rekommenderade praktiken är att alltid använda operativsystemets standardversion av TLS. Det är också den enda krypto agila lösningen som gör att dina appar kan dra nytta av framtida TLS 1.3-stöd.

Om du riktar in dig på äldre versioner av .NET Framework, till exempel 4.5.2 eller 3.5, använder programmet som standard de äldre och inte rekommenderade protokollen, till exempel SSL 3.0 eller TLS 1.0. Vi rekommenderar starkt att du uppgraderar till nyare versioner av .NET Framework, till exempel .NET Framework 4.6 eller anger lämpliga registernycklar för "UseStrongCrypto".

Testa med TLS 1.2+

Efter de korrigeringar som rekommenderas i avsnittet ovan bör produkter regressionstestas för protokollförhandlingsfel och kompatibilitet med andra operativsystem i 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 kan till exempel inte förhandla om TLS med en server som har konfigurerats för TLS 1.2+ eftersom Vistas högsta TLS-version som stöds är 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 val av certifikat som är associerad med TLS 1.0 var mindre uttrycksfull än för TLS 1.2.

  • Om en produkt använder sig av MTLS med ett certifikat från en icke-standardplats (utanför de standardiserade certifikatsarkiven i Windows) kan koden behöva uppdateras för att säkerställa att certifikatet hämtas korrekt.

• Beroenden mellan tjänster bör granskas för felsökningspunkter.

  • Alla tjänster som samverkar med tredjepartstjänster bör utföra ytterligare interoperabilitetstestning med dessa tredje parter.

  • Alla icke-Windows-program eller serveroperativsystem som används kräver undersökning/bekräftelse på att de har stöd för TLS 1.2. Skanning är det enklaste sättet att fastställa detta.

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

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

2. Genomsök källkoden och onlinetjänstkonfigurationsfilerna för hårdkodade TLS enligt beskrivningen i "Hitta och åtgärda TLS 1.0-beroenden i kod"

3. Uppdatera/kompilera om program efter behov:

   1. Hanterade appar

      1. Bygg om mot den senaste .NET Framework-versionen.

      2. Kontrollera att all användning av SSLProtocols-uppräkningen är inställd på SSLProtocols.None för att använda standardinställningarna för operativsystemet.

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

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 TLS-hårdkodning när de påträffas i testningen. Distribuera om programvaran och utför en ny regressionstestkörning.

Meddela partner om dina utfasningsplaner för TLS 1.0

När TLS-hårdkodningen har åtgärdats och uppdateringarna av operativsystemet/utvecklingsramverket har slutförts, bör du välja att ta bort TLS 1.0 måste du samordna med kunder och partner:

• Tidig partner-/kunduppsökande verksamhet är avgörande för en lyckad utfasning av TLS 1.0. Detta bör åtminstone bestå av blogginlägg, white paper eller annat webbinnehåll.

• Partner måste utvärdera sin egen TLS 1.2-beredskap genom de initiativ för operativsystemet/kodgenomsökning/regressionstestning som beskrivs i ovanstående avsnitt.

Conclusion

Att eliminera beroenden på TLS 1.0 är en komplex fråga att hantera i en helhetlig process. Microsofts och branschpartners vidtar åtgärder i dag för att säkerställa att hela vår produktstack är säkrare som standard, från våra OS-komponenter och utvecklingsramverk upp till de program/tjänster som bygger på dem. Genom att följa rekommendationerna i det här dokumentet hjälper du ditt företag att hitta rätt kurs och veta vilka utmaningar du kan förvänta dig. Det hjälper också dina egna kunder att bli mer förberedda för övergången.

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

Bilaga B: Avveckla TLS 1.0/1.1 medan man behåller FIPS-läge

Följ stegen nedan om nätverket kräver FIPS-läge, men du också vill avskaffa 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 Kurva 25519 (endast Server 2016) via gruppolicy.

3. Inaktivera alla chiffersviter med hjälp av algoritmer som inte tillåts av relevant FIPS-publikation. För Server 2016 (förutsatt att standardinställningarna gäller) innebär det att RC4, PSK och NULL-chiffer inaktiveras.

Bidragsgivare/Tack till

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