Het TLS 1.0-probleem oplossen, 2e editie

Door Andrew Marshall
Principal Security Program Manager
Microsoft Corporation

Samenvatting

In dit document vindt u de nieuwste richtlijnen voor het snel identificeren en verwijderen van TLS-protocolversie 1.0-afhankelijkheden in software die is gebouwd op microsoft-besturingssystemen, met informatie over productwijzigingen en nieuwe functies die door Microsoft worden geleverd om uw eigen klanten en onlineservices te beschermen. Het is bedoeld om te worden gebruikt als uitgangspunt voor het bouwen van een migratieplan naar een TLS 1.2+ netwerkomgeving. Hoewel de oplossingen die hier worden besproken, kunnen tls 1.0-gebruik in niet-Microsoft-besturingssystemen of cryptobibliotheken worden verwijderd, maar zijn ze niet gericht op dit document.

TLS 1.0 is een beveiligingsprotocol dat voor het eerst in 1999 is gedefinieerd voor het tot stand brengen van versleutelingskanalen via computernetwerken. Microsoft heeft dit protocol ondersteund sinds Windows XP/Server 2003. Hoewel het standaardbeveiligingsprotocol niet meer wordt gebruikt door moderne besturingssystemen, wordt TLS 1.0 nog steeds ondersteund voor compatibiliteit met eerdere versies. Het ontwikkelen van wettelijke vereisten en nieuwe beveiligingsproblemen in TLS 1.0 bieden bedrijven de stimulans om TLS 1.0 volledig uit te schakelen.

Microsoft raadt klanten aan dit probleem voor te gaan door TLS 1.0-afhankelijkheden in hun omgevingen te verwijderen en TLS 1.0 waar mogelijk uit te schakelen op besturingssysteemniveau. Gezien de tijdsduur dat TLS 1.0 wordt ondersteund door de software-industrie, wordt het ten zeerste aanbevolen dat een TLS 1.0-afschaffingsplan het volgende omvat:

  • Codeanalyse om vastgelegde exemplaren van TLS 1.0 of oudere beveiligingsprotocollen te vinden/herstellen.

  • Netwerkeindpuntscans en verkeersanalyse om besturingssystemen te identificeren met behulp van TLS 1.0 of oudere protocollen.

  • Volledige regressietests via de volledige toepassingsstack waarbij TLS 1.0 is uitgeschakeld.

  • Migratie van verouderde besturingssystemen en ontwikkelingsbibliotheken/frameworks naar versies die standaard kunnen onderhandelen over TLS 1.2.

  • Compatibiliteitstests in besturingssystemen die door uw bedrijf worden gebruikt om eventuele ondersteuningsproblemen met TLS 1.2 te identificeren.

  • Coördinatie met uw eigen zakelijke partners en klanten om hen op de hoogte te stellen van uw overstap om TLS 1.0 te verwijderen.

  • Begrijpen welke clients mogelijk geen verbinding meer kunnen maken met uw servers zodra TLS 1.0 is uitgeschakeld.

Het doel van dit document is aanbevelingen te bieden waarmee technische blokkerende gebruikers TLS 1.0 kunnen uitschakelen, terwijl tegelijkertijd de impact van deze wijziging op uw eigen klanten wordt vergroot. Het voltooien van dergelijke onderzoeken kan helpen de bedrijfsimpact van het volgende beveiligingsprobleem in TLS 1.0 te verminderen. Voor het doel van dit document bevatten verwijzingen naar de afschaffing van TLS 1.0 ook TLS 1.1.

Enterprise-softwareontwikkelaars hebben een strategische noodzaak om meer toekomstveilige en flexibele oplossingen (ook wel cryptoflexibiliteit genoemd) te gebruiken om toekomstige inbreuk op het beveiligingsprotocol op te vangen. Hoewel dit document flexibele oplossingen voorstelt voor het verwijderen van TLS-hardcodering, vallen bredere cryptoflexibiliteitsoplossingen buiten het bereik van dit document.

De huidige status van de TLS 1.0-implementatie van Microsoft

