Microsoft waarschuwt gebruikers opnieuw voor einde van tls 1.0 en 1.1 in Windows

Microsoft waarschuwt gebruikers opnieuw voor het naderende einde van tls 1.0 en 1.1. Die verouderde versies van het Transport Layer Security-protocol worden in de toekomst vervangen door tls 1.3.

Microsoft geeft die waarschuwing af in een advisory. Daarin schrijft het bedrijf dat tls 1.0 en 1.1 inmiddels zijn verouderd, omdat daar steeds vaker securityproblemen in voorkwamen. "Daarom worden tls 1.0 en 1.1 in toekomstige versies van Windows standaard uitgeschakeld", schrijft het bedrijf.

De eerstvolgende versie waarin dat gebeurt, is de Windows 11 Insider Preview, die deze maand uitkomt. Daarin zit nog wel een optie om de oude versies van tls weer in te schakelen voor wie dat nodig heeft voor bijvoorbeeld oude applicaties. Microsoft zegt ook dat de functionaliteit alleen in nieuwe versies van Windows wordt uitgeschakeld, maar nog wel in bestaande versies blijft zitten.

Tls 1.0 en 1.1 worden al jaren afgeraden door securityexperts. Het recentere tls 1.3 is veiliger. Microsoft is ook al net zoveel jaren bezig ondersteuning voor het protocol uit te faseren uit zijn software. Eerder gebeurde dat al in browsers als Edge en IE en later in Office 365. In Windows gaf het bedrijf gebruikers meer tijd, omdat veel software alsnog gebruikmaakte van de oude tls-versies. Wel waarschuwde het bedrijf gebruikers daar in het verleden vaker voor.

Reacties (52)

[wildhagen]

Als je dit zelf wil uitschakelen voordat Microsoft dit doet kan je het tooltje IISCrypto gebruiken. Deze kan je ook gebruiken om bepaalde cipher suites in- of uit te schakelen als je dat wil.

Je kan ook in de registry kijken:

- Ga naar HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client (en Server) (als deze bestaat, niet altijd het geval)
- De waarden DisabledByDefault moet 1 zijn, en bij Enabled moet 0 staan.
- Herhaal dit voor deze key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\

Volgens mij, maar ik weet dit niet zeker, moet je hierna wel de computer herstarten voor het effectief wordt.

Verdere documentatie over die TLS-gerelateerde registry settings zijn te vinden bij Microsoft zelf: https://learn.microsoft.c...tings?tabs=diffie-hellman

[Reactie gewijzigd door wildhagen op 22 juli 2024 15:36]

[djwice]

Goede tip, zo kun je nu al kijken - ook in oudere Windows versies - welke software moet worden geupdate of vervangen omdat het geen gebruik maakt van TLSv1.2 of TLSv1.3.

Side note for others
Mocht je overigens software schrijven, zorg dat je TLSv1.3 en HTTP/3 ondersteunt. Het is niet alleen veiliger, het is ook sneller en geeft minder server belasting.

TLSv1.2 komt uit 2008 en is voor het laatst bijgewerkt in 2011 en TLSv1.1 uit 2006.

Het is dus echt niet zo raar om nu 'al' op TLSv1.3 over te stappen, dat al sinds 2018 bestaat.

De protocollen achter HTTP/3 zijn door Google, Facebook en Twitter al jaren lang gebruikt (QUIC over UDP). En zorgen voor een snellere TCP-handshake. Dus je content staat sneller op het scherm.

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[The Zep Man]

Side note for others
Mocht je overigens software schrijven, zorg dat je TLSv1.3 en HTTP/3 ondersteunt. Het is niet alleen veiliger, het is ook sneller en geeft minder server belasting.

Aangenomen dat je software iets met TLS-verbindingen en/of HTTP doet. Een beter advies is:

Mocht je software schrijven, zorg dat je dergelijke zaken uitbesteedt (aan bijvoorbeeld een library of nog beter, een reverse proxy). Zo hoef je niet het wiel opnieuw uit te vinden.

