Está en la página 1de 37

VPN con el protocolo SSL/TLS y OpenVPN

5 Nov 2013 | Rafa Morales | Comentarios: 0

Tener un servidor OpenVPN nos ofrecerá dos funcionalidades muy interesantes:

 Realizar conexiones seguras (encriptadas).


 Acceder a recursos internos de nuestra red local desde el exterior.

En el siguiente documento tenéis mucha más información sobre su funcionamiento (VPN remota con

OpenVPN y SSL).
Podéis comparar las características de OpenVPN con el resto de protocolos en el siguiente enlace:

http://es.giganews.com/vyprvpn/compare-vpn-protocols.html

Podemos configurar tres esquemas de trabajo diferentes. Utilizaremos la estructura de red de las siguientes

imágenes para explicar cada uno de dichos esquemas:

 Arquitectura Host-to-Net (mediante túnel).


 Arquitectura Host-to-Net (mediante bridge).
 Arquitectura Net-to-Net (mediante túnel).
Crear una autoridad certificadora y generar certificados con
easy-RSA

OpenVPN se basa en OpenSSL para implementar la criptografía SSL/TLS. Para ello tenemos dos opciones:

 Configurar una clave privada compartida.


 Configurar un certificado con el estándar X.509 basado en infraestructura de llave pública.

Para este tutorial utilizaremos la segunda opción, aprovechando que OpenVPN incorpora todo lo necesario

para hacerlo.

Antes que nada deberemos proceder a instalar OpenVPN en el servidor:

apt-get install openvpn


Después de la instalación, si nos dirigimos a la carpeta /usr/share/doc/openvpn/examples encontraremos

distintas carpetas con ejemplos de configuración, claves, scripts y lo que ahora nos ocupa, con la carpeta

easy-rsa, que nos ayudará a crear nuestra propia autoridad certificadora con RSA. Así que procederemos a

copiar esta carpeta de ejemplo a la ubicación que queramos para trabajar con ella:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/

NOTA: Los siguientes comandos los vamos a ejecutar siempre teniendo como directorio de trabajo

/etc/openvpn

El siguiente paso será editar el archivo vars llenándolo con nuestra información. Así que lo abrimos y

lo rellenamos con nuestros datos.

nano /etc/openvpn/vars

export KEY_COUNTRY="ES"

export KEY_PROVINCE="CORDOBA"

export KEY_CITY="Cordoba"

export KEY_ORG="SudoSu"

export KEY_EMAIL="info@ticarte.com"

export KEY_CN=Info

export KEY_NAME=Info

export KEY_OU=IT
Después de esto ya estamos listos para exportar los datos del archivo vars y crear dichas variables de

entorno. IMPORTANTE: ejecutarlo situados en el directorio de openvpn:

/etc/openvpn# source vars

Ahora ejecutaremos el script clean-all que se encargará de eliminar una posible carpeta de claves

anteriormente creada. IMPORTANTE: ejecutarlo situados en el directorio de openvn:

/etc/openvpn# ./clean-all

Hecho esto vamos a crear el par de claves de la propia Autoridad Certificadora (CA). Que nos preguntará

acerca de los datos configurados anteriormente:

/etc/openvpn/build-ca

Llegados aquí ya somos capaces de generar nuestros propios certificados firmados. Con ello

crearemos nuestro certificado para el servidor VPN (clave privada) y los parámetros Diffie-Hellman utilizados

para establecer la conexión SSL/TLS. Para el certificado del servidor ejecutamos lo siguioente, y se nos

preguntarán los mismos datos que en el momento de la generación de los certificados de la CA, con lo que

contestaremos con los datos deseados y seguiremos las instrucciones.

/etc/openvpn/build-key-server servidor

Ahora vamos con los parámetros Diffie-Hellman:

/etc/openvpn/build-dh
Y por último con la clave para cada uno de los usuarios que se conecten vía VPN. Y seguiremos los pasos

rellenando los campos que se nos pregunten.

/etc/openvpn/build-key cliente

