gmail.com Google, fb, ... usa RC4-SHA. Come si crea un certificato autofirmato RC4-SHA?
O anche con la chiave aes128? Ho provato a usare "genrsa -aes128", il risultato è stato DHE-RSA-AES256-SHA
openssl genrsa -aes128 -out 1.key 1024 openssl req -new -key 1.key -out 1.csr cp -f 1.key orig.1.key openssl rsa -in orig.1.key -out 1.key openssl x509 -req -in 1.csr -signkey 1.key -out 1.crt
Il certificato non ha (quasi) nulla a che fare con la crittografia utilizzata nella comunicazione SSL / TLS. L'unico scopo dei certificati usati dai siti web che hai citato è quello di autenticare il server.
RC4, AES-128, AES-256 sono gli algoritmi di crittografia utilizzati dal canale SSL / TLS stesso. In questo contesto, SHA è il nome dell'algoritmo MAC (utilizzato per garantire l'integrità della comunicazione).
Entrambi sono crittografia e gli algoritmi MAC sono configurati con le suite di crittografia, che sono configurate su client e server e sono (relativamente) indipendenti dal certificato. L'unica dipendenza è che alcune suite di crittografia richiedono un certificato con una chiave RSA, altre un certificato con una chiave DSA.
Se osservi l' elenco di suite di crittografia nelle specifiche di TLS 1.1 , ci sono dei codici suite per RC4-SHA, AES128-SHA e AES126-SHA con chiavi RSA. Qualsiasi certificato moderno con una chiave RSA dovrebbe essere in grado di supportarli, a condizione che anche lo stack SSL / TLS che si desidera utilizzare li supporti e sia configurato per farlo.
(Potresti anche essere interessato a questa domanda .)
In openssl genrsa -aes128 , -aes128 è usato per dire a OpenSSL come crittografare la chiave privata che sta generando (nel file stesso).
Il codice utilizzato dipende dall'handshake SSL del client e del server; non è dettato dalla coppia di chiavi stessa. Durante questa stretta di mano, il client e il server mostrano quali algoritmi supportano e in genere il server sceglie il cifrario più potente disponibile.
Le chiavi pubbliche / private possono essere utilizzate per raggiungere tre obiettivi principali; integrità, autenticazione e riservatezza. Tuttavia, non è necessario eseguire l'autenticazione in quanto SSL / TLS può essere implementato con anonimato totale .
Dalla pagina 34 di TLS 1.0 ( RFC 2246 ):
The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key length) and a MAC algorithm. The server will select a cipher suite
or, if no acceptable choices are presented, return a handshake
failure alert and close the connection.
Dalla pagina 91 di TLS 1.2 ( RFC 5246 ):
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity.
Inoltre, vedi qui per una descrizione più semplice del processo di handshake SSL / TLS.
È anche importante notare che questa cifra viene utilizzata solo quando si esegue l'handshake e si scambia la chiave simmetrica che, dopo essere stata concordata, viene utilizzata esclusivamente per il resto della sessione A MENO che la chiave segreta è impostata per essere rinegoziata .
Leggi altre domande sui tag openssl tls certificates