¿Cuánta sobrecarga de red agrega TLS en comparación con una conexión no cifrada?

Question

(Aproximadamente) ¿Cuántos bits más de datos se deben transferir a través de la red durante una conexión cifrada en comparación con una conexión no encriptada?

IIUC, una vez que el protocolo de enlace TLS ha completado, el número de bits transferidos es igual a los transferidos durante una conexión sin cifrar. Es esto exacto?

Como un archivo grande de seguimiento, se transfiere a través de https significativamente más lento que la transferencia de archivos a través de HTTP que, dado procesadores rápidos y los mismos ideales) (condiciones de la red?

Answer 1

He recibido esta pregunta algunas veces, así que decidí escribir una pequeña explicación de la sobrecarga con algunos números de muestra basados ​​en el caso común. Puedes leerlo en mi blog al http://netsekure.org/2010/03/tls-overhead/.

Resumen de la entrada en el blog:

• La sobrecarga total de establecer una nueva sesión TLS trata de unos 6.5K bytes en promedio.
• La sobrecarga total para reanudar una sesión de TLS existente asciende a 330 bytes en promedio.
• La sobrecarga total de los datos cifrados es de aproximadamente 40 bytes.

Answer 2

un orden de magnitud. Ver this. Esto no es demasiado significativo, si vale la pena proteger la información que está protegida. Y recuerde que las velocidades del procesador solo pueden subir, por lo que el rendimiento seguirá mejorando.

Answer 3

La respuesta corta es: Su Kilometraje puede variar (YMMV) - todo depende de su patrón de tráfico. Hay una serie de factores a tener en cuenta:

• Los apretones de manos y los CERT adicionales añadirán 4-6KB al flujo TCP, esto se traducirá en más tramas Ethernet camino al cable, así
• clientes debería descargar certificate revocation list. Algunas herramientas como cURL omiten este paso. El navegador puede almacenar en memoria caché el crl, sin embargo, generalmente no tiene un asociado de larga edad. Verisign establece que expirará el suyo después de cuatro minutos. En mis pruebas, veo a Safari en Windows descargando el mismo archivo de 91KB dos veces.
• TLS Session resumption puede evitar la parte de intercambio de clave pública del apretón de manos, así como la verificación del certificado.
• HTTP keep-alives mantendrá el socket abierto, al igual que http, pero tiene más ahorros cuando la toma es TLS.
• SSL compression soporte está comenzando a aparecer en el lado del servidor, pero AFAIK, la mayoría de los navegadores no están implementando esto todavía. Además, si ya está comprimiendo en la capa http, no se obtendrá mucho aquí. Se podrían obtener ganancias potencialmente grandes si el cliente está enviando grandes cantidades de texto al servidor, que normalmente no está comprimido en la capa http.

Answer 4

En la sobrecarga calculada en http://netsekure.org/2010/03/tls-overhead/, ¿cree que podría haber saltado el vector de inicialización (IV) para la AES en modo CBC? dado que es AES128, creo que se deben agregar 16 Bytes de IV a la sobrecarga, lo que hace un total de 56 en lugar de 40 Bytes.