HOW-TO OpenSSL

Comenzaremos instalando una entidad certificadora:

1.Se instala openssl

#apt-get install openssl

2.Crear los siguientes directorios dentro de el directorio /etc/ssl/
certificadora/
certificadora/certs
certificadora/private
certificadora/newcerts
certificadora/crl
*”certificadora/” es un nombre de directorio que puede variar según el criterio de quien configure la entidad en contraste los subdirectorios de la misma deben tener los nombres señalados en este how-to.

#mkdir -p /etc/ssl/certificadora/certs
#cd etc/ssl/certificadora/
#mkdir private newcerts crl

3.luego de esto ingresamos al archivo de configuracion del openssl /etc/ssl/openssl.cnf

#pico /etc/ssl/openssl.cnf

4.en el archivo (/etc/ssl/openssl.cnf) encontraremos las siguientes lineas (los numeros en negrilla son el numero de cada linea en el archivo):

37 dir = /etc/ssl/certificadora
38 certs = /etc/ssl/certificadora/certs
39 crl_dir = /etc/ssl/certificadora/crl
40 database = /etc/ssl/certificadora/index.txt
43 new_certs_dir = /etc/ssl/certificadora/newcerts
45 certificate = /etc/ssl/certificadora/pub.crt
46 serial = /etc/ssl/certificadora/serial
50 private_key = /etc/ssl/certificadora/private/priv.key
68 default_days = 365 # dias en que caduca el certificado

5.Por ultimo generamos un certificado para nuestro CA (entidad certificadora).

#openssl req -nodes -new -keyout midominio.key -out midominio.csr

Luego lo firmamos

#openssl ca -out midominio.crt -in midominio.csr


Con esto tenemos lista la entidad certificadora y estamos listos para comenzar a firmar certificados.

Generar Certificados De Cliente:

El certificado se crea desde el equipo cliente de la siguiente manera

$openssl req -x509 -newkey rsa:2048 -keyout cakey.pem -days
365 -out cacert.pem

* Con este comando ademas de generar el certificado tambien generamos las llaves publica y privada del servidor, si ya tienes tus llaves omite la parte -newkey rsa:2048 de esta manera solamente generara el certificado.

solo falta enviarlo a la entidad certificadora nosotros para hacer esto utilizamos ssh:

$scp cacert.pem root@[aqui la ip de el CA]:/tmp

para hacer esto se necesita tener pasword de root, en caso de que no seas el adminisrtador de la entidad certificadora y no tengas contraseña de root por obvias razones puedes pasar tu certificado con otro usuario para esto le dises al administrador de el CA te cree un usuario y lo copias de la siguiente manera

ejemplo

$scp cacert.pem miuser@[aqui la ip de el CA]:/home/miuser

ya solo falta que la CA (entidad certificadora) firme el certificado (valga la redundancia) y nos devuelva el certificado ya firmado.


Firma De Certificados Por La Entidad Certificadora

Despues de generar los certificados como cliente es necesario que una entidad certificadora los firme.
El certificado que vamos a firmar es el mismo que generamos en el ejemplo anterior cacert.pem.

El comando para firmar es facil:

#openssl ca -out certfirmado.crt -in cacert.pem

La interpretacion tambien es sencilla, simplemente le dijimos a la entidad certificadora que tome el certificado cacert.pem, lo firme y lo exporte a un certificado nuevo en este caso llamado certfirmado.pem el cual seria el certificado ya firmado y el que habria que instalar en nuestro sitio web.



Integrar OpenSSL Con Un Servidor Web

Ahora solo queda integrar openSSL con nuestro servidor web, para la prueba utilizaremos apache 2.6 (obviaremos la instalacion y configuracion del apache asi que daremos por hecho que ya tienes configurado tu servidor web).

Teniendo en cuenta que ya tu servidor web esta corriendo y puedes acceder a el normalmente procederemos a agregarle la seguridad SSL, para esto agregamos las siguientes lineas en el archivo /etc/apache2/sites-available/default:

