¿Cuáles son las ventajas y desventajas de cifrar todo el tráfico HTTP para todo el sitio a través de SSL, en lugar de SSL solo en la página de inicio de sesión?
¿Cuáles son las ventajas y desventajas de cifrar todo el tráfico HTTP para todo el sitio a través de SSL, en lugar de SSL solo en la página de inicio de sesión?
Dado que la mayoría de las otras respuestas aquí se refieren a las desventajas de SSL en todo el sitio (principalmente problemas de rendimiento - por cierto, estos pueden mitigarse fácilmente descargando la terminación SSL, ya sea a una caja de proxy SSL o una tarjeta SSL), señalará algunos problemas con tener solo la página de inicio de sesión a través de SSL, y luego cambiar a no SSL:
secure , lo que significa que se pueden recuperar de formas adicionales. La "sobrecarga del servidor" que aumenta como un "con" significativo es un mito común. Los ingenieros de Google notaron que al cambiar gmail a 100% SSL no implementaron ningún hardware adicional, y ese SSL representó menos del 1% de aumento en la carga de CPU y el 2% en el tráfico de red. Stack Overflow también tiene algunas preguntas relacionadas con esto: ¿Cuántos gastos generales impone SSL? y Rendimiento de HTTP vs. HTTPS .
De la entrada del blog zscaler Por qué la web tiene ¿No has cambiado a SSL solo?
"Con el problema del pirateo de sesión resaltado una vez más por Firesheep, muchas personas me han preguntado por qué más sitios web, o al menos los principales jugadores (Google, Facebook, Amazon, etc.) no han habilitado SSL de forma predeterminada para todos De hecho, la encriptación es la única forma de garantizar que las sesiones de los usuarios no se puedan detectar fácilmente en una red inalámbrica abierta.
Esto suena fácil: ¡simplemente agrega una s después de http en la URL! En realidad no es tan fácil. Estos son algunos de los desafíos ".
Resumen de desafíos (contras):
- "sobrecarga del servidor"
- "latencia aumentada"
- "desafío para los CDN"
- "los certificados comodín no son suficientes"
- "HTTP / HTTPS mixto: la gallina y el problema del huevo"
- "las advertencias dan miedo!"
Ars Technica tiene un excelente artículo que explica algunos de los desafíos en la implementación de SSL en todo el sitio.
Uno grande: la mayoría de las redes publicitarias no ofrecen ninguna forma de publicar anuncios a través de SSL. Además, si incrusta anuncios (entregados a través de HTTP) en una página principal que se entrega a través de HTTPS, los navegadores emitirán advertencias de contenido mixto, a las que no desea someter a sus usuarios. Por lo tanto, es probable que los sitios compatibles con anuncios encuentren muy difícil la transición a SSL en todo el sitio.
El artículo también describe algunos otros desafíos, como widgets de terceros, análisis, videos integrados, etc.
Bien, esta es una pregunta antigua, así que mi respuesta probablemente languidecerá aquí abajo. Sin embargo, tengo algo que añadir al lado de 'contras'.
Latencia HTTPS:
Tener una baja latencia HTTP de cliente a servidor es fundamental para hacer sitios web de carga rápida y receptivos . Y los tiempos de carga de página rápidos aumentan la felicidad del usuario final .
TCP / IP solo tiene el famoso protocolo de enlace de 3 vías TCP, es decir, la configuración de conexión inicial para HTTP simple sobre TCP requiere 3 paquetes. Cuando se utiliza SSL / TLS, la configuración de la conexión es más complicada, lo que significa que la latencia de para las nuevas conexiones HTTPS es inevitablemente más alta que el texto sin formato HTTP.
Tenga en cuenta que el impacto de esto puede reducirse (pero no eliminarse) reutilizando la conexión HTTPS muchas veces, es decir, utilizando conexiones persistentes, y otras optimizaciones de rendimiento como SSL False Start .
Modelar exactamente la cantidad de HTTPS que ralentiza la carga de páginas es complicado, porque todos los navegadores modernos descargan objetos HTTP en paralelo siempre que sea posible . Aun así, el mayor tiempo de configuración inicial de la conexión es significativo e inevitable con la tecnología actual; por lo tanto, el aumento de la nueva latencia de conexión es una consideración importante.
Una desventaja que se pierde en las otras respuestas anteriores es la dependencia masiva en estos días de las redes de distribución de contenido (por ejemplo, Akamai): muchas páginas web en el uso actual obtienen contenido de una variedad de dominios, por lo que el navegador debería tener certeza para Cada uno de estos o advertencias aparecería. Y luego, por supuesto, si el atacante usó una plataforma CDN para la cual el navegador ya tenía certificados, es posible que no reciban una advertencia cuando deberían hacerlo.
Problema difícil con la forma en que se entregan actualmente las aplicaciones y el contenido.
Definitivamente, las ventajas son una mayor seguridad. Los contras podrían ser conexiones relativamente más lentas, un uso más intensivo de la CPU, una administración de certificados precisa y precisa, algunos costos para el certificado (si no utiliza certificados autofirmados). Sin embargo, en los últimos tiempos existe una práctica generalizada de usar https y esos contras llegan a un segundo plano debido al beneficio para los usuarios finales y al aumento de la confianza en una compañía que brinda servicios.
Otras respuestas han declarado un "problema de gallina / huevo" debido a las advertencias de contenido mixto que dificultan la migración HTTP-> HTTPS. Es un problema, pero no creo que sea tan difícil como lo hacen ser.
El contenido mixto se puede abordar utilizando URL relativas al protocolo y los mismos escáneres que debe usar para encontrar problemas de XSS.
RFC 3986 sección 4.2 utiliza el término referencia de ruta de red:
Una referencia relativa que comienza con dos caracteres de barra diagonal se denomina una referencia de ruta de red
Primero escanee sus páginas hasta que encuentre todos los usos de http://example.com/ en enlaces, imágenes y otros recursos del sitio del mismo origen y sustitúyalos por URL relativas al protocolo ( //example.com/... ). Esto le permite tener el mismo HTML servido independientemente de si está sirviendo una página a través de HTTP o HTTPS y lo coloca en una posición mucho mejor para retroceder si algo sale mal más adelante en su migración.
Luego, configure las redirecciones permanentes de HTTP- > HTTPS para que las URL existentes en los sitios fuera de su control continúen funcionando y comiencen a servir a través de HTTPS. El uso de una redirección permanente con encabezados de caché agresivos ayudará a los motores de búsqueda a transferir la clasificación de la página y acelerar el sitio para los visitantes que regresan.
Por supuesto, debe mantener sus escáneres buscando contenido mixto para que pueda capturar regresiones.
Sé que esta es una pregunta / tema anterior, pero solo quería señalar un gran PRO para hacer SSL de lado.
SPDY
El uso de mod_spdy en Apache requiere SSL.
¡Aún no has implementado SPDY, hazlo! Tanto Chrome como Firefox son compatibles con el protocolo, así como con Opera.
Eso es aproximadamente la mitad de tus usuarios que podrán aprovechar SPDY.
Otras desventajas (mencionadas por otros) es la falta de almacenamiento en caché que obviamente afectará la velocidad. Además, algunas variables de servidor no están disponibles, como HTTP_FORWARDED_FOR, creo.
Todos los puntos buenos mencionados aquí, sin embargo, ¡pierdo el costo! Y por costo no me refiero solo a comprar el certificado, sino a tener la infraestructura adecuada para administrar certificados, revocaciones, módulos criptográficos dedicados para disminuir la carga de CPU del servidor web, etc.
Beneficios de mantener todo el sitio encriptado:
La con:?
Lee los testimonios de google y otros. No tiene que ser costoso ir al 100% https.
Si un sitio web está administrado por un CMS que un usuario no técnico puede usar para editar páginas, es posible que edite el HTML para incluir referencias a recursos externos, como imágenes, a través de HTTP. Construí un sitio de compras que usa SSL solo cuando es necesario y redirige otras páginas a HTTP, porque de lo contrario obtendría advertencias de contenido mixto debido a todas las imágenes externas que el propietario ha pegado en el sitio.
Lea otras preguntas en las etiquetas web-application tls webserver