gmail.com Google, fb, ... usa RC4-SHA. ¿Cómo se crea un certificado autofirmado RC4-SHA?
¿O incluso con la clave aes128? Intenté usar "genrsa -aes128", lo que resultó en cert fue 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
El certificado no tiene (casi) nada que ver con el cifrado utilizado en la comunicación SSL / TLS. El único propósito de los certificados utilizados por los sitios web que menciona es autenticar el servidor.
RC4, AES-128, AES-256 son los algoritmos de cifrado utilizados por el propio canal SSL / TLS. En este contexto, SHA es el nombre del algoritmo MAC (utilizado para garantizar la integridad de la comunicación).
Ambos son cifrado y los algoritmos MAC se configuran con las suites de cifrado, que se configuran tanto en el cliente como en el servidor, y son (relativamente) independientes del certificado. La única dependencia es que algunas suites de cifrado requieren un certificado con una clave RSA, otras un certificado con una clave DSA.
Si observa la lista de conjuntos de cifrado en la especificación TLS 1.1 , hay cifrado Suites para RC4-SHA, AES128-SHA y AES126-SHA con llaves RSA. Cualquier certificado moderno con una clave RSA debe ser compatible con estos, siempre que la pila SSL / TLS que desee utilizar también los admita y esté configurado para hacerlo.
(También puede interesarle esta pregunta .)
En openssl genrsa -aes128 , -aes128 se usa para decirle a OpenSSL cómo cifrar la clave privada que está generando (en el propio archivo).
El cifrado utilizado depende del protocolo SSL del cliente y del servidor; no es dictada por el par de claves en sí. Durante este apretón de manos, el cliente y el servidor muestran qué algoritmos son compatibles, y el servidor normalmente elegirá el cifrado más fuerte disponible.
Las claves públicas / privadas pueden usarse para lograr tres objetivos principales; Integridad, autenticación y confidencialidad. Sin embargo, no tiene que realizar la autenticación, ya que SSL / TLS se puede implementar con anonimato total .
Desde la página 34 de TLS 1.0 ( RFC 2246 ):
La lista de CipherSuite, pasada del cliente al servidor en el
Mensaje de saludo del cliente, contiene las combinaciones de imágenes criptográficas. Algoritmos soportados por el cliente por orden del cliente. preferencia (elección favorita primero). Cada CipherSuite define una clave
algoritmo de intercambio, un algoritmo de cifrado masivo (incluida la clave secreta longitud) y un algoritmo de MAC. El servidor seleccionará una suite de cifrado
o, si no se presentan opciones aceptables, devuelva un apretón de manos
alerta de fallo y cierra la conexión.
Desde la página 91 de TLS 1.2 ( RFC 5246 ):
TLS admite tres modos de autenticación: autenticación de ambos
partes, autenticación del servidor con un cliente no autenticado, y
anonimato total.
También, vea aquí para obtener una descripción más sencilla del proceso de negociación SSL / TLS.
También es importante tener en cuenta que este cifrado solo se usa cuando se realiza el intercambio y el intercambio de la clave simétrica que, una vez acordado, se usa exclusivamente para el resto de la sesión A MENOS QUE la la clave secreta está configurada para renegociar .
Lea otras preguntas en las etiquetas tls certificates openssl