De TLS 1.0-implementatie van Microsoft is gratis van bekende beveiligingsproblemen. Vanwege het potentieel voor toekomstige protocol downgradeaanvallen en andere TLS 1.0-beveiligingsproblemen die niet specifiek zijn voor de implementatie van Microsoft, wordt aanbevolen dat afhankelijkheden van alle beveiligingsprotocollen die ouder zijn dan TLS 1.2, waar mogelijk worden verwijderd (TLS 1.1/1.0/ SSLv3/SSLv2).

Bij het plannen van deze migratie naar TLS 1.2+ moeten ontwikkelaars en systeembeheerders op de hoogte zijn van de mogelijkheden voor het coderen van protocolversies in toepassingen die zijn ontwikkeld door hun werknemers en partners. Hardcoding hier betekent dat de TLS-versie is vastgezet op een versie die verouderd en minder veilig is dan nieuwere versies. TLS-versies die hoger zijn dan de vastgelegde versie, kunnen niet worden gebruikt zonder het betreffende programma te wijzigen. Deze klasse van probleem kan niet worden opgelost zonder broncodewijzigingen en implementatie van software-updates. Hardcodering van protocolversies was in het verleden gebruikelijk voor test- en ondersteuningsdoeleinden, omdat veel verschillende browsers en besturingssystemen verschillende niveaus van TLS-ondersteuning hadden.

Ondersteuning voor TLS 1.2 garanderen voor geïmplementeerde besturingssystemen

Veel besturingssystemen hebben verouderde TLS-versies of ondersteuningsplafonds waarvoor rekening moet worden gehouden. Gebruik van Windows 8/Server 2012 of hoger betekent dat TLS 1.2 de standaardversie van het beveiligingsprotocol is:

Afbeelding 1: Security Protocol Support by OS Version

Windows OS SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2
Windows Vista Ingeschakeld Ingeschakeld Standaard Niet ondersteund Niet ondersteund
Windows Server 2008 Ingeschakeld Ingeschakeld Standaard Uitgeschakeld* Uitgeschakeld*
Windows 7 (WS2008 R2) Ingeschakeld Ingeschakeld Standaard Uitgeschakeld* Uitgeschakeld*
Windows 8 (WS2012) Uitgeschakeld Ingeschakeld Ingeschakeld Ingeschakeld Standaard
Windows 8.1 (WS2012 R2) Uitgeschakeld Ingeschakeld Ingeschakeld Ingeschakeld Standaard
Windows 10 Uitgeschakeld Ingeschakeld Ingeschakeld Ingeschakeld Standaard
Windows Server 2016 Niet ondersteund Uitgeschakeld Ingeschakeld Ingeschakeld Standaard

*TLS 1.1/1.2 kan worden ingeschakeld op Windows Server 2008 via dit optionele Windows Update-pakket.

Zie voor meer informatie over afschaffing van TLS 1.0/1.1 in IE/Edge TLS-verbindingen moderniseren in Microsoft Edge en Internet Explorer 11, wijzigingen die invloed hebben op sitecompatibiliteit die van invloed zijn op Microsoft Edge en TLS/1.0 en TLS/1.1 uitschakelen in de nieuwe Edge-browser

Een snelle manier om te bepalen welke TLS-versie wordt aangevraagd door verschillende clients wanneer u verbinding maakt met uw onlineservices, is door te verwijzen naar de Handshake-simulatie bij Qualys SSL Labs. Deze simulatie omvat combinaties van clientbesturingssystemen/browser tussen fabrikanten. Zie bijlage A aan het einde van dit document voor een gedetailleerd voorbeeld met de TLS-protocolversies die zijn onderhandeld door verschillende combinaties van het client-besturingssysteem/de browser wanneer u verbinding maakt met www.microsoft.com.

