SSL

Secure Sockets Layer es un Protocolo orientado a la implementación de sesiones de

transporte seguras: Privacidad, Autenticación, Integridad y no Repudio.
Desarrollado por Netscape Corporation y RSA Data Security.
Típicamente utilizado con HTTP pero puede ser usado con cualquier tipo de servicio
que lo soporte ya que es independiente de la aplicación:
Servicios: correo con SMTP, POP3, IMAP4, etc.
Túneles VPN.
Trabaja entre la capa de aplicación y la capa Transporte del modelo OSI o TCP/IP.

Soportado por los principales Browsers y Servidores WEB: Internet Explorer, IIS,
Apache, etc.
El servidor SSL tiene varias versiones: *SSL 2 que autentica solo al servidor
*SSL3 que autentica cliente /servidor
Para las aplicaciones que requieren una conexión segura SSL la URL seria https:// ; y
por lo general el servidor escucha por el puerto 443 para SSL.
Las funcione que el protocolo SSL puede cumplir son las siguientes:
-autenticación
-integridad
-confidencialidad
-compresión
-fragmentación
SSL utiliza estos algoritmos:
SSL Utiliza las tecnologías de encriptación así:
*No encryption
*Stream Ciphers
-RC4 con claves de 40-bit
-RC4 con claves de 128-bit
*CBC Block Ciphers
-RC2 con claves de 40-bit
-DES con claves de 40-bit
-DES con claves de 56-bit
-riple-DES con claves de 168-bit
-Idea (con claves de 128-bit)
-Fortezza (con claves de 96-bit)
PROTOCOLOS SSL

Fases Del Handshake:

Las fases del handshake se utilizan para el intercambio de una serie de mensajes para
negociar la seguridad pero valga decir que todo esto es tranparente para nosotros:
Fase1: Selección del conjunto de algoritmos para mantener la confidencialidad y la
autenticación
Fase2: Intercambio de claves
Fase3: Creación de la clave de sesión
Fase4: Verificación del servidor
Fase5: Autenticación del cliente
Fase6: Indicación del inicio de la sesión segura.
Protocolo de registro record
Para transmitir los datos cifrados, el cliente y el servidor se ponen de acuerdo en el
formato en que van a enviar la información cifrada, este consenso lo realiza el
protocolo record.
Para cifrar los datos se apoya en los algoritmos acordados en el protocolo hanshake.
El protocolo record SSL es el encargado de la seguridad en el intercambio de los
datos, cifrando los protocolos que llegan de capas superiores como los son la capa de
Aplicacion del OSI y la subcapa Handshake.
Estos son los componentes del protocolo de registro (record):
-MAC-DATA: Código de autenticación del mensaje
-ACTUAL-DATA: Los datos de aplicaciones a transmitir
-PADDING-DATA: Los datos requeridos para rellenar el mensaje cuando se usa cifrado
por bloque
Durante una comunicación con SSL, se pueden abrir varias sesiones, y dentro de cada
sesión se puede mantener varias conexiones SSL. El manejo de la apertura o el cierre
de las conexiones se hace a través del protocolo handshake.
Existen dos tipos de estado:
-Estado de sesión
-Estado de conexión
Estado de sesión incluye estos componentes
-Identificador de sesión
-Certificado.
-Método de compresión
-Algoritmo de cifrado
-Clave maestra
-Flag de nuevas conexiones
El estado de conexión incluye estos componentes
-Números aleatorios del servidor y cliente.
-Número secreto del cliente para MAC.
-Número secreto del servidor para MAC
-Clave secreta del cliente
-Vectores iníciales (IV)
-Clave secreta del servidor
-Números de secuencia
CONFIGURACION SSL2 EN DEBIAN ETCH

Luego de instalar openssl y estar en la ruta /etc/ssl/crearemos un directorio llamado

CA y dentro de este directorio crearemos otros dos llamados certificados y privado.

El primero directorio (certificados) es donde se guardará una copia de cada certificado

que firmemos y en el otro directorio privado es en done se guardará la llave privada.

mkdir CA

listamos y nos fijamos que el directorio CA esta creado

ls CA

luego dentro de este directorio creamos los siguientes

mkdir certificados
mkadir privado

luego dentro de el directorio CA crear un par de archivos llamados (serial e index.txt)

que en conjunto formarán la base de datos de los certificados auto firmados.

El archivo 'serial' contiene el número de serie de nuestros certificados, como apenas

vamos a crear el primero su número de serie será 01, después de crearlo se
actualizará a 02 y así sucesivamente.

El archivo 'index.txt' será la base de datos propiamente en base al número de serie.

echo '01' > serial

echo > index.txt

a continuación mostramos el archivo de configuración que usaremos para configurar

