Home > C A P I T U L O III

C A P I T U L O III


C A P I T U L O  III 
 

 
 
 

INDICE 

    3.1 Protocolos

    3.2 Criptograf��a 

          3.2.1 Criptograf��a moderna

          3.2.2 Algoritmos Sim��tricos

          3.2.3 Algoritmos Asim��tricos

          3.2.4 Firmas Digitales

          3.2.5 Funciones Hash 

    3.3 Seguridad en la Transmisi��n

    3.4 Protocolo SSH (Secure shell) 

          3.4.1 Caracter��sticas de SSH

          3.4.2 Por que usar SSH

          3.4.3 SSH v1 y SSH v2

          3.4.4 Tipos de Claves SSH

          3.4.5 M��todos de Autentificaci��n

          3.4.6 Forma de Operaci��n de SSH

          3.4.7 Redireccionamiento de puertos 

    3.5 Protocolo SSL (Secure Socket Layer) 

          3.5.1 Arquitectura de SSL

          3.5.2 Funcionamiento de SSL 
     
     
     
     
     

    3.6 Protocolo TLS (Transport Layer Security)

    3.7 Protocolo SHTTP

    3.8 Protocolo IPSec (Protocolo de Seguridad de Internet ) 

          3.8.1 Ventajas y Desventajas de IPSec

          3.8.2 Limitaciones de IPSec

          3.8.3 Caracter��sticas de Seguridad de IPSec

          3.8.4 Arquitectura de IPSec

                3.8.4.1 Protocolo AH

                3.8.4.2 Protocolo ESP

                3.8.4.3 Protocolo IKE

          3.8.5 Funcionamiento de IPSec

                3.8.5.1 Modo Transporte

                3.8.5.2 Modo T��nel

          3.8.6 Pol��ticas de Seguridad de IPSec 
     

 

PROTOCOLOS CRIPTOGRAFICOS Y DE SEGURIDAD DE COMUNICACIÓN 
 

3.1 PROTOCOLOS 

Los protocolos son reglas y procedimientos para la comunicaci��n. El t��rmino «protocolo» se utiliza en distintos contextos. Por ejemplo, los diplom��ticos de un pa��s se ajustan a las reglas del protocolo creadas para ayudarles a interactuar de forma correcta con los diplom��ticos de otros pa��ses. De la misma forma se aplican las reglas del protocolo al entorno inform��tico. Cuando dos equipos est��n conectados en red, las reglas y procedimientos t��cnicos que dictan su comunicaci��n e interacci��n se denominan protocolos.

Cuando piense en protocolos de red se debe tomar en cuenta  estos tres puntos: 

  • Existen muchos protocolos. A pesar de que cada protocolo facilita la comunicaci��n b��sica, cada uno tiene un prop��sito diferente y realiza distintas tareas. Cada protocolo tiene sus propias ventajas y sus limitaciones.
  • Algunos protocolos s��lo trabajan en ciertos niveles OSI. El nivel al que trabaja un protocolo describe su funci��n. Por ejemplo, un protocolo que trabaje a nivel f��sico asegura que los paquetes de datos pasen a la tarjeta de red (NIC) y salgan al cable de la red.
  • Los protocolos tambi��n puede trabajar juntos en una jerarqu��a o conjunto de protocolos. Al igual que una red incorpora funciones a cada uno de los niveles del modelo OSI, distintos protocolos tambi��n trabajan juntos a distintos niveles en la jerarqu��a de protocolos. Los niveles de la jerarqu��a de protocolos se corresponden con los niveles del modelo OSI. Por ejemplo, el nivel de aplicaci��n del protocolo TCP/IP se corresponde con el nivel de presentaci��n del modelo OSI. Vistos conjuntamente, los protocolos describen la jerarqu��a de funciones y prestaciones.
 

Como Funcionan los Protocolos

La operaci��n t��cnica en la que los datos son transmitidos a trav��s de la red se puede dividir en dos pasos discretos, sistem��ticos. A cada paso se realizan ciertas acciones que no se pueden realizar en otro paso. Cada paso incluye sus propias reglas y procedimientos, o protocolo. 
 

Los pasos del protocolo se tienen que llevar a cabo en un orden apropiado y que sea el mismo en cada uno de los equipos de la red. En el equipo origen, estos pasos se tienen que llevar a cabo de arriba hacia abajo. En el equipo de destino, estos pasos se tienen que llevar a cabo de abajo hacia arriba.

 

El equipo origen

Los protocolos en el equipo origen: 

  • Se dividen en secciones m��s pequeñas, denominadas paquetes.
  • Se añade a los paquetes informaci��n sobre la direcci��n, de forma que el equipo de destino pueda determinar si los datos le pertenecen.
  • Prepara los datos para transmitirlos a trav��s de la NIC y enviarlos a trav��s del cable de la red.

 

El equipo de destino

Los protocolos en el equipo de destino constan de la misma serie de pasos, pero en sentido inverso. 

  • Toma los paquetes de datos del cable y los introduce en el equipo a trav��s de la NIC.
  • Extrae de los paquetes de datos toda la informaci��n transmitida eliminando la informaci��n añadida por el equipo origen.
  • Copia los datos de los paquetes en un b��fer para reorganizarlos enviarlos a la aplicaci��n.
 

Los equipos origen y destino necesitan realizar cada paso de la misma forma para que los datos tengan la misma estructura al recibirse que cuando se enviaron.[www.005] 

3.2 CRIPTOGRAFIA  

La palabra criptograf��a proviene del griego  Kryptos que significa OCULTO y graphein,  ESCRIBIR es decir ��la t��cnica de escribir con algo secreto u oculto�� . La  criptograf��a a sido utilizada a trav��s de los años para ,andar mensajes confidenciales cuyo prop��sito es que ��solo personas autorizadas puedan entender el mensaje ��.

Hay cuatro elementos fundamentales para que esta t��cnica o mejor dicho ��conjunto de t��cnicas �� hagan que un documento encriptado sea seguro ,  estas son: 

PRIVACIDAD: se refiere a que la informaci��n solo pueda ser le��da por personas  autorizadas.  No sirve de nada,  por ejemplo proteger un documento de suma importancia para el futuro de la empresa,  si este documento es f��cilmente robado o copiado por la empresa competidora,  en este momento se dice que el documento ha perdido privacidad.   

INTEGRIDAD:  se refiere a que la informaci��n no pueda ser alterada en el transcurso de su transferencia hacia otro lugar,  la p��rdida de integridad puede resultar catastr��fica si por ejemplo enviamos un documento firmado por nosotros y en el transcurso del envi��, nuestra firma o datos son adulterados por terceros,  en este caso se dice que el documento no ha llegado ��integro��. 

AUTENTICIDAD: se refiere a que se pueda confirmar que el mensaje recibido haya sido enviado por quien dice ser enviado o que el mensaje recibido es el que se esperaba,  por ejemplo cuando se quiere cobrar un cheque a nombre de alguien quien lo cobra debe someterse a un proceso de verificaci��n de identidad para comprobar si en efecto es la persona que dice ser.  

NO RECHAZO: se refiere a que no se pueda negar la autor��a de un mensaje enviado,  por ejemplo si se  hace una compra por Internet y utilizamos alguna pagina que utilice m��todos criptogr��ficos para avalar nuestra compra,  se puede asegurar que los datos no sean adulterados  de ninguna forma en la operaci��n y los dueños de la pagina se aseguran de que no se pueda negar la compra.   

Si se necesita un ��mbito seguro de trabajo se deben incluir estas cuatro premisas,  adem��s de un buen manejo de claves para poder comprobar autenticidad,  garantizar  privacidad,  asegurar integridad,  y evitar el no rechazo.   

3.2.1 CRIPTOGRAFIA MODERNA 

La  llegada de la computadora a la sociedad trajo consigo una renovaci��n de t��cnicas criptogr��ficas nunca antes pensadas,   el gran proceso de c��lculo y la velocidad fueron desencadenantes para que una nueva raza de t��cnicas y algoritmos criptogr��ficos fueran creados. Estos algoritmos se dividen en algoritmos con t��cnicas sim��tricas y asim��tricas.  

3.2.2 ALGORITMOS SIMETRICOS  