De protocollen achter HTTP/3 zijn door Google, Facebook en Twitter al jaren lang gebruikt (QUIC over UDP). En zorgen voor een snellere TCP-handshake. Dus je content staat sneller op het scherm.

Het zorgt juist voor geen TCP handshake, want UDP.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:36]

[djwice]

Lijkt me geen goed idee om een oud protocol tegen een reverse proxy te praten.
In de meeste programmeertalen en libraries (nodejs, python etc.) moet je expliciet kiezen of je gebruik wilt maken van HTTP/3 of HTTP/3, juist van wege het verschil in afhandeling.

Ook riskeer je bij het volledige 'uitbesteden' dat je de voordelen van HTTP/3 niet incasseert omdat de layer backward compatible wil blijven.

Dus nee, schijf niet je eigen C++ implementatie van het HTTP/3 protocol en ook niet van TLSv1.3 maar zorg wel dat je er expliciet voor kiest.

Er zijn nog meer voordelen aan zelf je headers kiezen, zoals bijvoorbeeld het ontvangen van roundtrip tijden, dat is niet alleen handig voor een proxy of firewall om te weten, dat is ook zeer nuttig voor de business applicatie. Waarom zijn klanten in regio X minder tevreden: oh, roundtrip tijd is daar 3x hoger dan elders. Of vlak na de lunch verwerken we veel minder calls per minuut, hoe komt dat? Oh, roundtrip tijd, het ligt dus niet aan het lanterfanten van collega's met een lunch dip etc.

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[Alfa1970]

Het lijkt me juist een prima idee om een out protocol tegen een reverse proxy aan te laten praten zodat het verkeer dat van buiten komt en naar buiten gaat in ieder geval met een veilig protocol praat.

Het is ook nog eens vrij standaard in web server land om dit te doen.
Sterker nog, het gebeurt regelmatig dat er opstellingen zijn met reverse proxies die in plain text praten met de web server, maar iedereen die naar de webserver gaat praat in https.

TCPv1.3 bestaat niet, TLS 1.3 wel, HTTP/2 ook. HTTP/3 is pas 1 jaar oud (juni 22), dat zul je in softwareland nog niet zo vaak tegenkomen anders dan bij een paar pioniers.
Eerlijk gezegd ben ik niet zo overtuigd van of deze protocollen extra veiligheid bieden.
Ze zijn sneller omdat ze controle stappen hebben verwijdert.
HTTP/3 is sneller voor de server, want die kan z'n pakketjes afvuren zonder er verder over na te hoeven denken.
Maar aan de ontvangende kant is het verre van zeker of je er qua snelheid mee opschiet.
Er zit dan weliswaar een protocol ingebakken dat er voor zorgt dat je alle pakketjes krijgt, het kan zo maar dat je meerdere malen bij de server moet gaan bedelen om je pakketjes binnen te krijgen.
Ik denk dat je client side er niet zo heel veel mee opschiet eerlijk gezegd.

En minder verificatie stappen op de encryptie laag klinkt mij in de oren als minder veilig en niet beter.
Het doel is om minder energie te hoeven verstoken om de pakketjes de deur uit te krijgen, en in mijn optiek betekend dat niet direct dat we te maken hebben met een beter encryptie algoritme.
Maar we zullen het zien in de toekomst, Heartbleed werd ook pas 20 jaar later ontdekt..

[HollowGamer]

> En minder verificatie stappen op de encryptie laag klinkt mij in de oren als minder veilig en niet beter.

Wellicht dat het zelfs beter is, aangezien er weer één laag minder is om te onderhouden en waar fouten in zitten. Je kunt dus niet altijd zeggen of het ene beter is dan het ander. Een extra deur in real life maakt ook niet altijd het verschil, zeker als je die deur gewoon kan opendoen of als code 1-2-3-4 heeft.

[djwice]

HTTP/3 is het toevoegen van QUIC. QUIC bestaat als sinds 2012:
https://en.m.wikipedia.org/wiki/QUIC

En is al heel lang in gebruik voor bijvoorbeeld het serveren van advertenties aan Chrome clients.

