it-swarm-es.com

¿Cuáles son los pros y los contras de SSL en todo el sitio (https)?

¿Cuáles son los pros y los contras 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?

80
Olivier Lalonde

Dado que la mayoría de las otras respuestas aquí abordan las desventajas de SSL en todo el sitio (principalmente problemas de rendimiento, por cierto, esto puede mitigarse fácilmente descargando la terminación de 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:

  • El resto del sitio no está protegido (aunque esto es obvio, a veces la atención se centra demasiado en la contraseña del usuario).
  • La identificación de la sesión del usuario debe transmitirse de forma clara, lo que permite que sea interceptada y utilizada, y así permite que los malos suplanten a sus usuarios. (Esto es sobre todo de lo que se trataba Firesheep hubbub).
  • Debido al punto anterior, las cookies de sesión no se pueden marcar con el atributo secure, lo que significa que se pueden recuperar de formas adicionales.
  • He visto sitios con SSL de inicio de sesión y, por supuesto, no incluyo la página Olvidé mi contraseña, la página Cambiar contraseña e incluso la página Registro ...
  • El cambio de SSL a no SSL a menudo es complicado, puede requerir una configuración compleja en su servidor web y, en muchos casos, aparecerá un mensaje aterrador para sus usuarios.
  • Si es SOLO la página de inicio de sesión, y f.e. hay un enlace a la página de inicio de sesión desde la página de inicio de su sitio: ¿qué garantiza que alguien no falsifique/modifique/intercepte su página de inicio y haga que apunte a una página de inicio de sesión diferente?
  • Luego está el caso en que la página de inicio de sesión en sí no es SSL, pero solo el [~ # ~] submit [~ # ~] es - ya que es la única vez que se envía la contraseña, por lo que debería ser segura, ¿verdad? Pero, en realidad, eso elimina del usuario la capacidad de garantizar de antemano que la contraseña se envíe al sitio correcto, hasta que sea demasiado tarde. (Por ejemplo, Bank of America, y muchos otros).
61
AviD

La "sobrecarga del servidor" que aumenta como una "estafa" significativa es un mito común. Ingenieros de Google notado que al cambiar gmail a 100% SSL no implementaron hardware adicional, y que SSL representaba menos del 1% de aumento en la carga de la CPU y el 2% en el tráfico de red. Stack Overflow también tiene algunas preguntas relacionadas con esto: ¿Cuánta sobrecarga impone SSL? y HTTP vs. rendimiento HTTPS .

47
user502

Desde la entrada del blog de zscaler ¿Por qué la web aún no se ha cambiado solo a SSL?

"Con Firesheep resaltó una vez más el problema de la sesión lateral, 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 toda la comunicación. De hecho , el cifrado es la única forma de garantizar que las sesiones de usuario no se puedan rastrear fácilmente en una red inalámbrica abierta.

Esto suena fácil: ¡solo agregue 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 las CDN"
  • "los certificados comodín no son suficientes"
  • "HTTP/HTTPS mixto: el problema del huevo y la gallina"
  • "¡las advertencias dan miedo!"
25
Tate Hansen

Ars Technica tiene n 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 inserta anuncios (entregados a través de HTTP) en una página principal entregada 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, los sitios con publicidad probablemente encontrarán 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 incrustados, etc.

19
D.W.

OK, esta es una pregunta antigua, por lo que mi respuesta probablemente languidecerá aquí abajo. Sin embargo, tengo algo que agregar al lado 'contras'.

Latencia HTTPS:

Tener una baja latencia HTTP de cliente a servidor es fundamental para hacer sitios web receptivos y de carga rápida . Y los tiempos rápidos de carga de la página aumentan la felicidad del usuario final .

TCP/IP solo tiene el famoso TCP protocolo de enlace de 3 vías, es decir, la configuración de conexión inicial para HTTP simple TCP requiere 3 paquetes. Cuando SSL/TLS es utilizado, la configuración de la conexión es más complicada, lo que significa que la latencia para las nuevas conexiones HTTPS es inevitablemente mayor que el HTTP de texto sin formato.

Tenga en cuenta que el impacto de esto se puede reducir (pero no eliminar) reutilizando la conexión HTTPS muchas veces, es decir, utilizando conexiones persistentes y otras optimizaciones de rendimiento como SSL False Start .

Modelar exactamente cuánto HTTPS ralentiza las cargas de página es complicado, porque todos los navegadores modernos descargue 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.

15
Jesper M

Un inconveniente 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 uso actual obtienen contenido de una variedad de dominios, por lo que el navegador necesitaría tener certificados para cada uno de estos o aparecerían advertencias. Y luego, por supuesto, si el atacante utilizó una plataforma CDN para la cual el navegador ya tenía certificados, es posible que no reciba una advertencia cuando debería.

Problema complicado con la forma en que las aplicaciones y el contenido se entregan actualmente.

12
Rory Alsop

Pros definitivamente es mayor seguridad. Los inconvenientes podrían ser conexiones relativamente más lentas, un uso más intensivo de la CPU, una administración de certificados precisa, algunos costos para el certificado (si no usa certificados autofirmados). Pero en los últimos tiempos existe una práctica de difusión para usar https y esos inconvenientes pasan a un segundo plano debido al beneficio para los usuarios finales y una mayor confianza en una empresa que brinda servicios.

7
anonymous

Otras respuestas han afirmado un "problema de huevo/gallina" 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 parecer.

El contenido mixto se puede abordar usando RL relativas al protocolo y los mismos escáneres que debería 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 referencia de ruta de red.

Primero escanee sus páginas hasta que encuentre todos los usos de http://example.com/ en enlaces del mismo origen, imágenes y otros activos del sitio y reemplácelos con 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 revertir si algo sale mal más adelante en su migración.

Luego configure redirecciones HTTP-> HTTPS permanentes para que las URL existentes en 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 el rango de página y acelerar el sitio para los visitantes que regresan.

Por supuesto, debe mantener sus escáneres buscando contenido mixto para que pueda detectar regresiones.

5
Mike Samuel

Sé que esta es una vieja pregunta/hilo, pero solo quería señalar un gran PRO para hacer SSL lateral.

SPDY

El uso de mod_spdy en Apache requiere SSL.

Si todavía no ha implementado SPDY, ¡hágalo! Ambos Chrome y Firefox admiten el protocolo, así como Opera.

Esa es aproximadamente la mitad de sus usuarios que podrán aprovechar SPDY.

4
Spock

Otro inconveniente (tocado por otros) es la falta de almacenamiento en caché que obviamente afectará la velocidad. Además, algunas variables del servidor no están disponibles, como HTTP_FORWARDED_FOR, creo.

3
Nev Stokes

Todo lo bueno mencionado aquí, sin embargo, ¡erré el costo de estafa! 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.

3
Henri

Beneficios de mantener todo el sitio encriptado:

  • no molestará a sus visitantes preocupados por la privacidad enviándoles texto sin formato después de iniciar sesión.
  • menor riesgo de errores al redirigir/vincular partes http y https del sitio.

La estafa: ?

Lea los testimonios de google y otros. No tiene que ser costoso ir al 100% https.

3
MattBianco

Si un CMS administra un sitio web que un usuario no técnico puede usar para editar páginas, puede editar el HTML para incluir referencias a recursos externos, como imágenes, a través de HTTP. He creado 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 fuera del sitio que el propietario ha pegado en el sitio.

2
TRiG