DES:  en  1977 el Departamento de Comercio y la Oficina Nacional de estandares de Estados Unidos publicaron la  norma DES (Data Encryption Standar)  este es un esquema de cifrado de claves primarias,  es un sistemas monoalfab��tico que fue desarrollado en colaboraci��n de IBM  y se presento con la intenci��n de proporcionar un algoritmo de cifrado normalizado para redes de ordenadores.  DES utiliza una clave de 64 bits de los cuales 56 son utilizados directamente por el algoritmo DES y los 8 restantes se emplean para la detecci��n de errores. Como se visto se necesitan uno setenta mil billones de claves posibles de 56 bits.  Debido e esto DES es bastante duro de romper pero no ��imposible��.  En julio de 1998 la empresa EFF creo una m��quina que logro descifrar un mensaje DES en menos de tres d��as.  A pesar de esto el objetivo de DES   no es proporcionar una seguridad absoluta si no ��nicamente un nivel  de seguridad razonable,  para las redes orientadas a aplicaciones comerciales.  Posteriormente se ha sacado una versi��n de DES implementada por hardware que entro a formar parte de los est��ndares de la ISO con el nombre de DEA  

VENTAJAS DE DES:   

  • Es el sistemas mas extendido del mundo
  • El que mas m��quinas usan
  • El mas barato y el mas probado
  • R��pido y f��cil de implementar
 

TRIPLE DES: El sistemas DES se considera en la actualidad poco pr��ctico,  debido a la corta longitud de su clave.  Para resolver este problema y seguir utilizando DES se ha creado el sistema Triple DES (TDES),  basado en tres iteraciones sucesivas del algoritmo DES,  con lo que se consigue una longitud de clave de 128 bits,  y que es compatible con DES simple,  con esto se ha mantenido la sencillez y rapidez de DES, protegiendo al  algoritmo de ser hackeado. 

IDEA :  creado en Zurich por Lay y Massey en 1992,  este algoritmo emplea claves de encriptaci��n  de 128 bits de longitud consider��ndolo muy seguro.  Es uno de los algoritmos mas conocidos actualmente. El m��todo de cifrado esta basado en modificar la orientaci��n de cada bit y combinarla con una puerta l��gica variable.  Se lo considera como el mejor algoritmo sim��trico en la actualidad ya que emplea bloques de cifrado de 64 bits de longitud y utiliza claves de 128 bits.  El algoritmo de desencriptaci��n  es muy parecido al de encriptaci��n,  por lo que resulta muy f��cil y r��pido de programar   ,  y hasta ahora no ha sido roto nunca,  aportando su longitud de clave una seguridad fuerte ante los ataques por fuerza bruta (prueba y ensayo o diccionarios).    

RC4/5: el sistema criptogr��fico sim��trico RC5 es el sucesor de RC4,  frente al que presenta  numerosas mejoras.  Ambos han sido creados por RSA Data Security Inc.  La empresa creada por los autores del sistema RSA que es actualmente una de las mas importantes en el campo del cifrado y protecci��n de datos.

Permite diferentes longitudes de claves (aunque esta prohibida su exportaci��n fuera de EEUU con longitudes superiores a 56 bits),  y funciona como un generador de n��meros aleatorios que se suman al texto mediante una operaci��n de tipo OR-Exclusiva,  es adem��s ampliamente configurable, permitiendo fijar diferentes longitudes de clave,  numero de iteraciones y tamaño de los bloques a cifrar,  por lo que le permite adaptarse a cualquier aplicaci��n.  Por ejemplo este algoritmo es usado por NetScape para implementar su sistema de seguridad de comunicaciones SSL. En 1996 una universidad francesa consigui�� romper el sistema RC4 con clave de 40 bits,  lo que hace sospechar que RC5 con longitudes de clave de 56 bits no es lo suficientemente seguro. 

MD5: algoritmo desarrollado por el grupo RSA capaz de obtener 128 bits a partir de un determinado texto y es un intento de probar con otros sistemas criptogr��ficos que no empleen claves.  Hasta hoy no se sabe cuales son las operaciones matem��ticas para descifrarlo,  pero es probable que se base en factores de n��meros primos . 

SHA: es un algoritmo desarrollado por el gobierno de los EEUU y se pretende implantar en los sistemas inform��ticos de alta seguridad del estado como est��ndar  de protecci��n de documentos.  El algoritmo obtiene 160 bits de un texto determinado.[www.014] 

3.2.3 ALGORITMOS ASIMETRICOS  

Los algoritmos asim��tricos son tambi��n llamados de clave p��blica,  verdaderamente este sistema se compone de dos tipos de claves,  la publica y la privada,  el primer algoritmo de este tipo fue desarrollado por Whitfield Diffie y Martin Hellman. Este algoritmo de encriptaci��n supuso una verdadera revoluci��n en el campo de la criptograf��a fue creado en 1976 y su importancia se debe sobre todo  al hecho de ser el inicio de los sistemas asim��tricos,  ya que en la pr��ctica solo es v��lido para el intercambio de claves sim��tricas,  y con esta funcionalidad  es muy usado en los diferentes sistemas seguros implementados  en Internet   como SSL y VPN. 

RSA: el algoritmo RSA se basa en el hecho matem��tico de la dificultad de factorizar n��meros muy grandes.  Para factorizar un n��mero el sistema mas l��gico consiste en empezar a dividir sucesivamente este entre 2,  entre 3,  entre 4......y asi sucesivamente,  buscando que el resultado de la divisi��n sea exacto,  es decir de resto 0,  con lo que ya tendremos un divisor del n��mero.  Si el numero considerado es un numero primo,  tendremos que factorizarlo,  habr��a que empezar 1,2,3........ hasta llegar a el mismo ya que por ser primo es divisible para si mismo.  Y si el numero primo es lo suficientemente grande el proceso de factorizaci��n es complicado y lleva mucho tiempo. 

El funcionamiento de RSA es el siguiente: 

  1. Se busca dos n��meros primos  lo suficientemente grandes:  p y q de entre 100y 300 d��gitos
  2. Se obtienen los n��meros n= p*q    y  = (p-1)*(q-1)
  3. Se busca el numero e tal que no tenga   m��ltiplos comunes con 
  4. Se calcula d=e-1 mod  con mod = resto de la divisi��n   de n��meros enteros
 

Y con estos n��meros obtenidos,  n es la clave p��blica y d es la clave privada.  Los n��meros p, q,  se destruyen.  Tambi��n se hace p��blico el n��mero e necesario para alimentar el algoritmo.

El c��lculo de estas claves se realizan en secreto en la m��quina en la que se va a guardar la clave privada,  y una vez generada ��sta conviene protegerla mediante un algoritmo criptogr��fico sim��trico.

RSA permite longitudes variables,  siendo aconsejables actualmente el uso de claves de no menos de 1024 bits (se han roto claves de hasta 512 bits aunque se necesitaron mas de 5 meses y 300 pcs trabajando juntos para hacerlo)

RSA es el mas conocido y usado de los sistemas de clave p��blica,  y tambi��n el mas r��pido.  Presenta todas las ventajas de los sistemas asim��tricos incluyendo la firma digital aunque resulta mas ��til a la hora de implementar la confidencialidad el uso de sistemas sim��tricos por ser mas r��pidos. Se suele usar tambi��n en los sistemas mixtos para encriptar y enviar la clave sim��trica que se usara posteriormente en la comunicaci��n cifrada. 

3.2.4 FIRMAS DIGITALES  

Las firmas digitales son m��todos de cifrado que tienen dos prop��sitos :

  • Validar el contenido de un mensaje electr��nico y se puede utilizar posteriormente para comprobar que un emisor envi�� de hecho un mensaje
  • Probar que no se ha falsificado un mensaje durante su envi��.  Las firmas digitales respaldan la autenticidad del correo electr��nico,  transacciones de contabilidad,  ordenes de empresa, documentos para grupos de trabajo y otros mensajes y archivos que se trasladan entre sistemas,  usuarios u organizaciones.

Las firmas digitales se basan en el hecho de que dos grupos pueden autentificarse el uno al otro para el intercambio seguro de documentos,  pero la relaci��n entre ellos no se basa en una confianza total.  

3.2.5 FUNCIONES HASH 

Si se quiere firmar digitalmente  un documento extenso,  se puede dar cuenta que cifrar el documento entero es una perdida  de tiempo ya que los medios de encriptaci��n de llave p��blica son lentos y precisan un gran proceso de computo.  Para solventar este aspecto aparecen las funciones hash, que son unas funciones matem��ticas  que realizan un resumen del documento a firmar.  Su forma de operar es comprimir el documento en un ��nico bloque de longitud fija,  bloque cuyo documento es ilegible y no tiene ning��n sentido real.  Tanto es as�� que por definici��n las funciones hash son irreversibles,  es decir,  que partir de un bloque comprimido no se puede obtener el bloque sin comprimir,  y si no es as��   no es una funci��n hash.  Estas funciones son de dominio p��blico.

A un mensaje resumido mediante una funci��n hash y encriptado con una llave privada es lo que realmente se denomina FIRMA DIGITAL.

