encryption - tiene - ¿Deberían todos los sitios usar SSL por defecto?

nginx letsencrypt docker (7)

Estamos en el proceso de mover nuestra arquitectura web a un nuevo entorno. Se incluyen docenas de sitios diferentes que van desde sitios casi completamente estáticos a dinámicos que requieren autenticación y que contienen contenido confidencial. Nuestros administradores de servidores web (sin ningún aporte del equipo de desarrollo) decidieron convertirlo en un estándar en el nuevo entorno para forzar SSL para todo. No estoy de acuerdo con esta decisión y me gustaría tener el mayor conocimiento posible cuando me siento a discutirlo. Esto es lo que tengo hasta ahora:

Para cada sitio, un certificado SSL tiene un costo directo. Tenemos un entorno dev, qa y prod y, por lo tanto, son tres los certificados necesarios para cada sitio.
Para la mayoría de las páginas, el contenido no es seguro y obligar a SSL haría que las solicitudes de página requieran más tiempo en el servidor debido al cifrado y descifrado.
Por lo que entiendo, la mayoría de los navegadores no almacenan en caché las páginas que tienen SSL y, por lo tanto, las solicitudes de página tardarán más.
Los navegadores antiguos tienen problemas con la descarga de archivos cuando tienen SSL.

No tengo problemas para forzar SSL cuando los usuarios se autentican o solicitan datos confidenciales. Sin embargo, creo que forzar SSL por defecto en todos los sitios es un poco demasiado.

A partir de 2012, los sitios deben usar solo SSL si tienen información de identificación personal (PII) o información comercialmente importante, o si tienen algún concepto de inicio de sesión.

Los sitios que publican solo información pública de bajo valor y poca confianza son un poco discutibles, pero probablemente aún sirvan para todo a través de HTTPS. Los atacantes pueden intentar insertar malware o adware, o redirecciones, en el contenido HTTP.

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

También debe considerar implementar HTTP Strict Transport Security para asegurarse de que incluso la primera solicitud del usuario al escribir example.com se envíe a través de HTTPS.

Los ataques Man-in-the-middle son un problema del mundo real, especialmente en redes wifi, pero también a nivel de ISP y de país. Si solo hace la fase de inicio de sesión a través de SSL y luego pasa una cookie de sesión sin encriptar, esa cookie de sesión será robada. Vea Firesheep para una demostración clara.

SSL es almacenable de forma segura por usuario, ya sea para la sesión o indefinidamente. Las cachés de proxy del extremo del cliente son ahora raras y la optimización para ese caso no es importante. Cuando existen, comúnmente hacen las cosas mal y pasarlos por SSL es útil.

La implementación correcta de SSL o SPDY puede ser rápida: la sobrecarga del servidor no es alta y se puede mover fácilmente a una máquina de proxy inverso independiente. Hay SSL CDN.

No es necesario comprar certificados reales para sitios que son solo para desarrolladores y probadores. El costo de los certificados, en pocas decenas de dólares, es insignificante incluso para sitios no comerciales.

Cifrar datos en la red es una capa útil de defensa en profundidad. Obviamente, no es suficiente por sí mismo para garantizar la seguridad del servicio, pero elimina algunos tipos de problemas y tiene un costo bajo.

Incluso para los datos de solo lectura, los clientes tienen un gran valor al saber que están obteniendo el sitio auténtico: por ejemplo, si están descargando archivos binarios, no quieren que se inserten troyanos.

Distinguir de forma segura las páginas que necesitan ser sobre SSL de las que no lo hacen requiere un esfuerzo del desarrollador que casi con certeza podría ser mejor utilizado.

Hacer que los estándares sean una camisa de fuerza para diversos sistemas, especialmente sin consulta, nunca es bueno. Pero decir que todos los sitios deben estar en SSL a menos que haya una razón particular para hacerlo, en otro caso, tiene sentido para mí. Buenos ejemplos de excepciones caso por caso, donde aún debe ofrecer SSL pero no forzar una redirección:

el sitio está sirviendo grandes descargas binarias (distribuciones de música / video / software) por lo que es importante permitir más almacenamiento en caché y descargas más rápidas (mostrar datos)
los clientes son IE arcaicos o clientes integrados que simplemente no pueden hacer SSL de manera adecuada (nuevamente, muestran que en realidad es un problema)
hay muchos recursos en el sitio y desea que los robots lo indexen a través de HTTPS