Als je je meer verdiept in hoe het werkt zul je ontdekken waarom die stappen nu anders verlopen. En als server bepaal jij hoe lang de reconnect zonder nieuwe handshake geldig is.

Op clients zie ik in de praktijk bij een bedrijf met 40 miljoen klanten dat HTTP/3 content sneller op de cliënt staat dan HTTP/2 content vanaf dezelfde servers. Er zijn steeds minder browser clients die HTTP/3 niet ondersteunen. Vaak is al meer dan 80% van het verkeer HTTP/3 als je server het ondersteunt.
_____
Het is een beetje achterhaalde gedachte dat intern HTTP-traffic goed genoeg is, voor veel toepassingen is dat niet zo (klant gegevens, traffic logs, etc). En dat zelfde geld voor TLSv1.1 en lager. Het zal steeds moeilijker worden om dat nog te kunnen verantwoorden naar je klanten en wetgever(/rechter).

Dat je in de praktijk veel reverse proxies tegen komt die de communicatie van onveilige systemen upgrade voor de communicatie met de buitenwereld (ik heb zelf een upgrade proxy ontworpen en die is in productie op 300+ websites (bijna even zoveel onafhankelijke deployments) en die zelfs vulnerabilities in de content realtime fixt die via een ZeroTrust (werkt onder HTTP 1.1 en hoger) connectie maakt met de backend , betekend niet dat het een goede situatie is die zo moet blijven.

Ik vind het geen 'prima' idee om system op deze manier te ontzien van updates en de urgentie weg te nemen.
Zero Trust ontwerpen naar de reverse proxy zoals die van mij isoleren het systeem, maar wil je echt een systeem in de lucht houden waarvan de leverancier/maker al 15 jaar lang niet de moeite wil (of kan) kan nemen voor een beveiligings update?

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[The Zep Man]

Het is een beetje achterhaalde gedachte dat intern HTTP-traffic goed genoeg is, voor veel toepassingen is dat niet zo (klant gegevens, traffic logs, etc). En dat zelfde geld voor TLSv1.1 en lager. Het zal steeds moeilijker worden om dat nog te kunnen verantwoorden naar je klanten en wetgever(/rechter).

Er is niets mis om in een gesegmenteerd beveiligingsdomein (soms zelfs bestaande uit een enkele host) een reverse proxy te draaien. Als dat binnen dezelfde security context draait als de (legacy) software die geen moderne webstandaarden, dan is er niets aan de hand.

[djwice]

Ik heb niets tegen reverse proces, ze zijn heel handig, daarmee kun je o.a. meerdere applicaties onder dezelfde domein draaien. Bijvoorbeeld op je intranet domein zowel je CMS als je BI als je HR selfservice, gewoon op verschillende paden, zolang de applicatie relatieve URI gebruikt in de output hoeft de app zelf niet te weten op welk domein het werkt. Dat scheelt een hoop werk bij migraties, Blue/Green setup etc.

Uiteraard heb ik in mijn reverse proxy ook al een automatische fix voor applicaties die zelf geen relatieve paden uitpoepen. Of daar soms (door menselijk handelen) van afwijken. Uiteraard met logs, zodat het wel gefixt wordt bij de bron, maar dat de eindgebruiker er geen last van heeft als het bron systeem zich niet aan de afspraken houdt. (vergissing is menselijk en overdracht naar nieuwe of tijdelijke medewerkers zijn niet altijd perfect, en niet alle systemen hebben perfecte input validatie).

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[djwice]

[...]
Het zorgt juist voor geen TCP handshake, want UDP.

Als je dat zo formuleert schrikken de meeste senior beheerders en gaan er plat voor liggen.
Dus vandaar eerder even formuleren in taal die past in het bekende TCP/IP beeld dat ze hebben als ze QUIC nog niet kennen (= nog niet mee gewerkt hebben in productie).

[The Zep Man]

Als je dat zo formuleert schrikken de meeste senior beheerders en gaan er plat voor liggen.

Beheerders hoeven niet geknuffeld te worden. Beheerders moeten hun werk doen, en daarbij huidige en aankomende common best practices combineren met eisen en wensen vanuit de organisatie. Vast blijven zitten in de jaren 90 is daar geen onderdeel van.

Vertel die beheerders ook maar niets over stateless protocols, zoals WireGuard. Geen enkele handshake!

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:36]

