¿Cuánta sobrecarga impone SSL?

168

Sé que no hay una única respuesta rápida, pero ¿existe una aproximación genérica ~~de estimación de orden de magnitud~~ para la sobrecarga de cifrado de SSL versus comunicación de socket no cifrada? Solo estoy hablando del procesamiento de comunicaciones y el tiempo de transferencia, sin contar el procesamiento a nivel de aplicación.

Actualizar

Hay una pregunta sobre HTTPS versus HTTP , pero estoy interesado en mirar más abajo en la pila.

(Reemplacé la frase "orden de magnitud" para evitar confusiones; lo estaba usando como jerga informal en lugar de en el sentido formal de CompSci. Por supuesto, si lo hubiera querido decir formalmente, como un verdadero geek hubiera estado pensando en binario en lugar de en decimal! ;-)

Actualizar

Por solicitud en el comentario, supongamos que estamos hablando de mensajes de buen tamaño (rango de 1k-10k) a través de conexiones persistentes. Por lo tanto, la configuración de la conexión y la sobrecarga de paquetes no son problemas importantes.

— joel.neely
fuente

Puedes echar un vistazo a esta pregunta similar .

— Darin Dimitrov

¿Puedes caracterizar tu aplicación un poco más? Por ejemplo, ¿establece muchas conexiones de corta duración? Mientras está conectado, ¿qué tan grande tiende a ser un mensaje individual? (Por ejemplo, tal vez usted es el lavado de cada pulsación de tecla con Telnet a través de un túnel SSL, o tal vez usted está copiando archivos de registro de 1 Tb.)

— Erickson

Respuestas:

178

Orden de magnitud: cero.

En otras palabras, no verá su rendimiento reducido a la mitad, ni nada parecido, cuando agregue TLS. Las respuestas a la pregunta "duplicada" se centran en gran medida en el rendimiento de la aplicación y en cómo se compara con la sobrecarga de SSL. Esta pregunta excluye específicamente el procesamiento de la solicitud y busca comparar solo SSL que no sea SSL. Si bien tiene sentido tener una visión global del rendimiento al optimizar, eso no es lo que esta pregunta está planteando.

La sobrecarga principal de SSL es el apretón de manos. Ahí es donde ocurre la costosa criptografía asimétrica. Después de la negociación, se utilizan cifras simétricas relativamente eficientes. Es por eso que puede ser muy útil habilitar sesiones SSL para su servicio HTTPS, donde se realizan muchas conexiones. Para una conexión de larga duración, este "efecto final" no es tan significativo y las sesiones no son tan útiles.

Aquí hay una anécdota interesante. Cuando Google cambió a Gmail para usar HTTPS, no se necesitaron recursos adicionales; sin hardware de red, sin nuevos hosts. Solo aumentó la carga de la CPU en aproximadamente un 1%.

— erickson
fuente

¿Cómo "habilita las sesiones SSL para su servicio HTTPS"? ¿Qué es un buen recurso para aprender sobre esto?

— Justin Vincent

La habilitación de sesiones SSL es específica del servidor. Lea el manual de su servidor.

— erickson

@Bart van Heukelom: Keep-alive ayudará a mantener abierto un socket (y la conexión SSL) durante más tiempo, lo que ayuda. Pero las sesiones SSL hacen que los parámetros criptográficos negociados sean "recordados" de un socket a otro. Por lo tanto, HTTP keep-alive sería útil para cargar una sola página web con su contenido referenciado, pero después de unos segundos, esa conexión se cerrará. Tres minutos después, digamos, cuando se recupera otra página, una sesión SSL permite restablecer la conexión SSL sin repetir el apretón de manos completo. En particular, se puede omitir el intercambio lento de claves con criptografía de clave pública.

— erickson

@ Tony ¿Tienes algún ejemplo del mundo real en el que TLS agrega más de un porcentaje de gastos generales? Mi respuesta es tan general como la pregunta. Si tiene una opinión diferente, compártala.

— erickson

@ Tony He visto que los sockets simples superan a los sockets SSL por un factor de 42 en términos de espacio al escribir un solo byte a la vez, que es el peor de los casos. Nunca visto 250x. Hice un extenso experimento en Internet con 1700 puntos de datos donde el resultado general fue que los sockets de texto sin formato no eran mejores que tres veces más rápido que SSL, usando una programación no más sofisticada que el almacenamiento en búfer y el vaciado. JSSE, probablemente Java 5 dada la fecha del experimento.