Als dit nog niet is voltooid, wordt het ten zeerste aanbevolen om een inventarisatie uit te voeren van besturingssystemen die door uw onderneming, klanten en partners worden gebruikt (de laatste twee via communicatie of ten minste HTTP User-Agent tekenreeksverzameling). Deze inventaris kan verder worden aangevuld door verkeersanalyse aan de rand van uw bedrijfsnetwerk. In een dergelijke situatie levert een verkeersanalyse de TLS-versies op die zijn onderhandeld door klanten/partners die verbinding maken met uw services, maar het verkeer zelf blijft versleuteld.

Technische verbeteringen van Microsoft om TLS 1.0-afhankelijkheden te elimineren

Sinds de v1-versie van dit document heeft Microsoft een aantal software-updates en nieuwe functies geleverd ter ondersteuning van TLS 1.0-afschaffing. Deze omvatten:

  • Aangepaste IIS-logboekregistratie om client-IP-/gebruikersagenttekenreeks, service-URI, tls-protocolversie en coderingssuite te correleren.

    • Met deze logboekregistratie kunnen beheerders eindelijk de blootstelling van hun klanten aan zwakke TLS kwantificeren.
  • SecureScore : om Office 365-tenantbeheerders te helpen hun eigen zwakke TLS-gebruik te identificeren, is de SecureScore-portal gebouwd om deze informatie te delen als ondersteuning voor TLS 1.0 afgesloten in Office 365 in oktober 2018.

    • Deze portal biedt Office 365-tenantbeheerders de waardevolle informatie die ze nodig hebben om contact op te leggen met hun eigen klanten die mogelijk niet op de hoogte zijn van hun eigen TLS 1.0-afhankelijkheden.

    • Ga naar https://securescore.microsoft.com/ voor meer informatie.

  • .Net Framework-updates om hardcodering op app-niveau te elimineren en framework-overgenomen TLS 1.0-afhankelijkheden te voorkomen.

  • Ontwikkelaarsrichtlijnen en software-updates zijn uitgebracht om klanten te helpen .Net-afhankelijkheden op zwakke TLS te identificeren en te elimineren: Best practices voor Transport Layer Security (TLS) met .NET Framework

    • Ter informatie: alle apps die zijn gericht op .NET 4.5 of lager, moeten waarschijnlijk worden gewijzigd om TLS 1.2 te ondersteunen.
  • TLS 1.2 is teruggezet naar Windows Server 2008 SP2 en XP POSReady 2009 om klanten te helpen met verouderde verplichtingen.

  • Begin 2019 worden er meer aankondigingen gedaan en in latere updates van dit document gecommuniceerd.

TLS 1.0-afhankelijkheden zoeken en herstellen in code

Voor producten die gebruikmaken van de door het Besturingssysteem geleverde cryptografiebibliotheken en beveiligingsprotocollen van Windows, moeten de volgende stappen helpen bij het identificeren van elk vast gecodeerd TLS 1.0-gebruik in uw toepassingen:

  1. Identificeer alle exemplaren van AcquireCredentialsHandle(). Dit helpt revisoren dichter bij codeblokken te komen waar TLS mogelijk is vastgelegd.

  2. Controleer alle exemplaren van de SecPkgContext_SupportedProtocols en SecPkgContext_ConnectionInfo structuren voor vastgelegde TLS.

  3. Stel in systeemeigen code alle toewijzingen van grbitEnabledProtocols in op nul. Hierdoor kan het besturingssysteem de standaard TLS-versie gebruiken.

  4. Schakel de FIPS-modus uit als deze is ingeschakeld vanwege het potentieel voor conflict met instellingen die zijn vereist voor het expliciet uitschakelen van TLS 1.0/1.1 in dit document. Zie bijlage B voor meer informatie.

  5. Werk toepassingen bij en hercompileren met WinHTTP die worden gehost op Server 2012 of ouder.

    1. Beheerde apps: herbouwen en opnieuw werken op basis van de nieuwste .NET Framework-versie

    2. Toepassingen moeten code toevoegen ter ondersteuning van TLS 1.2 via WinHttpSetOption

  6. Als u alle bases wilt behandelen, scant u broncode en onlineserviceconfiguratiebestanden voor de onderstaande patronen die overeenkomen met geïnventareerde typewaarden die vaak worden gebruikt in TLS-hardcodering:

    1. SecurityProtocolType

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

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL of PROTOCOL_TLS

