La rimozione della crittografia vulnerabile su Windows 10 interrompe RDP in uscita

Lo scanner di vulnerabilità di TrustWave non esegue una scansione a causa di un computer Windows 10 che esegue RDP:

Algoritmi di cifratura a blocchi con dimensione del blocco di 64 bit (come DES e 3DES) attacco di compleanno noto come Sweet32 (CVE-2016-2183)

NOTA: sui sistemi Windows 7/10 che eseguono RDP (Remote Desktop Protocol), la cifra vulnerabile che dovrebbe essere disabilitata è etichettata 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'.

Utilizzando IIS Crypto (di Nartac), ho provato ad applicare il modello "Best Practices" e il modello PCI 3.1, tuttavia entrambi includono il codice non sicuro (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Se disabilito questo codice, RDP da questo computer a molte stazioni Windows smette di funzionare (funziona ancora su alcuni server 2008 R2 e 2012 R2). Il client RDP fornisce semplicemente "Si è verificato un errore interno" e il registro eventi:

Si è verificato un errore irreversibile durante la creazione di una credenziale client TLS. Lo stato di errore interno è 10013.

Ho controllato il registro eventi del server di uno dei server e ho visto questi due messaggi

È stata ricevuta una richiesta di connessione TLS 1.2 da un'applicazione client remota, ma nessuna delle suite di crittografia supportata dall'applicazione client è supportata dal server. La richiesta di connessione SSL non è riuscita.

È stato generato il seguente avviso irreversibile: 40. Lo stato di errore interno è 1205.

Come posso risolvere la vulnerabilità della sicurezza senza interrompere il RDP in uscita?

Oppure, se quanto sopra non è possibile, c'è qualcosa che posso fare su ogni host RDP a cui non riesco più a collegarmi a che gestirlo a tale scopo?

--- Aggiornamento n. 1 ---

Dopo aver disabilitato TLS_RSA_WITH_3DES_EDE_CBC_SHA sulla macchina Windows 10, ho provato a collegarmi a diversi host RDP (la metà di loro non è riuscita con "Un errore interno ..."). Quindi ho confrontato uno di questi host a cui posso connettermi con uno a cui non riesco a connettermi. Entrambi sono 2008 R2. Entrambi hanno la stessa versione RDP (6.3.9600, protocollo RDP 8.1 supportato).

Ho confrontato i protocolli e le cifre TLS utilizzando IIS Crypto per fare "Salva modello" sulle loro impostazioni correnti in modo da poter confrontare i file modello. Erano identici! Quindi, qualunque sia il problema, non sembra essere una questione di una suite di chipher mancante sull'host. Ecco una schermata di Beyond Compare sui file:

Cosa potrebbe esserci di diverso tra i due host RDP che causano questo problema e come risolverlo?

IIS Crypto ha l'opzione per impostare entrambe le opzioni lato server (in entrata) e lato client (in uscita). Esistono alcune cifre che è necessario lasciare abilitate sul lato client per la compatibilità.

Per fare quello che vuoi, personalmente sceglierei quanto segue:

• Applica modello 3.1
• Lascia tutte le suite di crittografia abilitate
• Applica a client e server (casella selezionata).
• Fai clic su "Applica" per salvare le modifiche

Riavvia qui se lo desideri (e hai accesso fisico alla macchina).

• Applica modello 3.1
• Lascia tutte le suite di crittografia abilitate
• Applica al server (casella deselezionata).
• Deseleziona l'opzione 3DES

Il riavvio qui dovrebbe comportare lo stato finale corretto.

In effetti, si desidera solo disabilitare 3DES in ingresso, ma consentire comunque l'utilizzo in uscita di tale suite di crittografia.

Ho avuto lo stesso problema, l'installazione della patch KB3080079 sul server abilita il supporto per tls 1.1 e 1.2.

Nota che per i client Windows 7 dovrai installare l'aggiornamento client rdp (KB2830477), altrimenti solo Windows 8+ sarà in grado di connettersi.

Modifica (26-09-2018): ho scoperto che disabilitare 3DES su 2012R2 NON rompe RDP ma si rompe su 2008 R2. Le opzioni supportate sembrano essere diverse tra i kernel.

Condividerò la mia risposta da un thread TechNet ma prima BLUF:

Conclusione serverfault: molto probabilmente hai qualche altra differenza tra i sistemi. Ti stai collegando tra diverse versioni del sistema operativo, un sistema ha FIPS abilitato e l'altro no, oppure hai restrizioni di cifratura diverse in atto sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Io certamente abilitare la registrazione SCHANNEL sul sistema che fa il lavoro per determinare quale cifra è in uso. Mi piacerebbe sentirti se in qualche modo RDP funziona con un codice alternativo.

Copia del post:

Abbiamo funzionato!

Apparentemente il 2008 e il 2012 hanno problemi di sintassi e il 2008/7 richiede un trailing / 168. 2012 / 8.1 / 10 no.

la chiave per il 2008 è simile alla seguente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

E la chiave per il 2012 è simile a questa: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Posso confermare che l'uso di "Triple DES 168/168" NON disabilita 3DES sul sistema. Puoi dimostrarlo a te stesso con uno scanner di protocollo (come Nessus) o abilitando la registrazione SCHANNEL:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

Ad esempio, si avranno eventi nel registro di sistema;

Stretta di mano client SSL completata correttamente. I parametri crittografici negoziati sono i seguenti.

Protocollo: TLS 1.0 CipherSuite: 0x2f Forza di scambio: 1024

Per me il risultato è 0xa che Google rivela come TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Quando utilizzo "Triple DES 168" (senza / 168), l'ID evento di sistema 36880 non viene visualizzato e la sessione RDP viene bloccata.

Per l'articolo: crittografia di sistema: utilizzare algoritmi conformi a FIPS per crittografia, hash e firma

Servizi Desktop remoto (RDS) Per crittografare le comunicazioni di rete di Servizi Desktop remoto, questa impostazione di criterio supporta solo l'algoritmo di crittografia Triple DES.

Per l'articolo: "Crittografia di sistema: utilizzare algoritmi conformi a FIPS per crittografia, hash e firma" effetti delle impostazioni di sicurezza in Windows XP e nelle versioni successive di Windows

Questa impostazione influisce anche su Servizi terminal in Windows Server 2003 e nelle versioni successive di Windows. L'effetto dipende dal fatto che TLS sia utilizzato per l'autenticazione del server.

Se TLS viene utilizzato per l'autenticazione del server, questa impostazione consente di utilizzare solo TLS 1.0.

Per impostazione predefinita, se TLS non viene utilizzato e questa impostazione non è abilitata sul client o sul server, il canale RDP (Remote Desktop Protocol) tra il server e il client viene crittografato utilizzando l'algoritmo RC4 a 128 bit lunghezza chiave. Dopo aver abilitato questa impostazione su un computer basato su Windows Server 2003, è vero quanto segue: Il canale RDP viene crittografato utilizzando l'algoritmo 3DES in modalità Cipher Block Chaining (CBC) con una lunghezza della chiave di 168 bit. L'algoritmo SHA-1 viene utilizzato per creare digest dei messaggi. I client devono utilizzare il programma client RDP 5.2 o una versione successiva per connettersi.

Quindi entrambi supportano l'idea che RDP possa utilizzare solo 3DES. Tuttavia, questo articolo suggerisce che è disponibile una gamma più ampia di cifre: Convalida FIPS 140

L'insieme di algoritmi crittografici che un server Remote Desktop Protocol (RDP) utilizzerà sarà impostato su: - CALG_RSA_KEYX - Algoritmo di scambio di chiavi pubbliche RSA - CALG_3DES - Algoritmo di crittografia Triple DES - CALG_AES_128 - AES a 128 bit - CALG_AES_256 - AES a 256 bit - CALG_SHA1 - 256 bit AES - CALG_SHA1 Algoritmo di hashing SHA - CALG_SHA_256 - Algoritmo di hashing SHA a 256 bit - CALG_SHA_384 - Algoritmo di hashing SHA a 384 bit - CALG_SHA_512 - Algoritmo di hash SHA a 512 bit

Alla fine non è chiaro se RDP sia in grado di supportare protocolli non 3DES quando la modalità FIPS è abilitata, ma l'evidenza suggerisce che non lo è.

Non vedo alcuna prova che Server 2012 R2 funzionerebbe diversamente da Server 2008 R2, tuttavia sembra che Server 2008 R2 fosse basato sulla conformità FIPS 140-1 e Server 2012 R2 segua FIPS 140-2, quindi è del tutto possibile che Server 2012 R2 supporti protocolli aggiuntivi. Noterai i protocolli aggiuntivi nel link di convalida FIPS 140 .

In conclusione: non credo che Server 2008 R2 possa supportare RDP in modalità FIPS con 3DES disabilitato. La mia raccomandazione è di verificare se il tuo sistema soddisfa le condizioni per un attacco SWEET32 (più di 768 GB inviati in una singola sessione) e se disabilitare 3DES vale la pena rimuovere la funzionalità RDP. Esistono altre utility per gestire i server oltre RDP, specialmente in un mondo in cui la virtualizzazione è molto comune.

Apparentemente il 2008 e il 2012 hanno problemi di sintassi e il 2008/7 richiede un trailing / 168. 2012 / 8.1 / 10 no.

la chiave per il 2008 è simile alla seguente: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Ottima scoperta ho avuto lo stesso identico problema su alcuni controller di dominio Windows 2008 R2, stranamente i miei server membri 2008R2 sembrano ok ... e anche i miei server 2012R2 funzionano bene. Ho bisogno di rompere il disimpegno di quelle vecchie DC :)