SSL

Secure Sockets Layer

Protocolo de Capa de Conexión Segura- (SSL) y Transport Layer Security
-Seguridad de la Capa de Transporte proporciona comunicaciones seguras por
una red, comúnmente Internet.

.SSL proporciona autenticación y privacidad de la información entre extremos

sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor
es autenticado (es decir, se garantiza su identidad) mientras que el cliente se
mantiene sin autenticar; la autenticación mutua requiere un despliegue de
infraestructura de claves públicas (o PKI) para los clientes. Los protocolos
permiten a las aplicaciones cliente-servidor comunicarse de una forma
diseñada para prevenir escuchas (eavesdropping), la falsificación de la
identidad del remitente (phishing) y mantener la integridad del mensaje.

SSL implica una serie de fases básicas:

• Negociar entre las partes el algoritmo que se usará en la comunicación

• Intercambio de claves públicas y autenticación basada en certificados
digitales
• Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos

criptográficos se van a usar. Las implementaciones actuales proporcionan las
siguientes opciones:

• Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital

Signature Algorithm) o Fortezza;
• Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption
Algorithm), DES (Data Encryption Standard), Triple DES o AES
(Advanced Encryption Standard);
• Con funciones hash: MD5 o de la familia SHA.

FUNCIONAMIENTO

Una conexión SSL siempre es iniciada por el cliente. Al principio de una sesión
SSL, se realiza un protocolo de enlace SSL. Este protocolo de enlace produce
los parámetros criptográficos de la sesión. Una visión general simplificada de
cómo se procesa el protocolo de enlace SSL se muestra en la figura a
continuación. En este ejemplo se supone que se está estableciendo la
conexión SSL entre un navegador Web y un servidor Web
1. El cliente envía el mensaje "hello" que lista las posibilidades
criptográficas del cliente (clasificadas por orden de preferencia del
cliente), como la versión de SSL, los grupos de programas de cifrado
soportados por el cliente y los métodos de compresión de datos
soportados por el cliente. El mensaje también contiene un número
aleatorio de 28 bytes.
2. El servidor responde con el mensaje "hello" del servidor que contiene
el método criptográfico (conjunto de programas de cifrado) y el método
de compresión de datos seleccionados por el servidor, el ID de sesión
y otro número aleatorio.

Nota:
El cliente y el servidor deben dar soporte como mínimo a un conjunto
de cifrado común; de lo contrario, el protocolo de enlace dará error.
Generalmente, el servidor elige el conjunto de programas de cifrado
común más potente.

3. El servidor envía su certificado digital. (El servidor utiliza certificados

digitales X.509 V3 con SSL.)
 Si el servidor utiliza SSL V3 y si la aplicación de servidor (por ejemplo,
el servidor Web) requiere un certificado digital para la autenticación de
cliente, el servidor envía el mensaje "digital certificate request". En el
mensaje "digital certificate request", el servidor envía una lista de los
tipos de certificados digitales soportados y los nombres distinguidos
de autoridades de certificación aceptables.

4. El servidor envía el mensaje "hello done" de servidor y aguarda una

respuesta del cliente.
5. Al recibir el mensaje "hello done" del servidor, el cliente (el navegador
Web) verifica la validez del certificado digital del servidor y comprueba
que los parámetros del mensaje "hello" del servidor son aceptables.

Si el servidor ha solicitado un certificado digital del cliente, el cliente

envía un certificado digital o, si no hay ningún certificado digital
adecuado disponible, el cliente envía la alerta "no digital certificate".
Esta alerta sólo es un aviso, pero la aplicación de servidor puede
hacer que la sesión sea anómala si la autenticación del cliente es
obligatoria.

6. El cliente envía el mensaje "client key exchange". Este mensaje

contiene el secreto pre-maestro, un número aleatorio de 46 bytes
utilizado en la generación de las claves de cifrado simétrico y las
claves de código de autenticación de mensajes (MAC), cifradas con la
clave pública del servidor.

Si el cliente ha enviado un certificado digital al servidor, el cliente

envía un mensaje "digital certificate verify" firmado con la clave
privada del cliente. Al verificar la firma de este mensaje, el servidor
puede verificar explícitamente la propiedad del certificado digital del
cliente.

Nota:
No es necesario un proceso adicional para verificar el certificado
digital del servidor. Si el servidor no tiene la clave privada que
pertenece al certificado digital, no podrá descifrar el secreto pre-
maestro y crear las claves correctas para el algoritmo de cifrado
simétrico y el protocolo de enlace dará error.

7. El cliente utiliza una serie de operaciones criptográficas para convertir

el secreto pre-maestro en un secreto maestro, del que se deriva todo
el material de clave necesario para el cifrado y la autenticación de
mensajes. A continuación, el cliente envía el mensaje "change cipher
spec" para que el servidor conmute al conjunto de programas de
cifrado recién negociado. El siguiente mensaje enviado por el cliente
(mensaje "finished") es el primer mensaje cifrado con este método y
estas claves de cifrado.
8. El servidor responde con mensajes propios "change cipher spec" y
"finished".
 9. El protocolo de enlace SSL finaliza y los datos de aplicación cifrados
se pueden enviar.

Certificados digitales y cadenas de confianza con SSL

Secure Sockets Layer V3 puede utilizar certificados digitales de servidor, así