[djwice]

Zie deze reactie Alfa1970 in 'Microsoft waarschuwt gebruikers opnieuw voor einde van tls 1.0 en 1.1 in Windows'

[JeroenV_]

Alleen wel jammer dat server 2019 geen tls 1.3 ondersteund, en max tot 1.2 gaat.
Dit terwijl die versie toch ook nog gewoon gesupport wordt.

[The Zep Man]

Alleen wel jammer dat server 2019 geen tls 1.3 ondersteund, en max tot 1.2 gaat.

Je kan prima software met een eigen TLS stack draaien die wel TLS 1.3 ondersteunt, of een reverse proxy/TLS offloader inzetten voor de (Microsoft-)software die dat niet doet. Het beste blijft natuurlijk op tijd migreren.

Verder is TLS 1.2 voorlopig nog OK, dus je hebt nog tijd voor die migratie.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:36]

[DDX]

Server 2022 installeren (beschouw het als een servicepack) is prima oplossing dan.
Maar blijft idd jammer dat microsoft tls 1.3 niet toevoegt aan oudere (supported) windows versies.

[HollowGamer]

HTTP/3 is helaas in Nginx nog altijd een feature-preview.
Dacht dat niet veel ook HTTP/3 gebruiken, wat inderdaad jammer is.

[djwice]

Ik heb het al een tijdje (sinds augustus 2022) aan op CloudFront, zowel privé als zakelijk voor enkele tientallen miljoenen klanten en honderden websites.

Als je heel technisch bent kan dit interessant zijn: https://github.com/aws/s2n-quic

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[HollowGamer]

https://nginx.org/en/docs/http/ngx_http_v3_module.html

Het probleem is dat het nogal unstable is. Voor andere tech. maakt mij dit niet veel uit, maar een webserver is het entry point voor gebruikers, dus die wel je stabiel hebben. Tevens moet je het zelf compilen, naar mijn weten doen niet veel Linux distro's deze module bouwen.

Misschien kijk ik eroverheen, maar volgens mij is er vanuit Nginx ook nog geen image met http3 built-in?

[djwice]

Snap ik, instabiele webservers heb je niets aan in productie.

Is dit iets https://github.com/cloudflare/quiche?

gevonden op https://en.m.wikipedia.org/wiki/HTTP/3 onder Implementations > Libraries

Er is ook een kopje Server, https://www.haproxy.org/ is vanaf
versie2.8 : QUIC prod ready.

[Reactie gewijzigd door djwice op 22 juli 2024 15:36]

[Mitsuko]

Geloof dat je nog een niveau mist: De sleutels zijn

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client

voor client connecties en

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server

voor server connecties.

Daarnaast is er ook nog een instelling in de Internet Opties - ik weet niet precies in welke situaties die gebruikt wordt, maar het is niet alleen voor Internet Explorer. De waarden die daarbij horen zijn:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DefaultSecureProtocols
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DefaultSecureProtocols

voor de systeembrede instellingen en

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\SecureProtocols
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\SecureProtocolsUpdated

voor de huidige gebruiker.

(Default)SecureProtocols is een bitmask van de actieve proocollen (slaat steeds een bit over):

0x80 voor TLS 1.0
0x200 voor TLS 1.1
0x800 voor TLS 1.2
0x2000 voor TLS 1.3

Dus 0x2800 voor TLS 1.2 + TLS 1.3 (maar: Windows 10 heeft geen officiële ondersteuning voor TLS 1.3!)

SecureProtocolsUpdated wordt op 1 gezet als je de opties aanpast via Internet Opties.

Daarnaast zijn er ook nog de Cipher Suites, die verschillen tussen versies van Windows. Doe daar voorzichtig mee, maar je kan zien wat actief is (en in welke volgorde!) in deze waarde:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002/Functions

