Het TLS 1.0-probleem oplossen, 2e editie
Door Andrew Marshall
Principal Security Program Manager
Microsoft Corporation
Samenvatting van leidinggevenden
Dit document bevat de meest recente richtlijnen voor het snel identificeren en verwijderen van TLS-protocolafhankelijkheden (Transport Layer Security) in software die bovenop Microsoft-besturingssystemen is gebouwd, 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 maken van een migratieplan naar een TLS 1.2+ netwerkomgeving. Hoewel de oplossingen die hier worden besproken, kunnen worden overgenomen en helpen bij het verwijderen van TLS 1.0-gebruik in niet-Microsoft-besturingssystemen of cryptobibliotheken, zijn ze geen focus van dit document.
TLS 1.0 is een beveiligingsprotocol dat voor het eerst is gedefinieerd in 1999 voor het opzetten van versleutelingskanalen via computernetwerken. Microsoft heeft dit protocol ondersteund sinds Windows XP/Server 2003. Hoewel TLS 1.0 niet langer het standaardbeveiligingsprotocol is dat door moderne OSe's wordt gebruikt, wordt TLS 1.0 nog steeds ondersteund voor compatibiliteit met achteruit. Veranderende regelgevingsvereisten 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 zijn door TLS 1.0-afhankelijkheden in hun omgeving te verwijderen en waar mogelijk TLS 1.0 uit te zetten op het besturingssysteemniveau. Gezien de tijdsduur die TLS 1.0 door de software-industrie wordt ondersteund, wordt ten zeerste aanbevolen dat een TLS 1.0-afbouwplan het volgende bevat:
Codeanalyse om hardcoded exemplaren van TLS 1.0 of oudere beveiligingsprotocollen te zoeken/oplossen.
Netwerk-eindpunten scannen en verkeersanalyse om besturingssystemen te identificeren met TLS 1.0 of oudere protocollen.
Volledige regressietests door de hele toepassingsstapel met TLS 1.0 uitgeschakeld.
Migratie van oudere besturingssystemen en ontwikkelingsbibliotheken/frameworks naar versies die standaard kunnen worden gebruikt voor TLS 1.2.
Compatibiliteitstests voor besturingssystemen die door uw bedrijf worden gebruikt om eventuele TLS 1.2-ondersteuningsproblemen te identificeren.
Coördinatie met uw eigen zakenpartners en klanten om hen op de hoogte te stellen van uw overstap om TLS 1.0 af te zetten.
Inzicht in welke clients mogelijk geen verbinding meer kunnen maken met uw servers wanneer TLS 1.0 is uitgeschakeld.
Het doel van dit document is om aanbevelingen te geven waarmee technische blokkeringen kunnen worden verwijderd voor het uitschakelen van TLS 1.0, terwijl tegelijkertijd de zichtbaarheid van de gevolgen van deze wijziging voor uw eigen klanten wordt vergroten. Als u dergelijke onderzoeken voltooit, kunt u de zakelijke impact van het volgende beveiligingsprobleem in TLS 1.0 verminderen. Voor de doeleinden van dit document bevatten verwijzingen naar de intrekking van TLS 1.0 ook TLS 1.1.
Ontwikkelaars van bedrijfssoftware hebben een strategische behoefte aan meer toekomstveilige en agile-oplossingen (ook wel bekend als Crypto Agile) om toekomstige beveiligingsprotocolcompromitteerden aan te kunnen. Hoewel in dit document agile-oplossingen worden voorgesteld voor het verwijderen van TLS-hardcoding, vallen bredere oplossingen voor Crypto Agile 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 vrij van bekende beveiligingsproblemen. Vanwege het potentieel voor toekomstige protocoldowngradingaanvallen en andere TLS 1.0-beveiligingslekken die niet specifiek zijn voor de implementatie van Microsoft, wordt aanbevolen om afhankelijkheden van alle beveiligingsprotocollen ouder dan TLS 1.2 waar mogelijk te verwijderen (TLS 1.1/1.0/ SSLv3/SSLv2).
Bij het plannen van deze migratie naar TLS 1.2+ moeten ontwikkelaars en systeembeheerders zich bewust zijn van de mogelijkheden voor hardcoding van protocolversies in toepassingen die zijn ontwikkeld door hun werknemers en partners. Hardcoding betekent hier dat de TLS-versie is gefixeerd op een versie die verouderd en minder veilig is dan nieuwere versies. TLS-versies die nieuwer zijn dan de hardcoded versie, kunnen niet worden gebruikt zonder het programma in kwestie te wijzigen. Deze probleemklasse kan niet worden opgelost zonder broncodewijzigingen en implementatie van software-update. Hardcoding 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 voor geïmplementeerde besturingssystemen
Veel besturingssystemen hebben verouderde TLS-versie defaults of ondersteuningsplafonds die moeten worden verantwoord. Gebruik van Windows 8/Server 2012 of hoger betekent dat TLS 1.2 de standaardversie van het beveiligingsprotocol is:
Afbeelding 1: Beveiligingsprotocolondersteuning per besturingssysteemversie
| 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 TLS/1.0 en Microsoft Edge Internet Explorer 11 ,Wijzigingen die van invloed zijn op sitecompatibiliteit in Microsoft Edge en TLS/1.0 en TLS/1.1 uitschakelen in de nieuwe Edge-browser voor meer informatie over de intrekking van TLS 1.0/1.1 in IE/Edge.
Een snelle manier om te bepalen welke TLS-versie door verschillende clients wordt aangevraagd wanneer u verbinding maakt met uw onlineservices, is door te verwijzen naar de Handshake-simulatie bij Qualys SSL Labs. Deze simulatie heeft betrekking op client os/browser combinaties tussen fabrikanten. Zie Bijlage A aan het einde van dit document voor een gedetailleerd voorbeeld van de TLS-protocolversies waarover verschillende gesimuleerde client-OS/browsercombinaties zijn onderhandeld wanneer u verbinding maakt met www.microsoft.com.
Als dit nog niet is voltooid, wordt het ten zeerste aangeraden een inventaris uit te voeren van besturingssystemen die worden gebruikt door uw onderneming, klanten en partners (de laatste twee via reikwijdte/communicatie of ten minste HTTP User-Agent tekenreeksverzameling). Deze inventaris kan verder worden aangevuld door verkeersanalyse aan de netwerkrand van uw bedrijf. In een dergelijke situatie levert verkeersanalyse de TLS-versies op waarover is 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-release van dit document heeft Microsoft een aantal software-updates en nieuwe functies geleverd ter ondersteuning van de intrekking van TLS 1.0. Deze omvatten:
AANGEPASTE IIS-logboekregistratie om de client-IP-/gebruikersagentreeks, service-URI, TLS-protocolversie en codeersuite 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 gemaakt om deze informatie te delen als ondersteuning voor TLS 1.0 die in Office 365 oktober 2018 is afgesloten.
Deze portal biedt Office 365 tenantbeheerders de waardevolle informatie die ze nodig hebben om contact op te zoeken 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 to eliminate app-level hardcoding and prevent framework-inherited TLS 1.0 dependencies.Net Framework updates to eliminate app-level hardcoding and prevent framework-inherited TLS 1.0 dependencies.
Ontwikkelaars richtlijnen en software-updates zijn uitgebracht om klanten te helpen .Net-afhankelijkheden op zwakke TLS te identificeren en te verwijderen: TLS-best practices (Transport Layer Security) met de .NET Framework
- TER INFORMATIE: Alle apps die zich richten op .NET 4.5 of lager, moeten waarschijnlijk worden gewijzigd om TLS 1.2 te ondersteunen.
TLS 1.2 is backported naar Windows Server 2008 SP2 en XP POSReady 2009 om klanten te helpen met oudere verplichtingen.
Er worden begin 2019 meer aankondigingen gedaan en in de volgende updates van dit document gecommuniceerd.
TLS 1.0-afhankelijkheden zoeken en oplossen in code
Voor producten die gebruikmaken Windows door besturingssysteem geleverde cryptografiebibliotheken en beveiligingsprotocollen, moeten de volgende stappen helpen bij het identificeren van hardcoded TLS 1.0-gebruik in uw toepassingen:
Alle exemplaren van AcquireCredentialsHandle() identificeren. Dit helpt revisoren dichter bij codeblokken te komen waar TLS mogelijk is gehard.
Controleer eventuele exemplaren van de SecPkgContext_SupportedProtocols en SecPkgContext_ConnectionInfo voor hardcoded TLS.
Stel in de oorspronkelijke code alle niet-nultoewijzingen van grbitEnabledProtocols in op nul. Hierdoor kan het besturingssysteem de standaard TLS-versie gebruiken.
Schakel de FIPS-modus uit als deze is ingeschakeld vanwege het mogelijke conflict met instellingen die nodig zijn voor het expliciet uitschakelen van TLS 1.0/1.1 in dit document. Zie Bijlage B voor meer informatie.
Alle toepassingen bijwerken en opnieuw aanvullen met WinHTTP dat wordt gehost op Server 2012 of ouder.
Beheerde apps: herbouwen en retargeten op de nieuwste .NET Framework versie
Toepassingen moeten code toevoegen ter ondersteuning van TLS 1.2 via WinHttpSetOption
Als u alle basissen wilt dekken, scant u broncode- en onlineserviceconfiguratiebestanden voor de onderstaande patronen die overeenkomen met de waarden van het type die vaak worden gebruikt in TLS-hardcoding:
SecurityProtocolType
SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11
WINHTTP_FLAG_SECURE_PROTOCOL_
SP_PROT_
NSStreamSocketSecurityLevel
PROTOCOL_SSL of PROTOCOL_TLS
De aanbevolen oplossing in alle bovenstaande gevallen is het verwijderen van de hardcoded protocolversieselectie en het standaard uitstellen van het besturingssysteem. Als u DevSkimgebruikt, klikt u hier om regels te zien voor de bovenstaande controles die u met uw eigen code kunt gebruiken.
Scripts Windows PowerShell gerelateerde registerinstellingen bijwerken
Windows PowerShell gebruikt .NET Framework 4.5, die TLS 1.2 niet als een beschikbaar protocol bevat. Hiervoor zijn twee oplossingen beschikbaar:
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
Oplossingen (1) en (2) sluiten elkaar uit, wat betekent dat ze niet samen hoeven te worden geïmplementeerd.
Beheerde toepassingen opnieuw opbouwen/retargeten met de nieuwste .Net Framework-versie
Toepassingen met .NET-frameworkversies die vóór 4.7 zijn gebruikt, kunnen beperkingen hebben om de ondersteuning voor TLS 1.0 effectief af te ronden, ongeacht de onderliggende besturingssysteeminstellingen. Raadpleeg het onderstaande diagram en https://docs.microsoft.com/dotnet/framework/network-programming/tls voor meer informatie.