Si ahora nos vamos a la carpeta /etc/openvpn/keys (o la que hayamos asignado en el archivo vars)

encontraremos un buen puñado de certificados y claves con distintos fines. Vamos ver qué nos interesa de

aquí para esta parte del tutorial:

 ca.crt: Este es el certificado público de la CA, que tendremos que usar en todos los clientes y en el
servidor.
 servidor.crt y servidor.key: Certificado público y privado respectivamente del servidor. Solo los
usaremos en el servidor.
 dh1024.pem: Los parámetros Diffie-Hellman que se ubicarán sólo en la carpeta de OpenVPN del
servidor.
 cliente.crt y cliente.key: Certificados público y privado de usuario que utilizaremos en los dispositivos
de dicho usuario.

Así que vamos a distribuir los distintos archivos en su sitio dentro del servidor:

cp /etc/openvpn/keys/ca.crt /etc/ssl/certs/SudoSu.crt

cp /etc/openvpn/keys/servidor.crt /etc/ssl/certs/

cp /etc/openvpn/keys/servidor.key /etc/ssl/private/

cp /etc/openvpn/keys/dh1024.pem /etc/openvpn/

NOTA: La ubicación de los certificados se puede configurar a mano en el archivo de configuración

correspondiente de OpenVPN que vamos a ver a continuación, pero los he copiado a los directorios donde se

suelen almacenar normalmente en el sistema.


Configuración Host-to-Net del servidor OpenVPN

Con el tema de los certificados solucionado ahora toca afrontar la configuración del servidor OpenVPN en si.

OpenVPN al arrancar, por defecto, intenta iniciar todas las conexiones VPN configuradas en los archivos

*.conf dentro de su directorio/etc/openvpn/.

Con su instalación, al igual que trae easy-RSA para no complicarnos mucho la vida con el tema de los

certificados, también trae una configuración por defecto sobre la que podremos trabajar. Lo primero que

haremos será copiar esta configuración a nuestro directorio de OpenVPN para trabajar sobre él y lo

descomprimimos:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz
/etc/openvpn/

gunzip /etc/openvpn/server.conf.gz

Existe dos maneras diferentes de configurar el servidor a la hora de asignar IPs y trabajar con las conexiones

de los clientes:

 Modo enrutamiento, túnel o ruted: En este caso el servidor creará una red nueva para las
conexiones VPN, diferente a las redes que se están usando tanto en el servidor como en los clientes, y
realizará un enrutamiento entre una red y otra. Conlleva habilitar el enrutamiento en el servidor si queremos
que el cliente conecte con el resto de la red (leer cómo habilitar el enrutamiento).
 Modo puente o bridged: En este caso el servidor otorgará una IP de una de sus redes locales
directamente, y tratará la conexión como si de un host más conectado al switch se tratara. Conlleva más uso
de recursos del equipo y de configuración.

El archivo /etc/openvpn/server.conf que hemos descomprimido nos servirá para realizar ambas

configuraciones. El archivo es bastante extenso pero está muy bien documentado, además incorpora una

configuración “out of the box” funcional, por lo cual comentaremos las opciones que se deben tocar para

funcione de manera básica.


Si elegimos la opción de enrutamiento, utilizando una red nueva, el fichero debe quedar de la siguiente manera:

# Tipo de interfaz que se creará

dev tun

# Los certificados anteriormente creados y ubicados

# El archivo "servidor.key" debería mantenerse en secreto

ca /etc/ssl/certs/SudoSu.crt

cert /etc/ssl/certs/servidor.crt

key /etc/ssl/private/servidor.key

# Parámetros Diffie-Hellman

dh /etc/openvpn/dh1024.pem

# Red que se asignará a la VPN

# El servidor tomará automáticamente la IP 1 de esa red

server 10.10.10.0 255.255.255.0

# Habilitamos a los clientes conectados para que puedan acceder a la


subnet interna

# mediante una ruta estática que se le creará al conectarse a la VPN


# o a cualquier otra red que se utilice en el destino

