¿Puede la implementación de SSL incurrir en problemas de rendimiento [cerrado]

  

¿La implementación de SSL para la comunicación segura de servidor-cliente incurre en una sobrecarga de rendimiento?

• SSL / TLS ya no es computacionalmente caro .
• De hecho, en algunos casos y con algunas optimizaciones, puede ser realmente más rápido que HTTP simple. Vea esto: enlace

  

¿Por qué no solo utilizar HTTPS para la navegación web estándar cuando se comprueba que protege nuestra privacidad?

Tradicionalmente, a las personas no les ha importado el HTTPS porque:

• Implica más trabajo como obtener certificados, reinstalar certificados nuevos después de que caduquen, etc.
• es difícil (o a veces no es posible) configurarlo en los servidores de alojamiento compartido.

Sin embargo, esto está cambiando rápidamente, gracias a iniciativas como letsencrypt que hacen que los certificados sean fáciles de crear y gratuitos.

Además, Google Chrome está haciendo un gran trabajo al impulsar a las personas a adoptar HTTPS. Hay dos iniciativas en tramitación que harán / obligará a muchos propietarios de sitios web a pasar a https. De este anuncio :

• A partir de enero de 2017 (Chrome 56), marcaremos las páginas HTTP que recopilan contraseñas o tarjetas de crédito como no seguras.
• Eventualmente,planeanetiquetartodaslaspáginasHTTPcomonoseguras,ycambiarelindicadordeseguridadHTTPaltriángulorojoqueusamosparaHTTPSroto.

Dadas estas iniciativas, deberíamos ver una adopción muy saludable de https en el futuro.

Supongo que de la pregunta que querías decir SSL. SSH o shell seguro es una alternativa a telnet para obtener una interfaz administrativa remota. No está relacionado con el tráfico web o la navegación.

Con respecto a su consulta, sí, hay una sobrecarga de rendimiento cuando se utiliza HTTPS en lugar de HTTP.

El motivo de esto es el apretón de manos y la comunicación involucrados en la configuración de una conexión SSL.

Al acceder a un sitio web HTTP normal, el cliente completará el protocolo de enlace de tres vías TCP, establecerá la comunicación y comenzará a enviar solicitudes HTTP.

Por otra parte, en un sitio web https, hay una renegociación adicional para establecer los parámetros de seguridad para TLS. Esto consume recursos y eso resulta en una sobrecarga computacional.

El código criptográfico del jefe de red de Google para Chrome y los servidores escribió en 2010 que la sobrecarga de CPU de TLS en Google fue del 1%.

TLS no ha sido lento durante mucho tiempo. Decir que es lento es casi como decir "Escuché que el 8087 es lento, así que no uso el número de punto flotante en mi código". Además, le tomaría 1 minuto a Google hacer este hecho.

SSH tiene un caso de uso muy diferente al de la web. Es para usuarios técnicos que acceden a sistemas internos. Siempre se implementa de una manera que requiere la autenticación del cliente al servidor y no solo del servidor al cliente.

La tecnología dentro de SSH moderno y TLS moderno es igual de segura y rápida: AES-GCM o ChaCha20-Poly1305 para una confidencialidad e integridad masivas, RSA o ECDSA o firmas digitales EdDSA para autenticación, ECDHE sobre P-256 o X25519 para el intercambio de claves y el secreto hacia adelante. Las CPU modernas de Intel hacen más de 2 GB por segundo por núcleo de AES y unos pocos miles de protocolos RSA por segundo. EdDSA es más rápido que RSA, pero solo estará disponible para TLS el próximo año.

SSH fue más rápido con la estandarización de X25519 y EdDSA, pero la adopción de nuevas versiones y suites de cifrado es más rápida con TLS, ambas cosas por razones no técnicas complicadas.

Ambos protocolos permiten que los clientes sean autenticados por el servidor usando claves previamente compartidas o públicas, con la clave privada potencialmente en una tarjeta inteligente.

Ambos protocolos pueden usar claves previamente compartidas o confianza en el primer uso o PKI. La configuración predeterminada de SSH es confiar en el primer uso. Por defecto, la Web se distribuye en caché con la confianza en el primer uso a través de certificados de dominio webpki validados. Los clientes pueden y con frecuencia realizan una autenticación no predeterminada (por ejemplo, certificados anclados emitidos por una CA corporativa).

Desde las revelaciones de Snowden, algunas organizaciones, especialmente Google, han declarado la guerra al tráfico no cifrado y están presionando a todos para que usen TLS. Los sitios que admiten TLS deben tener como valor predeterminado TLS y quizás no admitan texto sin formato. ¿Por qué stackexchange.com no establece el valor predeterminado de TLS? No lo sé.

La respuesta a tu pregunta es "sí". La pregunta real no es si es lenta, ya que puede atribuirse a múltiples factores variables como la velocidad de la red, el ancho de banda y la carga de tráfico. Sin embargo, si preguntas "¿Es más lento?" Entonces la respuesta es sí. Sin embargo, en una red suficientemente capaz la diferencia es insignificante.

Para ser justos, @ Z.T. tiene el derecho de hacerlo, aunque puede ser más detalles técnicos de lo que está buscando.