Ssl
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Ssl as PDF for free.
More details
- Words: 1,728
- Pages: 15
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 premaestro 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 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
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 premaestro 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 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
