Te sugerimos que pruebes esta solución en un ambiente controlado antes de enviarlo a producción, un saludo.
Solución:
El de 2048 bits es sobre el RSA key par: RSA keys son objetos matemáticos que incluyen un número entero grande y un “número de 2048 bits”. key” es un key tal que el entero grande es mayor que 22047 pero mas pequeño que 22048.
El de 256 bits se trata de SSL. En SSL, el servidor key se usa solo para transmitir una señal aleatoria de 256 bits key (que uno no tiene estructura matemática, es solo un montón de bits); en términos generales, el cliente genera un código aleatorio de 256 bits keylo encripta con el RSA público del servidor key (el que está en el certificado del servidor y es un “2048-bit key”), y envía el resultado al servidor. El servidor usa su RSA privado key para invertir la operación, y así obtener los 256 bits key elegido por el cliente. Luego, el cliente y el servidor usan 256 bits para hacer simétrico comprobaciones de cifrado e integridad, y RSA ya no se usa para esa conexión.
Vea esta respuesta para más detalles. Esta configuración a menudo se denomina “cifrado híbrido”. Esto se hace porque RSA no es apropiado para el cifrado masivo, pero el cifrado simétrico no puede hacer el negocio público/privado inicial que se necesita para comenzar.
(SSL puede hacer el key intercambie con otros algoritmos además de RSA, por lo que he simplificado un poco la descripción en el texto anterior, pero esa es la esencia de la idea).
Para agregar un poco más de detalle, el RSA de 2048 bits key es algo llamado criptografía asimétrica. Se utiliza para validar la identidad (firma) y garantizar que solo un destinatario pueda acceder a la información enviada (cifrado). Está compuesto por dos piezas, un público key y un privado key. los keys en realidad están relacionados entre sí, pero debido a que están relacionados por dos números pseudo-primos muy grandes (primos entre sí), es muy difícil descifrar el número privado. key del público
Dicho esto, debido a que el algoritmo se basa en algo que es realmente difícil de entender (pero que se puede resolver), es menos seguro que un algoritmo simétrico basado en un secreto compartido, que no se puede resolver matemáticamente y no depende de la complejidad. de un problema matemático de seguridad (más sobre eso más adelante). Esta es la razón por la cual el key es mucho más grande que la contraparte simétrica (que tiene solo 256 bits). Para hacer que la ecuación sea difícil de resolver, se requiere la mucho mayor key y también, cuanta más información se transmite con el asimétrico keyes más probable que se rompa (además, el cifrado/descifrado es más intenso en el procesador).
Por esta razón, SSL solo utiliza RSA para la validación y key fases de intercambio. En cambio, un simétrico key (en este caso, de 256 bits si el navegador del cliente lo admite) se genera y se transmite de vuelta al servidor a través del cifrado RSA y luego el resto de los datos se intercambia a través de la red compartida. key y un algoritmo simétrico.
Esto ocurre cuando el cliente primero decodifica la respuesta a un desafío que el servidor cifra con su código privado. keyel cliente puede mirar al público key del servidor (que está firmado por un root conocido key que la CA (en este caso DigiCert) ha incluido con la mayoría de los navegadores). Cuando la respuesta decodificada coincide con el desafío, el cliente sabe que el servidor respondió a la solicitud (aunque puede haber un intermediario que la transmita). Luego, el cliente genera el simétrico de 256 bits. key y lo cifra con el público del servidor key y lo envía al servidor. Porque el key está encriptado con el público del servidor keysolo el servidor (que conoce el privado key) puede descifrarlo. Esto significa que cualquier intermediario en el paso anterior no puede conocer el nuevo compartido. key. El cliente ahora puede confiar en que cualquier información enviada a través del key proviene solo del servidor previsto.
Solo para agregar algunos detalles a las respuestas existentes …
mi pregunta es cómo sabría el cliente generar un bit aleatorio de 256 key? (¿Por qué no 128?).
Esto depende del conjunto de cifrado que se negocie. La lista de los definidos como parte de TLS 1.1 se encuentra en el Apéndice A.5 de RFC 4346. Por ejemplo TLS_RSA_WITH_AES_128_CBC_SHA
usará una de 128 bits keymientras que TLS_DHE_RSA_WITH_AES_256_CBC_SHA
usará una de 256 bits key.
El conjunto de cifrado que se negocie dependerá de la configuración del cliente y del servidor, no del certificado instalado en el servidor. Cuando el cliente inicia la conexión con un Client Hello
mensaje, envía una lista de conjuntos de cifrado que admite. Luego, el servidor elige el que quiere y lo dice en su Server Hello
mensaje.
Esta suite de cifrado luego determina cómo estos simétricos keys finalmente se comparten. El propósito inmediato del protocolo de enlace SSL/TLS es establecer un intercambio secreto pre-maestro entre el cliente y el servidor. Esto se conoce más ampliamente como el key-intercambio (ver RFC 4346 Apéndice F.1.1).
Esto cae en dos categorías (excluyendo anónimo key intercambio):
- RSA key intercambio (por ejemplo
TLS_RSA_WITH_AES_128_CBC_SHA
): el cliente encripta el secreto pre-maestro usando el público del servidor key (que se encuentra en el certificado). - DH(E) key intercambio (por ejemplo
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
): un Diffie-Hellman key se produce el intercambio. El servidor firma sus parámetros DH y el cliente verifica la firma contra el público key en el certificado del servidor. (Tener un certificado basado en RSA no implica una RSA key intercambio.)
Al final del apretón de manos, cualquiera de estos dos pasos que se usaron, el cliente y el servidor están en posesión de un común secreto pre-maestrode donde derivan un secreto maestro (ver RFC 4346 Sección 8.1).
A partir de ese secreto maestroambas partes pueden derivar el cifrado keys (y secretos MAC), como se describe en RFC 4346 Sección 6.3.
junto al key tipo (RSA o DSS), no hay nada en esto que haga que el tamaño de la encriptación key depender del certificado. Además, ambos tipos tienen suites de cifrado que utilizan 256 bits keys: por ejemplo TLS_DHE_DSS_WITH_AES_256_CBC_SHA
y TLS_DHE_RSA_WITH_AES_256_CBC_SHA
. (DSS es un algoritmo de solo firma, por lo que no obtendría un RSA como key Exchange para cifrar el secreto premaestro).
el tamaño de la key en el certificado sólo importa para evitar la falsificación del key intercambio (o para poder descifrar el tráfico registrado): si alguien pudo encontrar el privado key del público key en el certificado, podrían actuar como un MITM para hacerse pasar por el servidor real o podrían descifrar el secreto pre-maestro cifrado (y, por lo tanto, el tráfico registrado) al usar un RSA key intercambio (los conjuntos de cifrado DHE están diseñados con precisión para evitar el acceso al secreto premaestro, incluso si el atacante se apodera del secreto privado). key y el tráfico registrado, consulte esta pregunta). Esta es la razón por la que un asimétrico suficientemente grande key asuntos.
Las Autoridades de Certificación tienden a poner “256 bits” en sus sitios web porque se ven bien desde el punto de vista del marketing.
No está mal, pero puede ser engañoso para las personas que no entienden que lo que importa es cómo está configurado su servidor y qué admiten sus clientes.
Ten en cuenta difundir este artículo si lograste el éxito.