Microsoft zelf raadt aan om het via Powershell commandlets of policies aan te passen, maar ik vind het lastig om daarmee snel een overzicht te krijgen (zeker wat betreft de volgorde).

Zie bijvoorbeeld deze pagina voor een aangeraden veiligere lijst van cipher suites, maar let wel: Daar missen de suites voor TLS 1.3 nog (TLS_AES_256_GCM_SHA384 en TLS_AES_128_GCM_SHA256).

[Reactie gewijzigd door Mitsuko op 22 juli 2024 15:36]

[wildhagen]

Dank, Client/Server was weggevallen in de keyname bij het copy/pasten, toegevoegd.

Daarnaast zijn er ook nog de Cipher Suites, die verschillen tussen versies van Windows. Doe daar voorzichtig mee, maar je kan zien wat actief is (en in welke volgorde!) in deze waarde:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002/Functions

Microsoft zelf raadt aan om het via Powershell commandlets of policies aan te passen, maar ik vind het lastig om daarmee snel een overzicht te krijgen (zeker wat betreft de volgorde).

Idem, ik vind dat niet overzichtelijk. Om die reden gebruik ik voor inventarisatie en aanpassing dan ook liever de genoemde IISCrypto-tool voor de cipher suites, dan heb je het netjes overzichtelijk.

Maar ben er inderdaad héél voorzichtig mee. Als je een cipher suite uitschakelt die wel werd gebruikt door een applicatie (die alleen die cipher suite aankan), dan werkt daarna die applicatie niet meer (goed).

Nog even een side note: de aanwezige cipher suites op een server/client zijn niet altijd gelijk, die verschillen namelijk per OS-versie. Zo ontbreken er in Windows Server 2012 R2 behoorlijk wat nieuwere cipher suites die pas aanwezig zijn vanaf Windows Server 2016 (of hoger, uiteraard). Volgens mij, maar hier ben ik niet 100 procent zeker van, kun je die cipher suites ook niet zomaar aan een ouder OS (als 2012 R2) toevoegen, maar moet je echt upgraden naar een nieuwer OS.

[Kabokey]

Je moet verplicht herstarten. Ik doe het zelf liever via PowerShell.

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' –PropertyType 'DWORD' -Name 'Enabled' -Value '0'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' –PropertyType 'DWORD' -Name 'DisabledByDefault' -Value '1'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -PropertyType 'DWORD' -Name 'Enabled' -Value '0'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' –PropertyType 'DWORD' -Name 'DisabledByDefault' -Value '1'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' –PropertyType 'DWORD' -Name 'Enabled' -Value '0'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' –PropertyType 'DWORD' -Name 'DisabledByDefault' -Value '1'

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -PropertyType 'DWORD' -Name 'Enabled' -Value '0'
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' –PropertyType 'DWORD' -Name 'DisabledByDefault' -Value '1'

[Keypunchie]

Dat dit toch nog zo lang duurt.

Vanuit mijn werk ben ik betrokken geweest bij implementatietrajecten voor TLS 1.2, waarbij dan in software-configuratie expliciet oudere versies werden uitgeschakeld en/of een 1.2 cipherspec expliciet werd aangezet.

En dat is intussen meer dan 10 jaar geleden…

[wildhagen]

Ja, maar helaas draait er nog héél veel legacy software die geen TLS1.2 ondersteunt, laat staan TLS1.3.

Sterker nog, er is nog altijd software die SSL2.0 en SSL3.0 gebruikt, de voorlopers van TLS, die nóg verder deprecated zijn.

Niet alle leveranciers leveren nieuwe versies, of soms bestaat de leverancier niet eens meer. Dit zijn vaak ook heel specialistische applicaties, die je niet zomaar kunt vervangen, omdat er geen (geschikt) alternatief is.

Wenselijk? Nee, verre van zelfs. Maar helaas vaak wel de realiteit.

[dmantione]

Persoonlijk vind ik het vrij arrogant om zo maar te beslissen dat een hoop software kapot gaat. SSL/TLS wordt voor alles en nog wat gebruikt en kan ook zo maar voor een lokale databaseverbinding gebruikt worden waar veiligheid minder van belang is. Veel software in veiligheidskritische situaties zal al lang vervangen zijn, software die nog draait zal een stuk minder kritisch zijn.

