Forza Chrome a ignorare una "debole chiave pubblica effimera Diffie-Hellman"

Con l'aggiornamento di Chrome alla v45, sta bloccando l'accesso alle pagine con deboli chiavi pubbliche effimere Diffie-Hellman. Capisco che ciò è dovuto a Logjam. Capisco che il passaggio da https a http è una "soluzione" in alcuni casi.

Tuttavia, non posso passare da https a http perché sono reindirizzato automaticamente a https dal software basato sul Web che utilizziamo sulla nostra intranet.

Ovviamente, la soluzione sarebbe quella di fare in modo che la sicurezza cambi i vari server Intranet per essere protetti da logjam, lo capisco, ma non è un'opzione in questo momento, e non posso fare altro lavoro fino a quando non viene risolto. Poiché è una rete intranet e la semplice connessione richiede che si sia fisicamente qui, il rischio è minimo.

Esiste un modo per continuare ad accedere alle pagine tramite il protocollo HTTPS, con deboli chiavi pubbliche effimere Diffie-Hellman in Chrome versione 45?

Hacky fix per aggirare questo problema (Mac OSX)

• Eseguilo nella riga di comando per risolvere il problema durante l'avvio di Chrome

Cromo:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Canarino:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Per Firefox

• Vai a about: config
• Cerca security.ssl3.dhe_rsa_aes_128_shaesecurity.ssl3.dhe_rsa_aes_256_sha
• Impostali entrambi su false.

NOTA: la correzione permanente sarebbe quella di aggiornare la chiave DH con una lunghezza> 1024

In effetti, sembra che i browser abbiano preso sul serio il problema Diffie-Hellman con tasti inferiori di 1024 di lunghezza, che in una parte è un'ottima notizia, ma d'altra parte, ha generato molti utenti arrabbiati di Chrome .

La correzione di questo problema (e molti altri relativi alla sicurezza) è responsabilità degli amministratori di sistema, quindi, a quanto ho capito, la decisione di bloccare qualsiasi sito Web che offre una chiave Diffie-Hellman debole a 512 bit o inferiore è una misura della pressione diretta verso coloro che gestiscono la sicurezza su siti remoti, con il "rovescio della medaglia" degli utenti che ne subiscono gli effetti.

Al momento è possibile inserire nella blacklist alcune Cipher Suites all'avvio del browser Google Chrome eseguendolo con il --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013parametro, che sembra disabilitare quelli relativi alla vulnerabilità LogJam e consentire agli utenti di unirsi ai siti, ma insisto sul fatto che dovrebbe essere responsabilità degli amministratori di sistema per risolvere il problema con le chiavi dei loro Diffie-Hellmann.

Una delle cose che hai chiesto era se ci fosse qualche svantaggio nell'uso delle soluzioni alternative elencate (o nell'uso di altre non elencate) in una configurazione Intranet. La risposta breve è che fintanto che i server coinvolti utilizzano chiavi deboli, i server coinvolti saranno sensibili a qualsiasi sistema che utilizza un attacco logjam e, a seconda della natura del server, il server può successivamente essere un server compromesso che può propagare il problema ad altri client che accedono al server.

Due scenari non improbabili sono un laptop infettato dall'Intranet che accede al server interno quando si connettono nuovamente alla Intranet o un browser configurato per ignorare il problema (come suggerito sopra e altrove) che è attualmente utilizzato per accedere a Internet e che capita di connettersi a un server compromesso essendo un punto di partenza per attaccare i server Intranet.

Poiché non conosco personalmente tutti i problemi che presenta il difetto del logjam, non posso dire se una di queste due situazioni sia particolarmente probabile. La mia esperienza personale è che gli amministratori di sistema con server che si affacciano su Internet tendono ad andare il più avanti possibile rispetto a tali problemi. Detto ciò, la mia esperienza è anche che gli amministratori dei server Intranet tendono a fare cose come rendere i siti piuttosto carini prima di affrontare i problemi di sicurezza del server.

Di fronte allo stesso problema. Se sei un ragazzo lato server, aggiungi le seguenti righe nel connettore 443 in server.xml tomcat

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" cifrari = "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA"

Questo ti aiuterà a risolvere questo problema con la chiave SSL.