push "route 10.0.1.0 255.255.255.0"

Si elegimos la opción de puente, utilizando la misma red del servidor, el fichero debe quedar de la siguiente

manera (ATENCIÓN que hay que comentar líneas):

# Tipo de interfaz que se creará (comentar "dev tun")

# dev tun

dev tap0

# Los certificados anteriormente creados y ubicados

# El archivo "servidor.key" debería mantenerse en secreto

ca /etc/ssl/certs/SudoSu.crt

cert /etc/ssl/certs/servidor.crt

key /etc/ssl/private/servidor.key

# Parámetros Diffie-Hellman

dh /etc/openvpn/dh1024.pem

# Red que se asignará a la VPN (comentar)

# server 10.10.10.0 255.255.255.0


# Habilitamos a los clientes conectados para que puedan acceder a la
subnet interna

# mediante una ruta estática que se le creará al conectarse a la VPN


(comentar)

# push "route 10.0.1.0 255.255.255.0"

# Configuramos la IP que ya tiene el servidor, la máscara de red de esa


misma red,

# la IP inicial y final para definir un rango de donde otorgar


direcciones IP a los clientes.

# Tener en cuenta que ese rango no debe pertenecer al servidor DHCP que
haya en la red.

server-bridge 10.0.1.1 255.255.255.0 10.0.1.200 10.0.1.220

Si hemos elegido la configuración de enrutamiento, ya tendremos la parte de configuración del servidor

OpenVPN completa, ahora sólo nos falta reiniciar el servicio OpenVPN, lo que cargará todos los archivos *.conf

de la carpeta /etc/openvpn, con lo cual quedará creada nuestra interfaz tun0.

/etc/init.d/openvpn restart

Si hemos elegido la configuración en puente, SÓLO EN ESTE CASO, tendremos que preparar la interfaz

eth como interfaz br, para que permita el modo bridge. Para ello comenzamos instalando el paquete que permita

este modo de trabajo en el sistema:


apt-get install bridge-utils

Copiamos los scripts de inicio y parada del modo bridge. Estos ficheros ya tienen permisos de ejecución

asignados por defecto.

cp /usr/share/doc/openvpn/examples/sample-scripts/bridge-start
/etc/openvpn/

cp /usr/share/doc/openvpn/examples/sample-scripts/bridge-stop
/etc/openvpn/

Y configuramos el script de inicio, /etc/openvpn/bridge-start, con los parámetros de la red en la que deseemos

configurar el modo puente:

eth="eth1"

eth_ip="10.0.1.1"

eth_netmask="255.255.255.0"

eth_broadcast="10.0.1.255"

Iniciamos el modo puente ejecutando el script:

/etc/openvpn/bridge-start

La configuración del servidor OpenVPN ya estaría completa, ahora solo nos falta reiniciar el servicio

OpenVPN, lo que cargará todos los archivos *.conf de la carpeta /etc/openvpn, con lo cual quedará creada

nuestra interfaz br0 y tap0.

/etc/init.d/openvpn restart
Configuración Net-to-Net del servidor OpenVPN

En el caso anterior, el servidor nunca va a poder acceder a la subred del cliente, ya que no posee las rutas

necesarias para encaminar los paquetes a dicha red. En el caso de que quisiéramos conseguir dicho objetivo,

tendríamos que AÑADIR a la configuración sel servidor en modo Host-to-Net que se ha explicado

anteriormente, los siguientes parámetros.

Al fichero /etc/openvpn/server.conf le añadimos la siguiente configuración:

# Habilitamos que cada cliente pueda tener su propio fichero de


configuración personalizado

client-config-dir ccd

# Permite que los clientes se vean entre ellos

client-to-client

# Añadimos la ruta para que el servidor encuentre la red del cliente

route 10.0.2.0 255.255.255.0

push "route 10.0.2.0 255.255.255.0"

Creamos el directorio de configuración personalizada para los clientes:

mkdir /etc/openvpn/ccd

En dicho directorio tenemos que crear un fichero con el nombre igual que el "Common Name" que le pusimos