[kozue]

Dan blijf je toch gewoon een oude versie van Windows gebruiken? Probleem opgelost. Ik zie geen use case voor wél de allerlaatste Windows hebben, maar daar een antieke applicatie op willen zetten.

[Bor]

Dan blijf je toch gewoon een oude versie van Windows gebruiken? Probleem opgelost.

Dan is het probleem helemaal niet opgelost want dan ben je kwetsbaar op nog veel meer vlakken. Het uitfaseren van oude software en protocollen kan een complex verhaal zijn.

[kozue]

Mijn reactie ging niet over veiligheid maar over dmantione’s opmerking dat ze dingen kapot maken. Ik ben het helemaal met je eens dat je je security op orde houden. Al onze servers draaien Ubuntu 22.04, en die hebben de ondersteuning van TLS ouder dan 1.2 er helemaal uit gesloopt. Als je 1.1 of ouder nodig hebt, moet je dus 20.04 draaien, want er is geen mogelijkheid om dit in 22.04 aan te zetten.

[Reactie gewijzigd door kozue op 22 juli 2024 15:36]

[dmantione]

Onder Linux is dit dan ook een non-probleem: Je hebt altijd de mogelijkheid om de benodigde bibliotheken met de hand te installeren, of als dat niet toereikend is een oude distributie in een chroot te plaatsen.

[bzzzt]

Persoonlijk vind ik het vrij arrogant om zo maar te beslissen dat een hoop software kapot gaat.

Ik vind het vrij arrogant om de hele wereld onveiliger te willen maken omdat je zelf geen investering wil doen in veiligheid. Je kan een eigen eilandje bouwen met alleen jouw software naar keus, maar als je gebruik wil maken van netwerkeffecten om makkelijk met de hele wereld te communiceren is het toch niet zo heel vreemd dat je enigszins up to date moet zijn.

[dmantione]

Mij hoef je niet aan te spreken, ik heb geen oude software waar ik geen investeringen in wel doen. Maar nogmaals: Het is buitengewoon arrogant om vanuit een ivoren toren te gaan beslissen software stuk te maken. Je argument over wereldveiligheid kan ik niet delen, dat de kwestie invloed heeft op de wereldveiligheid slaat nergens op.

[bzzzt]

Software gaat niet stuk, maar voortschrijdend inzicht in de wereld om de software heen kan kennis opleveren dat de belofte van veiligheid niet meer toereikend is.

[bantoo]

Cryptografische delen van een applicatie hebben altijd een houdbaarheidsdatum. Als er geen rekening met dit feit gehouden wordt is dat een applicatie probleem,niet iets wat je bij Microsoft kan leggen. Als het je niet uit maakt dat je crypto niet werkt had je geen crypto moeten gebruiken. Dit is al decennia zo.

[lenwar]

Niet flauw bedoelt, maar het feit dat het OS het niet meer ondersteund betekent niet dat het helemaal niet meer bruikbaar is. Die lokale databaseverbinding kan prima met een eigen database-client gemaakt worden die zijn eigen versleutelingsbibliotheken meelevert. Dan heb je hier niets mee te maken.

Voor de onderdelen van het OS zelf:
Door de zwakkere versleuteling uit te schakelen (of domweg te verwijderen) voorkom je ook dat bij bugs in andere software, zwakkere versleuteling wordt uitgelokt. (er zijn tenslotte bekende aanvallen, die tijdens de handshake een lagere/wakkere versleuteling afdwongen wordt)

[nandervv]

Ha. Ha. Ha.
Sure, als je industriele applicaties, brugbediening etc niet als kritisch ziet.

[Keypunchie]

Maar als je zulke ouwe meuk gebruikt en de beveiliging op netwerk niveau regelt, kun je echt net zo goed geen encryptie erop zetten, toch? Gebruik je gewoon plain http, minder overhead ook.

En geen schijnveiligheid.

[Metalfreak]