Si utiliza SSL en todas partes, usará algunos recursos más de la máquina, de manera que se puedan optimizar si se vuelven importantes. Si no usa SSL, gastará más recursos de desarrollador para considerar la seguridad caso por caso, o muy probablemente sea más propenso a robar la cuenta.

Adam Langley de Google escribió en 2010 :

Si hay un punto que queremos comunicarle al mundo, es que SSL / TLS ya no es costoso desde el punto de vista de la computación. Hace diez años, podría haber sido cierto, pero ya no es el caso. Usted también puede permitirse habilitar HTTPS para sus usuarios.
En enero de este año (2010), Gmail cambió a usar HTTPS para todo de manera predeterminada. Anteriormente se había introducido como una opción, pero ahora todos nuestros usuarios usan HTTPS para asegurar su correo electrónico entre sus navegadores y Google, todo el tiempo. Para hacer esto, no tuvimos que implementar máquinas adicionales ni hardware especial. En nuestras máquinas frontend de producción, SSL / TLS representa menos del 1% de la carga de la CPU, menos de 10 KB de memoria por conexión y menos del 2% de la sobrecarga de la red. Muchas personas creen que SSL requiere mucho tiempo de CPU y esperamos que los números anteriores (públicos por primera vez) ayuden a disipar eso.

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

Por qué usar SSL en todo

Seguridad : si solo unas pocas páginas están cifradas con SSL, es más fácil "detectar" qué páginas contienen datos confidenciales. Ahora SSL es bastante seguro, así que esto no es algo de lo que preocuparse, pero en el caso de que su clave privada se vea comprometida, es una buena práctica tener esa capa adicional de seguridad para que sea más difícil para los malos obtener el cosas jugosas
Confiabilidad : hay personas que argumentan que cuando visita un sitio que tiene un certificado verificado, es más fácil confiar. Como 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.
Problemas : blanquear todo bajo SSL es mucho más fácil. Todo lo que tienes que hacer es cortar el http: al comienzo de cada enlace de recursos y estás bien.
Configuración de SEO : no tendrá que preocuparse en absoluto con la configuración de SEO. He oído que los motores de búsqueda indexan http:// y https:// como entradas separadas, por lo que para coherencia (tanto en SEO como en comportamiento de página), cubrir SSL por completo y simplemente configurar una redirección 301 parece una buena solución fácil .
Consistencia : tendrá un sitio web mucho más consistente si solo https:// todo. Muchos marcos se rompen cuando intentas hacer un híbrido de SSL y no SSL. Además de esto, los plugins y el código dependientes de la URL serán realmente malos si intentas avanzar y retroceder entre http y https .
Ese Fuzzy Secure Feeling : tienes que admitir que esa pequeña barra verde en la parte superior izquierda que dice "dominio verificado" es una muy buena sensación.

Por qué no SSL todo

Velocidad : SSL es más lento. No mucho, por supuesto, y la mayoría de las veces el costo es insignificante. Sin embargo, es un hecho inevitable que SSL siempre será más lento.
Compatibilidad con el navegador : esto es probablemente insignificante, pero si quieres admitir navegadores realmente antiguos que no tienen memoria caché a través de SSL, tendrás que quedarte con el puerto 80.
Complementos : un montón de complementos no funcionan correctamente a través de SSL, por lo que deberá tener cuidado con eso. Si alguna vez desea agregar un nuevo complemento, deberá reconfigurar su configuración de SSL o buscar otro complemento.
Profesionalismo : ahora, aunque algunas personas argumentan que ver un dominio SSL verificado parece confiable, otros lo ven como una solución muy amateur y perezosa. De hecho, es muy fácil y económico (me costó unos 10 dólares) obtener un certificado SSL verificado que alcanza hasta el 96% de los navegadores.
Problemas - Entonces dije que es más fácil SSL todo, pero al mismo tiempo tendrá que asegurarse de que cada recurso se cargue a través de https:// (o haga la solución http:// -> // rápida ) Puede ser un poco tedioso si tiene muchos enlaces o incluso es incompatible si tiene contenido enviado por el usuario alojado en un sitio que no admite SSL. En esos casos, su navegador se queja con usted. Si alguna vez has visto ese aviso que dice "esta página tiene contenido inseguro", sabrás lo molesto que es y lo mal que se ve.