ssl(copia el siguiente archivo dentro de CA con el nombre de openssl.cnf)
# *************************************************************************************
# www.linuxtotal.com.mx
# sergio.gonzalez.duran@gmail.com
#
# Archivo de configuracion para openssl
#
# ***** openssl.cnf ******

dir = . # variable que establece el directorio de trabajo

# seccion que permite convertirnos en una CA

# solo se hace referncia a otra sección CA_default
[ ca ]
default_ca = CA_default

[ CA_default ]
serial = $dir/serial # archivo que guarda el siguiente número de serie
database = $dir/index.txt # archvio que guarda la bd de certificados
new_certs_dir = $dir/certificados # dir que guarda los certificados generados
certificate = $dir/cacert.pem # nombre del archivo del certificado raÃz
private_key = $dir/privado/cakey.pem # llave privada del certificado raÃz
default_md = md5 # algoritmo de dispersión usado
preserve = no # Indica si se preserva o no el orden de los
# campos del DN cuando se pasa a los certs.
nameopt = default_ca # esta opcion y la siguiente permiten mostrar
# detalles del certificado
certopt = default_ca
policy = policy_anything # indica el nombre de la seccion
# donde se especifica que campos son
# obligatorios, opcionales y cuales deben ser
# iguales al certificado raÃz

# seccion de politicas para la emision de certificados

[ policy_match ]

countryName = optional # match, obligatorio

stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional # optional, campo opcional
commonName = supplied # supplied, debe estar en la petición
emailAddress = optional

# seccion de politicas para la emision de certificados

[ policy_anything ]
countryName = optional # match, obligatorio
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional # optional, campo opcional
commonName = supplied # supplied, debe estar en la petición

# seccion que indica como los certificados deben ser creados

[ req ]
default_bits = 1024 # tamaño de la llave, si no se indica 512
default_keyfile = key.pem # nombre de la llave privada
default_md = md5 # algoritmo de dispersión a utilizar
string_mask = nombstr # caracteres permitidos en la mascara de la llave
distinguished_name = req_distinguished_name # seccion para el nombre distinguido
(DN)
req_extensions = v3_req # seccion con mas extensiones que se añaden a la
# peticion del certificado

# seccion del nombre distinguido, el valor es el prompt que se vera en pantalla.

# datos del propietario del certificado.
# esta seccion define el contenido de datos de id que el certificado llevara.
[ req_distinguished_name ]
0.organizationName = Nombre de la organizacion
0.organizationName_default = jolman s.a
organizationalUnitName = Departamento o division
emailAddress = Correo electronico
emailAddress_max = 40
localityName = Ciudad o distrito
localityName_default = Medellin
stateOrProvinceName = Estado o provincia
stateOrProvinceName_default = Guanajuato
countryName = Codigo del pais (dos letras)
countryName_default = MX
countryName_min = 2
countryName_max = 2
commonName = Nombre comun (hostname o IP)
commonName_max = 64

# si en la linea de comandos se indica la opcion -x509,

# las siguientes extensiones tambien aplican
[ v3_ca ]
# indica que se trata de un certificado CA raÃz con autoridad para
# firmar o revocar otros certificados
basicConstraints = CA:TRUE

# especifica bajo que metodo identificar a la llave publica que sera certificada
subjectKeyIdentifier = hash

# especifica como identifcar la llave publica $authorityKeyIdentifier =

keyid:always,issuer:always

# extensiones de la opcion req

[ v3_req ]
basicConstraints = CA:FALSE # los certificados firmados no son CA
subjectKeyIdentifier = hash

[ v3_client ]
basicConstraints = CA:FALSE # los certificados firmados no son CA
#subjectKeyIdentifier = hash
extendedKeyUsage = clientAuth

# *************************************************************************************

Luego comprobamos en este punto (CA) lo que debes de tener el directorio

> ls -l
drwxr-xr-x 2 root root 4096 ene 26 13:23 certificados

-rw-r--r-- 1 root root 0 ene 26 13:24 index.txt

-rwxr--r-- 1 root root 4776 ene 26 2006 openssl.cnf

-drwxr-xr-x 2 root root 4096 ene 26 13:23 privado

-rw-r--r-- 1 root root 3 ene 26 13:23 serial

Todo esta casi listo para crear el certificado raíz, recordemos que estecertificado es el
que nos convertirá en una autoridad certificadora CA, nos pedira un password par que
la autoridad certificadora pueda firmar peticiones de certificados.

openssl req -new -x509 -extensions v3_ca -keyout privado/cakey.pem -out cacert.pem
-days 3650 -config ./openssl.cnf

Generating a 1024 bit RSA private key

....++++++

