In una revisione datata 2016-10-31 , Mozilla ha modificato la raccomandazione Server TLS di generare un gruppo DH casuale a quelli pubblicati in RFC 7919 . Richieste di Mozilla:
These groups are audited and may be more resistant to attacks than ones randomly generated.
Non si sta utilizzando un gruppo DH pubblicato con qualcosa Logjam sconsigliato?
Penso che il motivo per cui utilizzi gruppi predefiniti risponda chiaramente alla pagina di riferimento:
Instead of using pre-configured DH groups, or generating their own with "openssl dhparam", operators should use the pre-defined DH groups ffdhe2048, ffdhe3072 or ffdhe4096 recommended by the IETF in RFC 7919. These groups are audited and may be more resistant to attacks than ones randomly generated.
Collegamento con l'attacco Logjam è stato consigliato di non utilizzare gruppi DH predefiniti con 1024 bit o inferiore poiché questa dimensione della chiave è considerata alla portata degli hacker odierni e potrebbe valere lo sforzo per le chiavi molto utilizzate. Ma le dimensioni delle chiavi più grandi non sono ancora considerate alla portata degli aggressori.
Penso che l'idea alla base di RFC 7919 riguardasse maggiormente l'interoperabilità.
Mentre un lato DH del server personalizzato è potenzialmente più sicuro e non verrà influenzato se ad es. la NSA riesce a rompere uno dei gruppi più comunemente usati, mette lo sforzo di controllo della sanità sul cliente. E questi clienti potrebbero avere idee completamente diverse su ciò che costituisce un gruppo sano e sicuro. Ad esempio, potrebbero avere idee diverse sulla lunghezza di bit accettabile. E non c'era nessun canale posteriore. Il cliente non aveva modo di dire in anticipo al server "Accetterò tali e tali gruppi ..." e in nessun modo dopo dirò al server "Scusa, non lavorerò con quel gruppo! " il client avrebbe fallito e il server non lo avrebbe mai saputo. Interoperabilità da incubo.
Ora ciò che RFC7919 tenta di fare è usare la stessa logica già in uso per la curva ellittica DH e usarla per il DH regolare ("MODP", "campo finito").
In questo modo il cliente almeno dirà in anticipo "Accetterò tali e tali gruppi ..." e la manciata di gruppi che lo fanno nel Numero di gruppo di AsianA può essere controllato / controllato dal pubblico.
Il riassunto delle RFC elenca la motivazione:
Abstract
Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.
This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).
Ho appena trovato questo documento:
Dicono in astratto che in genere i client non controllano i parametri in fase di esecuzione a causa dei risultati delle prestazioni.
Quindi la definizione, il controllo del benessere e la denominazione di gruppi di campi limitati DH ha senso qui. (Almeno più senso che non verificare affatto.)
Leggi altre domande sui tag tls diffie-hellman logjam