Che cosa protegge l'estensione TLS EC_POINT_FORMAT e qual è il rischio di non utilizzarlo?

1

Il test SSL di htbridge ha evidenziato che il server supporta le curve ellittiche ma non l'estensione TLS EC_POINT_FORMAT.

Che cosa protegge da tale estensione TLS? Qual è il (potenziale) rischio di non usarlo?

    
posta Bob Ortiz 17.07.2017 - 20:06
fonte

1 risposta

3

TLDR: non molto

L'invio dell'estensione è fondamentalmente per informare il peer se si supportano i punti compressi, poiché il supporto per i punti non compressi è obbligatorio (se si supportano le cipheruites e i certificati CE).

Se non si supporta la compressione e non si invia l'estensione, è probabile che il peer possa inviarti una chiave / catena e / o una chiave temporanea che utilizza la compressione, che non è possibile elaborare in modo che l'handshake non funzioni, anche se il peer potrebbe essere stato in grado di utilizzare un cert / catena e / o chiave non compressi, o qualche altra cipher suite negoziabile che avrebbe funzionato. Ma RFC 4492 5.2 proibisce esplicitamente al client di farlo, e Postelianismo generale dovrebbe scoraggiare il server anche se 4 è nel migliore dei casi ambiguo. Per non parlare di non aver visto alcuna implementazione di EC che non supporta la compressione in primo luogo.

Se si supporta la compressione ma non si invia l'estensione, c'è il rischio che il peer non riesca a utilizzare una catena / catena con punti compressi anche se l'avresti accettata. Se non ha un'altra catena / catena (e parametri correlati se applicabile come DHE) per una ciphersuite supportata da entrambe le parti, ciò potrebbe significare che la connessione TLS non riesce completamente e, a seconda dei sistemi e degli utenti coinvolti, potrebbe provocarli comunicazioni alternative che sono insicuri o meno sicure. Se ha un'altra catena / catena senza compressione ed è in grado di completare l'handshake, spreca una quantità molto piccola di larghezza di banda che quasi certamente non ha importanza e la connessione risultante potrebbe non essere così strong come avrebbe potuto essere, ma se entrambe le parti sono state configu- rate e implementate correttamente, dovrebbe comunque essere sufficientemente sicuro. Non ci dovrebbero essere problemi con la chiave temporanea perché il server può decomprimerla se necessario.

    
risposta data 18.07.2017 - 10:56
fonte

Leggi altre domande sui tag