En resumen, es realmente situacional, pero tiendo a evitar cubrir SSL. Claro, requiere un poco más de configuración, pero al final obtienes un sistema mucho más flexible. Personalmente creo que todo el "profesionalismo" es una mierda (Twitter y Google SSL todo). Sin embargo, si tiene contenido alojado externamente o contenido publicado por el usuario, generalmente es una mala idea para SSL todo. También puede comenzar a SSL todo y encontrarse con un montón de problemas.

Pero solo soy yo. :RE

En otra respuesta a la respuesta de Thomas, especialmente porque está en la parte superior.

Además, más adelante, vinculé un libro blanco con las mejores prácticas para SSL .

SSL evita el almacenamiento en caché, no solo desde los navegadores sino también desde los servidores proxy. Cada elemento de la página web tendrá que ser enviado por su servidor principal, una y otra vez. Esto aumenta la carga de la red.

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

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

Esto es parcialmente cierto. Sin embargo, los dominios virtuales funcionarán bien siempre que solo tenga un certificado. Incluso si no lo hace, Server Name Indication (SNI) debería ser una alternativa viable (o debería serlo, una vez que Windows XP esté fuera de la faz del planeta).

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

Incluso el apretón de manos no debería causar ningún problema de rendimiento en el lado del servidor si tiene hardware moderno. La razón principal por la cual el saludo de manos es "lento" se debe al hecho de que los paquetes de red deben enviarse varias veces entre el servidor y el navegador; la potencia de cálculo tiene poco que ver con eso.

Para decirlo de otra manera: la configuración de la conexión SSL será de un orden de magnitud más económica que la representación de una página PHP que obtiene datos de una base de datos.

En general, poner SSL en todas partes parece una forma de obtener una "sensación cálida y difusa" sobre la seguridad. > Esto no es bueno. Esto generalmente significa que al concentrarse en lo irrelevante,

NO ES VERDAD EN ABSOLUTO . O bien, no necesita SSL en su sitio, porque es un contenido completamente público. O necesita SSL por alguna razón (inicios de sesión de usuario, áreas protegidas). En ese caso, la mejor práctica es ponerlo en todas partes.

Tener SSL solo en partes de su página puede abrirlo a todo tipo de riesgos oscuros. Y si bien puede encontrarlos y mitigarlos de otras maneras, será más complejo, propenso a errores y más lento que simplemente tener habilitado SSL en todas las páginas.

Encontré este libro blanco sobre SSL. No estoy afiliado a la compañía que lo creó, pero me pareció un resumen muy conciso de todas las cosas que debe tener en cuenta al implementar una configuración de SSL.

Esa seguridad tiene más de un componente sin decir. Pero ya obtener el primer error no es un buen comienzo.

En respuesta a la respuesta de Thomas :

Para cada sitio, un certificado SSL tiene un costo directo. Tenemos un entorno dev, qa y prod y, por lo tanto, son tres los certificados necesarios para cada sitio.

Casi cierto. No necesita tener todos los desarrolladores y qa detrás de SSL con certificados válidos y actuales. Usted - tal vez - quiere un sitio de ensayo con un certificado válido. Pero más allá del front end de Apache, su back-end no debería saber que hay SSL involucrado. No está probando nada único o especial comprando certificados dev.

Además, el costo es nominal. Estás gastando más dinero en la conversación de lo que realmente cuestan los certificados.

Para la mayoría de las páginas, el contenido no es seguro y obligar a SSL haría que las solicitudes de página requieran más tiempo en el servidor debido al cifrado y descifrado.

Un poco. ¿Has medido? Es posible que sea difícil de medir porque la variabilidad de las velocidades de Internet supera el costo del procesamiento de SSL.

Por lo que entiendo, la mayoría de los navegadores no almacenan en caché las páginas que tienen SSL y, por lo tanto, las solicitudes de página tardarán más.

De nuevo, ¿has medido esto?

Los navegadores antiguos tienen problemas con la descarga de archivos cuando tienen SSL.

De Verdad? ¿Qué "navegador más antiguo" específico que planea soportar tiene este problema? Si no puede encontrar uno y está pensando que alguien, en alguna parte, podría tener este problema, es posible que esté sobreinnovando. Verifique sus registros y vea qué navegadores utilizan realmente sus clientes, y luego determine si tiene algún problema.