SystemDefaultTLSVersion heeft voorrang op app-targeting van TLS-versies. De aanbevolen aanbevolen aanbevolen aanbevolen optie is om altijd uit te stellen naar de standaardversie van het besturingssysteem TLS. 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. Het 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 fouten bij protocolonderhandeling en compatibiliteit met andere besturingssystemen in uw onderneming.
Het meest voorkomende probleem in deze regressietest is een TLS-onderhandelingenfout als gevolg van een poging tot clientverbinding vanuit een besturingssysteem of browser die geen ondersteuning biedt voor TLS 1.2.
- Een Vista-client kan bijvoorbeeld niet over TLS onderhandelen 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 op certificaten gebaseerde wederzijdse TLS-verificatie is mogelijk extra regressietests vereist, omdat de certificaatselectiecode die is gekoppeld aan TLS 1.0 minder expressief was dan die voor TLS 1.2.
- Als een product MTLS onderhandelt met een certificaat vanaf een niet-standaardlocatie (buiten de standaard met namen genoemde certificaatopslag in Windows), moet deze code mogelijk worden bijgewerkt om ervoor te zorgen dat het certificaat correct wordt verkregen.
Service interdependencies moeten worden gecontroleerd op problemen.
Alle services die interopereren met services vanderden,moeten aanvullende interop-tests uitvoeren met deze3 derden.
Voor niet-Windows toepassingen of serverbesturingssystemen die worden gebruikt, moet worden onderzocht of bevestigd 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 de volgende:
Een scan uitvoeren van productieomgevingsystemen om besturingssystemen te identificeren die TLS 1.2 niet ondersteunen.
Scan broncode- en onlineserviceconfiguratiebestanden voor hardcoded TLS zoals beschreven in 'TLS 1.0-afhankelijkhedenzoeken en oplossen in code'
Update/recompile applications as required:
Beheerde apps
Opnieuw opbouwen met de nieuwste .NET Framework versie.
Controleer of het gebruik van de SSLProtocols-verzameling is ingesteld op SSLProtocols.None om de standaardinstellingen van het besturingssysteem te gebruiken.
WinHTTP-apps: opnieuw opbouwen met WinHttpSetOption ter ondersteuning van TLS 1.2
Begin met testen in een pre-productie- of faseringsomgeving met alle beveiligingsprotocollen ouder dan TLS 1.2 uitgeschakeld via register.
Fix any remaining instances of TLS hardcoding as they are encountered in testing. Redeploy de software en voer een nieuwe regressietest uit.
Partners op de hoogte stellen van uw TLS 1.0-afzettingsplannen
Nadat TLS-hardcoding is opgelost en de frameworkupdates voor besturingssysteem/ontwikkeling zijn voltooid, moet u ervoor kiezen om TLS 1.0 af te trekken, is het noodzakelijk om te coördineren met klanten en partners:
Vroegtijdige samenwerking tussen partners en klanten is essentieel voor een succesvolle uitrol van TLS 1.0-afzetting. Dit moet minimaal bestaan uit blogberichten, whitepapers of andere webinhoud.
Partners moeten elk hun eigen TLS 1.2-gereedheid evalueren via het besturingssysteem/code scannen/regressie testinitiatieven die in bovenstaande secties worden beschreven.
Conclusie
Het verwijderen van TLS 1.0-afhankelijkheden is een ingewikkeld probleem om end-to-end te maken. Microsoft en branchepartners ondernemen vandaag actie om ervoor te zorgen dat onze hele productstapel standaard veiliger is, van onze besturingssysteemonderdelen en ontwikkelingskaders tot de toepassingen/services die erop zijn gebouwd. Als u de aanbevelingen in dit document volgt, helpt u uw bedrijf de juiste koers in kaart te brengen en weet u welke uitdagingen u kunt verwachten. Het helpt ook uw eigen klanten beter voorbereid te zijn op de overgang.
Bijlage A: Handshake-simulatie voor verschillende clients die verbinding maken met www.microsoft.com ,beleefdheid SSLLabs.com

Bijlage B: Deprecating TLS 1.0/1.1 met behoud van de FIPS-modus
Volg de onderstaande stappen als voor uw netwerk de FIPS-modus is vereist, maar u ook TLS 1.0/1.1 wilt afveren:
Configureer TLS-versies via het registerdoor 'Ingeschakeld' in te stellen op nul voor de ongewenste TLS-versies.
Schakel Curve 25519 (alleen server 2016) uit via groepsbeleid.
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-cijfers.
Inzenders/Bedankt aan
Cartwright markeren
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rijst
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson