En caso de que todos los sitios utilizar SSL por defecto?

Question

Estamos en el proceso de mover nuestra arquitectura web a un nuevo entorno. Se incluyen docenas de diferentes sitios que van desde casi completamente estática a sitios dinámicos que requieren autenticación y contenido sensible. Nuestros administradores del servidor web, tienen (y sin ninguna intervención del equipo de desarrollo) decidieron convertirlo en un estándar en el nuevo entorno de la fuerza SSL para todo. No estoy de acuerdo con esta decisión y me gustaría tener el mayor conocimiento posible cuando me siento a hablar de ello. Esto es lo que tengo hasta ahora:

• Para cada sitio, un certificado SSL tiene un costo directo. Tenemos una, control de calidad y entorno prod dev y por lo tanto es decir, tres certificados que son necesarios para cada sitio
• En la mayoría de las páginas, el contenido no es segura y forzar SSL haría que las solicitudes de páginas tardan más tiempo en el servidor debido a cifrar y descifrar
• Por lo que entiendo, la mayoría de los navegadores de páginas de caché No SSL'ed que son y por lo tanto una vez más, las solicitudes de páginas tardarán más
• Los navegadores más antiguos tienen problemas con la descarga de archivos cuando son SSL'ed

No tengo un problema con forzar SSL cuando los usuarios se autentican o que están solicitando los datos sensibles. Sin embargo, creo que forzar SSL por defecto en todos los sitios es un poco mucho.

Answer 1

SSL puede de inhibición de red a nivel de almacenamiento en caché. Hay soluciones a este, pero puede significar que varios equipos en la misma red tienen a los recursos página volver a descargar. Esto puede aumentar la carga de red en ambos extremos. el almacenamiento en caché de nivel navegador no es un problema en los navegadores modernos.

SSL complica el uso de los llamados "dominios virtuales". Tradicionalmente, a fin de formar una conexión SSL el navegador y el servidor necesidad de estar trabajando con el mismo nombre de dominio. Esto hizo que fuera imposible de acogida más de un certificado SSL en una sola dirección IP ya que el servidor responderá con el certificado mal. Las implementaciones de Nombre del servidor Indicación (una extensión del protocolo TLS que utiliza SSL) se ha arreglado muchos de los problemas con esto.

El rendimiento puro, el cifrado y comprobación de integridad de datos del túnel simétrica no es muy caro; si el servidor no puede cifrar y descifrar en la velocidad de la red, entonces o bien usted tiene propia de fibra óptica de Dios, o se debe pensar en la sustitución de los i486. Sin embargo, el inicio de una conexión SSL, conocido como "apretón de manos", es un poco más caro, y puede implicar un cuello de botella en el rendimiento de cargas pesadas (cuando hay cientos de conexiones por segundo, o más). Afortunadamente, una instancia de navegador determinado reutilizará túneles y sesiones SSL, por lo tanto, esto no es un problema si sólo tiene unas pocas docenas de usuarios.

En general, poniendo SSL en todas partes parece una manera de conseguir una "sensación borrosa caliente" en materia de seguridad. Esto no está bien. Esto generalmente significa que al concentrarse en lo irrelevante, los administradores serán más propensos a no tener en cuenta los problemas de seguridad reales. También harán el sistema más complejo de mantener, por lo que es más difícil de diagnosticar y corregir problemas. Tenga en cuenta que a partir de los administradores punto de vista, esto hace que su trabajo sea más seguro, ya que aumenta el costo de despedirlos y sustituirlos.

Answer 2

En respuesta a respuesta de Thomas:

  

Para cada sitio, un certificado SSL tiene un costo directo. Tenemos una, control de calidad y entorno prod dev y por lo tanto es decir, tres certificados que son necesarios para cada sitio

Apenas cierto. Usted no necesita tener todos y cada uno dev y qa detrás de SSL con certificados válidos, vigentes. Usted - quizá - quiere un sitio de ensayo con un certificado válido. Pero más allá del front-end de Apache, el programa de fondo no debe saber que está ahí SSL involucrado. No está probando algo único o especial mediante la compra de certificados dev.

Además, el costo es nominal. Usted está gastando más dinero en la conversación de los certificados realidad costo.

  

Para la mayoría de las páginas, el contenido no es segura y forzar SSL haría que las solicitudes de páginas tardan más tiempo en el servidor debido a cifrar y descifrar

Un poco. ¿Ha medido? Usted puede encontrar que es difícil de medir debido a la variabilidad de Internet acelera dejar sin efecto el costo de procesamiento SSL.

  

Por lo que entiendo, la mayoría de los navegadores de páginas de caché No SSL'ed que son y por lo tanto una vez más, las solicitudes de páginas tardarán más

Una vez más, tiene que se ha medido esto?

  

Los navegadores más antiguos tienen problemas con la descarga de archivos cuando son SSL'ed

En serio? ¿Qué específica "navegador más antiguo" está previsto apoyar que tiene este problema? Si no puede encontrar uno y está pensando que alguien, en algún lugar podría tener este problema, puede ser manipulación excesiva. Revisar sus registros y ver lo que los navegadores de sus clientes realmente uso, y luego determinar si usted tiene un problema.

Estoy de acuerdo que "SSL en todas partes" no es un método muy bueno. Creo que se necesita al menos un puerto-80 página no SSL "bienvenida". Pero no estoy seguro de que su actual conjunto de cuestiones son razones sólidas. Creo que se necesita considerablemente más medidas para hacer el caso de que SSL en realidad implica éxitos de costes reales o el rendimiento real.

Answer 3

A partir de 2012, sitios debe utilizar únicamente SSL si tienen de identificación personal (PII) o información de importancia comercial, o si tienen ningún concepto de un inicio de sesión.

Los sitios que publicar sólo bajo valor, de baja confianza de información de sólo lectura pública son una discutible poco, pero probablemente todavía podría servir útilmente todo a través de HTTPS. Los atacantes pueden intentar insertar malware o adware, o redirecciones, en HTTP contenido.

Una política corporativa de "todo a través de SSL, sin una exención específica" es razonable.

También debe mirar despliegue Seguridad HTTP Transporte estricto para realizar la primera solicitud seguro de que incluso el usuario de de tipificación example.com se envía a través de HTTPS.

Man-in-the-middle son un problema del mundo real, especialmente en redes WiFi, pero también a nivel de ISP y el país. Si lo hace sólo la fase de inicio de sesión a través de SSL y luego pasa una cookie de sesión sin cifrar, será robado que la cookie de sesión. Ver Firesheep para una demostración clara.

SSL es segura almacenar en caché por usuario, ya sea para la sesión o indefinidamente. De punto de cliente proxy caché son raras y la optimización para ese caso no es importante. Cuando los hay, que comúnmente se equivocan y pasar por ellos a través de SSL es que vale la pena.

SSL implementado correctamente o SPDY puede ser rápido: la sobrecarga del servidor no es muy alta y se mueve fácilmente en una máquina proxy inverso separado. Hay CDN SSL.

No hay necesidad de comprar certificados reales para los sitios que son sólo para los desarrolladores y probadores. El coste de los certificados, en unas pocas decenas de dólares, es insignificante incluso para los sitios no comerciales.

Cifrado de datos en toda la red es una capa útil de defensa en profundidad. Obviamente no es suficiente por sí misma para hacer que el servicio seguro, pero elimina algunos tipos de problemas y tiene un bajo costo.

A pesar de los datos de sólo lectura, hay un valor en los clientes sabiendo que van a obtener el sitio auténtico:. Por ejemplo, si se están descargando archivos binarios que no quiere troyanos que se insertan

páginas con seguridad que distinguen que necesitan ser a través de SSL de los que no conlleva esfuerzo desarrollador que es casi seguro que se podría utilizar mejor.

Hacer una camisa de fuerza para los estándares de diversos sistemas, sobre todo, sin consulta, nunca es bueno. Pero decir que los sitios deben ser todos de SSL a menos que haya una razón particular para hacer lo contrario en un caso tiene sentido para mí. Buenos ejemplos de excepciones caso por caso, en las que aún debe ofrecer SSL pero no forzar un redireccionamiento:

• El sitio está sirviendo grandes descargas binarios (distribuciones de música / vídeo / software) de manera que permite más almacenamiento en caché y descargas más rápidas es importante (data show)
• los clientes son arcaicas IE o clientes incrustados que simplemente no puede hacer adecuadamente SSL (una vez más, demuestran que en realidad es un problema)
• Hay muchos recursos en el sitio y usted quiere robots para indexarlo, a través de HTTPS

Si utiliza SSL en todas partes que va a utilizar un poco más de recursos de la máquina, de manera que pueden ser optimizados si llegan a ser importante. Si no se usa SSL, o bien gastar más recursos de desarrollo a considerar la seguridad caso por caso, o bastante probable que va a ser más propensos a robo de cuenta.

Adam Langley de Google escribió en 2010 :

  

Si hay un punto que queremos comunicar al mundo, es así de SSL / TLS no es costoso computacionalmente más. Diez años hace que podrían haber sido cierto, pero no es sólo el caso más. Usted también puede darse el lujo de activar HTTPS para sus usuarios.

     

En enero de este año (2010), Gmail cambió a través de HTTPS para todo, por defecto. Anteriormente había sidopresentado como una opción, pero ahora todos nuestros usuarios utilizan HTTPS para proteger su correo electrónico entre sus navegadores y Google, todo el tiempo. Con el fin de hacer esto, tuvimos que implementar ningún máquinas adicionales y sin necesidad de hardware especial. En nuestras máquinas frontend producción, SSL / TLS representa menos del 1% de la carga de la CPU, a menos de 10 KB de memoria por conexión y menos de 2% de sobrecarga de la red. Muchas personas creen que SSL necesita una gran cantidad de tiempo de CPU y esperamos que los números anteriores (pública por primera vez) ayudará a disipar esa.

Answer 4

Así que he visto algunas fantásticas respuestas a esta pregunta, pero después de unos días vi que hay algunas cosas que faltan . Por lo tanto, hay un par de cosas que quiero mencionar:

¿Por qué utilizar SSL en todo

• Seguridad - Si sólo unas pocas páginas son SSL encriptada, es más fácil de "oler" qué páginas contienen datos sensibles. Ahora SSL es bastante seguro maldito, así que esto no es algo de qué preocuparse, pero en el caso de que su clave privada es comprometida, es una buena práctica tener esa capa adicional de seguridad para que sea más difícil para los chicos malos para llegar a la cosas jugosas.
• Confianza - Hay personas que sostienen que cuando se visita un sitio que tiene un certificado verificado, es más fácil de confianza. Desde un certificado verificado cuesta dinero, es más fácil confiar en un sitio sabiendo que el propietario invirtió en un símbolo de confianza.
• Sin problemas - Inertización todo bajo SSL es mucho más fácil. Todo lo que tiene que hacer es cortar la http: al comienzo de cada enlace de recursos y ya está bueno.
• Configuración SEO - Usted no tendrá que preocuparse en absoluto con la configuración de SEO. He oído que los motores de búsqueda http:// índice y https:// como entradas separadas, por lo que para mantener la coherencia (tanto en la página de SEO y de comportamiento), cubriendo SSL a través de todo y sólo la creación de una redirección 301 parece una solución fácil agradable.
• La consistencia - Vas a tener un sitio web mucho más consistente si sólo https:// todo. Un montón de marcos se rompen cuando se intenta hacer un híbrido de SSL y no SSL. Además de esto, plugins y código de URL dependientes serán realmente quieren decir si intenta rebotar hacia atrás y adelante entre http y https.
• Esa sensación de seguridad Fuzzy -. Hay que admitir, que la pequeña barra verde en la parte superior izquierda que dice "Dominio verificado" es simplemente una muy buena sensación

¿Por qué no SSL Todo

• Velocidad - SSL es más lento. No por mucho, por supuesto, y la mayoría de las veces el costo es insignificante. Es un hecho inevitable, sin embargo, que SSL siempre será más lenta.
• compatibilidad del navegador - Este es probablemente insignificante, pero si quiere el apoyo realmente los navegadores antiguos que no lo hacen caché a través de SSL, que tendrá que seguir con el puerto 80.
• plugins - Un montón de plugins no funcionan correctamente a través de SSL, por lo que tendrá que tener cuidado de que. Si alguna vez quiere añadir un nuevo plugin, tendrá que volver a configurar los valores de SSL o buscar otro plugin.
• Profesionalismo - Ahora bien, aunque algunas personas argumentan que viendo un dominio SSL verificado parece digno de confianza, otros lo ven como una solución muy aficionado y perezoso. De hecho, es muy fácil y barato (me costó alrededor de $ 10) para obtener un certificado SSL verificado que éxitos hasta el 96% de los navegadores!
• Sin problemas - Así que lo hice decir que es más fácil de todo el SSL, pero, al mismo tiempo que vamos a tener que asegurarse de que todos los recursos se carga a través https:// (o hacer la solución rápida http:// -> // ). Puede ser un poco tedioso si usted tiene un montón de enlaces o incluso incompatibles si tiene contenido enviado por el usuario alojado en un sitio que no es compatible con SSL. En esos casos, el navegador va a quejarse de ti. Si alguna vez has visto que el aviso que dice "esta página tiene contenido no seguro", usted sabrá lo molesto que es y lo mal que se ve.

Así que en resumen, es realmente la situación pero tienden a evitar cubriendo SSL. Claro, lo hace tomar un poco más de configuración, pero al final se obtiene un sistema mucho más flexible. Yo personalmente creo que todo el asunto "profesionalismo" es una mierda (Twitter y Google SSL todo). Sin embargo, si usted tiene exinternamente alojado el contenido o el contenido publicado por los usuarios, por lo general es una muy mala idea para SSL todo. Usted también puede empezar todo de SSL-ción y correr en un montón de problemas.

Pero eso es sólo yo. : D

Answer 5

Este primero que hay que preguntarse, ¿qué SSL comprar ti? Se le compra la seguridad de que nadie ni ninguna aplicación puede "oler" el tráfico y ver lo que está pasando entre el servidor web y el navegador. El costo es el costo real de la compra de un certificado SSL, y el coste de ir en un ligero aumento en la velocidad de descarga. Usted menciona que el navegador más tienen problemas para la descarga de archivos más de la comunicación SSL. No puedo hablar de eso, y no me gustaría ocuparme demasiado con eso. Desde un punto de vista de la seguridad, usted tiene otra preocupación. servidores de seguridad modernos monitorear el tráfico en busca de varios intentos de hackeo. SSL impide que el servidor de seguridad del monitor que la comunicación, por lo que las necesidades de desarrolladores de aplicaciones / web-admin a ser aún más que ver con la protección de su aplicación y los sitios de varios intentos de piratería. Larga historia corta, hay que cifrar las comunicaciones única que realmente lo necesita.

Answer 6

En otra respuesta a Thomas respuesta, sobre todo porque es en la parte superior.

Además, más abajo que vincula un papel blanco con las mejores prácticas para SSL .

  

SSL impide el almacenamiento en caché, no sólo de los navegadores, sino también de los servidores proxy. Cada página Web   elemento tendrá que ser enviado por el servidor principal, una y otra vez. Esta red se incrementa   carga.

sólo parcialmente cierto. SSL evitará el almacenamiento en caché de proxy, pero no almacenamiento en caché del navegador - ver también las respuestas a esta pregunta . No es un gran problema en mi opinión.

  

SSL evita el uso de los llamados "dominios virtuales". [...]

Esto es parcialmente cierto. Sin embargo, los dominios virtuales no tendrán ningún problema, siempre y cuando sólo tiene un certificado. Incluso si no, Nombre del servidor Indicación (SNI) debe ser una alternativa viable (o debería ser, una vez que Windows XP está fuera de la faz de la tierra).

  

[rendimiento] Sin embargo, el inicio de una conexión SSL, conocido como "apretón de manos", es un poco más caro,> y puede implicar un cuello de botella en cargas pesadas (cuando hay cientos de conexiones por segundo, o más) . Afortunadamente, una instancia de navegador determinado reutilizará túneles   y las sesiones SSL, por lo tanto, esto no es un problema si sólo tiene unas pocas docenas de usuarios.

Incluso el apretón de manos no debe causar ningún problema de rendimiento en el lado del servidor si tiene el hardware moderno. La razón principal del apretón de manos siendo "lento" es debido al hecho de que los paquetes de red necesitan ser enviado atrás y hacia adelante varias veces entre el servidor y el navegador - potencia de cálculo no tiene mucho que ver con ello.

Para decirlo de otra manera:. Configuración de la conexión SSL será un orden de magnitud más barato que la prestación de una página PHP que obtiene datos de una base de datos

  

En general, poniendo SSL en todas partes parece una manera de conseguir una "sensación borrosa caliente" en materia de seguridad. > Esto no es bueno. Esto generalmente significa que al concentrarse en lo irrelevante,

NO cierto en absoluto . Ya sea que no es necesario en absoluto SSL en su sitio, porque es completamente contenido público. O lo haces necesidad SSL por alguna razón (logins de usuario, áreas protegidas). En ese caso, lo mejor es ponerlo en todas partes.

Tener SSL sólo en partes de su página se puede abrir hasta todo tipo de riesgos oscuros. Y si bien se pueden encontrar y mitigar los de otras maneras, es que será más complejo y propenso a errores y consume mucho tiempo que sólo tener habilitado SSL en todas las páginas.

He encontrado el este libro blanco sobre SSL . No estoy afiliado con la empresa que el autor de ella, pero me pareció un resumen muy concisa de todas las cosas que usted necesita para tener en cuenta al implementar una configuración de SSL.

Esa seguridad tiene más de un componente es evidente. Pero ya se ha tocado el primer error no es un buen comienzo.

Answer 7

No creo que usted debe SSL de los sitios y que sin duda no es necesario para comprar los CERT para sus entornos dev. Si usted quiere / necesita un certificado SSL para dev que se puede generar con facilidad y que en la mayoría de los casos sería lo suficientemente para ese entorno. La otra posibilidad es que se puede comprar un certificado comodín y fijarle Dev servidores en uno de los subdominios, de esta manera se puede tener el mismo certificado para entornos pero de nuevo: es una pérdida de dinero si compra certificado comodín (que son más caro) sólo para tener dev trabajar en él también. Tiene sentido si tiene varios subdominios en prod que necesita ser SSLed.

En cuanto a la velocidad: sí, es un poco de un problema, pero no es tan significativa. respuestas SSL no se almacenan en caché por lo que su uso aumentará sus servidores de carga un poco, pero creo que esta es la parte que administrador debe tener en cuenta.