— Marqués de Lorne

Segundo @erickson: la penalización de velocidad de transferencia de datos pura es insignificante. Las CPU modernas alcanzan un rendimiento de cifrado / AES de varios cientos de MBit / s. Entonces, a menos que esté en un sistema con recursos limitados (teléfono móvil), TLS / SSL es lo suficientemente rápido como para distribuir datos.

Pero tenga en cuenta que el cifrado hace que el almacenamiento en caché y el equilibrio de carga sean mucho más difíciles. Esto podría resultar en una gran penalización de rendimiento.

Pero la configuración de la conexión es realmente un obstáculo para muchas aplicaciones. En un ancho de banda bajo, una gran pérdida de paquetes y conexiones de alta latencia (dispositivo móvil en el campo), los viajes de ida y vuelta adicionales requeridos por TLS pueden hacer que algo lento se vuelva inutilizable.

Por ejemplo, tuvimos que abandonar el requisito de encriptación para acceder a algunas de nuestras aplicaciones web internas, que eran casi inutilizables si se usaban en China.

— max
fuente

Con 4 años en retrospectiva: China también podría haber desordenado intencionalmente todo el tráfico SSL / TLS.

— max

China censura Internet e intenta rastrear el tráfico de todos no es exactamente una noticia. Sin embargo, con 4 años en retrospectiva, pensarías que fue el NSA MITMing en el camino a tu sitio.

— Eugene Beresovsky

La clave con conexiones defectuosas es, configurar el cifrado una vez, y luego evitar renegociaciones a menos que sea realmente necesario, y permitir que ambas partes cambien sus direcciones IP en cualquier momento sin pestañear. (OpenVPN lo admite). TI ayuda a hacer posible la fragmentación, ya que la MTU puede ser muy poco confiable y francamente deshonesta.

— Evi1M4chine

Suponiendo que no cuenta la configuración de la conexión (como indicó en su actualización), depende en gran medida del cifrado elegido. La sobrecarga de la red (en términos de ancho de banda) será insignificante. La sobrecarga de la CPU estará dominada por la criptografía. En mi Core i5 móvil, puedo cifrar alrededor de 250 MB por segundo con RC4 en un solo núcleo. ~~(RC4 es lo que debe elegir para obtener el máximo rendimiento).~~ AES es más lento y proporciona "solo" alrededor de 50 MB / s. Por lo tanto, si elige los cifrados correctos, no podrá mantener un solo núcleo actual ocupado con la sobrecarga de cifrado, incluso si tiene una línea de 1 Gbit totalmente utilizada. [ Editar : RC4 no debe usarse porque ya no es seguro. Sin embargo, el soporte de hardware AES ahora está presente en muchas CPU, lo que hace que el cifrado AES sea realmente rápido en tales plataformas.]

El establecimiento de la conexión, sin embargo, es diferente. Dependiendo de la implementación (por ejemplo, soporte para inicio falso de TLS), agregará viajes de ida y vuelta, lo que puede causar retrasos notables. Además, se realiza una criptografía costosa en el primer establecimiento de conexión (la CPU mencionada solo podría aceptar 14 conexiones por núcleo por segundo si usaba tontamente claves de 4096 bits y 100 si usa claves de 2048 bits). En conexiones posteriores, las sesiones anteriores a menudo se reutilizan, evitando el costoso cifrado.

Entonces, para resumir:

Transferencia en conexión establecida:

Retraso: casi ninguno
CPU: insignificante
Ancho de banda: insignificante

Primer establecimiento de conexión:

Retraso: viajes de ida y vuelta adicionales
Ancho de banda: varios kilobytes (certificados)
CPU en el cliente: medio
CPU en el servidor: alta

Establecimientos de conexión posteriores:

Retardo: ida y vuelta adicional (no estoy seguro si uno o varios, pueden depender de la implementación)
Ancho de banda: insignificante
CPU: casi ninguna

— Jan Schejbal
fuente

Nota importante: Nadie debería usar RC4 nunca más. El protocolo debe considerarse roto y la transmisión RC4 con él debe verse como equivalente a la transmisión sin cifrar, como mínimo, por seguridad de las organizaciones de espionaje. Hoy en día, se recomienda encarecidamente algo como chacha20-poly1305 para el cifrado masivo debido a su independencia de tales organizaciones.

— Evi1M4chine