TLS 1.2 Certificato del server e signature_algorithms

2

Nelle specifiche per TLS 1.2 , si dice quanto segue:

If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension.

Tuttavia, quando ho provato il seguente comando in OpenSSL (come server) funziona senza problemi:

openssl s_server -accept 443 -cert ecdsa-cert.crt -key ecdsa-key.key -debug -msg -state -HTTP -cipher ECDHE-RSA-AES128-SHA

Quindi eseguo un altro comando per il client:

openssl s_client -connect 127.0.0.1:443 -debug -cipher ECDHE-RSA-AES128-SHA

Non può essere ulteriormente aggiunto alla console del server, dice "no shared codher". Tuttavia, quando ho usato wireshark e ispeziono ClientHello.signature_algorithms, ha effettivamente avuto una coppia ECDSA al suo interno. Quindi mi chiedo se sono io a interpretare male le specifiche?

    
posta Ryu 12.11.2013 - 09:52
fonte

3 risposte

3

La suite di cifratura ECDHE-RSA-AES128-SHA significa che lo scambio di chiavi utilizzerà una coppia di chiavi ECDH dinamicamente generata, che il server firmerà con la propria chiave privata RSA. Il certificato del server quindi contiene una chiave pubblica RSA, indipendentemente dal modo in cui tale certificato è stato firmato dalla sua CA.

Suppongo che il certificato che utilizzi contenga una coppia di chiavi EC, quindi non compatibile con la suite di crittografia ECDHE-RSA-AES128-SHA . È piuttosto stupido dal server avviare tutto con le opzioni fornite, poiché, in effetti, non supporta affatto la suite di crittografia. Ma il software è noto per essere stupido (a volte).

Quindi, mentre il client è perfettamente in grado di comprendere le firme ECDSA (e afferma come tale nella sua estensione signature_algorithms ), l'elenco delle suite di crittografia supportate che hai configurato gli impedisce di accettare qualsiasi messaggio di ServerKeyExchange che contiene nient'altro che una chiave pubblica ECDH firmata con RSA.

Inoltre, l'estensione signature_algorithms è solo parzialmente correlata a questo. Con questa estensione, il client può annunciare gli algoritmi di firma che supporta, e questo è inteso per help il server selezionare una catena di certificati appropriata e algoritmi per i messaggi che devono essere firmati. Se il client dice "Solo RSA", allora il server dovrebbe sforzarsi di utilizzare solo firme RSA, sia per ciò che si firma (es. ServerKeyExchange messaggio) e per le catene di certificati è invia (tutti i certificati CA dovrebbero essere basati su RSA).

Questo è, in pratica, un pio desiderio. La maggior parte dei server ha solo un certificato, e questo è quello che invierà, indipendentemente dall'estensione signature_algorithms . E la maggior parte dei client si adatterà: se il client supporta realmente le firme RSA, elaborerà le firme RSA sui certificati e sui messaggi TLS. Questo è il comportamento normale in assenza dell'estensione signature_algorithms .

Il vero uso di questa estensione non è limitare i possibili algoritmi di firma - questi sono vincolati sia dalla suite di crittografia che dal tipo di certificato effettivamente posseduto dal server - ma per aiutare il server a scegliere le funzioni di hash / em> da utilizzare con algoritmi di firma. Quando il client dice: "Suppongo RSA con SHA-256", mi sta davvero dicendo al server "se devi usare le firme RSA, allora puoi farlo con SHA-256 come funzione di hash di supporto, so come gestirlo ".

    
risposta data 15.04.2014 - 13:33
fonte
1

Sarei curioso di sapere se ecdsa.crt che stai usando sul server ha una coppia di chiavi che è pronta a gestire RSA. Come ricordo, non solo il client e il server devono essere d'accordo sugli algoritmi di firma e / o hash, ma il server deve avere un certificato e una coppia di chiavi rilevanti per quell'algoritmo.

Il mio pensiero è che il nome del certificato faccia riferimento a "DSA", un tipo di coppia di chiavi alternativo a "RSA" - così mentre hai configurato il server per consentire ECDHE-RSA-AES128-SHA non lo hai dato una coppia di chiavi che può utilizzare per eseguire una risposta ECDHE-RSA-AES128-SHA.

Ammetto che "nessun codice condiviso" non è un salto intuitivo a questo modo di pensare, ma la mia esperienza con OpenSSL è che i messaggi di errore intuitivi non sono verosimili.

    
risposta data 12.11.2013 - 17:11
fonte
-1

Stai utilizzando ECC con ecdsa-cert.crt, quindi dovresti specificare l'opzione di comando -cipher ECDHE-ECDSA-AES128-SHA .

    
risposta data 15.04.2014 - 11:12
fonte

Leggi altre domande sui tag