al certificado que generamos para el cliente:


touch /etc/openvpn/ccd/cliente

Y añadimos a ese fichero las siguientes líneas:

# La ruta que hay que añadir al servidor para alcanzar la red del cliente

iroute 10.0.2.0 255.255.255.0

# Las IPs fijas que queramos asignar al cliente (opcional)

ifconfig-push 10.10.10.61 10.10.10.62

Se necesita repetir varias veces la ruta porque una indica la ruta al paquete desde el kernel a OpenVPN, y

otra desde OpenVPN al kernel.

Sólo nos quedará reiniciar el servicio en el servidor y volver a lanzar la conexión VPN en el cliente.

Configuración del cliente VPN

La instalación del cliente OpenVPN en GNU/Linux guarda muchas similitudes con la de la parte servidor, de

hecho el paquete que instalaremos será exactamente el mismo. La configuración del cliente es independiente

de si en el servidor se utiliza el modo de enrutamiento o el modo puente, sólo modificando un parámetro como

veremos a continuación.

Previamente, necesitaremos poseer los siguientes certificados necesarios para la conexión SSL/TLS:

 Clave pública de la CA: SudoSu.crt.


 Clave pública de usuario: cliente.crt.
 Clave privada de usuario: cliente.key.

Los certificados los ubicaremos igual que en el anterior tutorial:

cp /directorio_con_certificados/SudoSu.crt /etc/ssl/certs/
cp /directorio_con_certificados/cliente.crt /etc/ssl/certs/

cp /directorio_con_certificados/cliente.key /etc/ssl/private/

Instalamos OpenVPN con el gestor de paquetes:

apt-get install openvpn

Como se dijo en el artículo de la parte servidor el comportamiento de OpenVPN por defecto es el de cargar

todos los archivos *.conf de su directorio /etc/openvpn al ejecutarse el servicio. Si no quisiéramos este

comportamiento, editaríamos el archivo de configuración de OpenVPN para que la conexión sólo se

establezca cuando se le solicite.

nano /etc/default/openvpn

Y descomentamos la línea:

AUTOSTART="none"

Lo siguiente que haremos es copiar el archivo de configuración de cliente de ejemplo que podemos

encontrar en el directorio de documentación del programa al directorio de trabajo del mismo.

Podemos copiar el fichero con diferentes nombres, uno para cada una de las conexiones VPN que queramos

lanzar desde el equipo.

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf \

/etc/openvpn/conexion.conf
Aquí básicamente deberemos configurar tres cosas: la dirección de nuestro servidor OpenVPN, la ruta hacia los

certificados anteriormente citados y forzar que todo el tráfico se envíe a través de la VPN.

# Tipo de interfaz que se creará

# tun para enrutamiento, tap para puente (elegir una u otra)

# dev tap

dev tun

# Nombre o dirección IP del servidor, y el puerto

remote servidor.com 1194

# Ruta de los certificados

ca /etc/ssl/certs/SudoSu.crt

cert /etc/ssl/certs/cliente.crt

key /etc/ssl/private/cliente.key

Si queremos lanzar manualmente la conexión VPN al servidor, ejecutaremos el siguiente comando. Podemos

lanzarlo en segundo plano si queremos seguir utilizando la misma terminal en la que estamos trabajando. Si la

lanzamos en primer plano la cancelaremos con Ctrl+C, pero si la lanzamos en segundo plano la cancelaremos

con el comando kill y su PID (leer más sobre procesos).

openvpn /etc/openvpn/conexion.conf &

Lo que debería acabar dándonos el siguiente mensaje por pantalla:


Initialization Sequence Completed

En el momento en el que esto pase ya estará establecida la VPN. Para comprobarlo podemos hacer ping a la

IP por defecto que hayamos asignado al servidor en la interfaz tun0 o tap0:

ping 10.10.10.1

Registro de sucesos y errores

Podemos consultar todos los sucesos y errores de OpenVpn en el siguiente archivo de registro por defecto:

cat /var/log/syslog

