it-swarm-eu.dev

ssltest: problemi di catena - contiene ancora

Ho eseguito ssltest sull'applicazione Web e ho trovato "Problemi relativi alla catena - Contiene l'ancora" (sezione "Certificati aggiuntivi (se forniti)")

Cosa significa? Dovrebbe essere riparato? Può essere sfruttato?

81
Andrei Botalov

Quando il server invia il proprio certificato al client, in realtà invia una catena di certificati in modo che il client trovi più facilmente la convalida del certificato del server (il client è non richiesto per usare esattamente quella catena, ma, in pratica, la maggior parte dei client utilizzerà la catena e nessun altro). Questo è descritto nel standard SSL/TLS , sezione 7.4.2, con, in particolare, questo estratto illuminante:

Il certificato del mittente DEVE essere il primo nell'elenco. Ogni certificato seguente DEVE certificare direttamente quello che lo precede. Poiché la convalida del certificato richiede che le chiavi radice vengano distribuite in modo indipendente, il certificato autofirmato che specifica l'autorità di certificazione radice PUO 'essere omesso dalla catena, presupponendo che l'estremità remota debba già possederla per convalidarla in ogni caso.

Poiché si tratta di un caso "MAGGIO" (la terminologia "MAGGIO", "DEVE", "DOVREBBE" ... in RFC ha significati molto precisi spiegati in RFC 2119 ), al server è consentito includere il certificato radice (noto anche come "trust anchor") nella catena o ometterlo. Alcuni server lo includono, altri no. Un'implementazione client tipica, intesa a utilizzare esattamente la catena che è stata inviata, proverà innanzitutto a trovare i certificati della catena nel suo negozio di fiducia; in caso contrario, tenterà di trovare un emittente per l '"ultimo" certificato della catena nel suo negozio di fiducia. Quindi, in entrambi i casi, questo è conforme agli standard e dovrebbe funzionare.

(Esiste una piccola fonte di confusione riguardo all'ordine della catena. In verità X.509 , la catena viene ordinata dall'ancoraggio di fiducia al certificato dell'entità finale. Il messaggio "Certificato" SSL/TLS è codificato in ordine inverso, il certificato dell'entità finale, che qualifica il server stesso, arrivando per primo. Qui sto usando "last" nella terminologia SSL/TLS, non X.509.)

L'unica cosa negativa che si può dire sull'invio del root nella catena è che usa inutilmente un po 'di larghezza di banda della rete. Sono circa 1 KB di dati per connessione che include una stretta di mano completa . In una sessione tipica tra un client (browser Web) e un server, solo una connessione sarà di quel tipo; le altre connessioni dal client useranno "handshake abbreviati" che si basano sull'handshake iniziale e non usano affatto i certificati. E ogni connessione sarà mantenuta attiva per molte richieste HTTP successive. Quindi l'overhead di rete implicato nell'invio di root è leggero.

104
Thomas Pornin

Significa che i certificati forniti dal sito includono il certificato radice della catena di certificati (la catena in cui un certificato è collegato al certificato del suo emittente, essendo la radice un certificato che è il proprio emittente).

Poiché un certificato è attendibile solo se il certificato radice (o alcuni intermedi) della sua catena è esplicitamente considerato attendibile dal client, non è necessario fornire il certificato radice: se è attendibile, il client lo possiede già. Il rapporto, a proposito, indica che più in basso con l'osservazione "Nel negozio di fiducia".

Non considererei questo un motivo per un avvertimento, forse solo per un suggerimento. ssltest sembra anche felice considerando la loro valutazione del 100% per il certificato.

Potrebbero esserci stati degli exploit al contrario: siti canaglia che forniscono certificati di root fasulli che i clienti errati scambiano con quelli fidati, il che si traduce in una fiducia del cliente nel sito. Gli utenti di tali clienti sono comunque nei guai.

24
mkl