Las funciones hash y la firma digital son elementos indispensables para el establecimiento de canales seguros de comunicaci��n,  basados en los certificados digitales.

Para que una funci��n pueda considerarse una funci��n hash debe cumplir con los siguientes requerimientos:  

  • Debe transformar un texto de longitud variable a un bloque de longitud fija,  que generalmente es pequeña (algunas son de 16 bits)
  • Debe ser c��moda de usar e implementar
  • Debe ser irreversible,  es decir,  no se puede obtener el texto original del resumen hash
  • Debe ser imposible encontrar dos mensajes diferentes cuya firma digital mediante la funci��n hash sea la misma (no – colici��n)
  • Si se desea adem��s mantener un intercambio de informaci��n con CONFIDENCIALIDAD,  basta con cifrar el documento a enviar con la clave p��blica del receptor.[www.014]
 

3.3 SEGURIDAD EN LA TRANSMICION  

La confidencialidad de la informaci��n, espec��ficamente de los usuarios que utilizan Internet es fundamental. La comunicaci��n entre las sucursales de una empresa u organizaci��n como es el caso de la Cooperativa Atuntaqui, la publicaci��n de informaci��n confidencial de una empresa, el compartir informaci��n estrat��gica, el ingreso en sitios Web, son solamente algunos ejemplos de contenido sensible que debe contar con las medidas de seguridad adecuadas para evitar problemas y no perder la privacidad y confianza.

La seguridad de este tipo se basa en el hecho de poder encriptar los mensajes que se intercambian a trav��s de la  red entre los  servidores  y los  clientes,   y que solo ellos puedan descifrar los contenidos a partir de una clave com��n conocida solo por los dos.

Para llevar a cabo esta seguridad se crearon diversos protocolos basados en esta idea, como son:


PROTOCOLO DESCRIPCION
SSH Usado exclusivamente en reemplazo de TELNET
SSL Y TSL Usado principalmente en comunicaciones de hipertexto pero con posibilidad de uso en otros protocolos
HTTPS Usado exclusivamente para comunicaciones de hipertexto
IPSec Usado como  protocolo de seguridad de Internet

Tabla 3.1 Protocolos de Seguridad de Comunicaci��n 

3.4  PROTOCOLO SSH (Secure Shell)

Este protocolo fue diseñado para dar seguridad al acceso a computadores en forma remota. A diferencia de FTP o Telnet, SSH encripta la sesi��n de registro imposibilitando que alguien pueda obtener contraseñas no encriptadas. SSH utiliza el puerto 22 para la comunicaci��n y la forma de efectuar su trabajo es muy similar al efectuado por SSL.

SSH est�� diseñado para reemplazar los m��todos m��s viejos y menos seguros para registrarse remotamente en otro sistema a trav��s de la shell de comando, tales como telnet o rsh. Un programa relacionado, el scp, reemplaza otros programas diseñados para copiar archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, evite usarlas mientras le sea posible. El uso de m��todos seguros para registrarse remotamente a otros sistemas har�� disminuir los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto

Para su uso se requiere que por parte del servidor exista un demonio que mantenga continuamente en el puerto 22 el servicio de comunicaci��n segura, el sshd. El cliente debe ser un software tipo TeraTerm o Putty que permita hacer pedidos a este puerto 22 de forma cifrada.

La forma en que se entabla una comunicaci��n es en base la misma para todos los protocolos seguros:

  • El cliente env��a una señal al servidor pidi��ndole comunicaci��n por el puerto 22.
  • El servidor acepta la comunicaci��n en el caso de poder mantenerla bajo encriptaci��n mediante un algoritmo definido y le env��a la llave publica al cliente para que pueda descifrar los mensajes.
  • El cliente recibe la llave teniendo la posibilidad de guardar la llave para futuras comunicaciones o destruirla despu��s de la sesi��n actual.

3.4.1 CARACTERISTICAS DE SSH

SSH (o Secure SHell) es un protocolo para crear conexiones seguras entre dos sistemas usando una arquitectura cliente/servidor.  

El protocolo SSH proporciona los siguientes tipos de protecci��n:  

  • Ofrece un mecanismote autentificaci��n de servidor a cliente adem��s de cifrado.
  • Se utiliza cifrado asim��trico al comienzo,  y sim��tricos una vez negociados  y autentificados el cliente y el servidor.
  • Da soporte a la integridad de los datos
  • Despu��s de la conexi��n inicial, el cliente puede verificar que se est�� conectando al mismo servidor al que se conect�� anteriormente.
  • El cliente transmite su informaci��n de autenticaci��n al servidor usando una encriptaci��n robusta de 128 bits.
  • Todos los datos enviados y recibidos durante la conexi��n se transfieren por medio de encriptaci��n de 128 bits, lo cual los hacen extremamente dif��cil de descifrar y leer.
  • El cliente tiene la posibilidad de enviar aplicaciones lanzadas desde el int��rprete de comandos de la shell. Esta t��cnica proporciona una interfaz gr��fica segura (llamada reenv��o por X11), proporciona un medio seguro para usar aplicaciones gr��ficas sobre una red.
 

Ya que el protocolo SSH encripta todo lo que env��a y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una t��cnica llamada reenv��o por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos.

Red Hat Linux contiene el paquete general de OpenSSH (openssh), el servidor de OpenSSH (openssh-server) y los paquetes de clientes (openssh-clients). Una gran cantidad de programas de cliente y servidor puede usar el protocolo SSH. Muchas aplicaciones SSH cliente est��n disponibles para casi todos los principales sistemas operativos en uso hoy d��a,  como por ejemplo el cliente Putty. 

3.4.2 POR QUE USAR SSH? 

Los usuarios tienen a su disposici��n una variedad de herramientas interceptar y dirigir el tr��fico de la red para ganar acceso al sistema. En t��rminos generales, estas amenazas se pueden catalogar del siguiente modo:  

  • Intercepci��n de la comunicaci��n entre dos sistemas: En este escenario, existe un tercero en alg��n lugar de la red entre entidades en comunicaci��n que hace una copia de la informaci��n que pasa entre ellas. La parte interceptora puede interceptar y conservar la informaci��n, o puede modificar la informaci��n y luego enviarla al recipiente al cual estaba destinada. Este ataque se puede montar a trav��s del uso de un paquete sniffer , una utilidad de red muy com��n.
  • Personificaci��n de un determinado host: con esta estrategia, un sistema interceptor finge ser el receptor a quien est�� destinado un mensaje. Si funciona la estrategia, el cliente no se da cuenta del engaño y contin��a la comunicaci��n con el interceptor como si su mensaje hubiese llegado a su destino satisfactoriamente.  

    Esto se produce con t��cnicas como el envenenamiento del DNS o spoofing de IP.  

Ambas t��cnicas causan que se intercepte informaci��n, posiblemente con prop��sitos hostiles. El resultado puede ser catastr��fico. Si se utiliza SSH para inicios de sesi��n de shell remota y para copiar archivos, estas amenazas a la seguridad se pueden disminuir notablemente. Esto es porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicaci��n entre los sistemas cliente y servidor es encriptada. No servir��n de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicaci��n ya que cada paquete est�� cifrado por medio de una clave conocida s��lo por el sistema local y el remoto. [www.004] 

3.4.3 SSH VERSIÓN 1 Y SSH VERSIÓN 2 

Como nada en este mundo es perfecto, existen dos versiones incompatibles del protocolo SSH: la versi��n 1.x (1.3 y 1.5) y la versi��n 2.0.

Pasar de una versi��n a la otra no es doloroso para el usuario, teniendo a mano el cliente correcto y el servidor correcto compatible con la versi��n. La versi��n 1 del protocolo SSH est�� integrada, mientras que la versi��n 2 ha definido el protocolo anterior en tres "capas":

  1. Capa de transporte del protocolo SSH (SSH-TRANS)
  2. Autentificaci��n del protocolo SSH (SSH-AUTH)
  3. Conexi��n del protocolo SSH (SSH-CONN)

Cada capa del protocolo est�� definida espec��ficamente en un documento (borrador) normalizado por la IETF, seguido de un cuarto borrador que describe la arquitectura (Arquitectura del protocolo SSH, SSH-ARCH). Se pueden encontrar todos los detalles en: [www.007] 

Sin meternos en muchos detalles, aqu�� tienes lo que encontrar��s en SSHv2:

        1. La capa de transporte proporciona integridad, cifrado, y compresi��n, la autentificaci��n de sistemas
        2. La capa de autentificaci��n proporciona ... autentificaci��n (contraseña, basada en m��quina, clave p��blica)
        3. La capa de conexi��n que gestiona el t��nel (shell, agente SSH, redirecci��n de puertos, control del flujo).