Estoy de acuerdo en que "SSL en todas partes" no es un enfoque muy bueno. Creo que necesita al menos una página de "bienvenida" del puerto 80 que no sea SSL. Pero no estoy seguro de que su conjunto actual de problemas sea una razón sólida. Creo que necesita considerablemente más mediciones para demostrar que SSL realmente implica éxitos de rendimiento real o de costo real.

Lo primero que debe preguntarse, ¿qué le compra SSL? Le compra la seguridad de que nadie y ninguna aplicación pueden "olfatear" el tráfico y ver qué ocurre entre el servidor web y el navegador. El costo es el costo real de comprar un certificado SSL y el costo continuo de un ligero aumento en la velocidad de descarga. Menciona que el navegador anterior tiene problemas para descargar archivos a través de la comunicación SSL. No puedo hablar de eso, y no me preocuparía demasiado por eso. Desde el punto de vista de seguridad, tiene otra preocupación. Los firewalls modernos monitorean el tráfico buscando varios intentos de pirateo. SSL evita que el firewall controle esa comunicación, por lo que el desarrollador de la aplicación / administrador web debe preocuparse aún más por proteger sus aplicaciones y sitios de varios intentos de piratería. Para resumir, uno solo debe cifrar las comunicaciones que realmente lo necesitan.

No creo que deba SSL todos sus sitios y definitivamente no necesita comprar certs para sus entornos de desarrollo. Si desea / necesita un certificado SSL para dev, puede generarse fácilmente y eso en la mayoría de los casos sería suficiente para ese entorno. La otra posibilidad es que pueda comprar un certificado de comodín y configurar servidores de desarrollo en uno de los subdominios, de esta manera puede tener el mismo certificado para ambos entornos, pero de nuevo: es una pérdida de dinero si compra un certificado de comodín (que son más costoso) solo para que el desarrollador también lo haga. Tiene sentido si tiene múltiples subdominios en prod que necesitan SSL.

En cuanto a la velocidad: sí, es un problema pero no tan significativo. Las respuestas SSL no están almacenadas en la memoria caché, por lo que su uso aumentará la carga de los servidores, pero creo que esta es la parte que el administrador debe tener en cuenta.

SSL puede inhibir el almacenamiento en caché a nivel de red. Hay soluciones para esto, pero puede significar que varias computadoras en la misma red tengan que volver a descargar los recursos de la página. Esto puede aumentar la carga de la red en ambos extremos. El almacenamiento en caché a nivel de navegador no es un problema en los navegadores modernos.

SSL complica el uso de los denominados "dominios virtuales". Tradicionalmente, para formar una conexión SSL, el navegador y el servidor deben funcionar con el mismo nombre de dominio. Esto imposibilitó alojar más de un certificado SSL en una sola IP porque el servidor respondería con el certificado incorrecto. Las implementaciones de Server Name Indication (una extensión del protocolo TLS que usa SSL) han solucionado muchos de los problemas con esto.

En rendimiento puro, el cifrado simétrico y la verificación de integridad en los datos de túnel no es muy caro; si su servidor no puede cifrar y descifrar a la velocidad de la red, entonces o tiene la fibra óptica de Dios, o debe pensar en reemplazar esos i486. Sin embargo, el inicio de una conexión SSL, conocido como "handshake", es un poco más caro y puede implicar un cuello de botella de rendimiento en cargas pesadas (cuando hay cientos de conexiones por segundo o más). Afortunadamente, una instancia determinada del navegador reutilizará túneles y sesiones SSL, por lo tanto, esto no es un problema si solo tiene unas pocas docenas de usuarios.

En general, poner SSL en todas partes parece una forma de obtener una "sensación cálida y difusa" sobre la seguridad. Esto no está bien. Esto generalmente significa que al concentrarse en lo irrelevante, es más probable que los administradores ignoren los problemas de seguridad reales. También harán que el sistema sea más complejo de mantener, por lo que es más difícil de diagnosticar y corregir problemas. Tenga en cuenta que desde el punto de vista de los administradores, esto hace que su trabajo sea más seguro, ya que aumenta el costo de dispararlos y reemplazarlos.