Prácticamente a diario, se deben tomar decisiones de seguridad relacionadas con la arquitectura de los proyectos, o por lo menos así nos pasa si trabajas en la gerencia de seguridad y ciberseguridad de la compañía, en la que el equipo de seguridad acompaña a los arquitectos y jefes de proyectos en estas decisiones. Por ello, veremos a lo largo del post, un modelo sencillo a seguir cuando se implementa la protección de la capa de transporte para una aplicación. Aunque el concepto de SSL es conocido por muchos, los detalles reales y las decisiones específicas de seguridad de la implementación, a menudo son mal entendidos y con frecuencia resultan en despliegues inseguros. Es por esto que trataremos de establecer reglas claras que proporcionen orientación sobre cómo diseñar y configurar de forma segura la seguridad de la capa de transporte para una aplicación. Centrándonos en el uso de SSL / TLS entre una aplicación web y un navegador web, fomentando también el uso de SSL / TLS u otras tecnologías de cifrado de red, como VPN, back-end y otras conexiones no basadas en navegador.
Pero antes de nada, os mostrare los resultados de intentar predicar con el ejemplo en nuestro blog
Esto, nos cuesta visitas, ya que son muchas las personas que no tiene un navegador o sistema operativo que acepte un certificado de 4096, pero como os indico más abajo, con un cifrado de 2048, sería suficiente. Os recomiendo también otro post anterior Intercepción SSL , sacrificando la ética por la seguridad
Decisión de arquitectura
Debe tomar una decisión de arquitectura para determine el método apropiado para proteger los datos cuando se está transmitiendo. Las opciones más comunes disponibles para las empresas son las redes privadas virtuales (VPN) o un modelo SSL / TLS comúnmente utilizado por las aplicaciones web. El modelo seleccionado está determinado por las necesidades empresariales de la organización en particular. Por ejemplo, una conexión VPN puede ser el mejor diseño para una asociación entre dos empresas que incluye el acceso mutuo a un servidor compartido a través de una variedad de protocolos. A la inversa, una aplicación web para empresas que se enfrenta a Internet probablemente sería mejor atendida por un modelo SSL / TLS.
TLS es principalmente una defensa contra ataques man in the middle . Un modelo de amenaza de TLS es aquel que comienza con la pregunta "¿Cuál es el impacto de la capacidad de un atacante de observar, interceptar y manipular el tráfico entre el cliente y el servidor?" .
A lo largo del post nos centraremos en las consideraciones de seguridad cuando se selecciona el modelo SSL / TLS. Modelo que como hemos dicho, es de uso frecuente para aplicaciones web de acceso público.
Proporcionar protección de capa de transporte con SSL / TLS
El principal beneficio de la seguridad de la capa de transporte es la protección de los datos de la aplicación web de la divulgación y modificación no autorizada cuando se transmite entre clientes (navegadores web) y el servidor de aplicaciones web y entre el servidor de aplicaciones web y otros servidores o componentes empresariales.
El componente de validación de servidor de TLS proporciona autenticación del servidor al cliente. Si está configurado para requerir certificados del lado del cliente, TLS también puede desempeñar un papel en la autenticación del cliente en el servidor. Sin embargo, en la práctica, los certificados del lado del cliente no se utilizan a menudo en lugar de nombre de usuario y contraseña basada en modelos de autenticación para estos.
TLS también proporciona dos beneficios adicionales que comúnmente se pasan por alto: Garantías de integridad y prevención de repetición. Un flujo de comunicación TLS contiene controles integrados para evitar la manipulación de cualquier parte de los datos cifrados. Además, los controles también están incorporados para evitar que una secuencia capturada de datos TLS se vuelva a reproducir en un momento posterior.
Cabe señalar que TLS proporciona las garantías anteriores a los datos durante la transmisión. Pero TLS no ofrece ninguna de estas ventajas de seguridad a los datos que están en reposo. Por lo tanto, se deben agregar controles de seguridad adecuados para proteger los datos mientras están en reposo dentro de la aplicación o dentro de los almacenes de datos.
- Debemos utilizar TLS, ya que SSL no se considera aconsejable para la seguridad.
- Todas las páginas deben ser servidas a través de HTTPS. Esto incluye css, scripts, imágenes, solicitudes AJAX, datos POST y terceros. De no hacerlo crea un vector para los ataques man in the middle.
- Sólo proteger las páginas autenticadas con HTTPS, no es suficiente. Una vez que hay una solicitud en HTTP, los ataques man in the middle son posibles, pudiendo evitarlo haciendo que los usuarios lleguen a las páginas protegidas.
- El HTTP Strict Transport Security Header debe ser utilizado y cargado previamente en los navegadores . Esto indicará a los navegadores compatibles que sólo utilicen HTTPS, incluso si se solicita el uso de HTTP.
- Las cookies deben estar marcadas como seguras
Requerimientos básicos
Los requisitos básicos para el uso de TLS son: acceso a una infraestructura de clave pública (PKI) con el fin de obtener certificados, acceso a un directorio o un respondedor del protocolo de estado de certificados en línea (OCSP) para verificar el estado de revocación de certificados y admitir una configuración mínima de las versiones de protocolos y opciones de protocolo para cada versión.
SSL vs. TLS
Los términos Secure Socket Layer (SSL) y TLS (Transport Layer Security) se utilizan a menudo de forma intercambiable. De hecho, SSL v3.1 es equivalente a TLS v1.0. Sin embargo, las diferentes versiones de SSL y TLS son compatibles con los navegadores web modernos y con los frameworks y plataformas web más modernos. Para el fin de este post, nos referiremos a la tecnología genéricamente como TLS. Las recomendaciones sobre el uso de los protocolos SSL y TLS, así como el soporte del navegador para TLS os la mostrare mas adelante con uno de los principios básicos.
Diseño de un servidor seguro
Veremos a los largo de este punto, una serie de reglas obtenidas de la guía de buenas practicas de SSL / TLS marcadas por OWASP . Como en todo proyecto tecnológico dentro de la empresa, debemos hacer un balance entre coste y seguridad, y sentido común dentro del uso que se haga del mismo, lo cual marcará las practicas que debemos obtener, pero para llegar a ello, marcaremos primeramente el buen uso SSL / TLS con esta serie de reglas.
Utiliza TLS u otro transporte fuerte end to end
Todas las redes, tanto externas como internas, deben utilizar TLS o un mecanismo equivalente de seguridad de la capa de transporte para toda comunicación. No basta con afirmar que el acceso a la red interna está "restringido a los empleados". Numerosos compromisos de datos recientes han demostrado que la red interna puede ser violada por los atacantes. En estos ataques, los sniffers se han instalado para acceder a los datos confidenciales no cifrados enviados en la red interna.
La página de inicio de sesión y todas las páginas autenticadas posteriores deben tener acceso exclusivo a través de TLS. La página inicial de inicio de sesión, denominada "página de inicio de sesión", debe ser servida a través de TLS. La no utilización de TLS para la página de inicio de sesión permite a un atacante modificar la acción del formulario de inicio de sesión, haciendo que las credenciales del usuario se publiquen en una ubicación arbitraria. Si no se utiliza TLS para páginas autenticadas después del inicio de sesión, el atacante puede ver el ID de sesión sin cifrar y comprometer la sesión autenticada del usuario.
Incluso la comercialización u otros sitios web de baja seguridad todavía requieren TLS. La falta de TLS conduce a una falta de integridad que permite a los atacantes modificar el contenido en tránsito.
No proporcionar páginas no TLS en contenido seguro
Todas las páginas que están disponibles a través de TLS no deben estar disponibles en una conexión que no sea TLS. Un usuario puede marcar inadvertidamente o escribir manualmente una URL a una página HTTP (por ejemplo, http:// #example# .com/cuenta ) dentro de la parte autenticada de la aplicación. Si esta solicitud es procesada por la aplicación, la respuesta y cualquier dato sensible se devolverán al usuario a través del HTTP en texto sin cifrar.
No mezclar contenido TLS y no TLS
Una página que está disponible a través de TLS debe estar compuesta completamente de contenido que se transmite a través de TLS. La página no debe contener ningún contenido que se transmita a través de HTTP sin cifrar. Esto incluye contenido de sitios de terceros no relacionados.
Un atacante podría interceptar cualquiera de los datos transmitidos a través del HTTP no cifrado e inyectar contenido malicioso en la página del usuario. Este contenido malintencionado se incluiría en la página incluso si la página general se sirve en TLS. Además, un atacante puede robar la cookie de sesión del usuario que se transmite con cualquier petición que no sea TLS. Esto es posible si el indicador 'seguro' de la cookie no está establecido. Para ello, veremos continuación la regla del uso de flan en la cookie.
Usar Secure Cookie Flag
El indicador "Seguro" debe estar configurado para todas las cookies del usuario. Si no se utiliza el indicador "seguro", el atacante puede acceder a la cookie de sesión engañando al navegador del usuario para que envíe una solicitud a una página sin cifrar del sitio. Este ataque es posible incluso si el servidor no está configurado para ofrecer contenido HTTP ya que el atacante está supervisando las solicitudes y no le importa si el servidor responde con un 404 o no responde en absoluto.
Mantener datos confidenciales fuera de la URL
Los datos confidenciales no deben transmitirse mediante argumentos en la URL. Siendo más correcto almacenar los datos confidenciales en un repositorio del lado del servidor o dentro de la sesión del usuario. Cuando se utiliza TLS, los argumentos y los valores de la URL se cifran durante la transmisión. Sin embargo, hay dos métodos en los que los argumentos de la URL y los valores podrían estar expuestos.
-
Toda la URL se almacena en caché dentro del historial del navegador del usuario local. Esto puede exponer los datos confidenciales a cualquier otro usuario de la estación de trabajo.
-
La URL completa queda expuesta si el usuario hace clic en un enlace a otro sitio HTTPS. Esto puede exponer los datos confidenciales dentro del campo de referencia al sitio de terceros. Esta exposición se produce en la mayoría de los navegadores y sólo se producirá en las transiciones entre dos sitios TLS.
Por ejemplo, un usuario que sigue un enlace en https:// ejemplo.com que conduce a https:// Otroejemplo.com expondría la URL completa de https:// ejemplo.com (incluidos los argumentos de URL) en el encabezado de referencia (dentro de la mayoría de los navegadores). Este no sería el caso si el usuario siguiera un enlace en https:// ejemplo.com a http:// OtroHTTPejemplo.com
Evitar el almacenamiento en caché de datos confidenciales
El protocolo TLS proporciona confidencialidad sólo para los datos en tránsito, pero puede ayudarnos con posibles problemas de pérdida de datos en los proxies de clientes o proxies intermediarios. Como resultado, es prudente instruir a estos nodos para que no almacenen en caché ni persistan datos sensibles. Una opción es agregar los encabezados anticaching a las respuestas HTTP relevantes (por ejemplo, "Cache-Control: no-cache, no-store" y "Expires: 0" para la cobertura de muchos navegadores modernos a partir de 2013). Para la compatibilidad con HTTP / 1.0 (es decir, cuando los agentes de usuario son realmente antiguos o el servidor web funciona alrededor de peculiaridades forzando HTTP / 1.0) la respuesta también debe incluir el encabezado "Pragma: no-cache". Podemos disponer de más información en HTTP 1.1 RFC 2616 , sección 14.9.
Certificado de servidor
Ahora nos toca hablar de la importancia de la configuración de los certificados a nivel servidor, esta parte esta muy en entredicho sobre cuales son las mejores practicas, sopesando siempre coste/seguridad/necesidad para los proyectos, pasaremos a ver las reglas marcadas por OWASP sobre los requisitos del certificado a nivel servidor.
Utilizar claves fuertes y protegerlas
La clave privada utilizada para generar la clave de cifrado debe ser lo suficientemente fuerte para la vida útil de la clave privada y el certificado correspondiente. La mejor práctica actual es seleccionar un tamaño de clave de al menos 2048 bits. Además, la clave privada debe almacenarse en un lugar protegido de acceso no autorizado.
Utilizar un certificado que admita los nombres de dominio necesarios
Un usuario nunca debe obtener un error de certificado, incluyendo desajustes de dominio o host, o certificados caducados. Si la aplicación está disponible en https:// www.ejemplo.com y https:// ejemplo.com, se debe presentar un certificado apropiado, o certificados, para acomodar la situación. La presencia de errores de certificado, desensibiliza a los usuarios a los mensajes de error de TLS y aumenta la posibilidad de que un atacante pueda lanzar un ataque de phishing o un ataque de man in the middle.
Por ejemplo, si consideramos una aplicación web accesible en https:// abc.ejemplo.com y en https:// xyz.ejemplo.com . Se debe adquirir un certificado para el host o servidor abc.ejemplo.com , un segundo certificado para el host o servidor xyz.ejemplo.com y en ambos casos, el nombre de host estaría presente en el nombre común del sujeto (CN).
Como alternativa, los Subject Alternative Name (SANs) pueden utilizarse para proporcionar una lista específica de varios nombres donde el certificado es válido. En el ejemplo anterior, el certificado podría enumerar el CN de Asunto como ejemplo.com y enumerar dos SAN: abc.ejemplo.com y xyz.ejemplo.com . Estos certificados a veces se denominan "certificados de dominio múltiple".
Utilizar nombres completamente calificados en certificados
Se deben usar nombres totalmente calificados en el campo de nombre DNS y no usar nombres no calificados ('www'), nombres locales ('localhost') o direcciones IP privadas (192.168.1.1) en el campo de nombre DNS . Los nombres sin calificar, los nombres locales o las direcciones IP privadas violan la especificación del certificado.
No utilizar certificados comodín
Debemos abstenernos de utilizar certificados comodín. Aunque son convenientes para eludir las molestas instrucciones de los usuarios, también violan el principio del mínimo privilegio y le pide al usuario que confíe en todas las máquinas del sistema, incluidas las máquinas de desarrollo, del vestíbulo , del gimnasio ... Obtener acceso a la clave privada es un ejercicio para el atacante, pero todo ello es mucho más fácil cuando se almacena en sistemas de archivos sin protección.
No utilizar direcciones RFC 1918 en certificados
Los certificados no deben utilizar direcciones privadas RFC 1918 es la asignación de direcciones para intranets . Las direcciones privadas son para la Autoridad de Números Asignados de Internet (IANA) las direcciones reservadas 192.168 / 16, 172.16 / 12 y 10/8.
Los certificados emitidos con direcciones privadas violan las directrices del certificado EV . Además, Peter Gutmann escribe en Ingeniería de Seguridad:
"This one is particularly troublesome because, in combination with the router-compromise attacks... and ...OSCP-defeating measures, it allows an attacker to spoof any EV-certificate site"
Utilizar una autoridad de certificación apropiada para la base de usuarios de la aplicación
Un usuario de la aplicación nunca debe obtener una advertencia de que el certificado fue firmado por una autoridad desconocida o no confiable. Los usuarios de la aplicación deben tener acceso al certificado público de la autoridad de certificación que emitió el certificado del servidor. Para los sitios web accesibles desde Internet, el método más efectivo para lograr este objetivo es comprar el certificado TLS de una autoridad de certificación reconocida. Los navegadores de Internet populares ya contienen los certificados públicos de estas autoridades de certificación reconocidas.
Las aplicaciones internas con un número de usuarios limitados pueden utilizar una autoridad de certificación interna siempre que su certificado público se distribuya de forma segura a todos los usuarios. Sin embargo, recuerde que todos los certificados emitidos por esta autoridad de certificación serán de confianza para los usuarios. Por lo tanto, debemos utilizar controles para proteger la clave privada y asegúrese de que sólo las personas autorizadas tengan la capacidad de firmar dichos certificados.
El uso de certificados auto firmados nunca es aceptable. Los certificados auto-firmados niegan el beneficio de la autenticación desde el punto final y también disminuyen significativamente la capacidad de un individuo para detectar un ataque man in the middle.
Proporcionar todos los certificados necesarios
Los clientes intentan resolver el problema de identificar un servidor o un host usando el certificado PKI y X509. Cuando un usuario recibe un certificado de servidor o host, el certificado debe ser validado de nuevo a una autoridad de certificación raíz de confianza. Esto se conoce como validación de ruta.
Puede haber uno o más certificados intermedios entre el certificado de entidad final (servidor o host) y el certificado raíz. Además de validar ambos extremos, el usuario también tendrá que validar todos los certificados intermedios. La validación de todos los certificados intermedios puede ser complicada porque el usuario puede no tenerlos localmente. Este es un problema conocido de PKI llamado “Which Directory?".
Para evitar el problema “Which Directory?", un servidor debe proporcionar al usuario todos los certificados necesarios utilizados en una validación de ruta.
Plan de depreciación SHA-1
Para evitar que los usuarios finales presenten advertencias progresivas de certificados, las organizaciones deben tratar proactivamente planes de depreciación del uso SHA-1 en los fabricante del navegador. El plan de Google Chrome es probablemente el más específico y agresivo en este momento: Gradually sunsetting SHA-1
Si la organización no tiene problemas de compatibilidad con SHA256 , lo correcto sería mover los certificados del sitio / cadena para firmarlo con SHA256. Pero si existen problemas, nos deberíamos haber asegurado que los certificados SHA-1 expirasen antes del 1/1/2017.
Proporcionar protección de capa de transporte para back-end y otras conexiones
Aunque no es el foco del post, pero mi búsqueda de esta información vino motivado por ello, debemos destacarse que la protección de la capa de transporte es necesaria para las conexiones de back-end y cualquier otra conexión donde se intercambian datos sensibles o donde se establece la identidad del usuario. Si no se implementa una seguridad de capa de transporte efectiva y robusta, se expondrán datos sensibles y se minará la eficacia de cualquier mecanismo de autenticación o control de acceso.
Error de red interna segura
La red interna de una corporación no es inmune a los ataques. Muchos intrusos de perfil de conocimiento alto han perpetrado atacantes que han accedido a la red interna y luego han utilizado sniffers para capturar datos no cifrados mientras atravesaban la red interna.
Protocolo y configuración de cifrado para back-end y otras conexiones
Es importante proporcionar TLS para la comunicación de servidor a servidor además de la comunicación de cliente a servidor. Debemos asegurar la configuración 'cliente' del servidor que se utiliza para backend y otras conexiones de acuerdo con el protocolo de servidor y la configuración de cifrado . Y asegurarnos de desactivar los protocolos de cifrado inseguros. (Por ejemplo, sólo admitir una configuración mínima sólida cuando el servidor actúa como "cliente").