NameVirtualHost *:443
ServerAdmin sgarcia@misena.edu.co
DocumentRoot /var/www/
SSLEngine on
SSLCertificateFile /etc/ssl/certfirmado.crt [ruta del certificado firmado]
SSLCertificateKeyFile /etc/ssl/cakey.pem [ruta de la llave privada creada] anteriormente
ServerName mypage.mydomain.com
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

Ahora debemos cargar los modulos de SSL en Apache

#a2enmod

Lo que sigue ahora es iniciar el Apache con SSL

#/etc/init.d/apache2 force-reload (Con este comando forzamos a Apache a cargar los modulos de SSL)

Ahora podemos proceder a probar si aun tenemos acceso normalmente a nuestro sitio web y notaran que se puede acceder tanto con HTTP como con HTTPS, pero al ingresar con este nos saca un aviso que nos dice que la pagina web solicitada tiene un certificado firmado por una entidad desconocida y pide autorizacion del usuario para ingresar.
Para que esto no suceda mas debemos instalar el certificado de la entidad certificadora en nuestro navegador.
En Mozilla Firefox se hace de la siguiente manera:
Editar
Preferencias
Avanzado
Cifrado
Ver certificados
Autoridades
Importar
Despues de esto podremos ingresar normalmente a la pagina con HTTPS.

© 2008, Stiven Garcia, Andres Uran, Andres Ruiz, Ferney Martinez
Este how-to Esta licenciado bajo los terminos de creative commons

Noticia:Ubuntu gana a Windows XP en rendimiento multitarea

Existen varias aplicaciones que están disponibles indistintamente para Linux y para Windows, y un usuario tuvo la feliz idea de comparar sus rendimientos en ambos sistemas operativos. Los resultados, sorprendentes (o no): Ubuntu superó a Windows XP en buena parte de las pruebas.
Las pruebas se realizaron en la misma máquina en la que estaban instalados Ubuntu 8.04 y Windows XP SP3, las ediciones más recientes de ambas alternativas en las que se ejecutaron una serie de aplicaciones que están disponibles en ambos sistemas operativos.
Las aplicaciones elegidas eran en su inmensa mayoría -con toda lógica- aplicaciones Open Source como Blender, avidemux, el compresor RAR en modo consola de comandos o la utilidad de antivirus ClamA. Mientras que Windows XP ganó a Ubuntu en aplicaciones relacionadas con temas multimedia, Ubuntu superó a su rival en aplicaciones con una entrada/salida intensiva.
Y de hecho, en un test especial en el que ejecutó varias aplicaciones al mismo tiempo para ver qué tal era la gestión de la multitarea en ambas alternativas se demostró que Ubuntu se comportaba de una forma muy superior a Windows XP. Las pruebas se realizaron en las mismas condiciones, salvo por el hecho de que Windows XP estaba instalado en un disco SATA y Ubuntu en uno IDE. Eso hace aún más curioso el hecho de que Linux ganase en aplicaciones con un alto manejo de operaciones de entrada/salida.

contenido tomado de www.linuxpreview.org

IPsec

IPsec es una extensión al protocolo IP que proporciona seguridad a IP y a los protocolos de capas superiores. Fue desarrollado para el nuevo estándar IPv6 y después fue portado a IPv4.

IPsec emplea dos protocolos diferentes - AH y ESP - para asegurarla autenticación, integridad y confidencialidad de la comunicación. Puede proteger el datagrama IP completo o sólo los protocolos de capas superiores. Estos modos se denominan, respectivamente, módo túnel y modo transporte. En modo túnel el datagrama IP se encapsula completamente dentro de un nuevo datagrama IP que emplea el protocolo IPsec. En modo transporte IPsec sólo maneja la carga del datagrama IP, insertándose la cabecera IPsec entre la cabecera IP y la cabecera del protocolo de capas superiores.

MODOS DE IPsec:

