SSL

SSL: buenas prรกcticas y recientes avances en la seguridad de aplicaciones web.

SSL/TLS: Introducción

• SSL (Secure Sockets Layer) – es el protocolo original desarrollado en 1995 por Netscape.

• Es fácil de implantar, pero lo que no suele ser tan común es hacerlo correctamente.

• En SSL/TLS hay varios elementos que debemos tener en cuenta: • certificado • protocolos • algoritmos de intercambio de clave • algoritmos de autenticación • algoritmos de cifrado • algoritmos para la creación de MAC 4/25

SSL/TLS: Certificados

• Sospechosos habituales: – Que no haya errores en el nombre/dominio – Certificado aún no válido – Certificado caducado – Uso de certificados autofirmados – CA no conocidas – Certificado revocado

5/25

SSL/TLS: Certificados (II)

• Tamaños de clave: – Usar ya claves de 2048 bits de clave pública* • Protección – Renovación a ser posible anual – Protección de las claves en el servidor – Y allí donde vayan a parar como: • Copias de seguridad

6/25

SSL/TLS: Certificados (IV)

• Nombres de DNS: – El certificado ha de contener TODOS los nombres que permitan acceder al servicio – Es posible usar certificados tipo: • *.blogs.net.mx

7/25

SSL/TLS: Certificados (IV)

8/25

SSL/TLS: Entidades Raíz y jerarquía (V)

• El servidor debe entregar su certificado y los intermedios • Han de entregarse en orden: primero la que firma el certificado del servidor y subiendo hasta la entidad raíz • La entidad raíz puede no entregarse, ya que el cliente ha de tenerla en su propio almacén • Los certificados intermedios aunque suelen tener periodos de validez mayores también expiran • Cada navegador reacciona de una manera ante un fallo de jerarquía; mejor probar 9/25

SSL/TLS: Protocolos

• SSLv2 – tiene graves fallos de seguridad no debería usarse nunca • SSLv3 y TLSv1 – TLSv1 es la versión del IETF de SSLv3 • Mayoritáriamente soportado – TLSv1.1 • Algunas mejoras • Bastante soportado – TLSv1.2 • Más mejoras 10/25 • Pero aún poco soportado

SSL/TLS: Renegociación

• El canal SSL puede pararse momentáneamente y permitir que los extremos renegocien la sesión • No hay una buena razón para que el cliente deba reiniciarla; sólo el servidor debería poder hacerlo, pues puede ser una vía de DoS • Esto depende del código del servidor

11/25

SSL/TLS: Ataque BEAST

• El 2004 se descubrió un ataque teórico a SSL v3/TLS v.1 conocido como BEAST • Desde 2011 es un ataque practicable • Desde 2006 TLS v1.1 resuelve este problema, aunque hay todavía muchos clientes que no soportan TLS v1.1 • La solución es priorizar RC4 que no se ve afectado por este ataque cuando los servidores hablen sólo TLS v1.0 or SSL v3

12/25

SSL/TLS: Apache

• Configurando Apache – SSLProtocol all ­SSLv2 – SSLHonorCipherOrder on # apache 2.1+ – SSLCipherSuite !ADH:!DSS:!RC2:RC4­ SHA:RC4­MD5:HIGH:MEDIUM:+AES128:+3DES

13/25

SSL/TLS: Alguna herramienta

• SSLLABS Server Test • https://www.ssllabs.com/ssltest/index.html – Herramienta gráfica y sencilla – Nos ayuda a corregir errores – Sólo para servicios web – No podemos ampliar las entidades raíz • OpenSSL

14/25

SSL/TLS: Otras recomendaciones

• Usa SSL en aquellos sitios que lo necesiten • Y evita que se acceda sin SSL • Cuidado con el contenido mixto, pues el usuario es vulnerable a un ataque MITM • Marca las cookies como: – Secure – Httponly

16/25

SSL/TLS: Resumen

•

Usar claves públicas de un mínimo de 2048 bits

•

No ofrecer cifrados de clave privada de menos de 128 bits

•

No permitir SSLv2; ofrecer TLS1.0 y posteriores

•

No permitir Anonymous Diffie Hellman (ADH)

•

Todos los nombres DNS que llevan al servicio deben estar incluidos en el certificado

•

Protege la clave privada correctamente en todo momento

•

Si el protocolo es SSL 3.0/TLS 1.0 utiliza RC4

•

Renegociación: siempre segura e iniciada por el servidor

•

Sitio web: todas las páginas y elementos por HTTPS

•

cookies: márcalas como seguras y HTTPonly

17/25

Avances en seguridad web

18/25

HSTS- HTTP Strict Transport Security

• HSTS (HTTP Strict Transport Security) – permite forzar el uso de HTTPS – se trata de una cabecera HTTP – Chrome viene con lista precargada • El propio navegador se encargaría de utilizar siempre HTTPS, a partir de la primera visita durante el tiempo de validez definido • No está soportado por el IE • Pero aún así es conveniente implementarlo: no tiene apenas coste y puede proteger a algunos usuarios • Ejemplo – Strict­Transport­Security: max­ age=16070400; includeSubDomains 19/25

X-Frame-Options

• Esta cabecera indica si un navegador puede renderizar una página dentro de <frame> o <iframe> • Orientado a evitar el clickjacking • Esta opción sí la soportan la mayoría de los navegadores: IE, FF, Opera, Safari, Chrome,...

• Ejemplos: – X-frame-options: DENY – X-frame-options: SAMEORIGIN – X-frame-options: ALLOW-FROM origen

20/25

Content-Security-Policy (CSP)

• Fue desarrollada para minimizar y 'eliminar' el riesgo de XSS, Clickjacking y navegación no segura.

• El fundamento es que el navegador sólo considere válidos determinadas fuentes de las que previamente le hemos informado por política, ignorando el resto • Necesita de ninguna o poca modificación en la aplicación • Se notifica al navegador bien – las cabeceras HTTP – y etiquetas Meta en el HTML • Tiene 3 partes: – Definición de políticas – Forzado de políticas – Informes de violación de políticas

21/25

Content-Security-Policy (CSP)- II

• Ejemplo : “Limita el contenido a este servidor” – X­Content­Security­Policy: default­src ‘self’ • Elemplo: “Permite imágenes de cualquier sitio, cotenido de plugins de esta lista de proveedores y scripts de un dominio específico” – X­Content­Security­Policy: default­src 'self'; img­src *; object­src tv1.um.es tv2.um.es; script­src fundewebscripts.um.es • Ensure all content is loaded over TLS: – X­Content­Security­Policy: default­src https://*:443

22/25

• Definida cabecera para testeo: – X-Content-Security-Policy-Report-Only: policy • Navegadores que lo implementan: – Firefox 4+ – Chrome 13+ – Safari 6+ • Navegadores que aún no lo implementan o el soporte es parcial – IE 10* – Opera

23/25