Las principales diferencias t��cnicas entre la versi��n 1 de SSH y la versi��n 2 son: 
 


SSH Versi��n 1 SSH Versi��n 2
Diseño monol��tico (integrado) Separaci��n de las funciones de autentificaci��n, conexi��n y transporte en capas
Integridad via CRC32 (no seguro) Integridad via HMAC (cifrado hash)
Un ��nico canal por sesi��n Un n��mero ilimitado de canales por sesi��n
Negociaci��n usando ��nicamente cifrado sim��trico en el canal, identificaci��n de sesi��n con una ��nica clave en ambos lados Negociaci��n m��s detallada (cifrado sim��trico, llave p��blica, compresi��n, ...), y una clave de sesi��n independiente, compresi��n e integridad

en ambos lados

S��lo RSA para el algoritmo de clave p��blica RSA y DSA para el algoritmo de clave p��blica
Clave de sesi��n transmitida por el cliente Clave de sesi��n negociada por el protocolo Diffie-Hellman
Clave de sesi��n v��lida para toda la sesi��n Clave de sesi��n renovable

Tabla 3.2 Diferencias entre SSH1 y  SSH2 

3.4.4 TIPOS DE CLAVES SSH  

Clave de usuario: un par de claves compuestas de una clave p��blica y otra privada (ambas asim��tricas), definidas por el usuario y permanentes (se guardan en el disco). Estas claves permiten la autentificaci��n de usuario si se utiliza el m��todo de autentificaci��n de clave p��blica.  

Clave de m��quina: tambi��n un par de claves compuestas de una llave p��blica y otra privada (ambas asim��tricas), pero definidas al instalar/configurar SSH por el administrador del servidor y permanentes (guardadas en el disco). Esta clave permite la autentificaci��n entre sistemas.

Clave de servidor: de nuevo un par de claves compuestas de una clave p��blica y otra privada (ambas asim��tricas), pero generadas por un demonio al iniciarse y renovadas regularmente. Esta clave permanece en memoria para asegurar el intercambio de la clave de sesi��n en SSHv1 (con SSHv2, no hay clave de servidor ya que el intercambio se asegura con el protocolo Diffie-Hellman).

Clave de sesi��n: esta es una clave secreta usada por el algoritmo de cifrado sim��trico para cifrar el canal de comunicaci��n. Como es en todos los productos modernos de criptograf��a, la clave es aleatoria y perecedera. SSHv1 tiene una clave por sesi��n, en ambos lados. SSHv2 tiene dos claves de sesi��n regeneradas, una en cada lado.

El usuario añade una frase de paso (pass phrase) que protege la parte privada de las anteriores claves. Esta protecci��n se asegura cifrando el fichero que contiene la clave privada con un algoritmo sim��trico. La clave secreta usada para cifrar el fichero se deriva de esta frase de paso. 

3.4.5 METODOS DE AUTENTIFICACION 

Hay varios m��todos de autentificaci��n de usuario, la elecci��n depende de la necesidades definidas en las pol��ticas de seguridad. Los m��todos autorizados se activan o no en el fichero de configuraci��n del servidor. Aqu�� est��n las principales categor��as:

"Similar a telnet":

Este es el "tradicional" m��todo de la contraseña: al conectar, despu��s de haber introducido nuestro identificador, se le pide al usuario que introduzca una contraseña que se env��a al servidor que la compara con la que tiene asociada a dicho usuario. El problema residual (el que causa una cifra astron��mica actos delictivos en Internet) es que la contraseña se env��a a la red en claro, y por lo tanto puede ser interceptada por cualquiera que  tenga un simple "sniffer" (capturador de paquetes). En este caso SSH tiene la misma apariencia (es un modo f��cil usuarios inexpertos que migran de telnet a SSH, ya que no hay nada nuevo que aprender ...), no obstante el protocolo SSH cifra el canal y la contraseña en claro se encapsula.

Una variante incluso m��s segura, configurable si uno tiene lo necesario en el servidor es el uso de una "Contraseña de un solo uso -- One time password" (S/Key por ejemplo): seguramente es mejor, obviamente m��s seguro, pero las limitaciones de ergonom��a lo hacen aplicable ��nicamente a situaciones particulares. Este sistema opera como sigue: despu��s de introducir nuestro identificador, en vez de preguntar al usuario una contraseña (est��tica), el servidor env��a un "desaf��o" al que el usuario debe responder. Dado que el desaf��o debe ser diferente, la respuesta debe tambi��n cambiar. En consecuencia, la interceptaci��n de la respuesta no es importante ya que no puede ser rehusada. La limitaci��n, como se mencion��, viene esencialmente de la codificaci��n de la respuesta que debe ser calculada (por un token, software en el lado cliente, etc.), y la entrada es bastante "cabal��stica" (seis monos��labos ingleses, en el mejor de los casos). [www.004]

3.4.6 FORMA DE OPERACIÓN DE SSH

  1. Identificaci��n del servidor con su clave publica (no se debe confiar en una IP). Atenci��n a la primera vez
  2. El cliente le pide una prueba