Modo transporte:
en el modo transporte (los datos que se transfieren) del paquete IP es cifrada y/o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticación (AH), las direcciones IP no pueden ser traducidas, ya que eso invalidaría el hash. Las capas de transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador.

Modo tunel:
En el modo tunel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado y/o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo tunel se utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre internet.




La familia de protocolos IPsec está formada por dos protocolos: el AH (Authentication Header - Cabecera de autenticación) y el ESP (Encapsulated Security Payload - Carga de seguridad encapsulada). Ambos son protocolos IP independientes. AH es el protocolo IP 51 y ESP el protocolo IP 50.

AH - Cabecera de autenticación

El protocolo AH protege la integridad del datagrama IP. Para conseguirlo, el protocolo AH calcula una HMAC basada en la clave secreta, el contenido del paquete y las partes inmutables de la cabecera IP (como son las direcciones IP). Tras esto, añade la cabecera AH al paquete. La cabecera AH se muestra en la siguiente figura:

Significado de los campos:

Next header

Identifica el protocolo de los datos transferidos.

Payload length

Tamaño del paquete AH.

RESERVED

Reservado para uso futuro (hasta entonces todo ceros).

Security parameters index (SPI)

Indica los parámetros de seguridad que, en combinación con la dirección IP, identifican la asociación de seguridad implementada con este paquete.

Sequence number

Un número siempre creciente, utilizado para evitar ataques de repetición.

HMAC

Contiene el valor de verificación de integridad (ICV) necesario para autenticar el paquete; puede contener relleno.

ESP - Carga de Seguridad Encapsulada

El protocolo ESP puede asegurar la integridad del paquete empleando una HMAC y la confidencialidad empleando cifrado. La cabecera ESP se genera y añade al paquete tras cifrarlo y calcular su HMAC. La cabecera ESP consta de dos partes y se muestra en la siguiente figura:

Significado de los campos

Security parameters index (SPI)

Identifica los parámetros de seguridad en combinación con la dirección IP.

Sequence number

Un número siempre creciente, utilizado para evitar ataques de repetición.

Payload data

Los datos a transferir.

Padding

Usado por algunos algoritmos criptográficos para rellenar por completo los bloques.

Pad length

Tamaño del relleno en bytes.

Next header

Identifica el protocolo de los datos transferidos.

Authentication data

Contiene los datos utilizados para autenticar el paquete.

documentacion tomada de http://es.wikipedia.org y de http://www.ipsec-howto.org/spanish/x161.html

Hash

es una funcion para resumir o identificar probabilísticamente un gran conjunto de información, Una función hash es una operación matemática que se aplica al conjunto de un mensaje, de forma que como resultado se obtiene una cadena de bits denominada "resumen". Este "resumen" tiene siempre la misma medida (128 ó 160 bits), independientemente de la medida de los datos originales y tiene la propiedad de encontrarse unívocamente asociada a los datos iniciales, es decir, garantiza que no sean posibles dos mensajes diferentes con un "resumen" hash idéntico.

CA (Certification Authority)

La Autoridad de Certificación o CA es el sistema responsable de la emisión de certificados digitales a los usuarios de un sistema que utiliza autenticación basada en certificación digital. Los certificados digitales relacionan la clave pública de un usuario con su identidad, y están firmados por la CA de modo que su integridad y autenticidad queden garantizadas.

SSL

Secure Sockets Layer (SSL):

protocolo diseñado por la empresa Netscape para proveer comunicaciones, segura y encriptadas en internet, ssl da privacidad para datos y mensajes, ademas permite autentificar los datos enviados.

Como funciona ssl:

SSL es un protocolo que proporciona privacidad e integridad entre dos aplicaciones de comunicaciones utilizando HTTP. El Protocolo de transferencia de hipertexto (HTTP) para World Wide Web utiliza SSL para que las comunicaciones sean seguras.


Pasos de la comunicacion de ssl:

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.


finish.