como certificados digitales de cliente. Como se ha explicado anteriormente, los
certificados digitales de servidor son obligatorios para una sesión SSL,
mientras que los certificados digitales de cliente son opcionales, según los
requisitos de autenticación de cliente.

La infraestructura de clave pública (PKI) utilizada por SSL permite cualquier

número de autoridades de certificación raíz. Una organización o un usuario final
debe decidir cuáles son las CA que aceptará como de confianza. Para poder
verificar los certificados digitales de servidor, el cliente debe estar en posesión
de los certificados digitales de CA raíz utilizados por los servidores.

Si una sesión SSL está a punto de establecerse con un servidor que envíe un
certificado digital con el certificado digital de CA raíz que no esté definido en el
archivo de almacén de confianza del cliente, la sesión SSL no se establecerá.
Para evitar esta situación, importe el certificado digital de CA raíz al almacén de
claves o al almacén de confianza del cliente.

Si se utiliza la autenticación de cliente, el servidor requiere la posesión de los

certificados digitales de CA raíz utilizados por los clientes. Todos los
certificados digitales de CA raíz que no forman parte del almacén de claves de
servidor predeterminado deben instalarse utilizando el programa de utilidad
iKeyman antes de que estas CA emitan cualquier certificado digital de cliente.
Para obtener más información sobre iKeyman, consulte el apartado Gestión de
certificados digitales con iKeyman
INSTALACION DE SSL EN LINUX (DEBIAN)

Para empezar ya debemos tener previamente instalado y configurado, El

apache2 y el Bind9 iremos a nuestro navegador y veremos si estos si nos están
respondiendo bien.

Luego procederemos a instalar el paquete de Openssl

Ahora vamos al ssl y allí crearemos nuestro directorio privado el nuestro lo

llamaremos CA, (podremos ponerle el nombre que gustemos), después de
estar dentro de este crearemos dos directorios que se llamaran certificados y
privado, certificados será guardar nuestros certificados firmados y el privado
donde guardaremos nuestra llave privada.

Crearemos dos archivos dentro de nuestro directorio CA llamados serial e

index.txt estos serán la base de datos para los certificados autoafirmados,
siendo el index la base de datos para el número de serie.

Ahora nos dirigiremos al archivo de configuración de openssl que será el

openssl.cnf esta esta ubicado allí por defecto pero lo redirecionaremos a
nuestro directorio CA y allí modificaremos los siguientes parámetros si
queremos podremos hacer un backup de este por motivos de seguridad.

1 Lo redirecionamos de la siguiente forma

Luego iremos al openssl.cnf y solo modificaremos algunas cosas

Podremos listar para ver que todo este en orden
Crearemos El Certificado Raíz

Este nos identificara como una Autoridad certificadora y permitirá que podamos
firmar otros certificados, cuando lo generamos se crean dos archivo el
cacet.pem que es el que es el que enviaremos a nuestros cliente y el
cakey.pem que es el certificado privado nuestro y que nadie lo debe conocer
los generaremos de la siguiente manera, luego nos pedirá un pass phrase que
se recomienda sea complejo y luego unos cuantos campos como departamento
o división (que deseemos), correo electrónico (que deseemos), al final el
hostname que será nuestro dominio o ip, los otros campos los dejaremos en
blanco pues ya configuramos anteriormente en el openssl.cnf

Valides del certificado

Podremos ver el tiempo de validez del certificado raíz.

Solicitud de firmado de certificado

O dicho en otras palabras generaremos la petición del certificado raíz esta

también generara dos archivos como cacert.pem y cakey.pem y nos pedirá que
llenemos los campos anteriormente vistos, en esta debe ser fundamental poner
nuestro dominio en el campo de hostname ya que si no hacemos echáremos a
perderle trabajo, es recomendable que los campos se llenen como los del
certificado raíz.

Generaremos la petición de la siguiente forma

FIRMADO DE CERTIFICADO

Ahora firmaremos la petición que acabamos de crear, nos mostrara los

campos y nos preguntara si queremos firmarlo si estamos de acuerdo y (si) y lo
guardara en la base de datos y autoafirmarlo.

Se comprueba que ya aumento el número de serie a 02, es decir, el siguiente

certificado que firmemos será ese número.
En el archivo index.txt el tercer campo indica 01, que es el número de serie
para el certificado recién creado y muestra también los campos del DN.

En el directorio de certificados se guarda también con el correspondiente

número de serie (01.pem) un archivo que complementa la base de datos de
certificados que podemos ir creando.

Instalando el certificado y la llave para Apache

Iremos al apache al fichero sites-available/default y

Configuraremos el </virtualHost> que se encuentra en el final de la siguiente

manera nameVirtualHost: nuestro dominio, el virtual Host poniéndole el puerto
443 para el sitio seguro y en SSLCertificateFile: pondremos la ruta de nuestro
certificado firmado SSLCertificateKeyFile: la ruta de nuestro certificado privado.

Y no debemos olvidar comentar el puerto 443 en el fichero ports.conf

 Por ultimo cargaremos el modulo para apache y lo reiniciaremos.

Ahora accederemos desde nuestro navegador a nuestro sitio y nos arrojara el

certificado, elegiremos la opción de aceptar temporalmente y aceptar