De aanbevolen oplossing in alle bovenstaande gevallen is het verwijderen van de vastgelegde protocolversieselectie en de standaardinstelling van het besturingssysteem uitstellen. Als u DevSkim gebruikt, klikt u hier om regels te zien voor de bovenstaande controles die u met uw eigen code kunt gebruiken.

Windows PowerShell maakt gebruik van .NET Framework 4.5, die GEEN TLS 1.2 als beschikbaar protocol bevat. Om dit te omzeilen, zijn er twee oplossingen beschikbaar:

  1. Wijzig het betreffende script om het volgende op te nemen:

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
    
  2. Voeg een systeembrede registersleutel (bijvoorbeeld via groepsbeleid) toe aan elke computer die TLS 1.2-verbindingen vanuit een .NET-app moet maken. Dit zorgt ervoor dat .NET de TLS-versies 'Systeem standaard' gebruikt die TLS 1.2 als een beschikbaar protocol toevoegt. Hierdoor kunnen de scripts toekomstige TLS-versies gebruiken wanneer het besturingssysteem deze ondersteunt. (bijvoorbeeld 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

Oplossingen (1) en (2) sluiten elkaar wederzijds uit, wat betekent dat ze niet samen hoeven te worden geïmplementeerd.

Beheerde toepassingen herbouwen/opnieuw beheren met behulp van de nieuwste versie van .Net Framework

Toepassingen die gebruikmaken van .NET Framework-versies vóór 4.7 kunnen beperkingen hebben voor het effectief beperken van ondersteuning voor TLS 1.0, ongeacht de standaardinstellingen van het onderliggende besturingssysteem. Raadpleeg het onderstaande diagram en de best practices voor Transport Layer Security (TLS) met .NET Framework voor meer informatie.

Rebuild managed applications

SystemDefaultTLSVersion heeft voorrang op app-niveau gericht op TLS-versies. De aanbevolen aanbevolen procedure is om altijd de standaard TLS-versie van het besturingssysteem uit te stellen. Het is ook de enige crypto agile-oplossing waarmee uw apps kunnen profiteren van toekomstige TLS 1.3-ondersteuning.

Als u zich richt op oudere versies van .NET Framework, zoals 4.5.2 of 3.5, gebruikt uw toepassing standaard de oudere en niet aanbevolen protocollen zoals SSL 3.0 of TLS 1.0. U wordt ten zeerste aangeraden een upgrade uit te voeren naar nieuwere versies van .NET Framework, zoals .NET Framework 4.6 of de juiste registersleutels in te stellen voor UseStrongCrypto.

Testen met TLS 1.2+

Na de oplossingen die in de bovenstaande sectie worden aanbevolen, moeten producten worden getest op protocolonderhandelingsfouten en compatibiliteit met andere besturingssystemen in uw onderneming.

  • Het meest voorkomende probleem in deze regressietest is een TLS-onderhandelingsfout vanwege een clientverbindingspoging van een besturingssysteem of browser die TLS 1.2 niet ondersteunt.

    • Een Vista-client kan bijvoorbeeld niet onderhandelen over TLS met een server die is geconfigureerd voor TLS 1.2+ omdat de maximaal ondersteunde TLS-versie van Vista 1.0 is. Deze client moet worden geüpgraded of buiten gebruik gesteld in een TLS 1.2+-omgeving.
  • Voor producten die gebruikmaken van wederzijdse TLS-verificatie op basis van certificaten, is mogelijk extra regressietests vereist omdat de certificaatselectiecode die is gekoppeld aan TLS 1.0 minder expressief was dan voor TLS 1.2.

    • Als een product onderhandelt over MTLS met een certificaat van een niet-standaardlocatie (buiten de standaardcertificaatarchieven in Windows), moet die code mogelijk worden bijgewerkt om ervoor te zorgen dat het certificaat correct wordt verkregen.
  • Service-interafhankelijkheden moeten worden gecontroleerd op problemen.

    • Alle diensten die samenwerken met 3 rd-party-services, moeten aanvullende interop-tests uitvoeren met die 3rd party's.

    • Alle niet-Windows-toepassingen of serverbesturingssystemen die in gebruik zijn, vereisen onderzoek/bevestiging dat ze TLS 1.2 kunnen ondersteunen. Scannen is de eenvoudigste manier om dit te bepalen.

Een eenvoudige blauwdruk voor het testen van deze wijzigingen in een onlineservice bestaat uit het volgende:

  1. Voer een scan uit van productieomgevingssystemen om besturingssystemen te identificeren die GEEN ondersteuning bieden voor TLS 1.2.

  2. Scan broncode- en onlineserviceconfiguratiebestanden voor in code vastgelegde TLS, zoals beschreven in 'TLS 1.0-afhankelijkheden zoeken en herstellen in code'

  3. Toepassingen bijwerken/opnieuw compileren zoals vereist:

    1. Managed apps

      1. Bouw opnieuw op basis van de nieuwste .NET Framework-versie.

      2. Controleer of het gebruik van de opsomming SSLProtocols is ingesteld op SSLProtocols.None om de standaardinstellingen van het besturingssysteem te gebruiken.

    2. WinHTTP-apps - herbouwen met WinHttpSetOption ter ondersteuning van TLS 1.2

  4. Begin met testen in een preproductie- of faseringsomgeving waarbij alle beveiligingsprotocollen ouder dan TLS 1.2 zijn uitgeschakeld via het register.

  5. Corrigeer eventuele resterende exemplaren van TLS-hardcoding tijdens het testen. Implementeer de software opnieuw en voer een nieuwe regressietest uit.

Partners informeren over uw TLS 1.0-afschaffingsplannen

Nadat TLS-hardcoding is opgelost en updates van het besturingssysteem/ontwikkelingsframework zijn voltooid, moet u ervoor kiezen OM TLS 1.0 te verwijderen, moet u het coördineren met klanten en partners:

  • Vroege partner-/klantactiviteiten zijn essentieel voor een succesvolle implementatie van TLS 1.0-afschaffing. Dit moet minimaal bestaan uit blogberichten, whitepapers of andere webinhoud.

  • Partners moeten elk hun eigen TLS 1.2-gereedheid evalueren via het besturingssysteem/codescans/regressietests die in de bovenstaande secties worden beschreven.

Conclusie

Het verwijderen van TLS 1.0-afhankelijkheden is een ingewikkeld probleem om end-to-end te rijden. Microsoft- en branchepartners ondernemen momenteel actie om ervoor te zorgen dat onze volledige productstack standaard veiliger is, van onze besturingssysteemonderdelen en ontwikkelingsframeworks tot de toepassingen/services die hierop zijn gebouwd. Als u de aanbevelingen in dit document volgt, kunt u de juiste cursus in kaart brengen en weten welke uitdagingen u kunt verwachten. Het helpt uw eigen klanten ook meer voorbereid te worden op de overgang.

Bijlage A: Handshake Simulatie voor verschillende clients die verbinding maken met www.microsoft.com, met dank aan SSLLabs.com

Results of Handshake Simulation

Bijlage B: TLS 1.0/1.1 wordt afgeschaft terwijl de FIPS-modus behouden blijft

Volg de onderstaande stappen als voor uw netwerk de FIPS-modus is vereist, maar u ook TLS 1.0/1.1 wilt afschappen:

  1. Configureer TLS-versies via het register door 'Ingeschakeld' in te stellen op nul voor de ongewenste TLS-versies.

  2. Schakel curve 25519 (alleen Server 2016) uit via Groepsbeleid.

  3. Schakel coderingssuites uit met behulp van algoritmen die niet zijn toegestaan door de relevante FIPS-publicatie. Voor Server 2016 (ervan uitgaande dat de standaardinstellingen van kracht zijn) betekent dit het uitschakelen van RC4-, PSK- en NULL-coderingen.

Inzenders/dankzij

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