Lösa TLS 1.0-problemet, 2:a utgåvan

Av Andrew Marshall
Principal Security Program Manager
Microsoft Corporation

Sammanfattning

Det här dokumentet presenterar de senaste råden om hur du snabbt identifierar och tar bort beroenden för Transport Layer Security (TLS) version 1.0 av programvara inbyggd på Microsofts operativsystem, som följer upp 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 i en TLS 1.2+-nätverksmiljö. Även om de lösningar som diskuteras här kan föra över och hjälpa till med att ta bort TLS 1.0-användning i andra operativsystem än Microsoft-operativsystem eller kryptobibliotek, är de inte fokus för det här dokumentet.

TLS 1.0 är ett säkerhetsprotokoll som först definierades 1999 för att etablera krypteringskanaler över datornätverk. Microsoft har stöd för detta protokoll sedan Windows XP/Server 2003. Även om det standardsäkerhetsprotokoll som används av moderna OSes inte längre stöds TLS 1.0 fortfarande för bakåtkompatibilitet. Framväxande regelkrav samt nya säkerhetsbrister i TLS 1.0 ger företag uppmuntran att inaktivera TLS 1.0 helt.

Microsoft rekommenderar kunder att gå vidare med problemet genom att ta bort TLS 1.0-beroenden i sina miljöer och inaktivera TLS 1.0 på operativsystemsnivå där det är möjligt. Givet hur lång tid TLS 1.0 har stöd av programvarubranschen rekommenderar vi starkt att utfasningsplan för TLS 1.0 inkluderar följande:

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

• Sökning av nätverksslutpunkter och trafikanalys för att identifiera operativsystem med TLS 1.0 eller äldre protokoll.

• Fullständig regressionstestning genom 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 i operativsystem som används av ditt företag för att identifiera eventuella problem med TLS 1.2-stöd.

• Koordination med dina egna affärspartner och kunder för att meddela dem om din flytt till utfasning av TLS 1.0.

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

Syftet 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 de ökar insynen i effekten av den här ändringen för dina egna kunder. Att slutföra sådana undersökningar kan minska påverkan på nästa säkerhetsrisk i TLS 1.0. I det här dokumentet innehåller referenser till utfasningen av TLS 1.0 även TLS 1.1.

Programvaruutvecklare inom företag har ett strategiska behov att använda mer framtida säkra och agile-lösningar (kallas annars Crypto Agility) för att hantera framtida säkerhetsprotokollkomprometter. I det här dokumentet föreslås agile-lösningar för uteslutningen av TLS-hårdkodning, medan bredare Crypto Agility-lösningar inte omfattas av det här dokumentet.

Aktuell status för Microsofts implementering av TLS 1.0

Microsofts implementering av TLS 1.0 är fri från kända säkerhetsproblem. På grund av risken för framtida nedgraderingsattacker i protokoll och andra 1.0-säkerhetsproblem som inte är specifika för Microsofts implementering, rekommenderar vi att beroenden av 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).

När du planerar för den här migreringen till TLS 1.2+ bör utvecklare och systemadministratörer vara medvetna om potentialen för protokollversionshårdkodning i program som utvecklats av deras anställda och partner. Hardcoding här innebär att TLS-versionen är korrigerad till en version som är inaktuell och mindre säker än nyare versioner. TLS-versioner senare än den hårdkodade versionen kan inte användas utan att programmet i fråga ändras. Den här problemklassen kan inte åtgärdas utan ändringar av källkoden och distribution av programuppdatering. Hardcoding för protokollversioner var vanligt förekommande tidigare för testning och stödbarhet då många olika webbläsare och operativsystem hade olika nivåer av TLS-stöd.

Säkerställa stöd för TLS 1.2 i distribuerade operativsystem

Många operativsystem har inaktuella standardinställningar för TLS-versioner eller support som måste redovisas. Användning av Windows 8/Server 2012 eller senare innebär att TLS 1.2 blir standardversionen av säkerhetsprotokoll:

Figur 1: Stöd för säkerhetsprotokoll i OS-version

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

Mer information om utfasningen av TLS 1.0/1.1 i IE/Edge finns i Moderniseraera TLS-anslutningar i Microsoft Edge och Internet Explorer 11, Ändringar som påverkar webbplatskompatibiliteten kommer till Microsoft Edge och Inaktiverar TLS/1.0 och TLS/1.1 i den nya Edge-webbläsaren