Legacy software en hardware, simpel. Ik loop nog regelmatig tegen apparaten aan die ineens niet meer te beheren zijn als dit is uitgeschakeld. Deze apparaten functioneren qua basisfunctionaliteit nog prima, alleen kun je er geen instellingen meer op beheren. Daar kom je vaak pas achter op het moment dat er iets aan veranderd moet worden en je ze in een ander subnet wil zetten o.i.d. De gebruiker ziet gewoon een apparaat dat werkt, dus die zal niet klagen.

[dasiro]

doet me een déjà-vu krijgen van het uitfaseren van SMB, alleen dat dit nog leuker zal worden als de enige werkbare optie van een oud systeem het uitschakelen wordt van security/encryptie door gebrek aan ondersteuning

[Bezulba]

Gaat gegarandeerd gebeuren. Zeker bij software die allang legacy is en eigenlijk 10 jaar geleden al vervangen had moeten worden.

[R4gnax]

En niet alleen zakelijk of voor power-users zoals met SMB het geval was.

Wat dacht je van zaken zoals oude videogames?
Zijn er genoeg waarvan de uitgever de multiplayer wel in de lucht houdt, of er nog de mogelijkheid tot self-hosting bestaat - maar het spel en de server software zelf niet meer onderhouden worden. Wordt leuk als die geen TLS 1.2 kunnen praten.

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:36]

[Annihlator]

Als de uitgever het in de lucht houdt zouden zij ook met bijv. een (reverse-) proxy layer als workaround dat kunnen toepassen.

Zelfde geldt voor games die bijv al jarenlang ipx zelfs repliceren over een tunnel/proxy, zou aardig vergelijkbaar moeten kunnen zijn (in de vorm dat je die pakketten in de tunnel "verpakt" en dus beveiligt).

TLS1.0 en TLS1.1 zijn eigenlijk conform de standaard al 2 jaar deprecated, dus het werd ook wel hoog-tijd.

[Reactie gewijzigd door Annihlator op 22 juli 2024 15:36]

[air2]

Uitschakelen van encryptie is in dit geval zelfs aan te raden, en dan met een reverse proxy de nieuwere (tls1.2/ tls1.3) encryptie aan te bieden. Dus je server gaat over http via de reverse proxy over https naar de client. Prima en veiligere oplossing.

[marcovit]

Of via cloudtfront (AWS)

[lenwar]

Dat ligt er heel erg aan over hoe en wat je kan implementeren.

Als je een reverse proxy kan installeren op het communicerende (virtuele) apparaat en daar 'lokaal' kan communiceren (via localhost bijvoorbeeld) dan kan het 'best wel goed' zijn, maar dat is nog altijd minder veilig dan dat de dienst zelf de versleuteling doet.

Als een stuk malware met hoge rechten meeluistert op de betreffende machine kan die dus alsnog meeluisteren op localhost.

Het is niet voor niets dat browsers zelf DoH doen en dat niet door het OS laten regelen. Doordat de browser het zelf doet, kan er "niets" (het is in elk geval een heel stuk complexer) op de computer de boel manipuleren.
Doordat je dus een reverse proxy er tussen zet, verlies je je volledige e2e-versleuteling.

Dit gezegd hebbende kan het inderdaad een goede 'oplossing/workaround' zijn in het geval van verouderde systemen die niet meer geüpdatet worden. Maar het blijft onder aan de streep toch een soort 'second-best'

[air2]

Het is niet minder veilig als dat de dienst zelf de versleuteling doet, aangezien localhost communicatie onder windows niet te onderscheppen is zonder speciale hogere rechten. Als je dat soort rechten hebt, kun je sowieso die applicatie wel als compromised beschouwen.

[lenwar]

Je geeft als voorbeeld dat de applicatie onversleuteld naar de reverse proxy praat. Dat stukje is dan 'open'. Als de applicatie zelf kan versleutelen heeft hij die reverse proxy niet nodig als TLS-terminator.

Als het stuk malware met hoge rechten heeft kan het dus meeluisteren zoals je al aangeeft. Je hebt dan uiteraard al een ander probleem. Maar dat probleem is dus kleiner, als je applicatie zelf de versleuteling doet.

