Gli standard TLS richiedono che la preferenza lato server venga sempre utilizzata durante la negoziazione dei codici da utilizzare?

Penso che la chiave sia capire la differenza tra accettabilità e preferenze. Ogni lato ha una serie di cipheresi accettate e un ordine di preferenza tra quelle cifrarie. Le ciphersuites non accettate non sono considerate per le preferenze.

A causa della progettazione del protocollo TLS, il client invia il suo insieme di cifrarie accettate al server. Invia questo set come una lista ordinata e l'ordine indica le preferenze del cliente. Il server non mostra mai al client cosa accetta o quali sono le sue preferenze. Effettua una selezione e dice al cliente che cos'è questa selezione. Ecco perché il server ha l'autorizzazione finale per selezionare la ciphersuite. Il server non ha tuttavia un'autorizzazione completa: non può far sì che il client usi una ciphersuite che il client non desidera.

Dal punto di vista del cliente, il server non ha un set accettabile, o preferenze. Tutto il cliente sa che il server ha scelto una particolare ciphersuite tra quelle offerte dal client.

Il server deve selezionare una ciphersuite che sia accettabile sia per il client che per il server. Se c'è qualche ciphersuite che il client accetta ma il server no, il server non lo prenderà affatto in considerazione. Allo stesso modo, se c'è qualche ciphersuite che il server accetta ma non il client, il server non può selezionarlo (ciò violerebbe il protocollo e il client interromperà la connessione).

Qualsiasi ciphersuite che sia nella lista delle preferenze del cliente sia nell'elenco delle preferenze del server è costruttiva accettabile per entrambe le parti. Tra i ciphersuites reciprocamente accettabili, il server ha l'autorità di decidere quale scegliere.

Potrebbe sceglierne uno a caso, o in base alla fase della luna, o potrebbe prendere un hash della concatenazione delle due liste modulo la dimensione del set accettabile reciprocamente e usarlo come indice nel mutuo- elenco accettabile ordinato in ordine alfabetico inverso della trasformazione rot13 dei nomi ciphersuite ufficiali. Oppure può fare la sua scelta in modo più sano, e OpenSSL offre i due modi che hanno un senso: tra i set accettabili, scegli quello che il server preferisce di più, o quello che il cliente preferisce di più.

All'interno di TLS il client invia un elenco di cifrari supportati nell'ordine di preferenza del cliente. Il server ha i suoi elenchi di codici che è disposto a supportare. Il server è libero di scegliere uno qualsiasi dei codici offerti dal client e che sono supportati anche dal lato server. Come viene fatta questa scelta non è specificata. Per mantenere la scelta semplice, l'API OpenSSL consente all'applicazione server di scegliere tra due strategie: utilizzare le preferenze del client delle cipher o utilizzare le preferenze del server . Esistono argomenti per entrambe queste strategie:

• usa le preferenze del cliente:
  Il client potrebbe mostrare una preferenza per le cifre che sono abbastanza forti ma richiedono risorse di calcolo basse sul client. Ad esempio, i client che hanno istruzioni native per AES probabilmente preferiscono un codice basato su AES. I client senza tali istruzioni (come i processori ARM di fascia bassa) potrebbero preferire ChaCha20 invece poiché questo algoritmo ha bisogno di molte meno risorse in questo caso.
• usa le preferenze del server:
  La crittografia non è molto economica e il server potrebbe quindi preferire cifrari che hanno bisogno del minor numero di risorse sul server (ma che sono ancora forti) al fine di servire molti client in parallelo. Quindi, anche se il cliente preferisse ChaCha20 per risparmiare risorse sul suo sito, il server potrebbe scegliere un codice AES basato poiché è molto più economico da fare sul server se il server ha supporto hardware per AES (la maggior parte fare).