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

Av Andrew Marshall
Principal Security Program Manager
Microsoft Corporation

Sammanfattning

Det här dokumentet innehåller den senaste vägledningen om snabb identifiering och borttagning av TLS-protokollversion 1.0-beroenden (Transport Layer Security) i programvara som bygger på Microsofts operativsystem, och följer 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 operativsystem eller kryptobibliotek som inte kommer från Microsoft, ä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 det inte längre är standardsäkerhetsprotokollet som 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 och hållet.

Microsoft rekommenderar att kunderna kommer 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ötts av programvaruindustrin rekommenderar vi starkt 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 med TLS 1.0 eller äldre protokoll.

  • Fullständig regressionstestning via 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 TLS 1.2-supportproblem.

  • Samordning med dina egna affärspartner och kunder för att meddela dem om din flytt för att göra TLS 1.0 inaktuell.

  • 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. Om du slutför sådana undersökningar kan du minska effekten 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 smidiga lösningar (även kallade Crypto Agility) för att hantera framtida säkerhetsprotokollintrång. Även om det här dokumentet föreslår flexibla lösningar för eliminering av TLS-hårdkodning, ligger bredare Crypto Agility-lösningar 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äkerhetsproblem. På grund av risken för framtida nedgraderingsattacker 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 för 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 här innebär att TLS-versionen är fast 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 ändra programmet i fråga. Den här problemklassen kan inte åtgärdas utan ändringar i källkoden och distribution av programuppdateringar. Hårdkodning av protokollversioner var vanligt tidigare i testnings- och supportsyfte eftersom 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 standardvärden för TLS-version eller stödtak som måste redovisas. Användning av Windows 8/Server 2012 eller senare innebär att TLS 1.2 är standardversionen av säkerhetsprotokollet:

Bild 1: Stöd för säkerhetsprotokoll efter operativsystemversion

Windows OS SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2
Windows Vista Enabled Enabled Standardvärde Stöds inte Stöds inte
Windows Server 2008 Enabled Enabled Standardvärde Inaktiverad* Inaktiverad*
Windows 7 (WS2008 R2) Enabled Enabled Standardvärde Inaktiverad* Inaktiverad*
Windows 8 (WS2012) Inaktiverad Enabled Enabled Enabled Standardvärde
Windows 8.1 (WS2012 R2) Inaktiverad Enabled Enabled Enabled Standardvärde
Windows 10 Inaktiverad Enabled Enabled Enabled Standardvärde
Windows Server 2016 Stöds inte Inaktiverad Enabled Enabled Standardvärde

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

Mer information om utfasning av TLS 1.0/1.1 i IE/Edge finns i Modernisera TLS-anslutningar i Microsoft Edge och Internet Explorer 11, Ändringar som påverkar webbplatskompatibilitet 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 vid anslutning 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 kombinationer av simulerade klientoperativsystem/webbläsare vid anslutning till www.microsoft.com.

Om det inte redan är klart rekommenderar vi starkt att du gör en inventering av operativsystem som används av ditt företag, kunder och partner (de två sistnämnda via uppsökande/kommunikation eller minst HTTP-User-Agent strängsamling). Den här inventeringen kan kompletteras ytterligare med trafikanalys vid företagets nätverksgräns. I en sådan situation 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 som stöd för utfasning av TLS 1.0. Dessa omfattar:

  • 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 när 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 nå ut till sina egna kunder som kanske inte känner till sina egna TLS 1.0-beroenden.

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

  • .Net Framework-uppdateringar för att eliminera hårdkodning på appnivå och förhindra ramverksä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å svag TLS: Metodtips för Transport Layer Security (TLS) med .NET Framework

    • Obs! Alla appar som är inriktade på .NET 4.5 eller senare måste förmodligen ändras för att stödja TLS 1.2.
  • TLS 1.2 har återporterats 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 hårdkodas.

  2. Granska alla instanser av SecPkgContext_SupportedProtocols och SecPkgContext_ConnectionInfo strukturer 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 program med WinHTTP som finns på Server 2012 eller äldre.

    1. Hanterade appar – återskapa och ommåla mot den senaste .NET Framework-versionen

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

  6. För att 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. 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 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, 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 "SystemStandard" 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.

Återskapa/ommåla 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 begränsar stödet till TLS 1.0 oavsett de underliggande os-standardvärdena. Mer information finns i diagrammet nedan och metodtips för Transport Layer Security (TLS) med .NET Framework .

Rebuild managed applications

SystemDefaultTLSVersion har företräde framför mål på appnivå för TLS-versioner. Den rekommenderade bästa metoden är att alltid skjuta upp till 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 ditt program 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 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 förhandlar MTLS med ett certifikat från en annan plats än standardplatsen (utanför de namngivna standardcertifikatarkiven i Windows) kan koden behöva uppdateras för att säkerställa att certifikatet införskaffas korrekt.
  • Beroenden mellan tjänster bör granskas för felsökningspunkter.

    • Alla tjänster som samverkar med 3 rd-party-tjänster bör utföra ytterligare interop-testning med dessa 3rd-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. Genomsökning är det enklaste sättet att avgöra 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. Sök igenom källkoden och onlinetjänstkonfigurationsfilerna efter hårdkodad 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. Återskapa 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 kunna använda operativsystemets standardinställningar.

    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 vid testning. Distribuera om programvaran och utför en ny regressionstestkörning.

Meddela partner om dina utfasningsplaner för TLS 1.0

När TLS-hårdkodning har åtgärdats och uppdateringar av operativsystemet/utvecklingsramverket har slutförts, bör du välja att ta bort TLS 1.0 om du väljer 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, whitepapers eller annat webbinnehåll.

  • Partner måste utvärdera sin egen TLS 1.2-beredskap via operativsystemets/kodens genomsöknings-/regressionstestningsinitiativ som beskrivs i ovanstående avsnitt.

Slutsats

Att ta bort TLS 1.0-beroenden är ett komplicerat problem för att driva från slutpunkt till slutpunkt. 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 kan du hjälpa ditt företag att hitta rätt kurs och veta vilka utmaningar som kan förväntas. 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

Results of Handshake Simulation

Bilaga B: Föråldra TLS 1.0/1.1 samtidigt som FIPS-läget behålls

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

  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 grupprincip.

  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.

Deltagare/tack vare

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