El servidor responde correctamente (EL SERVIDOR YA ESTA AUTENTICADO) 

    Fig. 3.1 Mecanismo de Operaci��n de SSH (I)

    Una vez autenticado el servidor, y s��lo entonces, el cliente se autentifica:

    1. El servidor, ya con una conexi��n segura (negociada antes) pide al cliente autenticarse.
    2. El cliente le responde,  puede autenticarse mediante:  Keberos,  publickey,  y contraseña entre otros.
    3. Si el cliente responde de forma correcta,  la conexi��n se permite y esta ser�� cifrada,  y con verificaci��n de integridad.

    Por lo tanto SSH nos ofrece un servicio de acceso seguro y con garant��a de integridad.

     

      Fig. 3.2 Mecanismo de Operaci��n SSH (II)

    El protocolo SSH nos protege f��sicamente de un corte de comunicaci��n y a nivel de transporte de que se resetee una conexi��n falsificando segmentos TCP de forma adecuada.  

    3.4.7 REDIRECCIONAMIENTO DE PUERTOS

    SSH permite la redirecci��n (forwarding) de cualquier flujo de datos TCP a trav��s de un "t��nel" en una sesi��n SSH. Esto significa que el flujo de datos de la aplicaci��n, en vez de ser gestionada directamente por los puertos del servidor y el cliente, es "encapsulada" en un "t��nel" creado al conectar (inicio de sesi��n).

    Esto mismo se hace con el protocolo X11 sin ning��n esfuerzo especial (por parte del usuario), con un manejo transparente de los displays y la capacidad de propagarse continuamente cuando se realizan varias conexiones

    Existen muchos protocolos que no  tienen implementados mecanismos de cifrados.  Se puede bien utilizar un protocolo nuevo que soporten cifrados, o bien protocolos de nivel inferior  (SSL o IPSec).

    El problema es que estas soluciones requieren o bien un protocolo nuevo, o bien una configuraci��n m��s o menos complicada en el extremo servidor y en el extremo cliente. Mediante SSH, sabemos que podemos crear una conexi��n segura o t��nel  entre el cliente SSH y el servidor SSH; de lo que se trata es de usar esa conexi��n para crear un t��nel por el que pueda transportar una conexi��n no segura. 

    Ejemplo de Redireccionamiento de puerto utilizando POP 

    • El primer paso consiste en realizar la conexi��n con los par��metros que permitan crear el t��nel.
     
     

    Fig. 3.3 Par��metros para crear una conexi��n

      

    • En un extremo (Cliente o Servidor) se  crea la cabecera del t��nel en el otro la salida.
     
     
     
     

      Fig. 3.4 Redireccionamiento completo para POP

    La figura 3.5 presenta una forma mas simplificada de  un redireccionamiento de un servidor de correo.

     

      Fig. 3.5 Simplificaci��n del Redireccionamiento

    El t��nel de comunicaci��n se puede iniciar en el cliente ssh (como se ha visto anteriormente) o tambi��n en el servidor  (Hacia el cliente ssh)

    El redireccionamiento de puertos puede plantear problemas de seguridad.[www.006] 

    3.5 PROTOCOLO SSL (Secure Socket Layer)

     

    Son protocolos criptogr��ficos que proporcionan comunicaciones seguras en Internet. Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El t��rmino "SSL" seg��n se usa aqu��, se aplica a ambos protocolos a menos que el contexto indique lo contrario

    .

    Secure Socket Layer es un sistema de protocolos de caracter general diseñado en 1994 por la empresa Nestcape Communcations Corporation, y est�� basado en la aplicaci��n conjunta de Criptograf��a Sim��trica, Criptograf��a Asim��trica (de llave p��blica), certificados digitales y firmas digitales para conseguir un canal o medio seguro de comunicaci��n a trav��s de Internet. De los sistemas criptogr��ficos sim��tricos, motor principal de la encriptaci��n de datos transferidos en la comunicaci��n, se aprovecha la rapidez de operaci��n, mientras que los sistemas asim��tricos se usan para el intercambio seguro de las claves sim��tricas, consiguiendo con ello resolver el problema de la Confidencialidad en la transmisi��n de datos.

    SSL implementa un protocolo de negociaci��n para establecer una comunicarci��n segura a nivel de soket (nombre de la maquina mas puerto) de forma transparente al usuario y a las aplicaciones que lo usan, trabaja  una capa por debajo de HTTP por lo que permite ser usado no tan solo para proteger documentos de hipertexto sino tambi��n servicios como FTP, SMTP, TELNET entre otros. La idea que persigue SSL es encriptar la comunicaci��n entre servidor y cliente mediante el uso de llaves y algoritmos de encriptaci��n

    .

    Actualmente es el est��ndar de comunicaci��n segura en los navegadores Web m��s importantes (protocolo HTTP), como Nestcape Navigator e Internet Explorer, y se espera que pronto se saquen versiones para otras otros protocolos de la capa de Aplicaci��n (correo, FTP, etc.).

    La identidad del servidor Web seguro (y a veces tambi��n del usuario cliente) se consigue mediante el Certificado Digital correspondiente, del que se comprueba su validez antes de iniciar el intercambio de datos sensibles (Autenticaci��n), mientras que de la seguridad de Integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y la comprobaci��n de res��menes de todos los datos enviados y recibidos.

    Desde el punto de vista de su implementaci��n en los modelos de referencia OSI y TCP/IP, SSL se introduce como una especie de nivel o capa adicional, situada entre la capa de Aplicaci��n y la capa de Transporte, sustituyendo los sockets del sistema operativo, lo que hace que sea independiente de la aplicaci��n que lo utilice, y se implementa generalmente en el puerto 443.

     

    Fig. 3.6 Aplicaci��n de SSL en el modelo OSI y TCP/IP

    SSL proporciona servicios de seguridad a la pila de protocolos, encriptando los datos salientes de la capa de Aplicaci��n antes de que estos sean segmentados en la capa de Transporte y encapsulados y enviados por las capas inferiores. Es m��s, tambi��n puede aplicar algoritmos de compresi��n a los datos a enviar y fragmentar los bloques de tamaño mayor a 214 bytes, volvi��ndolos a reensamblarlos en el receptor.

    Habitualmente, s��lo el servidor es autentificado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autentificar; la autentificaci��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 y mantener la integridad del mensaje.

    El protocolo TLS esta basado en SSL y son similares en el modo de operar. Es importante señalar que ambos protocolos se ejecutan sobre una capa de transporte definida, pero no determinada. Esto indica que pueden ser utilizados para cualquier tipo de comunicaciones. La capa de transporte m��s usada es TCP cobre la cual pueden implementar seguridad en HTTP.  Como punto de diferencia se puede mencionar que existen protocolos implementados sobre la capa de red, por ejemplo sobre IP. Tal es el caso de IPSec.

     

    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
    • Encriptaci��n 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.

    La versi��n m��s actual de SSL es la 3.0. que usa los algoritmos sim��tricos de encriptaci��n DES, TRIPLE DES, RC2, RC4 e IDEA, el asim��trico RSA, la funci��n hash MD5 y el algoritmo de firma SHA-1.

    Los algoritmos, longitudes de clave y funciones hash de resumen usados en SSL dependen del nivel de seguridad que se busque o se permita, siendo los m��s habituales los siguientes:  

    RSA + Triple DES de 168 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, es uno de los conjuntos m��s fuertes en cuanto a seguridad, ya que son posibles 3.7 * 1050 claves sim��tricas diferentes, por lo que es muy dificil de romper. Por ahora s��lo est�� permitido su uso en Estados Unidos, aplic��ndose sobre todo en transacciones bancarias.

    RSA + RC4 de 128 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, permite 3.4 * 10 38 claves sim��tricas diferentes que, aunque es un n��mero inferior que el del caso anterior, da la misma fortaleza al sistema. An��logamente, en teor��a s��lo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementaci��n en los navegadores m��s comunes, siendo usado por organismos gubernamentales, grandes empresas y entidades bancarias. [www.009]

    RSA + RC2 de 128 bits + MD5: soportado s��lo por SSL 2.0, permite 3.4 * 10 38 claves sim��tricas diferentes, y es de fortaleza similar a los anteriores, aunque es m��s lento a la hora de operar. S��lo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementaci��n en los navegadores m��s comunes.

    RSA + DES de 56 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, aunque es el caso de la versi��n 2.0 se suele usar MD5 en vez de SHA-1. Es un sistema menos seguro que los anteriores, permitiendo 7.2 * 10 16 claves sim��tricas diferentes, y es el que suelen traer por defecto los navegadores Web en la actualidad (en realidad son 48 bits para clave y 8 para comprobaci��n de errores).

    RSA + RC4 de 40 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, ha sido el sistema m��s com��n permitido para exportaciones fuera de Estados Unidos. Permite aproximadamente 1.1 * 10 12 claves sim��tricas diferentes, y una velocidad de proceso muy elevada, aunque su seguridad es ya cuestionable con las t��cnicas de Criptoan��lisis actuales.

    RSA + RC2 de 40 bits + MD5: en todo an��logo al sistema anterior, aunque de velocidad de proceso bastante inferior.

    S��lo MD5: usado solamente para autentificar mensajes y descubrir ataques a la integridad de los mismos. Se usa cuando el navegador cliente y el servidor no tienen ning��n sistema SSL com��n, lo que hace imposible el establecimiento de una comunicaci��n cifrada. No es soportado por SSL 2.0, pero si por la versi��n 3.0.

     

    La clave de encriptaci��n sim��trica es ��nica y diferente para cada sesi��n, por lo que si la comunicaci��n falla y se debe establecer una nueva sesi��n SSL, la contraseña sim��trica se generar�� de nuevo. SSL proporciona cifrado de alto nivel de los datos intercambiados (se cifran incluso las cabeceras HTTP), autenticaci��n del servidor (y si es necesario tambi��n del cliente) e integridad de los datos recibidos.

    Durante el proceso de comunicaci��n segura SSL existen dos estados fundamentales, el

    estado de sesi��n

    y el

    estado de conexi��n

    . A cada sesi��n se le asigna un n��mero identificador arbitrario, elegido por el servidor, un m��todo de compresi��n de datos, una serie de algoritmos de encriptaci��n y funciones hash, una clave secreta maestra de 48 bytes y un flag de nuevas conexiones, que indica si desde la sesi��n actual se pueden establecer nuevas conexiones. Cada conexi��n incluye un n��mero secreto para el cliente y otro para el servidor, usados para calcular los MAC de sus mensajes, una clave secreta de encriptaci��n particular para el cliente y otra para el servidor, unos vectores iniciales en el caso de cifrado de datos en bloque y unos n��meros de secuencia asociados a cada mensaje.

    3.5.1 ARQUITECTURA DE SSL

    SSL trabaja sobre el protocolo TCP y por debajo de protocolos como HTTP, IMAP, LDAP, etc., y puede ser usado por todos ellos de forma transparente para el usuario. Opera entre la capa de transporte y la de sesi��n del modelo OSI (o entre la capa de transporte y la de aplicaci��n del modelo TCP) y est�� formado, a su vez, por dos capas y cuatro componentes bien diferenciados. 

     

    Fig. 3.7 Arquitectura SSL

    1. El protocolo de registro (Record Protocol)  es inmediatamente superior a TCP y proporciona una comunicaci��n segura, se encarga de encapsular el trabajo de los elementos de la capa superior, construyendo un canal de comunicaciones entre los dos extremos objeto de la comunicaci��n. Principalmente esta capa toma los mensajes y los codifica con algoritmos de
     

      encriptaci��n de llave sim��trica como DES, RC4 aplic��ndole una MAC (Message Authentication Code) para verificar la integridad , logrando as�� encapsular la seguridad para niveles superiores. 

      1. El verdadero coraz��n de SSL est�� en el protocolo de Handshake que es el encargado de intercambiar la clave que se utilizar�� para crear un canal seguro mediante un algoritmo eficiente de cifrado sim��trico. Tambi��n es responsabilidad de este protocolo coordinar los estados de ambos extremos de la transmisi��n.
      1. El protocolo de Alerta es el encargado de señalizar problemas y errores  concernientes a la sesi��n SSL establecida. 
      1. Por ��ltimo, el Change Cipher Spec Protocol est�� formado por un ��nico mensaje consistente en un ��nico byte de valor 1 y se utiliza para notificar un cambio en la estrategia de cifrado. 
       

      A grandes rasgos, podr��amos decir que SSL trabaja de la siguiente forma: 

      • En primer lugar intercambiamos una clave de longitud suficiente mediante un algoritmo de cifrado asim��trico.
      • Mediante esa clave establecemos un canal seguro utilizando para ello un algoritmo sim��trico previamente negociado.
      • A continuaci��n, toma los mensajes a ser transmitidos, los fragmenta en bloques, los comprime, aplica un algoritmo hash para obtener un resumen (MAC) que es concatenado a cada uno de los bloques comprimidos para asegurar la integridad de los mismos, realiza el cifrado y env��a los resultados.
      • El estado de todas estas operaciones son controladas mediante una m��quina de control de estados.
       

      Una sesi��n SSL puede comprender m��ltiples conexiones. Adicionalmente, se pueden establecer m��ltiples sesiones SSL simultaneas. [www.010] 

      3.5.2 FUNCIONAMIENTO DE SSL  

      1. El protocolos SSL esta basado en capas,  al igual que la familia de protocolos de TCP/IP.
      2. La capa de los mensajes incluye longitud,  descripci��n y contenido.
      3. SSL toma los mensajes que debe transmitirse,  divide los datos en bloques manejables,  comprime los datos si se los desea,  aplica un MAC,  cifra y transmite el resultado en forma de un registro SSL
      4. El receptor debe procesar los datos de forma an��loga,  es decir son descifrados,  verificados y descomprimidos (si fueron comprimidos) y reensamblarlos.
       
       
       

      Fig. 3.8 Funcionamiento de SSL 

      En resumidas cuentas, despu��s que se solicita una comunicaci��n segura, servidor y el cliente se deben poner de acuerdo en como se comunicaran (SSL Handshake) para luego comenzar la comunicaci��n encriptada. Luego de terminada la transacci��n, SSL termina. 

      Solicitud de SSL:

      T��picamente este proceso ocurre en el momento que un cliente accede a un servidor seguro, identificado con "https://...". pero como se mencion��, no necesariamente es usado para HTTP. La comunicaci��n se establecer�� por un puerto distinto al utilizado por el servicio normalmente. Luego de esta petici��n, se procede al SSL Handshake.

      SSL Handshake:

      En este momento, servidor y cliente se ponen de acuerdo en varios par��metros de la comunicaci��n. Se puede dividir el proceso en distintos pasos:

      • Client Hello: El cliente se presenta. Le pide al servidor que se presente (certifique quien es)y le comunica que algoritmos de encriptaci��n soporta y le env��a un n��mero aleatorio para el caso que el servidor no pueda certificar su validez y que aun as�� se pueda realizar la comunicaci��n segura.
      • Server Hello: El servidor se presenta. Le responde al cliente con su identificador digital encriptado, su llave p��blica, el algoritmo que se usar��, y otro n��mero aleatorio. El algoritmo usado ser�� el m��s poderoso que soporte tanto el servidor como el cliente.
      • Aceptaci��n del cliente: El cliente recibe el identificador digital del servidor, lo desencripta usando la llave p��blica tambi��n recibida y verifica que dicha identificaci��n proviene de una empresa certificadora segura. Luego se procede a realizar verificaciones del certificado (identificador) por medio de fechas, URL del servidor, etc. Finalmente el cliente genera una llave aleatoria usando la llave p��blica del servidor y el algoritmo seleccionado y se la env��a al servidor.
      • Verificaci��n: Ahora tanto el cliente y el servidor conocen la llave aleatoria (El cliente la gener�� y el servidor la recibi�� y desencript�� con su llave privada). Para asegurar que nada ha cambiado, ambas partes se env��an las llaves. Si coinciden, el Handshake concluye y comienza la transacci��n.

      Intercambio de Datos:

      Desde este momento los mensajes son encriptados con la llave conocida por el servidor y el cliente y luego son enviados para que en el otro extremo sean desencriptados y le��dos

      Terminaci��n de SSL

      Cuando el cliente abandona el servidor, se le informa que terminara la sesi��n segura para luego terminar con SSL. [www.004] 
       
       
       
       
       


       
       
       

      Fig 3.9 Esquema del proceso Handshake 

      3.6 PROTOCOLO TLS (Transport Layer Security )

      Se construye a partir de las especificaciones de SSL 3.0 y son tan semejantes que a veces se lo conoce como SSL 3.1. Por decirlo con las propias palabras de los autores el protocolo TLS est�� basado en las  especificaciones de SSL 3.0 publicadas por Netscape. Las diferencias entre este protocolo y SSL 3.0 no son grandes, pero si suficientes para que TLS 1.0 y SSL 3.0 no puedan interoperar (aunque TLS incorpora un mecanismo mediante el cual una implementaci��n de TLS puede trabajar con SSL 3.0). 
       
       
       

      Las principales diferencias entre SSL 3.0 y TLS 1.0 son las siguientes: 

      • En los mensajes Certificate Request y Certificate Verify del protocolo de Handshake. En SSL 3.0 si el servidor solicita un certificado al cliente para que se autentique, este debe de responder con el o con un mensaje de alerta advirtiendo de que no lo tiene. En TLS 1.0 si el cliente no posee certificado no responde al servidor de  ninguna forma a este requerimiento.
      • C��lculo de las claves de sesi��n. El mecanismo utilizado para construir las claves de sesi��n es ligeramente diferente en TLS 1.0.
      • TLS 1.0 no soporta el algoritmo de cifrado sim��trico FORTEZZA que si es soportado por SSL 3.0. Esto es debido a que TLS busca ser ��ntegramente p��blico mientras que FORTEZZA es un algoritmo propietario.
      • TLS utiliza un mecanismo diferente y m��s seguro en el c��lculo del MAC.
      • TLS 1.0 introduce nuevos c��digos de alerta no contemplados por SSL 3.0
      • TLS 1.0 introduce un nuevo mecanismo en el relleno de los bloques para frustrar ataques basados en el an��lisis de la longitud de los mensajes.
        1. PROTOCOLO SHTTP 
       

      El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticaci��n mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicaci��n. Se puede identificar r��pidamente a una p��gina Web servida con este protocolo porque la extensi��n de la misma pasa a ser .shtml en vez de .html como las p��ginas normales.

      El mecanismo de conexi��n mediante S-HTTP, que ahora se encuentra en su versi��n 1.1, comprende una serie de pasos parecidos a los usados en SSL, en los que cliente y servidor se intercambian una serie de datos formateados que incluyen los algoritmos criptogr��ficos, longitudes de clave y algoritmos de compresi��n a usar durante la comunicaci��n segura.

      En cuanto a estos algoritmos, lo usados normalmente son RSA para intercambio de claves sim��tricas, MD2, MD5 o NIST-SHS como funciones hash de resumen, DES, IDEA, RC4 o CDMF como algoritmos sim��tricos y PEM o PKCS-7 como algoritmos de encapsulamiento.

      A diferencia de SSL, el protocolo S-HTTP est�� integrado con HTTP, actuando a nivel de aplicaci��n, como ya hemos dicho, negoci��ndose los servicios de seguridad a trav��s de cabeceras y atributos de p��gina, por lo que los servicios S-HTTP est��n s��lo disponibles para el protocolo HTTP. Recordemos que SSL puede ser usado por otros protocolos diferentes de HTTP, pu��s se integra a nivel de shocked.

      Las principales ventajas de S-HTTP son su flexibilidad y su integraci��n dentro de HTML (extensiones al lenguaje similares a las introducidas peri��dicamente por Netscape Co. en sus navegadores). Entre sus debilidades podemos señalar los efectos derivados de mantener la compatibilidad hacia atr��s y la necesidad de implementar servidores que soporten las extensiones a HTML aportadas por el protocolo S-HTTP. [www.009] 
       

        1. PROTOCOLO DE SEGURIDAD IP (IPSec)
       

      IPSec (Internet Protocol Security) es en realidad un conjunto de est��ndares abiertos  para garantizar comunicaciones privadas y seguras a trav��s de redes IP mediante el uso de  funciones de seguridad basadas en criptograf��a. Es un est��ndar de la IETF (Internet Engineering Task Force) definido en el RFC 2401. Provee servicios de seguridad como autenticaci��n, integridad, control de acceso,  confidencialidad, y protecci��n frente a reenv��o . Combinando tecnolog��as de clave p��blica RSA,  algoritmos de cifrado(DES,  3DES,  IDEA, Bolwfish), algoritmos de hash (MD5, SHA-1) y certificados digitales.

      Es implementado en la capa de Red, de tal forma que su funcionamiento es completamente transparente al nivel de aplicaciones, y es mucho m��s poderoso. IPSec provee un mecanismo est��ndar, robusto y con posibilidades de expansi��n, para proveer seguridad al protocolo IP y protocolos de capas superiores

      IPSec est�� soportado en Windows Server™ 2003, Windows XP, y Windows 2000, y est�� integrado con el servicio de Directorio Activo. Las pol��ticas IPSec se pueden asignar mediante Pol��ticas de Grupo, lo que permite que los par��metros de IPSec se configuren a nivel de dominio, site o unidad organizativa.

      El objetivo principal de IPSec es proporcionar protecci��n a los paquetes IP. IPSec est�� basado en un modelo de seguridad de extremo a extremo, lo que significa que los ��nicos hosts que tienen que conocer la protecci��n de IPSec son el que env��a y el que recibe. Cada equipo controla la seguridad por s�� mismo en su extremo, bajo la hip��tesis de que el medio por el que se establece la comunicaci��n no es seguro. 

      IPSec aumenta la seguridad de los datos de la red mediante: 

      • La autenticaci��n mutua de los equipos antes del intercambio de datos. IPSec  puede utilizar Kerberos V5 para la autenticaci��n de los usuarios.
      • El establecimiento de una asociaci��n de seguridad entre los dos equipos. IPSec se puede implementar para proteger las comunicaciones entre usuarios remotos y redes, entre redes e, incluso, entre equipos cliente dentro de una red de ��rea local (LAN).
      • El cifrado de los datos intercambiados mediante Cifrado de datos est��ndar (DES, Data Encryption Standard), triple DES (3DES) o DES de 40 bits. IPSec usa formatos de paquete IP est��ndar en la autenticaci��n o el cifrado de los datos. Por tanto, los dispositivos de red intermedios, como los enrutadores, no pueden distinguir los paquetes de IPSec de los paquetes IP normales.
       

      3.8.1 VENTAJAS Y DESVENTAJAS DE IPSec 

      • Compatibilidad con la infraestructura de claves p��blicas. Tambi��n acepta el uso de certificados de claves p��blicas para la autenticaci��n, con el fin de permitir relaciones de confianza y proteger la comunicaci��n con hosts que no pertenezcan a un dominio Windows 2000 en el que se conf��a.
      • Compatibilidad con claves compartidas. Si la autenticaci��n mediante Kerberos V5 o certificados de claves p��blicas no es posible, se puede configurar una clave compartida (una contraseña secreta compartida) para proporcionar autenticaci��n y confianza entre equipos.
      • Transparencia de IPSec para los usuarios y las aplicaciones. Como IPSec opera al nivel de red, los usuarios y las aplicaciones no interact��an con IPSec
      • Administraci��n centralizada y flexible de directivas mediante Directiva de grupo. Cuando cada equipo inicia una sesi��n en el dominio, el equipo recibe autom��ticamente su directiva de seguridad, lo que evita tener que configurar cada equipo individualmente. Sin embargo, si un equipo tiene requisitos exclusivos o es independiente, se puede asignar una directiva de forma local.
      • Est��ndar abierto del sector. IPSec proporciona una alternativa de est��ndar industrial abierto ante las tecnolog��as de cifrado IP patentadas. Los administradores de la red aprovechan la interoperabilidad resultante. [www.011]
      • La ��nica desventaja que se le ve a IPSec por el momento, es la dificultad de configuraci��n con sistemas Windows. Windows 2000 y Windows XP proveen herramientas para configurar t��neles con IPSec, pero su configuraci��n es bastante dif��cil (Microsoft nombra a todas las cosas en forma diferente de lo est��ndar).  
         
         

      3.8.2 Limitaciones de IPSec

      • IPSec no es seguro si el sistema no lo es: Los gateways de seguridad deben estar en perfectas condiciones para poder confiar en el buen funcionamiento de IPSec.
      • IPSec no provee seguridad de usuario a usuario: IPSec no provee la misma clase de seguridad que otros sistemas de niveles superiores. Por ejemplo, el GPG que se utiliza para cifrar mensajes de correo electr��nico, si lo que se necesita es que los datos de un usuario los pueda leer otro usuario, IPSec no asegura esto y se tendr�� que utilizar otro m��todo.
      • IPSec autentica m��quinas, no usuarios: el concepto de identificaci��n y contraseña de usuarios no es entendido por IPSec, si lo que se necesita es limitar el acceso a recursos dependiendo del usuario que quiere ingresar, entonces habr�� que utilizar otros mecanismos de autenticaci��n en combinaci��n con IPSec.
      • IPSec no evita los ataques DoS: estos ataques se basan en sobrecargar la m��quina atacada de tal modo de que sus usuarios no puedan utilizar los servicios que dicha m��quina les provee.

      3.8.3 CARACTERISTICAS DE SEGURIDAD DE IPSec 

      Las siguientes caracter��sticas de IPSec afrontan todos estos m��todos de ataque: 

      • Protocolo Carga de seguridad de encapsulaci��n (ESP, Encapsulating Security Payload). ESP proporciona privacidad a los datos mediante el cifrado de los paquetes IP.
      • Claves basadas en criptograf��a. Las claves cifradas, que se comparten entre los sistemas que se comunican, crean una suma de comprobaci��n digital para cada paquete IP. Cualquier modificaci��n del paquete altera la suma de comprobaci��n, mostrando al destinatario que el paquete ha sido cambiado en su tr��nsito.     Se utiliza material de claves diferente para cada segmento

        del esquema de protecci��n global y se puede generar nuevo material de claves con la frecuencia especificada en la directiva de IPSec.

      • Administraci��n autom��tica de claves. La claves largas y el cambio din��mico de claves durante las comunicaciones ya establecidas protegen contra los ataques. IPSec usa el protocolo Asociaci��n de seguridad en Internet y administraci��n de claves (ISAKMP, Internet Security Association and Key Management Protocol) para intercambiar y administrar din��micamente claves cifradas entre los equipos que se comunican.
      • Negociaci��n de seguridad autom��tica. IPSec usa ISAKMP para negociar de forma din��mica un conjunto de requisitos de seguridad mutuos entre los equipos que se comunican. No es necesario que los equipos tengan directivas id��nticas, s��lo una directiva configurada con las opciones de negociaci��n necesarias para establecer un conjunto de requisitos con otro equipo.
      • Seguridad a nivel de red. IPSec existe en el nivel de red, proporcionando seguridad autom��tica a todas las aplicaciones.
      • Autenticaci��n mutua. IPSec permite el intercambio y la comprobaci��n de identidades sin exponer la informaci��n a la interpretaci��n de un atacante. La comprobaci��n mutua (autenticaci��n) se utiliza para establecer la confianza entre los sistemas que se comunican. S��lo los sistemas de confianza se pueden comunicar entre s��. Los usuarios no tienen que estar en el mismo dominio para comunicar con la protecci��n de IPSec. Pueden estar en cualquier dominio de confianza de la empresa. La comunicaci��n se cifra, lo que dificulta la identificaci��n e interpretaci��n de la informaci��n.
      • Filtrado de paquetes IP. Este proceso de filtrado habilita, permite o bloquea las comunicaciones seg��n sea necesario mediante la especificaci��n de intervalos de direcciones, protocolos o, incluso, puertos de protocolo espec��ficos.
       
       

      3.8.4 ARQUITECTURA  DE IPSec 

      La arquitectura de IPSec define la granularidad con la que el usuario puede especificar su pol��tica de seguridad. Permite que cierto tr��fico sea identificado para recibir el nivel de protecci��n deseado. 
       
       
       
       
       
       

       
       

      Fig 3.10 T��neles de comunicaci��n protegidos por IPSec entre redes separadas 
       

      IPSec est�� diseñado para proveer seguridad interoperable de alta calidad basada en criptograf��a, tanto para IPv4 como para IPv6.

      Est�� compuesto por dos protocolos de seguridad de tr��fico, el Authentication Header (AH) y el Encapsulating Security Payload (ESP), adem��s de protocolos y procedimientos para el manejo de llaves encriptadas. AH provee la prueba de los datos de origen en los paquetes recibidos, la integridad de los datos, y la protecci��n contra-respuesta. ESP provee lo mismo que AH adicionando confidencialidad de datos y de flujo de tr��fico limitado.

      En la Fig 3.10  se aprecia la arquitectura de IPSec. Al utilizar el mecanismo de AH se aplican algoritmos de autenticaci��n, con la aplicaci��n del mecanismo ESP, adem��s de autenticaci��n, tambi��n algoritmos de encriptaci��n. El esquema de interoperabilidad se maneja a trav��s de Asociaciones de Seguridad (SA), almacenadas en una base de datos. Los par��metros que se negocian para establecer los canales seguros se denominan Dominio de Interpretaci��n IPSec (Domain of Interpretation, DOI), bajo pol��ticas pre-establecidas dentro de un esquema de funcionamiento est��tico con valores fijos y previamente establecidos, o  

      bien, en un esquema de funcionamiento din��mico utilizando un protocolo de manejo de llaves, Interchange Key Exchange (IKE). 
       
       
       
       
       
       
       
       
       

       
       
       

      Fig 3.11 Arquitectura de IPSec 
       
       

      3.8.4.1 PROTOCOLO AH 

      Es el procedimiento previsto dentro de IPSec para garantizar la integridad y autenticaci��n de los datagramas IP.  Proporciona un medio al receptor de los paquetes IP para autenticar el origen de los datos y para verificar que dichos datos no han sido alterados en transito.  Sin embargo no proporciona ninguna garant��a de confidencialidad,  es decir, los datos transmitidos pueden ser vistos por terceros. Es importante indicar que AH asegura la integridad y autenticidad de los datos transportados y de la cabecera IP.[www. 0.13] 
       
       

       
       

      Fig 3.12 Funcionamiento del protocolo AH 
       

      3.8.4.2 PROTOCOLO ESP 

      El objetivo principal del protocolo ESP(Encapsulating Security Payload) es proporcionar confidencialidad,  para esto especifica el modo de cifrar los datos  que se desean enviar y como este contenido cifrado se incluyen en un datagrama IP.  Adicionalmente puede ofrecer los servicios de integridad y autenticaci��n del origen de los datos incorporando un mecanismo similar al de AH. 

       
       

      Fig. 3.13 Funcionamiento del protocolo ESP 

      3.8.4.3 PROTOCOLO IKE 

      El IETF a definido el protocolo IKE para realizar la funci��n de gesti��n autom��tica  de claves como el establecimiento de las SAs correspondientes.  Una caracter��stica importante de IKE es que su utilidad no se limita a IPSec,  si no que es un protocolo est��ndar  de gesti��n de claves  que podr��a ser ��til en otros protocolos como por ejemplo: OSPF, RIPv2.  Consiste en establecer una conexi��n cifrada y autenticada entre dos entidades, a trav��s de la cual se negocian los par��metros  necesarios para establecer una asociaci��n de seguridad IPSec. 

       
       

      Fig 3.14 Funcionamiento de IKE

      Los servicios que ofrecen los  componentes principales de IPSec son los siguientes: 


        AH ESP (solo encriptaci��n) ESP (encriptaci��n mas autentificaci��n)
      Control de acceso X X X
      Integridad de la conexi��n X   X
      Autentificaci��n en el origen de los datos X   X
      Rechazo de paquetes retocados X X X
      Confidencialidad   X X
      Confidencialidad limitada por el tr��fico   X X

      Tabla 3.3 Servicios de IPSec 

      3.8.5 FUNCIONAMIENTO DE IPSec 

      El diseño de IPSec plantea dos formas de funcionamiento para sus protocolos:  modo de transporte y modo de t��nel,  la diferencia se ve en la unidad que se esta protegiendo en modo transporte se protege la carga ��til IP (capa de transporte), en modo t��nel se protegen paquetes IP (capa de red) y se pueden implementar tres combinaciones: AH en modo transporte, ESP en modo transporte, ESP en modo t��nel (AH en modo t��nel tiene el mismo efecto que en modo transporte).  

      3.8.5.1 Modo Transporte: la encriptaci��n se realiza extremo a extremo, es decir del host de origen al host de destino. Para extender en una empresa el uso de IPSec en modo transporte es necesario que todos los hosts tengan una implementaci��n de IPSec. 

       
       

      Fig. 3.15 Aplicaci��n de IPSec modo transporte 

      Los paquetes de la capa de transporte como TCP y UDP pasan a la capa de red, que agrega el encabezado IP y pasa a las capas inferiores; cuando se habilita IPSec en modo transporte, los paquetes de la capa de transporte pasan al componente de IPSec (que es implementado como parte de la capa de red, en el caso de sistemas operativos), el componente de IPSec agrega los encabezados AH y/o ESP, y la capa de red agrega su encabezado IP. En el caso que se apliquen ambos protocolos, primero debe aplicarse la cabecera de ESP y despu��s de AH, para que la integridad de datos se aplique a la carga ��til de ESP que contiene la carga ��til de la capa de transporte, esto se muestra en la Fig. 3.13. [www. 012]

       
       

      Fig. 3.16 Formato del paquete con AH y ESP 

      3.8.5.2 Modo T��nel: el encriptado se efect��a ��nicamente entre los routers de acceso a los hosts implicados. En este caso la informaci��n viaja no encriptada en la parte de la red local. El funcionamiento de IPSec en modo t��nel permite integrar de forma elegante IPSec en una VPN, ya que el mismo dispositivo que realiza el t��nel VPN se encarga de realizar las labores correspondientes al t��nel IPSec

       
       

      Fig. 3.17 Aplicaci��n de IPSec modo t��nel  

      IPSec en modo t��nel, tiene dos encabezados IP, interior y exterior. El encabezado interior es creado por el host y el encabezado exterior es agregado por el dispositivo que est�� proporcionando los servicios de seguridad. IPSec encapsula el paquete IP con los encabezados de IPSec y agrega un encabezado exterior de IP como se muestra en la Fig. 3.14

       
       

      Fig 3.18 Formato del paquete aplicando IPSec en modo t��nel

       

      Evidentemente el modo transporte es m��s fiable puesto que ofrece comunicaci��n segura host a host. Sin embargo el modo t��nel tiene la ventaja de que permite incorporar la seguridad sin necesidad de incorporar IPSec en los hosts; aunque la seguridad que se obtiene en este caso no es tan alta la sencillez de implantaci��n es mucho mayor y se consiguen la mayor parte de los beneficios del modo transporte, ya que se protege la parte m��s expuesta del trayecto, que corresponde precisamente a la infraestructura p��blica o del operador. En funci��n de las circunstancias que rodeen cada caso se deber�� optar por una u otra, pudiendo haber incluso situaciones h��bridas en las que en una misma empresa determinado  

      tipo de informaci��n baste protegerla con el modo t��nel mientras que para alg��n host concreto, que maneje informaci��n de mayor importancia, se deba utilizar el modo transporte. 

      Aunque en IPSec se prev�� la posibilidad de utilizar una amplia diversidad de algoritmos de autentificaci��n y encriptado el ��nico exigido para todas las implementaciones es el DES (Data Encription Standard) que utiliza claves de 56 bits. Desde hace unos años se sabe que DES es relativamente poco seguro, ya que el c��digo puede ser descifrado utilizando fuerza bruta en un tiempo no demasiado grande con un ordenador potente actual, por lo que tambi��n se suele utilizar

      bastante Triple DES, que es mucho m��s seguro aunque tambi��n algo m��s costoso de calcular.  

      3.8.6 POLITICAS DE SEGURIDAD DE IPSec 

      La pol��tica es uno de los componentes m��s importantes de la arquitectura de IPSec, determina los servicios de seguridad que ser��n aplicados a un paquete. Las pol��ticas de seguridad son tambi��n almacenadas en una base de datos (Security Policy Database, SPD) indexada por seleccionadores.

      La SPD es consultada tanto para el procesamiento de salida como el de entrada, se propone un administrador de la SPD para agregar, borrar y modificar; no hay un est��ndar que lo defina, pero se propone que los seleccionadores contengan los siguientes campos:  

      Direcci��n fuente: puede ser indistinta, un rango de direcciones, un prefijo de red, o una direcci��n IP espec��fica. Indistinta en el caso de que sea la misma pol��tica para todos los paquetes con un mismo host de origen, el rango de direcciones y prefijo de red, para los gateways de seguridad y para VPNs, la direcci��n espec��fica para un host con varias direcciones, o en un gateway cuando los requerimientos de alg��n host sean espec��ficos.  

      Direcci��n destino: puede ser indistinta, un rango de direcciones, un prefijo de red, o una direcci��n IP espec��fica (homologada o no). Los tres primeros para gateways de seguridad, la direcci��n espec��fica como ��ndice para la SPD.  

      Nombre: nombre de un usuario o sistema sobre el cual se aplique la pol��tica de forma espec��fica.  

      Protocolo: el protocolo de transporte.  

      Puertos de capas superiores: los puertos  fuente y destino sobre los que se aplica la pol��tica. [www.013] 


Search more related documents:C A P I T U L O III
Download Document:C A P I T U L O III

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com
TOP