Il numero di nomi è una quantità molto piccola di dati in generale; se spinge a consegnare il certificato su una soglia di dimensione del pacchetto, il ritardo aggiunto non avrà un impatto percettibile sugli utenti umani che dispongono di connessioni a banda larga o ad alta velocità. Il computer ricevente avrà fino a 14 stringhe aggiuntive da esaminare; di nuovo, una quantità impercettibile di spese generali per ogni particolare utente umano.
Qualys SSL Labs ha fatto un sondaggio sui certificati alcuni anni fa e ha presentato i loro risultati a Blackhat . Hanno trovato molti problemi che hanno contribuito a problemi di prestazioni. Nel caso di più nomi di dominio, hanno trovato un certificato con 354 nomi di dominio non correlati e il certificato era lungo 8.2KB! Quindi sì, c'è una linea che probabilmente non vuoi attraversare e 354 sembra attraversarla.
Un altro problema comune che hanno riscontrato che influiva sulle prestazioni era che alcune catene di convalida erano troppo lunghe. Molto tempo fa, alcuni architetti PKI sostenevano un approccio a più livelli, in cui ogni certificato sarebbe stato firmato da una CA principale, una o due CA subordinate e una o due CA Policy. L'esecuzione della matematica RSA su quattro diversi passaggi di convalida è ciò che impantana i client, molto più della dimensione dei certificati. (Qualys ha trovato 8 certificati con una profondità di firma di 6!) Per mantenere le prestazioni il più alte possibile, mantenere la catena di firma il più breve possibile.
Hanno anche visto il 43% dei server che inviavano troppi certificati. Normalmente, dovresti includere il certificato del server e tutti i certificati di firma intermedi necessari per convalidarlo fino alla radice (il certificato radice è normalmente contenuto nel browser, a meno che non sia un certificato autofirmato). Molti siti sprecano larghezza di banda includendo certificati aggiuntivi non è necessario per convalidare il loro sito. Un sito ha inviato un file di certificato che conteneva 116 certificati!
Finalmente, hanno trovato molti certificati che erano semplicemente cattivi. Erano autofirmati, scaduti, utilizzavano algoritmi deboli o avevano altri difetti che significavano che la loro protezione non era ottimale. Di tutte le cose che è necessario ottenere con un certificato, la sicurezza è il numero uno - le prestazioni non lo sono. Quindi consiglierei di usare il loro strumento di analisi e scoprire cosa pensano della tua configurazione. link . Eseguo questo controllo ogni volta che cambio la configurazione del mio server e dopo aver aggiornato il mio certificato.
AGGIORNAMENTO: sono passato all'utilizzo di uno script nmap per controllare il mio server. Assicurati di eseguire una versione aggiornata di nmap, quindi esegui nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org . Questo elencherà le cifre supportate dal server e fornirà un voto di lettera che indica la sicurezza di ciascuno e un voto complessivo per il tuo server. Buono per trovare cose come versioni non sicure di SSL / TLS, crittografie a 64 bit, ecc. E puoi eseguirlo su qualsiasi host e porta, così puoi testare server di app, servizi web, server interni dietro i tuoi firewall , ecc.