.......++++++

Writing new private key to 'privado/cakey.pem'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Nombre de la organizacion [jolman, S.A.]:

Departamento o division []:redes

Correo electronico []:admin@jolman.net

Ciudad o distrito [Leon]:

Estado o provincia [Guanajuato]:

Codigo del pais (dos letras) [MX]:

Nombre comun (hostname o IP) []:www.jolman.net

el comando que le dimos anterior da por resultado dos archivos:Un certificado raíz CA
(cacert.pem) y una llave privada (privado/cakey.pem)(La extensión ".pem" es de
Privacy Enhanced Message)

El archivo cacert.pem es el que se puede mandar a nuestros clientes o usuarios del

sistema, y que estos lo instalen o importen a su navegador, de esta manera
quedaríamos como una CA más válida para el navegador y cada vez que el cliente se
conecte a nuestro servidor, su navegador no mostraría el diálogo donde se pide si
aceptar la conexión segura o no.

Verifiquemos el contenido del archivo cacert.pem y el contenido de la llave privada

nano cacert.pem

nano privado/cakey.pem

En este punto, ya tenemos un certificado raíz que nos válida como CA, claro sin mas
autoridad que nuestro propio dominio pero podemos crear certificados no solo para
https, sino también spop, o simap o crear autentificación para vpn's a través de
aplicaciones como stunnel.

El siguiente procedimiento es crear una llave privada y una solicitud de certificado

openssl req -new -nodes -out jolman-cert.pem -config ./openssl.cnfGenerating a 1024

bit RSA private key

......................................................++++++

.......++++++

writing new private key to 'key.pem'

-----

You are about to be asked to enter information that will be incorporatedinto your
certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Nombre de la organizacion [jolman, S.A.]:

Departamento o division []:redes

Correo electronico []:admin@jolman.net

Ciudad o distrito [Leon]:

Estado o provincia [Guanajuato]:

Codigo del pais (dos letras) [MX]:

Nombre comun (hostname o IP) []:www.jolman.net

Lo último que nos pregunto es el nombre común (CN common name), aqui es
sumamente importante indicarlo igual a como esta el certificado raíz generado
previamente, como se trata de un servidor web, lo correcto es poner www.jolman.net

Lo anterior genera dos archivos:jolman-cert.pem = el certificate signing request (csr)

key.pem = la llave privada

verifiquemos el contenido de la solictud:

#> nano jolman-cert.pem

-----BEGIN CERTIFICATE REQUEST-----

MIIBwTCCASoCAQAwRjETMBEGA1UEChMKUGF0bywgUy5BLjENMAsGA1UEBxME

TGVvbjETMBEGA1UECBMKR3VhbmFqdWF0bzELMAkGA1UEBhMCTV

gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMMvo7xg3vmdlf/

38yA68uzNq2WYTtkyecuBnUgocOqDgc0Yl2hrfXN6lHl65kxeRFVdEBYh

GgA7JoISivuDTvWwVOIxmH5HOFzZlIPIZ3xThHCdWUKipXhcsVCTGV

+rbB1F9kkIAMrmtaNH2+Zj261jdB7eX960l1EqQaWt71dJAgMBAAGgOzA

5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYEFGVfA

/CDDXl6LQs1MH/XItqJl/8kMA0GCSqGSIb3DQEBBAUAA4GBAJH0sO7bR+

dJL67pxK5oEG9LPA2KcP+W7Vn5edpaLtUs/jYyvhQaCdSBxbMkV42nmt9DGD

5p5caTFk3M5guV9f087K+eYnUGILGQS51tXFcmYramZLETzs7nVfwGnXGsDG

yKDkG6VTkx46pzJrRTJfWBpWpo4FWg/Fi2l4E4PLv8

-----END CERTIFICATE REQUEST-----

Observe claramente que se trata de una solicitud de certificación (Certificate Request),

es decir que tiene que ser firmado por una autoridad certificadora CA que somos
nosotros mismos.

Por último firmaremos la solicitud que hicimos anteriormente para generar un

certificado autofirmado, para firmarlo necesitaremos indicar la contraseña que
autentifique que somos la CA y que por serlo tenemos la autoridad de autorizar (firmar)
certificados. (Para nuestro propio uso sslv2)

#> openssl ca -out certificado-jolman.pem -config ./openssl.cnf -days 3650 -infiles

jolman-cert.pem

Using configuration from ./openssl.cnf

Enter pass phrase for ./privado/cakey.pem:

Check that the request matches the signatureSignature ok

The Subject's Distinguished Name is as follows

organizationName :PRINTABLE:'jolmanS.A.'
organizationalUnitName:PRINTABLE:'redes'

localityName :PRINTABLE:'Leon'