Basado en los artículos de http://sobrebits.com y http://tuxjm,net.


Características protocolos VPN
(OpenVPN, SSTP, L2TP,
IKEv2 y PPTP)
Que no se te escape nada de seguridad y descubre las características de los diferentes
protocolos de VPN que podemos encontrar.
Escrito por Jenifer Castellano oct 16 2017 17:15










Una de las tecnologías más usadas hoy en día por razones de seguridad,
conectividad y sencillez de uso es la VPN (Virtual Private Network -Red Privada
Virtual) la cual, gracias a su diseño, nos permite definir diversas formas de
conectividad ya sea a nivel de hogar o a nivel corporativo.

Qué es una VPN


Una VPN, es una tecnología de red la cual se implementa para conectar uno o más
equipos a una red privada a través de Internet.

Al usar VPN, las empresas permiten que sus empleados se conecten de forma remota
desde sus casas o diversos lugares como si estuvieran físicamente allí y así tener la
oportunidad de acceder a los recursos corporativos de forma simple.

Al usar una red VPN todo el tráfico de red sigue partiendo desde el dispositivo hacia
nuestro proveedor de Internet, pero de ahí se dirige directo al servidor VPN, desde
donde partirá al destino lo cual implementa la seguridad y la posibilidad de navegar de
forma oculta. Lo vemos más sencillo en la siguiente imagen de Microsoft:
Algunas de las ventajas que tenemos al implementar y usar una red VPN son:
 Evitar censura y bloqueos geográficos de contenido para algunos sitios.
 Mayor nivel de seguridad al usar diversos tipos de protocolo.
 Capacidad de realizar descargas P2P.
 Facilidad de conexión y desconexión.
 Funciona con todas las aplicaciones.

Ahora, Solvetic analizará los diversos protocolos disponibles para la conexión VPN.

Un protocolo de VPN determina exactamente cómo se han de enrutar los datos entre
nuestro equipo y el servidor VPN. Los protocolos tienen especificaciones diferentes,
las cuales ofrecen beneficios a los usuarios en una variedad de circunstancias de este
modo, algunos priorizan la velocidad, y otros se centran en la privacidad y la
seguridad.

Protocolo OpenVPN
OpenVPN es un protocolo VPN de código abierto siendo catalogado como uno de los
más importantes en la actualidad.

OpenVPN ha sido desarrollado como una solución de software VPN enfocada en el


túnel de red completamente equipado el cual integra capacidades de servidor
OpenVPN, capacidades de administración empresarial, paquetes de software de
OpenVPN Connect UI y OpenVPN Client simplificados los cuales pueden ser usados
en entornos Windows, MAC, Linux, Android e iOS.

Con OpenVPN contamos con una amplia gama de configuraciones, en las cuales
incluimos el acceso remoto seguro y granular a la red interna y/o los recursos y
aplicaciones de la red de la nube privada con control de acceso de grano fino.

OpenVPN permite a los usuarios proteger sus datos mediante el cifrado de clave
AES-256 bits (entre otros), esencialmente irrompible, con autenticación RSA de 2048
bits y algoritmo hash SHA1 de 160 bits.

Características de OpenVPN
Dentro de sus principales características encontramos:
 Es un protocolo multiplataforma.
 Cuenta con el modo multi-cliente.
 Es portable.
 Cuenta con el modo multi-acceso.
 Posee control de acceso el cual permite o deniega a usuarios o grupos el
acceso granular a la red.
 Implementación dinámica de aplicaciones mediante la cual será posible el
despliegue y ejecución dinámica cualquier aplicación.
 Soporta diversos métodos de autenticación dentro de los cuales tenemos PAM,
LDAP, RADIUS, y Local DB.
 Altos niveles de escalabilidad la cual permite tener de 1000 a 100.000 VPN
concurrentes por sesiones y conexiones.
 Alta disponibilidad.
 Permite generar diversos reportes de estadística.
 Es flexible con la configuración DMZ.
 Dispone de múltiples niveles de seguridad.

Protocolo L2TP/IPSec

