Rendimiento SSL bidireccional

3

Estamos planeando usar un ssl de 2 vías en lugar del token de nombre de usuario / contraseña para la autenticación. ¿Alguien sabe cuál es la penalización de rendimiento por usar SSL de 2 vías?

    
pregunta Ashish 18.03.2013 - 19:43
fuente

2 respuestas

6

Si por "2-Way" quiere decir "SSL con autenticación de cliente basada en certificado", entonces puede esperar la siguiente sobrecarga:

  • El servidor envía un mensaje CertificateRequest que contiene la lista de los nombres de la CA raíz que el servidor usará para validar el certificado del cliente. Dependiendo de la lista de dicha CA, este mensaje puede tener un tamaño no despreciable (por ejemplo, 10 kilobytes). Por supuesto, en cualquier configuración razonable, el servidor debe aceptar solo una o dos CA, dejando este tamaño de mensaje muy por debajo de 1 kilobyte (pero muchos Windows / IIS no son muy razonables).
  • El cliente envía su certificado como parte de una cadena. El tamaño típico de un certificado es de 1 a 2 kilobytes, y la cadena del cliente contendrá entre 1 y 4 certificados (puede contener más, pero si lo hace, entonces está haciendo cosas extrañas con su PKI).
  • El cliente calculará una firma y el servidor verificará la firma. En una PC básica, con RSA, el tiempo de generación de firmas será de unos pocos milisegundos, y la verificación será al menos 20 veces más rápida que eso. Si el cliente utiliza una tarjeta inteligente, el tiempo de generación de la firma probablemente será de aproximadamente 1 segundo (el cuello de botella principal es la velocidad de E / S con la tarjeta).
  • La firma del cliente también es enviada por el cliente (alrededor de 260 bytes para un RSA de 2048 bits).

La autenticación del cliente con certificados no conlleva un viaje de ida y vuelta adicional, pero sí significa más datos durante el saludo inicial (como se explicó anteriormente, hasta unas pocas docenas de kilobytes) y un poco de CPU adicional (en cantidades similares a las que debe tener el servidor calcular de todos modos). Una vez que se han jugado estos juegos de certificados, el resto de la conexión es idéntica a lo que ocurriría sin un certificado de cliente. No hay más impacto.

Además:

  • Una vez que un cliente y un servidor han hecho un apretón de manos con certificados, ambos conocen un secreto compartido, que pueden reutilizar. Otras conexiones utilizarán el protocolo de enlace abreviado , que no implica criptografía asimétrica y es más rápido (en particular, un viaje de ida y vuelta menos a la red). Esto mantiene el costo general bajo en un servidor típico.
  • En muchas configuraciones, la autenticación del cliente basada en certificados se realiza con una renegociación: el cliente primero se conecta "anónimamente" al servidor, y luego el servidor solicita un nuevo saludo dentro de la conexión , esto Tiempo con un certificado de cliente. Esto suele ser necesario en un contexto HTTPS, porque el servidor aprenderá la URL de destino solo cuando se haya completado el primer intercambio, y solo entonces sabrá el servidor que el cliente desea llegar a una parte del Sitio que requiere autenticación de cliente con certificados. Con una renegociación, el segundo saludo significa dos viajes de ida y vuelta adicionales a la red.

La autenticación de inicio de sesión + contraseña tiene mayores gastos generales porque tendrá que enviar una redirección a una página de inicio de sesión y luego verificar la contraseña. El procesamiento de la página de inicio de sesión, el trabajo de la interfaz gráfica adicional en el cliente y el hashing lento en el servidor para la verificación de la contraseña, incurrirán en gastos de red y CPU que reducirán los costos de los certificados de cliente. Por lo tanto, el cambio de inicio de sesión + contraseña a certificados puede disminuir los costos de red y CPU en su servidor.

(Pero certificados significa gestión de certificados y PKI , y eso es nuevamente un costo mucho mayor.)

    
respondido por el Tom Leek 18.03.2013 - 20:13
fuente
0

Los certificados de cliente se utilizan para la autenticación y la negociación de claves en SSL. Se sigue utilizando una clave de sesión, por lo que no debería haber ninguna diferencia después de que se establezca una conexión. No estoy seguro de cuánta penalización, si la hubiera, habría para la fase de autenticación, pero no esperaría que fuera significativa en comparación con tener que ejecutar un hash seguro con una contraseña. Bien puede ser más rápido.

    
respondido por el AJ Henderson 18.03.2013 - 19:50
fuente

Lea otras preguntas en las etiquetas