stateOrProvinceName :PRINTABLE:'Guanajuato'

countryName :PRINTABLE:'MX'

commonName :PRINTABLE:'www.jolman.net'

Certificate is to be certified until Jan 26 00:10:10 2016 GMT (3650 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

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

certificado que firmemos será ese número.

#> nano serial

02

En el archivo index.txt el tercer campo indica 01, que es el número de seriepara el

certificado recien creado y muestra también los campos del DN.

#> nano index.txt

V 160126001010Z 01 unknown /C=MX/ST=Guanajuato/O=jolman, S.A./OU=redes/

CN=www.jolman.netEn 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

#> ls -l certificados

total 4

-rw-r--r-- 1 root root 2597 ene 27 18:10 01.pem

Y por último tenemos el certificado en si:

#> ls -l certificado-jolman.pem

-rw-r--r-- 1 root root 2597 ene 27 18:10 certificado-jolman.pem

Y podemos inspeccionarlo:

#> openssl x509 -in certificado-jolman.pem -noout -text –purpose

Instalando el certificado y la llave para ApacheTenemos entonces dos elementos ya

generados que necesitaremos para Apache: key.pem = llave privada ; certificado-
jolman.pem = certificado autofirmado

Hay algunas aplicaciones (no Apache) que requieren estos dos elementos en un solo
archivo, como en el caso de stunnel:
# > nano key.pem certificado-jolman.pem > key-cert-jolman.pem

Simplemente se concatenan los dos archivos en uno. Pero esto no es necesario para
el caso del servidor Web Apache. Lo que hay que hacer es copiar nuestros dos
archivos en un directorio, de hecho podrían quedarse donde están, es lo de menos,
pero por cuestión de orden y organización vamos a copiarlos a /etc/httpd/conf que en
la mayoría de distribucciones es el directorio de configuración del Apache.

NOTA IMPORTANTE: por ningún motivo los copies dentro del directorio raíz del
servicio de Apache como /var/www/html ya que podrías dejar expuestos los archivos a
todo el mundo y ser vulnerados.

#> cp key.pem certificado-ostau.pem /etc/httpd/conf/.

Una vez copiados los archivos, hay que crear un servidor virtual en Apache, esto
dentro del archivo de configuración httpd.conf, en algunas distribucciones como
Fedora y otras dentro de /etc/httpd/conf.d hay un archivo llamado ssl.conf que es
donde viene un servidor virtual ya creado, se puede tomar como plantilla.

VirtualHost 192.168.1.127:443

ServerName www.jolman.net

DocumentRoot /var/www/consulta

... (demás directivas del sitio)

SSLEngine on SSLCertificateFile /etc/httpd/conf/certificado-jolman.pem

SSLCertificateKeyFile /etc/httpd/conf/key.pem

VirtualHost

Como ya había mencionado antes, si quieres evitar que a tus clientes cada vez que
ingresen a tu sitio salga el molesto diálogo que pide aceptar el certificado, la única
solución es que distribuyas el archivo cacert.pem, recuerda que este archivo es el que
te identifica como una autoridad certificadora. Lo puedes poner a descarga desde tu
propio sitio, o mandarlo por correo, como sea. Cuando el cliente lo tenga en su equipo
deberá importarlo dentro del browser o navegador. Todos los navegadores en sus
preferencias o herramientas tienen una opción de certificados y desde ahí existe un
botón importar para realizar esto.

Pues eso es todo, si todo funcionó bien, tienes ahora un sitio con encriptación de
extremo a extremo y todo el tráfico viaja seguro. (sslv2)

sslv3

crear solicitud de certificado para ser firmado por otra CA

generamos la peticion y la clave dentro de /etc/ssl/CA

openssl req -new -out solicitudclient.pem -keyout privado/claveclient.pem -config

./openssl.cnf

firmar la peticion del cliente

openssl ca -out firmaclient.pem -config ./openssl.cnf -extensions v3_client -days 3650

-infiles solicitudclient.pem
pero antes agregamnos las siguientes lineas en el archivo openssl.cnf al final del
archivo

#nano /etc/ssl/CA openssl.cnf

[ v3_client ]

basicContraints = CA:FALSE

extendedKeyUsage = ClientAuth

guardamos la configuracion y luego editamos

#nano /etc/apache2/sites-available/default

y agregamos para que el certificado del cliente sea valido en el navegador

SSLCACertificateFile /etc/ssl/CA/cacert.pem

SSLVerifyClient require

ahora exportamos el certificado con un formato p12 para que el navegador lo

reconosca

openssl pkcs -export -in firmaclient.pem -inkey privado/claveclient.pem -certfile

cacert.pem -out cerclient.p12