El Protocolo de Layer 2 Tunneling Protocol (L2TP) es un protocolo de túnel usado


para soportar la red virtual privada, VPN, o como parte de un servicio de entrega por
ISPs. No provee ningún servicio de encriptación o confidencialidad en si razón por la
cual los servicios que hacen uso de L2TP incluyen con frecuencia protocolos de
seguridad IPSec.

Recordemos que L2TP es el sucesor del PPTP depreciado, el cual fue desarrollado
por Microsoft y L2F, desarrollado por Cisco.
Una vez se implementa L2TP/IPSec se convierte en una de las conexiones VPN más
seguras disponibles actualmente.

L2TP/IPSec hace uso del cifrado AES-256 bit y no tiene vulnerabilidades conocidas.

Dentro de sus ventajas podemos mencionar que es más seguro que PPTP. A nivel de
desventajas tenemos que puede ser más lento que OpenVPN y en algunos casos
puede ser bloqueado por reglas específicas de firewall.

Protocolo SSTP
SSTP (Secure Socket Tunneling Protocol) es un protocolo VPN que se ha integrado
completamente con todos los sistemas operativos de Microsoft desde Windows Vista
Service Pack 1 hasta los actuales Windows 10 lo cual permite usar SSTP con
Winlogon o, si deseamos mayor seguridad, un chip inteligente. Además, muchos
proveedores de VPN cuentan con instrucciones específicas de Windows SSTP
integradas disponibles.

SSTP hace uso de certificados SSL/TLS de 2048 bits para la autenticación y claves
SSL de 256 bits para el cifrado lo cual lo convierte en un protocolo bastante seguro.

Este protocolo SSTP ofrece un túnel cifrado mediante el protocolo SSL/TLS, de modo
que cuando un cliente establece una conexión VPN basada en SSTP, primero se
establece una conexión TCP con el servidor SSTP a través del puerto TCP 443, el
protocolo de enlace SSL/TLS se produce a través de esta conexión TCP.

Posterior a esto, después de la negociación exitosa de SSL/TLS, el cliente envía una


solicitud HTTP con codificación de longitud de contenido y una gran longitud de
contenido en la conexión protegida con SSL y allí el servidor devuelve una respuesta
HTTP con el estado HTTP_STATUS_OK.

Características SSTP
Algunas de sus principales ventajas son:
 Permitir la delimitación de tramas PPP a partir de la transmisión continua de
datos que se envía utilizando HTTPS.
 Negociar los parámetros entre dos entidades.
 Realiza operaciones de seguridad para evitar que un atacante en el medio
transmita frames de PPP de manera inapropiada sobre SSTP.
 Los paquetes de control de SSTP contienen mensajes para negociar
parámetros y para garantizar que no exista un elemento de confianza en el
medio.
Protocolo IKEv2

IKEv2 (Internet Key Exchange versión 2) es un protocolo VPN desarrollado en


conjunto por Microsoft y Cisco. IKEv2 de forma individual es solo un protocolo de
túnel, que proporciona una sesión segura de intercambio de claves por lo cual IKEv2
se empareja frecuentemente con IPSec para el cifrado y la autenticación de la
información gestionada.

Uno de los principales usos de IKEv2 es a nivel de soluciones de VPN móvil ya que es
bastante útil y dinámico en volver a conectar durante los momentos de pérdida
temporal de conexión a Internet, así como durante un cambio de red (desde Wi-Fi a
datos móviles, por ejemplo).

IKEv2 es un protocolo patentado, con compatibilidad nativa para dispositivos con


Windows, iOS y Blackberry. Las implementaciones de código abierto están
disponibles para Linux, y la asistencia de Android está disponible a través de
aplicaciones de terceros.

Los cifrados usados para generar las claves Phase1 son AES-256-GCM para cifrado,
junto con SHA2-384 para garantizar la integridad, combinado con PFS (Perfect
Forward Secrecy) con claves.