Ett snabbt sätt att avgöra vilken TLS-version som begärs av olika klienter när du ansluter till dina onlinetjänster är genom att referera till Handskakningsberäkningen på Qualys SSL-labb. Den här simuleringen täcker kombinationer av klient-OS/webbläsare mellan tillverkare. Se bilaga A i slutet av det här dokumentet för ett detaljerat exempel som visar vilka versioner av TLS-protokoll som har förhandlats fram av olika simulerade kombinationer av klientoperativsystem/webbläsare när du ansluter till www.microsoft.com.

Om detta inte redan är klart rekommenderar vi starkt att göra en inventering av operativsystem som används av ditt företag, kunder och partner (de senare två via upp-/kommunikation eller minst HTTP User-Agent strängsamling). Denna inventering kan ytterligare påverkas av trafikanalys på företagets nätverks-Edge. I sådana fall ger trafikanalys TLS-versionerna förhandlats fram av kunder/partners som ansluter till dina tjänster, men själva trafiken förblir krypterad.

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

Sedan v1-versionen av det här dokumentet har Microsoft levererat ett antal programvaruuppdateringar och nya funktioner till stöd för utfasningen av TLS 1.0. De omfattar:

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

  • Med denna loggning kan administratörer slutligen mäta sina kunders exponering för svag TLS.

• SecureScore – För att Office 365-innehavaradministratörer ska kunna identifiera sin egen svaga TLS-användning har SecureScore-portalen skapats för att dela den här informationen som stöd för TLS 1.0 i Office 365 i oktober 2018.

  • Den här portalen ger Office 365-innehavaradministratörer den värdefull information som de behöver för att kunna kontakta sina egna kunder, som kanske inte är medvetna om sina egna beroenden av TLS 1.0.

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

• .Net Framework-uppdateringar för att ta bort hårdkodning på appnivå och förhindra att framework-ärvda TLS 1.0-beroenden.

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

  • Obs! Alla appar som är anpassade till .NET 4.5 eller senare kommer sannolikt att behöva ändras för att det ska gå att stödja TLS 1.2.

• TLS 1.2 har bakåtporterats 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 Windows OS-angivna krypteringsbibliotek och säkerhetsprotokoll bör följande steg hjälpa till att identifiera alla hårdkodade TLS 1.0-användning i programmen:

1. Identifiera alla förekomster av AcquireCredentialsHandle(). Det här hjälper granskare att komma närmare kodblock där TLS kan vara hårdkodade.

2. Granska alla instanser av SecPkgContext_SupportedProtocols och SecPkgContext_ConnectionInfo för hårdkodade TLS.

3. I intern kod anger du tilldelningar som inte är noll för grbitEnabledProtocols till noll. Då kan operativsystemet använda sin standardversion av TLS.

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 hos Server 2012 eller tidigare.

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

   2. Programmen måste lägga till kod för att det ska gå att använda TLS 1.2 via WinHttpSetOption

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

   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 alla fall ovan är att ta bort valet av hårdkodad protokollversion och skjuta upp operativsystemets standardlösning. Om du använder DevSkim klickar duhär för att se regler som täcker de kontroller ovan som du kan använda med din egen kod.

Uppdatera Windows PowerShell skript eller relaterade registerinställningar

Windows PowerShell används .NET Framework 4.5, som inte innehåller TLS 1.2 som ett tillgängligt protokoll. Det finns två lösningar för att komma runt det här:

1.  Modify the script in question to include the following:
    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

