Tabla de contenido

1 Contexto del proyecto 11

1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Organismo de bienvenida. . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Problema12
1.4 Trabajo a hacer12
1.4.1 Critères de aceptabilidad. . . . . . . . . . . . . . . . . . . 12
1.4.2 Actores 12
1.4.3 Besoins funcionales................. 13
1.4.4 Necesidades no funcionales 13
1.4.5 Restricciones 13
1.5 Organización del informe . . . . . . . . . . . . . . . . . . . . . . . 13

2 Estadodel arte 14
2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Protocolos SSL/TLS...................... 14
2.2.1 Definición 14
2.2.2 Historial SSL/TLS15
[Link] Historial del protocolo SSL 15
[Link] Histórico del protocolo TLS 15
2.2.3 SSL/TLS Apretón de manos16
2.3 Configuración du HTTPS bajo Apache 219
2.4 Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

SSL/TLS
3 Auditoría 20
3.1 Introduction 20
3.2 Auditoría SSL/TLS20
3.3 Estudio herramientas similares 21
3.3.1 Estudio herramientas de escaneo de clientes . . . . . . . . . . . . . . . . . 21
3.3.2 Étude herramientas de escaneo de servidores .......................... 22
3.3.3 Estudio herramientas de escaneo cliente/servidor . . . . . . . . . . . . . 23
3.4 Elecciónde la solución . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1
4 Solución propuesta 25
4.1 Introducción ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 25
4.2 Presentación de la solución propuesta . . . . . . . . . . . . . . . . 25
4.2.1 Escanear lado del servidor . . . . . . . . . . . . . . . . . . . . . . 25
[Link] SSLyze . . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Mejora del Proyecto SSLyze. . . . . . . . . . 26
4.2.2 Escanear lado del cliente . . . . . . . . . . . . . . . . . . . . . . . . 28
[Link] Configuración du módulo SSLhaf. . . . . . . . . 28
[Link] Le contenido de registro por defecto. . . . . . . . . . . . . 29
4.3 Solución Completa AliveSSL29
4.3.1 AliveSSL escanear Cliente . . . . . . . . . . . . . . . . . . . . 30
4.3.2 AliveSSL escáner de servidor . . . . . . . . . . . . . . . . . . . . 31
4.3.3 Elección del tipo de servidor 31
[Link] Servidor red. . . . . . . . . . . . . . . . . . . . 31
[Link] Servidor FTP ................................32
[Link] Servidor SMTP. . . . . . . . . . . . . . . . . . . 32
[Link] Servidor POP332
[Link] Servidor LDAP. . . . . . . . . . . . . . . . . . . 33
[Link] Elección del tipo de escáner . . . . . . . . . . . . . . 33
[Link] Resultado du scan35
4.4 Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Buenas prácticas 36
5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1 Utilización claves privadas de 2048 bits . . . . . . . . . . . 36
5.2.2 Protección claves privadas. . . . . . . . . . . . . . . . . . 37
5.2.3 Garantía de una cobertura suficiente del nombre de host . . 37
5.2.4 Obtención certificados de una autoridad de certificación
fiable38
5.2.5 Utilización algoritmos de firma de certificado sólido 39
5.3 Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Utilisation cadenas de certificados completas 39
5.3.2 Utilización protocolos seguros 39
5.3.3 Utilización des suites de chiffrages sécurisées . . . . . . 40
5.3.4 Selección des meilleures suites de chiffrement . . . . . . . 42
5.3.5 Confidencialidad persistente. . . . . . . . . . . . . . . . . . 42
5.3.6 Utilización intercambio de claves fuertes. . . . . . . . . . . . . 42
5.3.7 Atenuación problemas conocidos 43
5.4 Performance 43
5.4.1 Evitación demasiada seguridad43
5.4.2 Reprise de sesión de utilización 43
5.4.3 Utilización de la optimizaciónWAN et HTTP/2 . . . . . . 44
5.4.4 Caché contenido público. . . . . . . . . . . . . . . . . . . 44
5.4.5 Utilización de aglomeración OCSP 44
5.4.6 Utilización primitivas criptográficas rápidas . . . 44

2
5.5 Protocolo HTTP y la seguridad de las aplicaciones . . . . . . . . . . 45
5.5.1 Chi ffrementde todo . . . . . . . . . . . . . . . . . . . . . 45
5.5.2 Eliminación de contenido mixto . . . . . . . . . . . . . . . . 45
5.5.3 Confianza terceros 45
5.5.4 Aseguramiento de galletas . . . . . . . . . . . . . . . . . . . 46
5.5.5 Compresión de HTTP segura 46
5.5.6 Despliegue de HTTP Strict Transport Security . . . . . 46
5.5.7 Despliegue de la política de seguridad del contenido . . . . 47
5.5.8 Mise en caché de contenido sensible . . . . . . . . . . . . . 47
5.5.9 Consideración d’autres menaces . . . . . . . . . . . . . . . 47
5.6 Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3
Table des figures

1 Reparto del tráfico cifrado por servicio . . . . . . . . . . . . . . 9

2 Ilustración HTTP vs HTTPS10

2.1 Evolución del protocolo SSL/TLS a lo largo del tiempo .............. 16

2.2 Secuencia simplificada del handshake SSL/TLS entre el cliente y el
servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Captura con la herramienta Wireshark del mensaje Client Hello enviado
par Firefox présentant les 20 suites cryptographiques présentés
por el navegador . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Ejemplo d'alerte qu'un client SSL/TLS peut retourner en cas de
problema en la negociación. . . . . . . . . . . . . . . . . . . . . 18

3.1 Prueba ¿Cómo está MySSL? . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Prueba DCseg22
3.3 Prueba Wormly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Prueba Servidor SSLabs. . . . . . . . . . . . . . . . . . . . . . . . . . 23
Prueba 3.5 Cliente de SSLabs . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Los autoridades de certificación añadidas27

4.2 Escanearcliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Página d’accueil del servicio AliveSSL 29
4.4 AliveSSL escanear cliente . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Los protocolos soportados del log 30
4.6 Las protocolos utilizados . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Elección del tipo de servidor . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Descripción de FTP . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.9 Fonctionnement de SMTP. . . . . . . . . . . . . . . . . . . . . . 32
4.10 Funcionamiento de POP333
4.11 Funcionamiento de LDAP . . . . . . . . . . . . . . . . . . . . . . 33
4.12 Escanear regular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.13 Escanear específico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.14 Résultat du scan . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4
Agradecimientos

Es porque hemos estimado mucho a todos los que nos han escuchado.
tés, conseguidos, criticados y enmarcados que queremos hacerles partícipes de toda nuestra
gratitud y queremos agradecerles a través de estas líneas.
Primero que nada, expresamos nuestro más sincero agradecimiento al Señor
Nizar Ben Neji notre encadrant pédagogique, pour les encouragements, pour le
tiempo que nos ha dedicado y por sus valiosos consejos.
Nuestros agradecimientos también se dirigen al Sr. Hamdi Mohamed por nosotros
haber acogido en el centro de incubación del Pôle El Ghazala así como para
su apoyo y sus consejos que siempre han constituido una ayuda valiosa.
Queremos agradecer de todo corazón a nuestros padres que siempre nos han apoyado
y animar en esta aventura y en todo nuestro recorrido universitario.
Expreso mi sincero agradecimiento a todos los profesores de nuestro departamento
tement informatique y todas las personas que han contribuido de cerca o de lejos
por sus palabras, sus escritos, sus consejos y sus críticas a lo largo de
et enfin, queremos expresar toda nuestra gratitud al Señor Mohamed
Oueld El Hassan, nuestro coordinador por sus visitas frecuentes a la organización
de stage y por su apoyo inestimable.
Un gran agradecimiento también a todos nuestros amigos y amigas por su sincera amistad y confianza.
Finalmente, gracias a los colegas de la oficina por las discusiones constructivas.
que tuvimos y por su buen humor.

5
6
Acrónimos y abreviaturas

ADH Difíe-Hellman anónimo

AEAD Cifrado autenticado con datos asociados
AES Estándar de Encriptación Avanzada
BESTIA Explotación del Navegador contra SSL/TLS
CA Autoridad de Certificación
CBC Encadenamiento de Bloques de Cifrado

CPU Unidad Central de Procesamiento

CRL Lista de Revocación de Certificados
CSP Política de Seguridad de Contenido
DROWNDesencriptando RSA con cifrado obsoleto y debilitado
ECDHE Diffie-Hellman de curvas elípticas
ECDSA Algoritmo de Firma Digital de Curva Elíptica
VE Validación Extendida
FTP Protocolo de transferencia de archivos

HSM Módulos de seguridad de hardware

HSTS Seguridad de Transporte Estricta HTTP
HTTP Protocolo de Transferencia de Hipertexto

HTTPS Protocolo de Transferencia de Hipertexto Seguro

IETF Fuerza de Tarea de Ingeniería de Internet
LDAP Protocolo ligero de acceso a directorios
MITM Hombre en el medio
OCSP Protocolo de Estado de Certificado en Línea
PCI DSS Norma de Seguridad de Datos para la Industria de Tarjetas de Pago
PODDLEOracle de Padding en Cifrado Heredado Degradado
POP3 Protocolo de Oficina de Correos SHA1

RC4 Cifrador Rivest 4

RFC Solicitud de Comentarios
SHA1 Algoritmo de hash seguro
SMTP Protocolo Simple de Transferencia de Correo

SSL Capa de Conexión Segura

SRI Integridad de subrecursos
TCP Protocolo de Control de Transmisión
TIC Tecnologías de la información y de la comunicación
TLS Capa de Transporte Seguro
UDP Protocolo de Datagramas de Usuario

VPN Red Privada Virtual

WAN Red de Área Amplia 7
XSS Cross-site Scripting
Prefacio

Nuestro proyecto forma parte de la obtención del diploma de fin de estudios