Protocolo PPTP
PPTP (Point-to-Point Tunneling Protocol - Protocolo de Túnel Punto a Punto), es uno
de los protocolos VPN más antiguos pero aún está en uso en algunos lugares, pero la
mayoría de los servicios se han actualizado a protocolos más rápidos y más seguros.

El protocolo PPTP opera en el puerto TCP 1723 y es un estándar en todas las


versiones de Windows desde entonces. PPTP fue desarrollado gracias a una iniciativa
de Microsoft con el fin de encapsular otro protocolo llamado PPP (Protocolo Punto a
Punto).

PPTP ofrece las mejores velocidades de conexión, precisamente debido a la falta de


características de seguridad (en comparación con los protocolos modernos) siendo
una de sus principales ventajas.

Así hemos visto que las conexiones VPN nos ofrecen alternativas prácticas para todo
lo relacionado con la seguridad, velocidad e integridad de los datos allí generados.

¿En qué protocolos se basan las


soluciones VPN hoy por hoy?
Productos
Panda GateDefender Integra 100
Panda GateDefender Integra 300

A continuación se describen los protocolos en los que se basan las soluciones VPN más
destacadas del mercado actual:
 PPTP (Point-to-Point tunneling protocol): Protocolo de red que permite
la realización de transferencias desde clientes remotos a servidores
localizados en redes privadas, empleando tanto líneas telefónicas
conmutadas como Internet. PPTP es una extensión de PPP que soporta
control de flujos y túnel multiprotocolo sobre IP. Implementado
principalmente por Microsoft, este protocolo funciona en la capa de
enlace (Link layer) de modelo OSI, lo que le permite, una vez
establecida sesión PPTP, pasar encriptados tanto frames IPX como IP ó
AppleTalk. Para la encriptación utiliza las llaves generadas por MS-
CHAP, MS-CHAP versión 2 o EAP-TLS, protocolos de autenticación. El
protocolo de la capa de enlace se puede utilizar en NAT en los
cortafuegos corporativos.
 L2TP (Layer 2 Tunneling Protocol): Resuelve los problemas de
interoperatividad entre los protocolos PPTP y L2F. Tiene
características de ambos protocolos. Permite crear el túnel en nivel de
enlace, de forma que los paquetes IP, IPX y AppleTalk enviados de
forma privada puedan ser transportados por Internet. Como carece de
mecanismos de encriptación y autenticación para seguridad de los
datos, se apoya en L2TP/IPSec, lo que le hace vulnerable a NAT, por lo
que las implementaciones que incluyen este protocolo tienen que
utilizar el mecanismo NAT-T (NAT transversal).
 IPSec (IP Secure): Protocolo de seguridad que permite el intercambio
seguro de paquetes en la capa de red (Network Layer) de modelo OSI,
garantizando la protección del enlace entre un dispositivo y la red. Es el
protocolo equipado con los mejores mecanismos de encriptación
ofreciendo máxima integridad, autenticación, control de acceso y
confidencialidad para el envío de paquetes IP por Internet. Como se
trata de un protocolo de capa 3, está limitado a los protocolos IP. La
combinación de IPSec con L2TP, se puede utilizar para el transporte de
prácticamente cualquier protocolo. Para resolver problemas de
traslado de las direcciones IP (NAT), este protocolo utiliza los
mecanismos NAT-T (NAT transversal). Por ello, aunque la configuración
de una red VPN basada en IPSec resulta más compleja, se trata
indiscutiblemente del protocolo más seguro.
 SSL (Secure Socket Layer): Protocolo de seguridad que salvaguarda los
accesos a la información que circula por los protocolos de Internet
(HTTP, SMTP, FTP, etc.) cifrando los datos de forma simétrica. El acceso a
esos datos sólo será posible si se posee la clave correcta. Este
protocolo funciona en la capa de aplicación.

Ayuda nº- 20070702 31425 ES

Buenas prácticas TLS / SSL


RUBEN.RAMIROJULIO 16, 2017

Share this article


 Fac ebook

 Twitter

 Google+

 Linkedin

 Pinterest

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").

Share this article