2.  Add a system-wide registry key (e.g. via group policy) to any machine that needs to make TLS 1.2 connections from a .NET app. This will cause .NET to use the "System Default" TLS versions which adds TLS 1.2 as an available protocol AND it will allow the scripts to use future TLS Versions when the OS supports them. (e.g. 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ösningar (1) och (2) är ömsesidigt uteslutande, vilket innebär att de inte behöver implementeras tillsammans.

Återskapa/återskapa hanterade program med den senaste .Net Framework-versionen

Program som använder .NET Framework-versioner före 4.7 kan ha begränsningar som effektivt hjälper till att hantera TLS 1.0 oavsett underliggande os-standardinställningar. Mer information finns i diagrammet https://docs.microsoft.com/dotnet/framework/network-programming/tls nedan.

SystemDefaultTLSVersion har företräde framför programnivå för mål för TLS-versioner. Den rekommenderade metodinställningen är att alltid skjuta upp operativsystemets standardversion av TLS. Det är också den enda crypto-agile-lösningen som gör att dina appar kan dra nytta av det framtida stödet för TLS 1.3.

Om du riktar information till äldre versioner av .NET Framework till exempel 4.5.2 eller 3.5 används de äldre och rekommenderas inte som standard i programmet, 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.

Testar med TLS 1.2+

I enlighet med de korrigeringar som rekommenderas i avsnittet ovan bör produkter testas regressionstestade för fel i protokollförhandlingar och kompatibilitet med andra operativsystem i företaget.

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

  • Till exempel kan en Vista-klient inte förhandla fram TLS med en server som konfigurerats för TLS 1.2+ eftersom Vistas högsta stödda TLS-version är 1.0. Klienten ska antingen uppgraderas eller inaktiveras i en TLS 1.2+-miljö.

• Produkter som använder certifikatbaserad gemensam TLS-autentisering kan kräva ytterligare regressionstestning eftersom den kod för certifikaturval som är kopplad till TLS 1.0 var mindre uttrycksfull än för TLS 1.2.

  • Om en produkt förhandlar om MTLS med ett certifikat från en plats som inte är en standardplats (utanför de namngivna standardarkiven i Windows) kan den koden behöva uppdateras för att säkerställa att certifikatet förvärvas korrekt.

• Tjänsteproblem bör granskas för att se om det finns problem med platser.

  • Alla tjänster som fungerar tillsammans med tredjepartstjänster från 3^rdbör utföra ytterligare interopstestning med dessa 3^rd-parter.

  • Alla icke-Windows-program eller serveroperativsystemet som används kräver undersökning/bekräftelse på att de kan stödja TLS 1.2. Skanning är det enklaste sättet att avgöra det.

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

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

2. Skanna källkod och konfigurationsfiler för onlinetjänster efter hårdkodade TLS enligt beskrivningen i " Hitta och åtgärdaTLS 1.0-beroenden i kod"

3. Uppdatera/kompilera om program efter behov:

   1. Hanterade appar

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

      2. Verifiera all användning av SSLProtocols-uppräkning är inställd på SSLProtocols.None för att kunna 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 produktions- eller mellanlagringsmiljö med alla säkerhetsprotokoll ä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 vid testning. Distribuera om programvaran och kör ett nytt regressionstest.

Meddela partner om dina utfasningsplaner för TLS 1.0

Om du väljer att utfasa TLS 1.0 efter att TLS-hardcoding har hanterats och uppdateringar av operativsystemet/utvecklingsramen har slutförts, är det nödvändigt att samordna med kunder och partner:

• Tidig utfasning av partner/kund är nödvändigt för en lyckad utfasning av TLS 1.0. Det bör åtminstone bestå av blogginlägg, informationsbladet eller annat webbinnehåll.

• Partner måste var och en utvärdera sin egen beredskap hos TLS 1.2 genom operativsystemet/kodsökning/regressionstestningsinitiativ som beskrivs i ovanstående avsnitt.

Sammanfattning

Att ta bort TLS 1.0-beroenden är ett komplicerat problem för att få enheten att sluta. Microsofts och branschpartner arbetar på det här idag för att säkerställa att hela vår produktstack är säkrare som standard, från våra OS-komponenter och utvecklingsramar till de program/tjänster som bygger på dem. Genom att följa rekommendationerna i det här dokumentet får ditt företag en bra diagram över kursen och vilka utmaningar du kan förvänta dig. Det kommer också att hjälpa dina egna kunder att bli mer förberedda på övergången.

Bilaga A: Handskakning av simulering för olika klienter som ansluter www.microsoft.com, men SSLLabs.com

Bilaga B: Tar bort TLS 1.0/1.1 men behåller FIPS-läge

Följ stegen nedan om nätverket kräver FIPS-läge men du även vill utfasa TLS 1.0/1.1:

1. Konfigurera TLS-versioner via registret genomatt ange "Aktiverad" till noll för oönskade TLS-versioner.

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

3. Inaktivera alla chiffersviter med hjälp av algoritmer som inte är tillåtna av relevant FIPS-publikation. För Server 2016 (under förutsättning att standardinställningarna är i kraft) innebär det att RC4, PSK och NULL-chiffer inaktiveras.

Deltagare/Tack till

Markera Cartwright
Sådd
Patrick Patrick Patricks
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommer den här
Andrei Popov
Michich Short
Justin Burke
Gov Maharaj
Brad Bengt Bengt
Sean Stevenson