Het ligt volledig aan de aard van de malware of en wat de exacte impact is in elk geval.

[air2]

Maar onder windows kun je helemaal niet meeluisteren op dat stukje onversleutelde communicatie, als dat via localhost loopt. Om dat te kunnen heb je admin rechten nodig, dus tja dan helpt die versleuteling ook niet meer.

[Zenix]

Voor veel bedrijven is dit lang niet voldoende, alleen de voorkant beveiligen (en vaak alleen aan de buitenkant) Als je je wilt voldoen aan de beveiligingsrichtlijnen. De achterkant is namelijk nog steeds niet veilig en dat verkeer kan ook onderschept worden. Helemaal als je vervolgens encryptie gaat uitschakelen.

En wat als die servers moeten praten met een andere server die ook achter een reverse proxy zitten (of alleen TLS1.2 en TLS1.3 doen)? Dan moet je opnieuw een reverse proxy maken die aan de voorkant 1.0 en 1.1 doet (of niks in jou voorbeeld) en aan de achterkant 1.3, zodat die servers kunnen praten met de servers die wel voldoen aan de eisen.

Het kan soms niet anders, vanwege legacy. Maar laten we niet doen alsof reverse proxy de oplossing is, want dat is het niet.

[Reactie gewijzigd door Zenix op 22 juli 2024 15:36]

[air2]

Die reverse proxy draait dan wel op dezelfde server. Natuurlijk is dat wel een oplossing voor een legacy app, die geen 1.3 ondersteund.
Immers als je op windows over localhost communiceert (en dat is precies waar ik op doel, dat de reverse proxy op hetzelfde systeem draait) dan heb je speciale rechten nodig om dat verkeer te onderscheppen.

Als je dat soort rechten op die server kan bemachtigen, kun je ok het geheugen wel uitlezen, en veel meer, dus dan helpt die encryptie je ook niet.

[KittySeraphim]

Oude softwares/pc's zijn soms gewoon niet te vervangen. Voorbeeld is de aansturing van veel analysemateriaal in labo's. Deze software wordt gewoonlijk nooit geupdate. We hebben zelfs nog een apparaat staan dat windows xp draait omdat de software gewoonweg niets nieuwers ondersteund.

[beerse]

Zomaar een paar gedachten die bij mij opkwamen:

Waarom heeft microsoft gewacht tot Windows 2022 met het beschikbaar stellen van TLS1.3? Dat had ook heel goed al in Windows 2019 gekund en het liefst had ik toen ook een W 2016 update gezien... Dat de specificatie 'pas' in 2018 is vastgelegd wil niet zeggen dat ze op dat moment pas kunnen beginnen met implementeren.

Dat ze deze deze oudere TLS versies op de server uit schakelen, kan ik mij voorstellen. Het liefst zie ik dat nog als patch op de niet meer ondersteunde windows versies verschijnen. Maar dat ze het ook op de client (browser en dergelijke) uit zetten zou ik niet willen. Het liefst zie ik dat ze bijvoorbeeld de kleur van het slotje aanpassen. Bijvoorbeeld: De laatste 2 op groen en iedere volgende op oranje, rood en paars of zo iets. Daarnaast zou ik ondertussen ssl gelijk stellen als 'zonder encryptie'.

[Reactie gewijzigd door beerse op 22 juli 2024 15:36]

[MOO!!!!]

En zoals vaak voor .NET/WinHTTP vergeten, zet je de protocollen uit en werkt je .NET applicatie niet meer, deze forceren door settings onderaan te passen, maar eerst WinHTTP!

Voor IISCrypto.exe
Protocollen wijzigen = rebooten
Cyphers wijzigen = direct actief


WinHTTP bijwerken VOORDAT je de protocollen aanpast:
https://learn.microsoft.c...s-1-2-client#bkmk_winhttp

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\
DefaultSecureProtocols = (DWORD): 0xAA0
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\
DefaultSecureProtocols = (DWORD): 0xAA0


.NET aanpassen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001