de la licenciatura aplicada en Redes Informáticas, especialidad Tecnologías de la In-
formación y de Telecomunicaciones dentro de la Facultad de Ciencias de
Bizerte (FSB). En la búsqueda de un tema, el Sr. Nizar Ben Neji nos ha pro-
planteé la idea de realizar una herramienta de auditoría y evaluación de los servidores SSL/TLS
Web, mensajería y directorio LDAP. La herramienta permitirá a los auditores de la
seguridad de evaluar las soluciones Cliente y Servidor SSL/TLS para la elaboración
de un informe detallado sobre los algoritmos de cifrado utilizados y las vulnerabilidades
de cada protocolo soportado.
Este proyecto nos permitió aplicar nuestros conocimientos teóricos y prácticos.
tiques en un marco de proyecto profesional. También era una oportunidad para
descubrir el mundo profesional, sus exigencias y sus necesidades en términos de com-
competencias.

8
Introducción general

La seguridad informática sigue progresando, evolucionando de un enfoque

pasiva, puntual y basada en producto a un enfoque activo de principio a fin
hacia el reconocimiento y la relación contenedor-contenido. Hoy en día, los cuatro-
Los proveedores de servicios luchan arduamente para garantizar la seguridad de sus clientes.
y integran mecanismos variados de seguridad en el marco de sus ofertas de
servicio. Pero las amenazas a la seguridad están en constante evolución, es por
esta razón por la que las empresas deben dotarse de los medios adecuados para
mejorar sus servicios en línea y proteger continuamente a su clientela. El uso
el cifrado, en particular el protocolo SSL/TLS, mejorará considerablemente la
seguridad de los servicios en línea en su conjunto. La implementación de SSL/TLS
garantizará a los internautas:
— La confidencialidad de los datos enviados en línea por el cifrado (que
pueden incluir números de tarjeta de crédito y otra información
financieras y personales como los nombres y las direcciones.
— La identidad de los sitios donde se depositarán estos datos por
el uso de certificados electrónicos

Figura 1 - Distribución del tráfico clasificado por servicio

9
SSL/TLS es un protocolo que opera en la interfaz de los sockets TCP. En consecuencia-
quencia, todos los protocolos de la capa de aplicación como HTTP, FTP, TEL-
NET, LDAP, SMTP y otros pueden ser protegidos por un canal de transmisión
seguro. En el caso de HTTP o de la Web, el número de sitios web seguros
El uso de SSL/TLS ha aumentado en los últimos años. Datos recientes
venant de Google montre que plus de 10% du trafic web est désormais chiffré par
SSL/TLS y el 50% del tráfico cifrado es generado por los servicios de Google (Figura
1). En Túnez, la mayor parte de los sitios son o no están asegurados por SSL/TLS o
presentando problemas de configuración.
Dans le cadre de notre projet, on va ainsi réaliser un outil pour scanner les
servidores y clientes TLS. Permite elaborar un informe detallado sobre los pro-
protocolos soportados, las suites de cifrado utilizadas, las posibles vulnerabilidades
así como las insuficiencias de seguridad relativas a SSL/TLS.
En este manuscrito, el capítulo 1 presenta el contexto del proyecto, el problema-
tique, el organismo de acogida así como la especificación detallada. En el capítulo
2, presentaremos los protocolos SSL y TLS y sus versiones. El capítulo 3
detalla y explica la operación de auditoría SSL/TLS así como las herramientas actualmente
utilizados. En el capítulo 4, se presenta la elección tecnológica así como la solu-
acción propuesta. Finalmente, el capítulo 5 incluye una lista de recomendaciones y
buenas prácticas que ayudarán a los administradores de sitios y expertos en seguridad
a mejor configurar sus servidores.

(a) Funcionamiento de HTTP

(b) Funcionamiento de HTTPS

Figura2 – Ilustración HTTP vs HTTPS

10
Capítulo 1

Contexto del proyecto

1.1 Introduction
En este capítulo, exponemos el contexto general del proyecto. Se presenta
primeramente el organismo de acogida, la problemática, el trabajo solicitado y la
metodología adoptada.

1.2 Organisme d’accueil

Nuestro proyecto se realizó en el Centro de Innovación del Polo Tecnológico El
Ghazela, que es un incubador de empresas y una estructura de apoyo
de proyectos de creación de start-ups. El centro de innovación está ubicado en el polo
tecnológico El Ghazela que forma parte de los 10 tecnopolos especializados en
sectores de actividad diferentes.
El centro de innovación comenzó en enero de 2016 con una decena de pro-
jets que han sido seleccionados de acuerdo con la política del centro y los
temáticas prioritarias. Varios equipos están trabajando actualmente a nivel
del centro de innovación y entre ellos estudiantes en prácticas de PFE que vienen de
diversos establecimientos. Estos equipos están trabajando actualmente en la implementación
de prototipos. Se beneficiarón de una supervisión en diversos aspectos como
la gestión de proyectos, la elaboración de un plan de negocios, el proceso de innovación,
el marketing, el comercial, la propiedad industrial y la vigilancia tecnológica.
Este centro tiene como objetivos:
Identificar los buenos proyectos para ayudar en la creación de empresas innovadoras.
trices
— Favorecer la aparición de una nueva generación de creadores y formar
de emprendedores con el fin de transformar a técnicos en portadores de proyectos
en chefs de entreprise
— Contribuir a la consolidación del tejido industrial en el marco de las TIC
y minimizar los factores de fracaso en la creación de empresas

11
1.3 Problemática
Hoy en día, las empresas ofrecen la posibilidad a sus clientes de realizar
des operaciones financieras y económicas a distancia sin tener que presentarse
en persona. Si la experiencia ha mostrado que esto era ventajoso y incluso muy
atractivo, también presenta un peligro hiperreal cuando la seguridad no está
en la cita. Para asegurar la seguridad de los servicios en línea, un conjunto
Las herramientas de auditoría pueden ser utilizadas para identificar las posibles vulnerabilidades.
La mayoría de las herramientas existentes son escáneres de vulnerabilidades de aplicaciones
que no realizan la inspección de las configuraciones del lado del servidor y más precisamente
la configuración SSL/TLS. Incluso las herramientas existentes no realizan todas las pruebas
necesarias para resolver los problemas relacionados con este protocolo. Se centran en
qüement sobre la parte del servidor ignorando las vulnerabilidades relativas a la parte
cliente y solo tratan el caso de la web y negligencian las otras aplicaciones.
caciones del SSL/TLS como la mensajería, los directorios LDAP, la transferencia de
fichero y los otros servicios.

1.4 Trabajo por hacer

Para resolver los problemas planteados, vamos a desarrollar un servicio web
para la auditoría SSL/TLS de las soluciones servidor y cliente para determinar los posibles
vulnerabilidades relacionadas con los protocolos y suites de cifrado utilizados y
de generar un informe detallado sobre los problemas encontrados. A nivel de esto
proyecto, también presentamos las recomendaciones y las buenas relacionadas con la
configuración de SSL/TLS del lado del cliente y del servidor. El servicio que se va a desarrollar
est destinado a los oyentes y a los administradores de seguridad y a los usuarios
queriendo evaluar a sus clientes SSL/TLS.

1.4.1 Criterios de aceptabilidad

El trabajo que se realizará en el ámbito de este proyecto será validado en base a
necesidades expresadas en el pliego de condiciones. Nuestro trabajo no será validado
que si :
— Permite realizar una buena verificación sobre la configuración SSL/TLS del lado
servidor y lado del cliente (la cadena de certificación, los protocolos compatibles,
la eficacia del cifrado y el intercambio de claves
— Proporciona un conjunto de recomendaciones y buenas prácticas para
los auditores de seguridad

1.4.2 Actores
Los oyentes, los administradores de seguridad y los usuarios de la web
serán los actores del servicio de auditoría SSL/TLS.

12
1.4.3 Necesidades funcionales
Las necesidades funcionales de la solución son:
— Escanear las configuraciones SSL/TLS de los servidores SMTP, FTP, POP,
IMAP, LDAP y los otros
— Escanear las soluciones SSL/TLS de los clientes como los navegadores (IE, Chrome,
Firefox, Opera, ...), los clientes de mensajería (MS Outlook, Mozzila
Thunderbird, ...), los clientes LDAP y otros
— Elaborer un rapport sur les eventuels vulnérabilités et insufisance de
seguridad
— Presentar un conjunto de recomendaciones y buenas prácticas relacionadas
garantizar la seguridad a través del protocolo SSL/TLS

1.4.4 Necesidades no funcionales

La solución desarrollada asegura los siguientes requisitos no funcionales:
— El rendimiento y la fiabilidad: el servicio web debe funcionar en la
mejores condiciones. Para este fin, es necesario gestionar bien los errores y los
excepciones y gestionar el aumento de carga en caso de múltiples conexiones
simultáneas.
— La ergonomía: la aplicación web debe tener cierta claridad y
de una simplicidad de uso.
— La portabilidad: la aplicación web debe funcionar en diversos entornos.
mentes y realizar la inspección de diversas soluciones cliente y servidor.
— La extensibilidad: la aplicación debe ser extensible y fácil de mantener
para responder a futuras necesidades

1.4.5 Contraintes
La solución debe ser de bajo costo y desarrollada con soluciones de código abierto.
El producto final debe ser entregado a la empresa a más tardar el 31 de mayo de 2017.

1.5 Organización del informe

Nuestro informe está formado por cinco capítulos. El capítulo 2 detalla el protocolo.
SSL/TLS y el proceso detallado para su implementación del lado del servidor. En el
chapitre 3, nous présentons l’importance de l’audit SSL/TLS ainsi que l’étude
comparativa de las herramientas existentes. El capítulo 4 presenta en detalle la solución
propuesta. Proporcionamos en el capítulo 5 un conjunto de recomendaciones
y buenas prácticas para ayudar a los actores a llevar a cabo adecuadamente la
tarea de aseguramiento SSL/TLS. Concluimos el informe con los objetivos
alcanzados y las posibles mejoras futuras.

13
Capítulo 2

Estado del arte

2.1 Introducción
Hoy en día, la seguridad juega un papel muy importante en el ámbito
de redes y telecomunicaciones. Los clientes del comercio electrónico
no tienen la confianza suficiente para pagar con tarjeta de crédito. Para asegurar
para este pago, es necesario utilizar protocolos de autentificación y cifrado
como SSL/TLS. Con estos protocolos, los datos personales de los clientes (nu-
méro de carte bancaire, mot de passe, etc) estarán protegidos y nadie puede
interceptarlos.
En este capítulo, vamos a presentar en detalle el protocolo SSL/TLS, sus dif-
versiones diferentes, fallos y vulnerabilidades reconocidas para cada versión
ainsi que la mise en oeuvre de ce dernier du côté serveur.

2.2 Protocolos SSL/TLS

2.2.1 Definición
Los protocolos SSL (Capa de Sockets Seguros) y TLS (Seguridad de la Capa de Transporte)
rity) son dos protocolos criptográficos de seguridad que permiten la autenticación
la identificación y el cifrado de datos entre dos entidades cliente y servidor. El
TLS es el sucesor de SSL, estos dos últimos funcionan según un modo
cliente/servidor que satisface los siguientes objetivos:
— la autenticación del servidor así como de los clientes: autenticación SSL/TLS
simple y mutua
— la confidencialidad de los datos intercambiados por el cifrado híbrido de
comunicaciones
— la integridad de los datos intercambiados
SSL/TLS fue diseñado inicialmente por Netscape y actualmente es un estándar
oficialmente estandarizado por la IETF. El protocolo SSL/TLS es un protocolo de seguridad
rité que crea un canal seguro entre dos máquinas comunicantes en Internet.

14
Se utiliza para asegurar la autenticación y las transacciones electrónicas.
Los dos protocolos SSL y TLS funcionan entre la capa de transporte (TCP
ou UDP) y la capa de aplicación para asegurar los protocolos nativamente pocos
sûrs. Il est le protocole de sécurité le plus utilisé aujourd’hui sur le Internet. Il
permite asegurar varias aplicaciones y servicios de red, como la transferencia
de archivos por FTP, las conexiones VPN, la mensajería instantánea y la voz
sobre IP.
El protocolo SSL/TLS consta de dos componentes: el Registro TLS y
El apretón de manos TLS. El registro TLS tiene como objetivo cifrar conexiones con
un algoritmo simétrico y el apretón de manos TLS tienen como objetivo autenticar a los dos
partes comunicantes, de permitirles negociar los algoritmos así como
el protocolo. El protocolo incluye la verificación de los certificados electrónicos del
cliente y del servidor para asegurarse de las identidades de las entidades comunicantes.

2.2.2 Historial SSL/TLS

El protocolo SSL/TLS nació en 1994 y fue creado por Netscape. Ha evolucionado
con el tiempo, dadas las nuevas exigencias tecnológicas y dadas las vulnerabilidades
detectadas como BEAST, PODDLE y DROWN (Ver Figura2.1).

[Link] Historial del protocolo SSL

Al principio, Netscape desarrolló la versión SSL 1.0 que permaneció teórica y
n’ha sido nunca implementada. Las versiones que han sido implementadas y ampliamente
utilizadas son:
— SSL 2.0 es la versión inicial que fue desarrollada en 1995. Ella pre-
siente problemas a nivel de la seguridad y ha sido desaconsejada desde entonces
mucho tiempo.
Netscape desarrolló al año siguiente SSL 3.0 para reemplazar SSL 2.0
que presentaba varias vulnerabilidades como DROWN y otras. Esta
la versión se mantuvo activa y muy utilizada durante un buen período. Una
El equipo de investigación de Google ha identificado una vulnerabilidad llamada PODDLE
en el diseño de esta versión que permite descifrar el contenido
información intercambiada entre el navegador web de la víctima y el
servidor seguro con el ataque Hombre en el Medio. A causa de POODLE,
la mayoría de los navegadores han desactivado definitivamente SSL 3.0 hacia la
fin de 2014.

[Link] Histórico del protocolo TLS

— TLS 1.0 fue desarrollado en 1999. La evolución de SSL dio el proto-
cole TLS que fue confiado por el IETF. TLS 1.0 no era más que una ligera évo-
lution de SSL 3.0 que presenta una parte del establecimiento de la conexión
(apretón de manos) y aporta flexibilidad con la introducción de extensiones
opcional que permiten hacer evolucionar el protocolo sin revisar sus

15
 bases. Su mayor debilidad es el ataque BEAST que se basa en Ja-
vaScript, permite a un atacante en la misma red interceptar
y descifrar cookies SSL a través de un ataque en paquetes cifrados.
Esta versión también es incapaz de utilizar suites de cifrado
modernos que ofrecen una mayor seguridad y eficiencia. Tras esto
debilidades, esta versión ha sido reemplazada por una nueva más segura.
TLS 1.1 fue desarrollado en 2006, es la segunda versión más reciente
de TLS, es una versión de transición que consolida ciertos RFC in-
intermediarios e incluye una modificación de la inicialización de los bloques CBC
(seguido de un informe presentado en 2011). Sin embargo, el entorno de
la seguridad moderna ha impulsado hacia TLS 1.2.
— TLS 1.2 es la última versión de TLS. Esta versión permite acceder
a secuencias de cifrado avanzadas que admiten la cripto-
gráfica de curva elíptica (eficiencia para un intercambio de información
en un canal no seguro). Aporta una evolución importante que se
presentes en los modos de cifrado autenticado de bloque AEAD.

Figura 2.1 – Evolución del protocolo SSL/TLS a través del tiempo

2.2.3 Intercambio SSL/TLS

La parte de Handshake del TLS es responsable de la autenticación y de
el intercambio de las claves necesarias para establecer una sesión segura (Ver Figura
2.2).Durante el establecimiento de una sesión segura, el protocolo Handshake
gère ce qui suit :
— Negociación de la suite de cifrado: El cliente y el servidor entran en
contactan y eligen la secuencia de cifrado que se utilizará durante todo
de su intercambio de mensajes.
— Autenticación del servidor: el servidor prueba su identidad al cliente
gracias a su certificado electrónico. El cliente también puede necesitar
de probar su identidad para el servidor si es necesario. El uso de
pares de claves públicas/privadas, es la base de esta autenticación. La
método exacto utilizado para la autenticación se determina según la

16
 suite de cifrado negociada.
— Elaboración e intercambio de una clave de sesión entre el cliente y el servidor: En
Primero, las partes comunicantes llegan a un acuerdo sobre el algoritmo
de cifrado simétrico que se utilizará y en segundo lugar, el cliente
SSL/TLS generan la clave de sesión simétrica en base a la elección
efectué.
Este protocolo tiene como objetivo permitir que el servidor y el cliente se autentiquen.
vincularse entre sí y luego negociar un algoritmo de cifrado y una clave
criptográfica antes de que la aplicación transmita.
Como muestra la Figura2.2un primer mensaje ClientHello es enviado por
el cliente al servidor para iniciar la comunicación. En este mensaje, el cliente
propone un conjunto de suites criptográficas que es capaz de implementar
obra (Ver Figura2.3).Cada una de estas suites criptográficas describe las
mecanismos criptográficos que se utilizarán para las siguientes funciones:
— el intercambio de llaves
— la autenticación del servidor.
— la protección de los datos de aplicación, en confidencialidad e integridad.
Este mensaje contiene otros parámetros que deben ser negociados: la ver-
versión del estándar utilizado (SSLv2, SSLv3, TLS 1.0, TLS 1.1 o TLS 1.2) y
el mecanismo de compresión que eventualmente se aplicará a los datos
aplicativos. En respuesta, el servidor rechazará la negociación si ninguna de las propuestas
La posición del cliente no se considera aceptable. El servidor entonces finaliza la conexión.
En caso contrario, el servidor elige una secuencia de cifrado entre las que hay
propuestas por el cliente y emite el mensaje ServerHello que indica su elección
en la que presenta su certificado electrónico y envía un mensaje Serve-
Hola, hecho para indicar que ahora espera una respuesta del cliente.

Figura 2.2 – Secuencia simplificada del handshake SSL/TLS entre el cliente y el

servidor

17
 À la fin de la négociation, une fois la suite de chiffrement choisie et le cer-
Certificado recibido, el cliente verifica la cadena de certificación y el estado del certificado del
servidor. Si el certificado no está validado, el cliente emite una alerta que pone fin a
la connexion (Voir Figure 2.4).De lo contrario, él continúa y envía un mensaje, Cliente-
Intercambio de claves, que contiene el pre-master secreto cifrado. A partir de ahí, el cliente y
el servidor dispone de una clave secreta compartida y de varios elementos
mentas aleatorias públicas intercambiadas durante los mensajes ClientHello y ServerHello.
Estos elementos compartidos serán útiles para proporcionar las claves simétricas que serán
utilizadas para proteger todas las sesiones: para garantizar la confidencialidad y
la integridad de los intercambios. Se intercambian mensajes ChangeCipherSpec para
indiquer l’activation des paramètres (algorithmes et clés) négociés. Les mes-
sages Terminados son, por lo tanto, los primeros en ser protegidos criptográficamente, y
contienen un hash de todos los mensajes intercambiados durante la negociación
acción, a fin de garantizar a posteriori la integridad de la negociación.

Figura 2.3 - Captura con la herramienta Wireshark del mensaje Client Hello enviado
par Firefox présentant les 20 suites cryptographiques présentées par le navigateur

Figura 2.4 - Ejemplo de alerta que un cliente SSL/TLS puede devolver en caso de
problema en la negociación.

18
2.3 Configuración de HTTPS en Apache 2
En esta parte, vamos a hablar de la configuración del protocolo HTTPS con
Apache 2 en Ubuntu 14.04.
1. Instalación del módulo SSL de Apache para que el protocolo SSL pueda
funcionar con el servidor Apache 2:
sudo apt-get install mod_ssl
2. Activación del módulo SSL de Apache 2:
sudo a2enmod ssl
3. Después de activar el SSL, es necesario reiniciar el servidor web para que la
la modificación se tenga en cuenta:
sudo servicio apache2 reiniciar
4. Creación del certificado electrónico utilizando la herramienta OpenSSL[[Link]
A nivel de esta etapa, debemos precisar el nombre de dominio del sitio que va a
aparecer a nivel de certificado. La ubicación del certificado SSL y de
la clave privada del servidor se colocará en el directorio /etc/apache2/ssl.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
/etc/apache2/ssl/[Link] -out /etc/apache2/ssl/[Link]
5. Configuración del VirtualHost a nivel de Apache:

6. Activación de la configuración del VirtualHost:

sudo a2ensite [Link]
7. Inicio del servidor Apache:
sudo servicio apache2 iniciar
8. Test du serveur Web avec le navigateur Firefox :

2.4 Conclusion
En este capítulo, se han presentado los protocolos SSL y TLS así como su
histórico y las fallas conocidas. También se ha establecido la configuración de SSL/TLS
bajo Apache. La configuración del SSL/TLS por sí sola no es suficiente. Es
pourquoi il faut se doter d’un outil pour l’évaluation de la configuration faite.
A nivel de la siguiente parte, vamos a explicar y presentar la auditoría SSL/TLS.

19
Capítulo 3

Auditar SSL/TLS

3.1 Introducción
La seguridad informática está relacionada con Internet, a menudo implicando la seguridad de
navegador web y también la seguridad de la red. El protocolo SSL/TLS interviene
para asegurar que las comunicaciones entre dos sistemas no caigan en
de malas manos y que no puedan ser leídas ni manipuladas.
En este capítulo, se destaca la importancia de la auditoría SSL/TLS seguida
a través de un estudio sobre las herramientas similares existentes. Y finalmente, concluimos este capítulo
por una justificación de la elección de nuestra solución.

3.2 Auditoría de SSL/TLS

En el ámbito de la seguridad informática, la auditoría interviene para realizar un

operaciones de evaluaciones, de verificaciones o de control. Permite recopilar
información objetiva para determinar en qué medida los elementos
de un sistema observado deben cumplir con los requisitos de un dominio específico.
En este contexto, se puede hablar del protocolo SSL/TLS que permite el establecimiento
mente de una conexión segura, es durante su negociación que el cliente y
el servidor elige sistemas conocidos (protocolos, suites de cifrado).
Durante esta negociación, es necesario asegurar la identidad de la entidad con la que
una máquina se comunica. Es necesario asegurarse de que el cliente se comunique con el
servidor que dice ser. En este caso, el certificado SSL interviene, es un
una forma de prueba de identidad de un sitio web, también es un archivo de datos que vincula
una clave criptográfica a la información de un individuo. Este último está instalado
en un servidor para asegurar una conexión segura entre el servidor web y el
navegador.
El uso de certificados SSL/TLS se generaliza para:
— El acceso a sitios seguros.
Las aplicaciones bancarias.
Las respuestas a las licitaciones del mercado público.

20
Los certificados SSL son emitidos y firmados por un tercero de confianza (autoridad
de certificación) para asegurar el vínculo entre dos entidades comunicantes. Para
un sitio web, se debe adoptar un certificado SSL para la seguridad de los visitantes
sitio web (por ejemplo, el caso de un sitio de comercio electrónico). La configuración de este tipo de
el certificado no siempre era aceptable, es por esta razón que se debe utilizar
herramientas que lo permiten.

3.3 Estudio de herramientas similares

Dado que el uso del protocolo SSL/TLS permite tener com-
comunicaciones cifradas lo que permite evitar que los datos sean interceptados.
Numerosos son los herramientas de evaluación sobre la configuración SSL/TLS, pero...
cun a su ventaja en comparación con los demás, hay aquellos que escanean el servidor
y otros que escanean al cliente y también herramientas que permiten escanear
todos los dos.

3.3.1 Estudio de las herramientas de escaneo del cliente

En esta sección se presentan herramientas similares a nuestra solución propuesta.

que permiten el escaneo a nivel del cliente, como la herramienta How's MySSL y
DCsec.
— How's MySSL es una herramienta que escanea el cliente (navegador) permitiendo
de faire des vérifications sur les protocoles supportés et leur versions
y sobre las secuencias de cifrados soportados. Está diseñado para ayudar a un
desarrollador de un servidor web para aprender mejor sobre los clientes TLS. Este
la herramienta se ha ampliado para dar a los desarrolladores una forma rápida y fácil
para comprender mejor las herramientas utilizadas. Su principal desventaja es
que no presenta todas las secuencias de cifrados.

Figura 3.1 - Prueba Cómo está mi SSL

21
 — DCsec es una herramienta creada por un grupo de investigadores que permite evaluar
luer el navegador mientras da las secuencias de cifrados y los proto-
coles soportadas. Esta herramienta no proporciona el nivel de seguridad de cada uno.
suite de ciframiento.

Figura 3.2 - Prueba DCsec

3.3.2 Estudio de las herramientas de escaneo de servidor

En esta parte se presentan algunas herramientas similares a nuestra solución.

propuestas que permiten el escaneo a nivel del servidor, como la herramienta SSLyze
et Wormly.
— SSLyze es un proyecto de código abierto que analiza la configuración de un servidor.
veur, es rápido y comprensible y ayuda a los oyentes a identificar los
malas configuraciones que afectan su servidor. Esta herramienta se caracteriza
por una prueba de seguridad para las suites de cifrado, de validación y de
vérification de la révocation du certificat d’un serveur.
Wormly es una herramienta que realiza un análisis profundo sobre la configuración.
la interacción y el rendimiento del servidor web, incluidos los protocolos soportados
y las debilidades de seguridad conocidas. Esta herramienta en línea también permite
probar un servidor de mensajería SMTP. Su principal inconveniente es que
no presenta las suites de cifrado soportadas por el servidor.

22
 Figura 3.3 – Test Wormly

3.3.3 Estudio de las herramientas de escaneo cliente/servidor

SSLLabs es una herramienta que proporciona una prueba SSL para verificar el correcto
instalación de los certificados así como la seguridad SSL/TLS de su servidor y de
detectar debilidades de configuración SSL y problemas de rendimiento.
Esta herramienta es una de las herramientas de prueba SSL más populares para verificar todas
las vulnerabilidades y la mala configuración del protocolo SSL/TLS. Esta herramienta
permite escanear servidores web.

Figura 3.4 – Servidor de prueba SSLabs

23
 Figura 3.5 - Prueba del cliente SSLabs

3.4 Elección de la solución

Tras nuestro estudio previo que nos permitió comprender profundamente
el concepto de nuestro tema, encontramos el proyecto de código abierto SSLyze que se
puerto como una biblioteca Python que permite analizar la configuración
SSL/TLS de un servidor, sin embargo, esta solución aún puede mejorarse. Se puede
también encontró el módulo de Apache SSLhaf que permite analizar paquetes
ClientHello. Tras este estudio, hemos tomado la iniciativa de diseñar una solución
complemento que permite iniciar un escaneo a nivel del cliente y del servidor en
explotando estas dos soluciones. Se nota que hemos elegido SSLyze por su rapidez
des scans et leurs envoi automatique. Cet outil est caractérisé par un test de
rendimiento y una prueba de seguridad, en lo que respecta a la elección de SSLhaf es
justificó gracias a su capacidad de analizar los paquetes ClientHello que vienen del cliente.

3.5 Conclusión
En este capítulo, se ha realizado un estudio sobre las diferentes herramientas similares a
nuestra solución propuesta. Aunque estas herramientas incluyen diferentes servicios,
quedan aún por encontrar una solución completa es un objetivo mayor. De hecho
hemos presentado brevemente la elección de nuestra solución propuesta que será
descripción detallada en el siguiente capítulo.

24
Capítulo 4

Solución propuesta

4.1 Introducción
Una mala configuración del protocolo SSL/TLS puede hacerlo poco seguro
y incluso vulnerable a ataques y dado que hay numerosos parámetros de
configuración disponibles, es difícil saber de antemano qué impacto ciertos
los cambios tendrán, estos cambios pueden ser realizados accidentalmente.
Entonces en este caso, se debe utilizar una herramienta de evaluación SSL/TLS completa para
la verificación de la configuración y para saber si el sistema es vulnerable. On
va presentar en este capítulo nuestra solución propuesta de una manera detallada.

4.2 Presentación de la solución propuesta

A nivel de nuestro proyecto, hemos adaptado e integrado la herramienta de código abierto SS-
Lyze y el módulo de Apache SSLhaf. Los componentes implementados van a
evaluar la configuración SSL/TLS y realizar un escaneo completo en el
servidor/cliente. Por esta razón, nuestra herramienta AliveSSL proporciona:
— Un escaneo del lado del cliente que proporciona la configuración SSL/TLS del navegador,
las suites de cifrado y los protocolos activos.
— Un escaneo del lado del servidor que proporciona la configuración SSL/TLS del servidor,
las suites de cifrado, los protocolos soportados y si es vulnerable a
algunos tipos de ataques.

4.2.1 Escaneo lado Servidor

Un gran número de suites de cifrado disponibles y avances rápidos
en la criptoanálisis hace que la evaluación de un servidor SSL sea una tarea evidente,
de donde es necesario elegir bien la herramienta de escaneo SSL/TLS a utilizar. Por estas razones,
nuestra herramienta debe permitir hacer un escaneo completo de los certificados instalados
en un servidor, las secuencias de cifrado, y para alcanzar esta necesidad hemos
utilizado e integrado la herramienta SSLyze.

25
[Link] SSLyze
SSLyze es un proyecto open source en Python que analiza la configuración SSL/TLS
de un servidor. Está diseñado para ser rápido y completo, y debería ayudar a las orga-
las organizaciones y los probadores a identificar las malas configuraciones que afectan sus
servidores SSL. Para hacer un escaneo en un servidor se lanza este comando:

[Link] Amélioration du Projet SSLyze

Se han añadido algunas mejoras en el proyecto SSlyze para hacerlo más
fiable y más eficiente que se identifican en esta sección.

Las autoridades de certificación son

La adición de las autoridades de certificación
un tercio de confianza que permite autenticar la identidad de los corresponsales.
Cada entidad integra de forma nativa una lista de certificados provenientes de diferentes
autorités de certification choisies selon des règles internes définies par les déve-
loppeurs de l’entité (exemple : Adobe), esta lista está en formato .pem, on
ha añadido listas al proyecto SSLyze para hacer que el escaneo sea más fiable.

26
 Las listas agregadas son:
— tienda de Google CA
— Tienda Adobe CA
— Tienda de Microsoft CA
— Almacén CA de Java

Figura 4.1 – Las autoridades de certificación añadidas

La adición de la prueba de ataque El protocolo SSL/TLS incluye efectivamente un

cierto número de fallas que un usuario malintencionado puede aprovechar
para provocar un denegación de servicio o introducir un código malicioso o aún
interceptar el tráfico entre las dos partes que se comunican.
Existen varias vulnerabilidades en las versiones del protocolo SSL/TLS
telque l’attaque DROWN. Cependant, on a ajouté un test sur cette attaque.
Prueba del ataque Drown en SSLv2: esta vulnerabilidad permite a un piratear ...
recuperar información de un servidor y comprometer una comunicación
utilizando el protocolo SSLv2 :

27
4.2.2 Escaneo del lado del cliente

El escaneo del lado del cliente consiste en realizar un análisis sobre los protocolos soportados y
las suites de cifrados configurados en un navegador. Al principio de la comu-
nicación SSL/TLS, el cliente envía un paquete ClientHello al servidor que contiene
toda la información del navegador.

Figura 4.2 – Cliente de escaneo

De dónde encontramos el módulo SSLhaf que permite capturar el paquete

ClientHello y registrar estos datos en un archivo de log.

[Link] Configuración del módulo SSLhaf

En esta sección, vamos a presentar los pasos de configuración del módulo.
SSLhaf en Ubuntu 14.04:
— Copie de archivos a partir de GitHub:
git clone [Link]
— Compilación del módulo
sudo apxs -cia mod_sslhaf.c
Este script agrega el LoadModule en los archivos de configuración de Apache.
— Adición del módulo manualmente en el archivo [Link]
Este archivo se encuentra en /etc/apache2/sites-enabled/; se le añaden las líneas
siguientes :
CargarMódulo sslhaf_module /usr/lib/apache2/modules/mod_sslhaf.so
CustomLog logs/[Link] "%t %{X-Forwarded-For}i "%{SSL-
HAF_HANDSHAKE}e" \
%{SSLHAF_PROTOCOL}e \"%{SSLHAF_SUITES}e\"
"%{SSLHAF_COMPRESSION}e" \
"%{SSLHAF_EXTENSIONS_LEN}e" %{SSL-
HAF_EXTENSIONS}e" "%{User-Agent}i"
env=SSLHAF_LOG
— Apertura del servidor local
Https ://[Link] :443
— Contenido del archivo [Link]
El archivo [Link] que se encuentra en /etc/apache2/logs/[Link] contiene
maintenant la configuration SSL du navigateur qui visite le https ://[Link] :443
.

28
[Link] Le contenu log par défaut
El contenido del archivo de registro es incomprensible:
— El primer campo contiene la versión del protocolo SSL utilizado: 2 y 3
por ejemplo, google bot utiliza el apretón de manos SSLv2 para SSLv2 y SSLv3+
entonces está listo para usar SSLv2 o mejor.
— El segundo campo contiene la mejor versión utilizada, por ejemplo
SSLv3 es "3.0", TLSv1.0 es "3.1", TLSv1.1 corresponde a "3.2" y TLSv1.2
corresponde a "3.3".
El tercer campo contiene la lista de las secuencias de soportes diferentes
por el cliente.
Cada secuencia está asociada a un código hexadecimal. Por ejemplo:
0x04 representa la suite SSL_RSA_WITH_RC4_128_MD5,
0x010080 representa SSL_CK_RC4_128_WITH_MD5
et 0x05 representa la suite SSL_RSA_WITH_RC4_128_SHA.
— El cuarto campo contiene la lista de los métodos de compresión de-
fertes par le client (00 = NULL , 01 = DEFLATE).
De donde, estábamos obligados a convertir este contenido utilizando PHP para que pudiéramos
mostrar a los usuarios un resultado comprensible.

4.3 Solución Completa AliveSSL

Nuestra aplicación web AliveSSL permite utilizar las dos herramientas SSLyze y
SSLhaf para realizar una evaluación completa sobre la configuración SSL/TLS del lado
servidor/cliente.

Figure4.3 – Page d’accueil du service AliveSSL

29
4.3.1 Escaneo AliveSSL Cliente
Esta parte de nuestra aplicación web utiliza el archivo de registro generado por el mo-
dule sslhaf al cambiar el contenido para hacerlo comprensible para la audiencia
teur : se extrae el contenido del registro campo por campo y el tercer campo será
comparé con una base de datos para determinar las secuencias de manera diferente
relacionados con cada código hexadecimal.

Figura 4.4 - Cliente de escaneo AliveSSL

Luego se pueden determinar los protocolos compatibles con el navegador a través de

primer campo del archivo de registro.

Figura 4.5 – Protocolo soportados del registro

También se puede determinar el protocolo utilizado gracias al segundo campo.

Figura 4.6 - Los protocolos utilizados

30
4.3.2 Escaneo de servidor AliveSSL

Esta parte de la aplicación web permite probar la configuración del servidor.

gracias a SSLyze donde vamos a analizar su contenido y mostrarlo al auditor. Con
sslyze se pueden realizar escaneos en varios tipos de servidores como LDAP,
FTP, SMTP, POP3. De donde nuestra aplicación web podrá hacer escaneos.
sobre estos tipos de servidor.
Nuestra aplicación proporciona a los auditores una interfaz donde pueden elegir
el tipo de servidor a analizar que puede ser un servidor web, SMTP, LDAP,
FTP y POP3.

4.3.3 Elección del tipo de servidor

Figura 4.7 - Elección del tipo de servidor

[Link] Servidor web

El servidor web es específicamente un servidor multi-servicio utilizado para pu-
blier des sites sur Internet, ce type de serveur est un ordinateur qui stocke les
ficheros que componen un sitio web (por ejemplo, documentos HTML, imágenes,
el archivo javascript) y permite enviarlos al dispositivo de un usuario que
visite el sitio. Esta computadora está conectada a Internet y generalmente es accesible.
posible a través de un nombre de dominio como [Link].

31
[Link] Servidor FTP
El servidor FTP (Protocolo de Transferencia de Archivos) permite el intercambio de archivos en
ternet . Todo usuario autorizado puede descargar o enviar archivos en
un ordenador distante que ejecuta dicho servidor. El puerto por defecto es
a menudo se utiliza el puerto 21.

Figura 4.8 - Descripción de FTP

[Link] Servidor SMTP

El servidor SMTP es un protocolo de comunicación utilizado para la trans-
ferts de correos electrónicos hacia los servidores de mensajería electrónica. El
la transferencia se realiza a través del puerto 25. Debemos comenzar por la especificación del ex-
péditeur del mensaje luego el o los destinatarios de un mensaje. Es posible
de probar un servidor SMTP utilizando el comando telnet en el puerto 25 de un
servidor remoto.

Figura 4.9 – Funcionamiento de SMTP

[Link] Servidor POP3

El servidor POP3 es un protocolo que permite recuperar correos.
electrónicos ubicados en un servidor de correo electrónico remoto cuando
no estás conectado permanentemente a Internet. Permite descargar los
mensajes y retirarlos del servidor.

32
 Figura 4.10 - Funcionamiento de POP3

[Link] Servidor LDAP

El servidor LDAP (Protocolo Ligero de Acceso a Directorios) es un protocolo
de acceso a los directorios ligeros que permiten gestionar directorios; de acceder a unos
bases de información sobre los usuarios de una red a través de pro-
tocoles TCP/IP. Este protocolo define el método de acceso a los datos sobre el
servidor a nivel del cliente, y no la manera en que la información se encuentra
almacenadas. . Un directorio está diseñado para recibir muchas más solicitudes en
lectura que en escritura.

Figura 4.11 – Funcionamiento de LDAP

[Link] Elección del tipo de escaneo

Después de elegir el tipo de servidor, el auditor elige el tipo de escaneo a realizar.

en este servidor. Elige un escaneo regular o un escaneo específico.

33
 Figura 4.12 – Escaneo regular

En el caso del escaneo regular, nuestra aplicación proporciona a los auditores

información sobre los protocolos compatibles con el servidor, las suites de cifrado
de cada protocolo y de la información sobre el o los certificados electrónicos del
servidor. Así que si el servidor es vulnerable a algunos ataques como los siguientes:
pantalla
En este caso, el auditor debe elegir un escaneo específico o también sobre qué punto
hacer el escaneo, ya sea en un protocolo específico o en un ataque bien determinado
o incluso en el certificado electrónico solamente.

Figura 4.13 – Escaneo específico

34
[Link] Resultado del escaneo

Después de seleccionar el tipo de escaneo, AliveSSL muestra el resultado según el tipo de

escaneo elegido presentando un informe sobre los puntos específicos que el auditor tiene
elige.

Figura 4.14 - Resultado del escaneo

4.4 Conclusión
En este capítulo, hemos resaltado nuestra solución propuesta de la cual hemos
detalló sus diferentes etapas y las mejoras que hemos agregado. A continuación
en esta fase, tenemos en cuenta la mala configuración que puede generar
ataques críticos debido a un mal conocimiento de la configuración SSL/TLS.
Por eso hemos proporcionado una parte dedicada a las buenas prácticas en el
capítulo 5.

35
Capítulo 5

Buenas prácticas

5.1 Introducción
SSL/TLS es una tecnología engañosamente simple, fácil de implementar, pero
su problema principal es que el cifrado a menudo no es fácil de implementar
correctamente. Para asegurarse de que TLS proporciona la seguridad necesaria, los adminis-
los traidores del sistema y los desarrolladores deben hacer un esfuerzo adicional
a la configuración de sus servidores y el desarrollo de las [Link]
En este capítulo, presentaremos recomendaciones y buenas prácticas.

5.2 Recommandations
En TLS, la seguridad comienza con la identidad criptográfica del servidor,
una clave privada fuerte es necesaria para evitar que los atacantes realicen
ataques de suplantación de identidad. También es importante tener un certificado válido
et, solide que proporciona a la clave privada el derecho a representar un nombre de host
particular. Sin estos dos elementos fundamentales, nada más puede ser
asegurado.

5.2.1 Utilización de claves privadas de 2048 bits

Para la mayoría de los sitios web, la seguridad proporcionada por las claves RSA de 2048
bits es suficiente. El algoritmo de clave pública RSA está ampliamente respaldado,
lo que convierte a las claves de este tipo en una opción segura por defecto. A 2048 bits, estas claves
proporcionan alrededor de 112 bits de seguridad. Si se quiere más seguridad que eso,
se nota que las claves RSA no escalan muy bien. Para obtener 128 bits de
sécurité, on a besoin des clés RSA de 3072 bits, ce qui est sensiblement plus
Las claves ECDSA ofrecen una alternativa que brinda una mejor seguridad y
de mejores rendimientos. A 256 bits, las claves ECDSA proporcionan 128 bits de
seguridad. Un pequeño número de los antiguos clientes no soportan ECDSA,
pero los clientes modernos lo hacen. Es posible obtener lo mejor de ambos

36
y de desplegar las claves RSA y ECDSA simultáneamente si los gastos generales de la
la gestión de una tal configuración no le molesta.

5.2.2 Protección de las claves privadas

Trate sus claves privadas como un activo importante, restringiendo el acceso a
el grupo más pequeño posible de empleados manteniendo sus acuerdos pra-
Las políticas recomendadas incluyen los siguientes elementos:
— Generar claves privadas en un ordenador de confianza con una entropía
suficiente. Algunas autoridades de certificación le permiten generar
claves privadas; en este caso, hay que evitarlas.
— Asistir las claves con una contraseña desde el principio para evitar cualquier com-
promesas cuando se almacenan en sistemas de respaldo. Las claves
privadas no contribuyen mucho a la producción, ya que un atacante
bien informado puede siempre recuperar las claves de la memoria del proceso.
Existen dispositivos de hardware (llamados módulos de seguridad maté-
rielle o HSMs (Módulos de Seguridad de Hardware) que pueden proteger los
claves privadas, incluso en caso de compromiso del servidor, pero son caras y
solo pueden ser justificados para las organizaciones que tienen requisitos
de seguridad estrictas.
— Después de un compromiso, revoquen los antiguos certificados y generen nuevos.
viejas llaves.
Renovar los certificados cada año, y más a menudo si puedes
automatizar el proceso. La mayoría de los sitios deberían suponer que un
el certificado comprometido será imposible de revocar de manera fiable. Los
Los certificados con una vida útil más corta son, por lo tanto, más fiables en
practique. A menos que las mismas llaves sean importantes para el anclaje de la llave
publique, usted también debe generar nuevas claves privadas cada
vez que recibe un nuevo certificado.

5.2.3 Aseguramiento de una cobertura suficiente del nombre de host

Asegúrese de que sus certificados cubran todos los nombres que desea
utilizar con un sitio. Su objetivo es evitar las advertencias de los certificados
inválidos, que confunden a los usuarios y debilitan su confianza. Incluso
cuando espera utilizar un solo nombre de dominio, no olvide
que no puedes controlar la forma en que tus usuarios llegan a la
site o cómo los demás lo vinculan. En la mayoría de los casos, debe usted
asegúrese de que el certificado funcione con y sin el prefijo www (por ejemplo, él
debe funcionar para [Link] y [Link]). La regla general
un servidor web seguro debería tener un certificado válido para cada
DNS configurado para apuntar. Los certificados genéricos tienen sus usos,
pero evite utilizarlos si implica exponer las claves subyacentes a
un grupo de personas mucho más grande, y sobre todo si se cruzan con los
límites del equipo o de un departamento así. En otras palabras, cuanto menos hay
des personnes avec accès aux clés privées, mieux ca sera. Sachez également que

37
el intercambio de certificados crea un vínculo que puede ser abusado para transferir
vulnerabilidades de un sitio web o de un servidor a todos los demás sitios y servidores
que utilizan el mismo certificado (incluso cuando las claves privadas subyacentes son
diferentes).

5.2.4 Obtención de certificados de una autoridad de certificación

tion fiable
Seleccione una Autoridad de certificación (CA: Certificación Authority) que
es fiable y seria en lo que respecta a su actividad de certificación y su seguridad.
Considere los siguientes criterios al seleccionar su autoridad de certificación
cation :
— Puesto de seguridad: Todas las autoridades de certificación están sujetas a
auditorías regulares, pero algunas son más serias en materia de seguridad
qué otros. Determinar cuáles son las mejores autoridades en este aspecto
que no es fácil, pero una opción consiste en examinar su historial
de seguridad y lo más importante es cómo reaccionaron a
compromiso y si han aprendido de sus errores.
—Enofqueemper:aslirLasauodtiradesdec
caifócietne
r mperaslircuyasvadictades-
vités constituyen una parte sustancial de su empresa han todo a
perder si algo es terriblemente falso, y no descuidarán pro-
probablemente no su división de certificados buscando oportunidades
potencialmente más lucrativas en otros lugares.
— Servicios ofrecidos: Como mínimo, su autoridad de certificación seleccionada
debería proporcionar un soporte para los métodos de revocación de lista de
certificados (CRL: Lista de Revocación de Certificados) y el protocolo de estado
de certificado en línea (OCSP: Protocolo de Estado de Certificado en Línea), con
una disponibilidad y rendimiento de red confiable. Muchos sitios
están satisfechos con los certificados validados por el dominio, pero deberías
también considere si necesita certificados de validación
debido (EV : Validación Extendida). En ambos casos, deberías tener
una elección de algoritmo de clave pública. La mayoría de los sitios web utilizan
RSA hoy, pero ECDSA puede volverse importante en el futuro en
razón de sus ventajas de rendimiento.
— Las opciones de gestión de certificados: Si necesita uno grande
nombre de certificats et que vous êtes dans un environnement complexe,
elija una autoridad de certificación que le dará buenas herramientas
para gestionarlos.
— Soporte: Elija una autoridad de certificación que le dará un
buen soporte si lo necesitas.
Nota: Para obtener mejores resultados, obtenga sus certificados en
el avance y al menos una semana antes de desplegarlos en la producción.
Esta práctica te ayuda a evitar las advertencias de certificado para algunos
usuarios que no tienen la hora correcta en sus computadoras y contribuyen a
evitar comprobaciones de revocación fallidas con las autoridades de certificación
que necesitan más tiempo para propagar nuevos certificados como

38
siendo válidos para sus respondedores OCSP. Con el tiempo, intente ampliar
este período de "calentamiento" de 1 a 3 meses. Del mismo modo, no espere hasta que
que sus certificados estén a punto de expirar para reemplazarlos. Al dejar
varios meses adicionales, también ayudaría a las personas cuyas
los relojes son incorrectos

5.2.5 Utilisation des algorithmes de signature de certificat

sólido
La seguridad del certificado depende de la fortaleza de la clave privada utilizada para firmar
el certificado y la fuerza de la función de hash utilizada en la firma.
Hasta hace poco, la mayoría de los certificados se basaban en la función de ha-
cambiar SHA1, que ahora se considera no seguro. Por lo tanto,
estamos en proceso de pasar a SHA256.
A partir de enero de 2016, no deberías poder obtener un certifi-
cat SHA1 ante una autoridad de certificación pública. Los certificados SHA1
los existentes continuarán funcionando (con advertencias en algunos na-
vigateurs), pero solo hasta finales de 2016.

5.3 Configuración
Con la configuración correcta del protocolo TLS en un servidor, usted asegura
que su información de identificación esté correctamente presentada a los visitantes
del sitio, que solo se utilizan primitivas criptográficas seguras
y que todas las debilidades conocidas están mitigadas.

5.3.1 Utilización de cadenas de certificados completas

En la mayoría de los despliegues, un solo certificado de un servidor es insuficiente.
fisant, se necesitan dos certificados o más para construir una cadena de
confianza completa. Un problema de configuración común se produce al
despliegue de un servidor con un certificado válido, pero sin todos los certificados
intermediarios necesarios. Para evitar esta situación, simplemente utilice todos
los certificados que le son proporcionados por su autoridad de certificación. Un certi-
Un certificado inválido hace que toda la cadena de certificados de un servidor sea inválida y provoca
advertencias del navegador. En la práctica, este problema a veces es dif-
difícil de diagnosticar porque algunos navegadores pueden reconstruir cadenas
incompletas y algunos no pueden. Todos los navegadores tienden a
almacenar en caché y reutilizar certificados intermedios.

5.3.2 Utilización de protocolos seguros

Existen cinco protocolos en la familia SSL/TLS: SSL v2, SSL v3, TLS
v1.0, TLS v1.1 y TLS v1.2 :

39
 — SSL v2 no es segura y no debe ser utilizada. Esta versión de
el protocolo es tan grave que puede ser utilizado para atacar claves
RSA y sitios con el mismo nombre incluso si están en servidores
entera y completamente diferentes (el ataque DROWN).
— SSL v3 es poco seguro cuando se utiliza con HTTP (el ataque POO-
DLE) y débil cuando se utiliza con otros protocolos. También es
Elemento obsoleto y no debe ser utilizado.
— TLS v1.0 es también un protocolo heredado que no debería ser utilizado.
lisée, pero aún es necesario en la práctica. Su principal debilidad
(BEAST) ha sido atenuado en los navegadores modernos, pero otros
los problemas persisten.
— TLS v1.1 y v1.2 son ambos sin problemas de seguridad conocidos, pero
solo TLS v1.2 proporciona algoritmos criptográficos modernos.
TLS v1.2 debería ser su protocolo principal ya que es la única versión
que ofrece un cifrado autenticado moderno (también llamado AEAD). Si
usted no soporta TLS v1.2 hoy, tiene una falta de
seguridad. Para atender a los antiguos clientes, deberá tomar en cuenta
nuer a asumir TLS v1.0 y TLS v1.1 por ahora. Sin embargo-
Dant, deberías retirar TLS v1.0 en un futuro cercano. Por ejemplo,
la norma PCI DSS exigirá todos los sitios que acepten pagos por
tarjeta de crédito para eliminar el soporte de TLS v1.0 antes de junio de 2018.
Actualmente se están realizando trabajos para diseñar TLS v1.3, cuyo objetivo
eliminar todas las funcionalidades obsoletas y no seguras y aportar
mejoras que permitirán asegurar nuestra comunicación durante
décadas siguientes.

5.3.3 Utilización de secuencias de cifrados seguros

Para comunicarse de manera segura, primero debe verificar que usted
comuníquese directamente con la parte deseada (y no a través de un
persona que escucha) y intercambiar datos de manera segura. En SSL/TLS
las suites de cifrado definen la manera en que se comunica de forma segura
se déroule. Ils sont composés de différents blocs de construction avec l’idée de sé-
curiser la diversité. Si l’un des blocs de construction se révèle faible ou instable,
deberías poder pasar a otro. Deberías contar principalmente
sobre las secuencias AEAD que proporcionan autenticación e intercambio de claves
fuerza, una confidencialidad persistente y un cifrado de al menos 128 bits.
Ciertas suites más débiles pueden seguir siendo soportadas, siempre que
que sean negociadas solo con clientes más antiguos que no se ocupan de
No hay nada mejor. Existen varias primitivas criptográficas obsoletas.
que deben ser evitadas:
— El Di ffie-Hellman anónimo (ADH) son secuencias que no proporcionan
una autenticación.
— Las secuencias de cifrado NULL que no proporcionan ningún cifrado.
Los conjuntos de cifrado de exportación no son seguros cuando están
se negocian en una conexión entre dos entidades, pero pueden

40
 también pueden ser utilizados contra un servidor que prefiere suites más fuertes
(el ataque FREAK).
Las secuencias con números bajos (típicamente de 40 y 56 bits) utilizan
un cifrado que puede romperse fácilmente.
— RC4 no es seguro.
— 3DES es lento y débil.
Utilice la configuración de la lista siguiente, diseñada para las claves RSA y ECDSA,
como punto de partida :
TLS_ECDHE_ECDSA_CON_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_CON_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_CON_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_CON_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_CON_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_CON_AES_256_CBC_SHA384
TLS_ECDHE_RSA_CON_AES_128_GCM_SHA256
TLS_ECDHE_RSA_CON_AES_256_GCM_SHA384
TLS_ECDHE_RSA_CON_AES_128_CBC_SHA
TLS_ECDHE_RSA_CON_AES_256_CBC_SHA
TLS_ECDH_ECDSA_CON_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_CON_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_CON_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_CON_AES_256_GCM_SHA384
TLS_DHE_RSA_CON_AES_128_GCM_SHA256
TLS_DHE_RSA_CON_AES_256_GCM_SHA384
TLS_DHE_RSA_CON_AES_128_CBC_SHA
TLS_DHE_RSA_CON_AES_256_CBC_SHA
TLS_DHE_RSA_CON_AES_128_CBC_SHA256
TLS_DHE_RSA_CON_AES_256_CBC_SHA256
Atención: Le recomendamos que primero pruebe su configuración
TLS en un entorno de puesta en escena, transfiera las modificaciones en
el entorno de producción solo cuando esté seguro de que todo
funcionan como se esperaba. Tenga en cuenta que lo anterior es una lista
genérico y que todos los sistemas (en particular los más antiguos) no son
compatibles con todos estos suites. Por eso es importante probar
Primero. La configuración anterior utiliza nombres de suites TLS estándar.
Ciertas plataformas utilizan nombres no estándar, por favor consulte la
documentación de su plataforma para más detalles. Por ejemplo, los nombres
de suite siguientes serían utilizados con OpenSSL :
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384

41
 ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

5.3.4 Selección de las mejores suites de cifrado

En las versiones del protocolo SSL v3 y versiones posteriores, los clientes
presentan una lista de suites de cifrado soportadas y los servidores eligen
una secuencia de la lista a utilizar para la conexión. No todos los servidores son
no son capaces de hacer eso correctamente, sin embargo, algunos seleccionarán la
primera suite atendida en la lista de suites del cliente. Los servidores que
seleccionar la mejor suite de cifrado disponible es esencial para
obtener la mejor seguridad.

5.3.5 Confidencialidad persistente

La confidencialidad persistente (a veces también llamada confidencialidad persistente
parfaite) es una función de protocolo que permite conversaciones seguras
que no dependen de la clave privada del servidor. Con las suites de cifrado
que no proporcionan la confidencialidad persistente, alguien que puede recibir
Perder la clave privada de un servidor puede descifrar todas las conversaciones cifradas
registradas anteriormente. Debe apoyar y preferir las secuencias ECDHE
a fin de permitir la confidencialidad persistente con los navegadores web mo-
Para apoyar una gama más amplia de clientes, también deberías
utilizar las suites DHE en alternancia después de ECDHE. Evite el intercambio de claves
RSA a menos que sea absolutamente necesario. Nuestra configuración predeterminada pro-
posee en la subsección 5.3.3 solo contiene secuencias que proporcionan una
confidencialidad persistente.

5.3.6 Utilización de intercambio de claves fuertes

Para el intercambio de claves, los sitios públicos generalmente pueden elegir entre
el intercambio de claves Diffie-Hellman (DHE) y su variante ECDHE. Existen otros
algoritmos de intercambio de claves, pero en general son inestables de una manera o
de otra. El intercambio de claves RSA sigue siendo muy popular, pero no proporciona
pas la confidentialité persistante. En 2015, un groupe de chercheurs ont publié
nuevas ataques contra DHE; Su trabajo es conocido como el ataque
de Logjam. Los investigadores han descubierto que los intercambios de claves DHE a baja
la resistencia (por ejemplo, 768 bits) puede ser fácilmente quebrada y que algunos

42
Los grupos DHE de 1024 bits conocidos pueden ser vulnerados por las agencias del Estado.
Para estar seguro, si despliega DHE, configúrelo con al menos 2048 bits de
seguridad. Algunos clientes más antiguos (por ejemplo, Java 6) podrían no
apoyar este nivel de fuerza. Por razones de rendimiento, la mayoría de
los servidores prefieren ECDHE, que es tanto más fuerte como más rápido. El secp256r1
(también llamada P-256) es una buena elección en este caso.

5.3.7 Atenuación de problemas conocidos

Ha habido numerosos ataques contra SSL y TLS en los últimos años,
pero en general no deberían concernirte si cuentas con
software actualizados y siguiendo los consejos de este capítulo. Sin embargo, nada es
perfectamente seguro, por eso es bueno mantener un ojo en lo que
se pase en seguridad. Aplicar rápidamente los parches de los proveedores si y
cuando estén disponibles, de lo contrario apoyarse en soluciones alternativas
para mitigar los riesgos.

5.4 Rendimiento
La seguridad es nuestro objetivo principal en este capítulo, pero debemos
también tener cuidado con el rendimiento
Un servicio seguro que no cumpla con los criterios de rendimiento será sin
ninguna duda abandonada. Con una configuración correcta, TLS puede ser bastante
rápido. Con los protocolos modernos, por ejemplo HTTP/2, podría incluso
ser más rápido que la comunicación en claro.

5.4.1 Evitación de demasiada seguridad

El establecimiento de un enlace (handshake) criptográfico, utilizado para establecer
serán conexiones seguras, es una operación para la cual el costo es alto-
La encriptación influenciada por el tamaño de la clave privada. El uso de una clave demasiado corta
es poco seguro, pero el uso de una clave demasiado larga resultará en una seguridad muy
elevada y un funcionamiento lento. Para la mayoría de los sitios web, use claves
RSA superiores a 2048 bits y ECDSA superiores a 256 bits, es un gas-
el saqueo del poder de la CPU puede perjudicar la experiencia del usuario. De
aunque, hay pocos beneficios en aumentar la fuerza del intercambio de claves efímeras
mères más allá de 2048 bits para DHE y 256 bits para ECDHE. No hay ningún
ventaja evidente de utilizar un cifrado superior a 128 bits.

5.4.2 Reanudación de la sesión de uso

La reanudación de la sesión es una técnica de optimización del rendimiento
que permite guardar los resultados de operaciones criptográficas costosas
y reutilizarlas durante un tiempo determinado. Un mecanismo de recuperación de sus-
una sesión inválida o no funcional puede introducir una penalización de rendimiento
significativo.

43
5.4.3 Utilización de la optimización WAN y HTTP/2
Estos días, los gastos generales de TLS no provienen de operaciones criptográficas.
gráficos hambrientos de la CPU, pero de la latencia de la red. el establecimiento
de una conexión TLS, que no puede comenzar hasta después de la finalización del establecimiento de una
la conexión TCP, requiere un nuevo intercambio de paquetes y será más costosa si
estás lejos del servidor. La mejor manera de minimizar la latencia es evitar
de crear nuevas conexiones, es decir, de mantener las conexiones existentes
abiertas durante mucho tiempo (keep-alives). Otras técnicas que proporcionan
buenos resultados incluyen el apoyo a protocolos modernos como HTTP/2
y el uso de la optimización WAN (generalmente a través de redes de distribución
bución del contenido).

5.4.4 Caché del contenido público

Durante la comunicación con SSL/TLS, los navegadores pueden suponer
que todo el tráfico es sensible. Generalmente utilizan la memoria para ocultar
ciertas recursos, pero una vez que cierras el navegador, todo el contenido
puede estar perdido. Para obtener una mejora en el rendimiento y permitir
el almacenamiento en caché a largo plazo de ciertos recursos, marque los recursos
publicar (por ejemplo, las imágenes) como público.

5.4.5 Utilización de aglomeración OCSP

La aglomeración OCSP es una extensión del protocolo OCSP que entrega
información de revocación en el marco del apretón de manos TLS, directamente desde
el servidor. En consecuencia, el cliente no necesita contactar los servidores
OCSP para la validación fuera de banda y el tiempo total de conexión TLS es
considerablemente reducido. La aglomeración OCSP es una técnica de optimización
Es un tema importante, pero debes saber que no todos los servidores web proporcionan
no hay implementaciones sólidas de aglomeración OCSP. Asociados a una autoridad
de certificación que tiene un respondedor OCSP lento o poco fiable, esos servidores web
peuvent créer des problèmes de performances. Pour de meilleurs résultats, si-
mulez las condiciones de fracaso para ver si podrían tener un impacto en
su disponibilidad.

5.4.6 Utilización de primitivas criptográficas rápidas

Además de proporcionar una mejor seguridad, nuestra configuración sobre la suite
de cifrado recomendada ofrece también las mejores prestaciones. En
En la medida de lo posible, utilice CPU que admitan el AES.
leído por el material. Después de eso, si realmente deseas otra ventaja de
rendimiento (probablemente no necesario para la mayoría de los sitios), considere
de utilizar las claves ECDSA.

44
5.5 Protocolo HTTP y la seguridad de las aplicacio-
iones
El protocolo HTTP y la plataforma circundante para la entrega de-
Las aplicaciones web continuaron evolucionando rápidamente después del nacimiento de SSL. A
la suite de cette évolution, la plate-forme contient maintenant des fonctionnali-
tés que se pueden utilizar para vencer el cifrado. En esta sección, nosotros
presentaremos estas funcionalidades, así como los medios para utilizarlas de manera segura
seguridad.

5.5.1 Chi ffrement de tout

El hecho de que el cifrado sea opcional es probablemente uno de los problemas
de seguridad. Vemos los siguientes problemas:
— Sin TLS en los sitios que lo necesitan.
— Los sitios que tienen TLS pero que no lo aplican.
— Sitios que mezclan contenido TLS y no TLS, a veces incluso en la
la misma página.
— Sitios con errores de programación que sufren TLS.
Aunque muchos de estos problemas pueden ser mitigados si sabe exactamente
tement ce que vous faites, le seul moyen de protéger de manière fi able la com-
La comunicación en el sitio web es de hacer cumplir el cifrado sin excepción.

5.5.2 Eliminación de contenido mixto

Las páginas de contenido mixto son aquellas que se transmiten por TLS, pero
incluyen recursos (por ejemplo, archivos JavaScript, imágenes,
ficheros CSS) que no se transmiten por TLS. Estas páginas no se
curisées. Un attaquant actif d’un homme dans le milieu (MITM : Homme au milieu)
Middle) puede desprenderse en un solo recurso JavaScript no protegido, por
ejemplo y desviar toda la sesión del usuario. Incluso si sigues los consejos
de la sección anterior y cifre todo su sitio web, siempre corre el riesgo de
recuperar ciertos recursos no cifrados desde sitios web de terceros.

5.5.3 Confianza de terceros

Los sitios web a menudo utilizan servicios de terceros activados a través del código JavaS-
cript descargado de otro servidor. Un buen ejemplo de tal servicio
est Google Analytics, qui est utilisé sur de grandes parties du web. Une telle
la inclusión de código de terceros crea una conexión de confianza implícita que da ef-
efectivamente a la otra parte un control total sobre su sitio web. El tercero puede
no ser malintencionado, pero los grandes proveedores de estos servicios son cada vez más
además considerados como objetivos. El razonamiento es simple: si un gran
el proveedor está comprometido, el atacante accede automáticamente a todos los sitios
que dependen del servicio. Si sigues los consejos de la sección 5.5.2, al menos

45
tus enlaces de terceros serán cifrados y, por lo tanto, estarán protegidos contra ataques MITM. Este-
pendant, deberías ir más lejos: aprender los servicios que utilizas y
eliminarlas, reemplazarlas por soluciones más seguras o aceptar el riesgo de
su utilización. Una nueva tecnología llamada integridad de sub-recurso (SRI:
integridad de subrecursos) podría ser utilizada para reducir la exposición potencial
a través de recursos de terceros.

5.5.4 Seguridad de las cookies

Para estar correctamente seguro, un sitio web requiere TLS, pero también todos
ses cookies sont explicitement marqués comme sécurisés lorsqu’ils sont créés.
La no securización de las cookies permite a un atacante MITM activo provocar
quieres información con trucos inteligentes, incluso en sitios 100%
chiffrés. Para obtener mejores resultados, considere agregar una validación de integridad
criptográfica o incluso un cifrado de tus cookies.

5.5.5 Compression de HTTP sécurisée

El ataque CRIME 2012 mostró que la compresión TLS no puede ser
implementada de manera segura. La única solución era desactivar totalmente
ment la compresión TLS. Al año siguiente, dos variantes más de ataque han
seguimiento TIME y BREACH centrados en los secretos en los cuerpos de respuesta HTTP
comprimidos mediante la compresión HTTP. A diferencia de la compresión
TLS, la compresión HTTP es una necesidad y no se puede desactivar.
Así, para resolver estos ataques, se necesitan modificaciones en el código de la aplicación
deben ser realizadas.
Las ataques TIME y BREACH no son fáciles de realizar, pero si qué-
que uno está suficientemente motivado para utilizarlos, el impacto es aproximadamente
equivalente a un ataque exitoso de falsificación de petición en sitios cruzados (CSRF).

5.5.6 Déploiement de HTTP StrictTransport Security

HTTP Strict Transport Security (HSTS) es una capa de seguridad para TLS.
Fue diseñado para garantizar que la seguridad siga intacta incluso en el caso de los
problemas de configuración y errores de implementación. Para activar la protección
tion HSTS, añades una nueva cabecera de respuesta a tus sitios web. Luego,
los navegadores que son compatibles con HSTS (todos los navegadores modernos a
(ese momento) lo aplican. El objetivo de HSTS es simple: después de la activación,
no permite ninguna comunicación no segura con el sitio web que lo utiliza. Él
alcanzar este objetivo convirtiendo automáticamente todos los enlaces en texto
Clair seguro. Además, también desactiva las advertencias de certificado.
haga clic (las advertencias de certificados son un indicador de un ataque MITM
activos). Estudios han mostrado que la mayoría de los usuarios hacen clic en estos
advertencias, por lo tanto, es de su interés nunca permitirlas. La adición
el soporte para HSTS es la mejora más importante posible para la sé-
seguridad TLS de sus sitios web. Los nuevos sitios siempre deberían ser diseñados

46
con HSTS en mente y los antiguos sitios convertidos para soportarlos tanto como
posible y tan pronto como sea posible. Para una mejor seguridad, considere usar el
pre-carga HSTS, que integra tu configuración HSTS en los navegadores
moderno, lo que hace que la primera conexión a su sitio sea segura.
El siguiente ejemplo de configuración activa HSTS en el nombre de host principal.
pal y todos sus subdominios por un período de un año, permitiendo
también la precarga:
Strict-Transport-Security : max-age=31536000 ; includeSubDomains ; pre-
cargar

5.5.7 Despliegue de la política de seguridad del contenido

La stratégie de sécurité de contenu (CSP :Content Security Policy) est un
mécanisme de sécurité que les sites Web peuvent utiliser pour restreindre le fonc-
Funcionamiento del navegador. Aunque fue diseñado inicialmente para tratar el Cross-Site
La elaboración de guiones (XSS), CSP evoluciona constantemente y admite las funcionalidades
tés que son útiles para mejorar la seguridad TLS. En particular, puede ser
utilizado para restringir el contenido mixto cuando se trata de sitios web de terceros, para
les cuales HSTS no los ayuda. Para implementar CSP para evitar el contenido
mezcla tercio, utilice la configuración siguiente :
Content-Security-Policy : default-src https : ’unsafe-inline’ ’unsafe-eval’ ;
conectar-fuente https : wss :
Nota: Esta no es la mejor manera de implementar CSP. Para proporcionar
un ejemplo que no cesa nada excepto el contenido mixto, tuvimos que desactivar algunos
funcionalidades de seguridad por defecto. Con el tiempo, a medida que usted las
apprendrez plus sur CSP, vous devriez modifier votre politique pour les ramener.

5.5.8 Almacenamiento en caché de contenido sensible

Todo el contenido sensible debe ser comunicado únicamente a las partes involucradas.
nacidos y tratados en consecuencia por todos los dispositivos. Aunque los proxies no
no ven el tráfico cifrado y no pueden compartir el contenido entre los
usuarios, el uso de plataformas de difusión de aplicaciones basadas en
el cloud está en aumento, por eso hay que tener mucho cuidado cuando
usted especifica lo que es público y lo que no lo es.

5.5.9 Consideración de otras amenazas

TLS está diseñado para abordar un solo aspecto de la confidencialidad de la seguridad
y la integridad de la comunicación entre ustedes y sus usuarios, pero existe
de muchas otras amenazas a las que debes hacer frente. En la mayoría
En caso de que sí, eso significa que su sitio web no tiene otras debilidades.

47
5.6Validación
Con muchos parámetros de configuración disponibles para los ajustes
Declaraciones, es difícil saber de antemano qué impacto tendrán algunos cambios
tendrán. Además, los cambios a veces se realizan accidentalmente.
Las actualizaciones de software pueden introducir modificaciones silenciosas
ment. Por esta razón, le aconsejamos que primero use una herramienta de eva-
luation SSL / TLS complet pour vérifier votre configuration afin de vous assurer
que comiencen de manera segura, luego periódicamente para asegurarse de
mantenerse seguro. Para los sitios web públicos, recomendamos la prueba del
servidor SSL Labs gratuito.

5.7 Conclusion
La parte de recomendaciones y buenas prácticas se ofrece a los auditores para que
de les aider pour une meilleure configuration SSL/TLS d’un serveur .

48
Conclusión y Perspectivas

Esta pasantía fue una oportunidad para enfocarse en el área de la seguridad.

rité informática. Nuestra misión tenía como objetivo realizar una herramienta de auditoría
sobre la configuración SSL/TLS de un servidor para permitir detallar los
protocolos soportados y las suites de cifrado. Después de un estudio profundo que
informe sobre las diferentes soluciones de código abierto disponibles del lado del cliente y del lado del servidor

servidor, hemos llegado a elegir el proyecto de código abierto sslyze gracias a su rapidez
dans la partie serveur et le projet sslhaf grâce à son exactitude dans la partie
cliente.
A raíz de esta experiencia y en respuesta a sus desafíos, nos gustaría próximamente
mejorar esta solución añadiendo nuevas funcionalidades como:
La gestión de las cuentas de los usuarios.
— El uso de la herramienta nmap que permite proporcionar el nivel de seguridad
de una serie de cifrado.
— La adición de pruebas de vulnerabilidades para los ataques más recientes.
— La adaptación de nuestra herramienta al protocolo TLS 1.3.

49
Bibliografía

[1][Link] (15Avril 2017)

[2][Link]
metodos-utilizados-por-defecto (24 de febrero de 2017)
[3][Link] 3 de marzo de 2017
[4][Link] de marzo de 2017)
[5][Link] (28 de abril de 2017)

[6][Link] (6 de marzo de 2017)

[7][Link] (20 de mayo
2017)
[8]T. Dierks; E. Rescorla (agosto de 2008). "La Seguridad de la Capa de Transporte (TLS)
Protocolo, Versión 1.2
[9]A. Freier; P. Karlton; P. Kocher (agosto de 2011). "La Capa de Sockets Segura
(SSL) Protocolo Versión 3.0

50