Ssl En Debian Etch

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 # [email protected] # # 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 []:[email protected] 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 []:[email protected] 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 ; certificadojolman.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