INSTITUTO TECNOLGICO

DE
ACAPULCO

Prctica SSL
ADMINISTRACIN DE
LA SEGURIDAD

Profesor:
Dr. Eduardo de la Cruz Gmez
Alumnas:
Martnez Crdenas Erika
07320406
Salmern Romn Marina Nohemi
07320470
Silverio Valdez Martha Lizbeth
Acapulco, Gro., a 6 de Diciembre
de 2011

NDICE
INTRODUCCIN................................................................................................... 2
MARCO TERICO................................................................................................. 2
HISTORIA.......................................................................................................... 2
SSL................................................................................................................... 3
Protocolo TLS - TransportLayer Security...........................................................7
Protocolo S-HTTP.............................................................................................. 7
DESARROLLO...................................................................................................... 8
PREGUNTAS....................................................................................................... 16
CONCLUSIN..................................................................................................... 17
BIBLIOGRAFA.................................................................................................... 17

INTRODUCCIN
El protocolo SSL (Secure Sockets Layer) es un protocolo de comunicacin
que se ubica en la pila de protocolos sobre TCP/IP5.2. SSL proporciona
servicios de comunicacin ``segura'' 5.3 entre cliente y servidor, como
por ejemplo autenticacin (usando certificados), integridad (mediante
firmas digitales), y privacidad (mediante encriptacin).
El protocolo se dise de forma escalable permitiendo la eleccin de
diversos algoritmos para la criptografa, compendios y firmas. Esto
permite que la eleccin del algoritmo pueda hacerse teniendo en cuenta
cuestiones legales, de exportacin u otras preocupaciones, y tambin
permite al protocolo aprovecharse de nuevos algoritmos. Las opciones
se negocian entre el cliente y servidor al comienzo de la sesin.
Hay varias versiones del protocolo, la primera, SSL v1 fue creada por
Netscape Corporation y nunca tuvo uso pblico. La versin 2 ya formaba
parte del las primeras versiones del navegador Netscape Navigator.
Actualmente la versin que incluyen todos los navegadores de ltima
generacin es SSL v3. El nuevo paso se llama TLS (Transport Layer
Security), este nuevo protocolo ha sido diseado por el IETF (Internet
Engeneering Task Force) [47] como una ampliacin de SSL v3 con
mejoras en la forma de realizar la autenticacin. Por ltimo y muy
relacionado con el anterior ha surgido WTLS (Wireless Transport Layer
Security) que implementa un TLS para comunicaciones inalmbricas.

MARCO TERICO
HISTORIA
Netscape desarroll la primera versin de SSL en 1994. Est primera
versin jams fue implementada de forma pblica. Tan slo unos pocos
meses despus liber una importante actualizacin que vino a llamarse
SSL 2.0 y que si tuvo una implementacin real a pesar de ir aquejada de
importantes errores de diseo. En noviembre de 1995 Netscape publica
la especificacin para SSL 3.0 la cual desde entonces, se ha convertido
en el estndar para comunicaciones seguras entre clientes y servidores
en Internet.
El objetivo de Netscape era crear un canal de comunicaciones seguro
entre un cliente y un servidor que fuese independiente del sistema
operativo usado por ambos y que se beneficiara de forma dinmica y
flexible de los nuevos adelantos en materia de cifrado a medida de que
estos estuvieran disponibles. SSL fue diseado como un protocolo
seguro de propsito general y no teniendo en mente las necesidades
especficas del comercio electrnico.

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
sesin del modelo OSI (o entre la capa de transporte y la de aplicacin
del modelo TCP) y est formado, a su vez, por dos capas y cuatro
componentes bien diferenciados.

Figura 1.Capas (y protocolos) para una navegacin de usuario

con SSL.

El protocolo de registro (Record Protocol) 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 comunicacin.
El verdadero corazn 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 simtrico.
Tambin es responsabilidad de este protocolo coordinar los estados de
ambos extremos de la transmisin.
El protocolo de Alerta es el encargado de sealizar problemas y errores
concernientes a la sesin SSL establecida.
Por ltimo, el ChangeCipherSpecProtocol 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.
SSL trabaja de la siguiente forma:
En primer lugar intercambiamos una clave de longitud suficiente
mediante un algoritmo de cifrado asimtrico. Mediante esa clave
establecemos un canal seguro utilizando para ello un algoritmo simtrico
previamente negociado. A continuacin, 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 enva los resultados. El estado de todas

estas operaciones son controladas mediante una mquina de control de
estados. Una sesin SSL puede comprender mltiples conexiones.
Adicionalmente, se pueden establecer mltiples sesiones SSL
simultneas.
A continuacin veremos todos estos procesos con un poco ms de
detalle.
El protocolo de Handshake es el encargado de negociar los atributos de
la sesin SSL que permitirn construir un canal seguro de
comunicaciones.
En primer lugar el cliente enva un mensaje ClientHello al servidor el
cual debe de responder con un mensaje similar de Server Hello. Estos
mensajes son utilizados para dar a conocer ciertas caractersticas de
ambos: versin del protocolo usado, algoritmos de cifrado conocidos y
preferidos, longitudes mximas de clave que admite para cada uno de
ellos, funciones hash y mtodos de compresin a utilizar. Adicionalmente
cliente y servidor pueden intercambiar dos nmeros generados
aleatoriamente para ser usados como sal. En este momento, adems, el
servidor asigna un identificador a la sesin y se hace constar la fecha y
hora de la misma. El identificador de sesin es enviado al cliente en el
mensaje de Server Hello. Si el servidor no respondiera con un mensaje
de Server Hello ste no fuese vlido o reconocible la sesin abortara
inmediatamente. Generalmente el servidor, el segundo en contestar,
elige los algoritmos ms fuertes de entre los soportados por el cliente. Si
no hay acuerdo en este punto se enva un mensaje de error y se aborta
la sesin.
A continuacin del mensaje de Server Hello, el servidor puede enviar su
Certificado (tpicamente un X.509) de forma que sea autenticado por el
cliente y que, adems, este reciba su clave pblica. Si no es as, le enva
al cliente su clave pblica mediante un mensaje de Server Key Exchange
(o tambin si ha enviado su Certificado y este es nicamente para firma
y autenticacin).
Est claro es que al menos uno de estos dos mensajes es necesario para
establecer el canal seguro. Un ltimo mensaje que puede enviar el
servidor en esta fase de negociacin es una solicitud de certificado al
cliente.
Por ltimo, la fase concluye con el envo, por parte del servidor, de un
mensaje de Server Hello Done. Si el Servidor ha solicitado su certificado
al cliente, este debe de responder con l o con un mensaje de alerta
indicando que no lo posee.

A continuacin se enva un mensaje de Client Key Exchange donde el

cliente enva al servidor, cifrada mediante la clave pblica de este, la
clave maestra, un nmero aleatorio generado por l y que actuar como
clave del algoritmo simtrico acordado para el intercambio de datos.
Por ltimo, si el cliente ha enviado un certificado y este tiene
capacidades de firma, enviar adicionalmente un mensaje de
CertificateVerify firmado digitalmente con cliente da por concluida la
fase
mediante
un
mensaje
de
ChangeCipherSpec
seguido,
inmediatamente, de un mensaje de Finished que ya va cifrado mediante
los algoritmos y claves recin negociados.
En
respuesta,
el
servidor
enva
su
propio
mensaje
de
ChangeCipherSpecy, a continuacin, su mensaje de Finished cifrado con
los parmetros negociados. En este momento finaliza la fase de
Handshakey cliente y servidor pueden intercambiar datos libremente.
Podemos ver un esquema de este intercambio de mensajes en la
siguiente figura:

Figura 2. Intercambio de mensajes

Durante la transmisin de datos los mensajes son fragmentados y

comprimidos por el protocolo de registro antes de su envo y
descomprimidos y reconstruidos por el mismo protocolo al otro extremo

de la comunicacin. El algoritmo de compresin utilizado es

caracterstico de la sesin y se negocia, como hemos visto, en la fase de
Handshake.
Los mensajes que provengan del navegador primero se dividen en
unidades de hasta 16 KB. Si se activa la compresin, cada unidad se
comprime por separado. Despus de eso, se deriva una clave secreta a
partir de las dos marcas aleatorias y la clave premaestra se concatena
con el texto comprimido y al resultado se le aplica un hash con el
algoritmo de hash acordado (por lo general
MD5). Este hash se agrega a cada fragmento como el MAC. Despus, el
fragmento comprimido y el MAC se encriptan con el algoritmo de
encriptacin simtrico acordado (por lo general, aplicndole un OR
exclusivo con el flujo de claves RC4). Por ltimo, se agrega un
encabezado de fragmento y el fragmento se transmite a travs de la
conexin TCP.

Figura 3. Transmisin de datos mediante SSL

Como hemos dicho, SSL es capaz de trabajar de forma transparente con

todos los protocolos que trabajan sobre TCP. La IANA tiene asignado un
nmero de puerto por defecto a cada uno de ellos que podemos ver en
la tabla siguiente:

Tabla 1. Puertos

Estos puertos son vlidos tambin para las implementaciones de estos

mismos protocolos sobre TLS.

Protocolo TLS - TransportLayer Security

En 1996, Netscape Communications Corp. mand el SSL a la IETF para
su estandarizacin. El resultado fue TLS (Seguridad de Capa de
Transporte). Se describe en el RFC 2246.
Los cambios hechos a SSL fueron relativamente pequeos, pero slo lo
suficiente para que
SSL versin 3 y TLS no puedan interoperar. Por ejemplo, la forma en que
se deriva una clave de sesin a partir de la clave premaestra y las
marcas aleatorias se cambi para hacer que la clave fuera ms fuerte
(es decir, fuera difcil de criptoanalizar). La versin TLS tambin se
conoce como SSL versin 3.1. Las primeras implementaciones
aparecieron en 1999.
TLS busca integrar en un esquema tipo SSL al sistema operativo, a nivel
de la capa TCP/IP, para que el efecto "tnel" que se implement con SSL
sea realmente transparente a las aplicaciones que se estn ejecutando.
Parte de las mismas bases que SSL, pero se diferencia de l en varios
aspectos fundamentales:
1. En el paso CertificateRequest del protocolo Handshake los clientes
slo contestan con un mensaje si son SSL.
2. Las claves de sesin se calculan de forma diferente.
3. A la hora de intercambiar las claves, TLS no soporta el algoritmo
simtrico Fortezza, que s es soportado por SSL. Esto es debido a la
bsqueda de un cdigo pblico, ya que Fortezza es de propiedad
privada.

4. TLS utiliza dos campos ms en el MAC que SSL, lo que lo hace ms

seguro.

Protocolo S-HTTP
El protocolo Secure HTTP fue desarrollado por Enterprise Integration
Technologies, EIT, y al igual que SSL permite tanto el cifrado de
documentos como la autenticacin mediante firma y certificados
digitales, pero se diferencia de SSL en que se implementa a nivel de
aplicacin. Se puede identificar rpidamente a una pgina web servida
con este protocolo porque la extensin de la misma pasa a ser .shtml en
vez de .html como las pginas normales.
El mecanismo de conexin mediante S-HTTP, que ahora se encuentra en
su versin 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 criptogrficos, longitudes de
clave y algoritmos de compresin a usar durante la comunicacin
segura.
En cuanto a estos algoritmos, lo usados normalmente son RSA para
intercambio de claves simtricas, MD2, MD5 o NIST-SHS como funciones
hash de resumen, DES, IDEA, RC4 o CDMF como algoritmos simtricos 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 aplicacin, como ya hemos dicho, negocindose los
servicios de seguridad a travs de cabeceras y atributos de pgina, por
lo que los servicios S-HTTP estn slo disponibles para el protocolo HTTP.
Recordemos que SSL puede ser usado por otros protocolos diferentes de
HTTP, por lo que se integra a nivel de shocked.

DESARROLLO
Para la realizacin de esta prctica utilizamos las siguientes
herramientas:
Dos computadoras con sistema operativo Windows 7, una fue
utilizada como sniffer y la otra como cliente.
Una computadora con sistema operativo Centos 5.5.
Openssl
Conexin a Internet

1. Comenzaremos instalando openssl, este nos servir para crear un

certificado digital.

2. Ahora accederemos a httpd.conf con el siguiente comando cd

/etc/http/conf y vamos a crear 3 directorios con el comando
mkdir ssl.crt ssl.csr ssl.key

2. Verificamos que los directorios se hayan creado correctamente.

3. Ahora accedemos al directorio ssl.key, para poder ejecutar el

comando openssl genrsa out ca.key 1024, para generar
una llave.

4. Cuando estamos en el directorio ssl.key

ejecutamos el
siguiente comando cat ca.key y continuacin se nos solicitara
una clave para poder iniciar el servicio de Apache seguro,
donde debemos ingresar una contrasea es nuestro caso
pondremos: gustavo.

5. Despus de haber generado nuestra clave, nos cambiamos de

directorio al ssl.csr y ejecutamos el siguiente comando
openssl req days 365 new key ../ssl.key/ca.key out
ca.csr, con este comando estaremos creando un certificado
digital con un ao de validez. Despus de ejecutar el comando
nos solicitara una informacin para que se complete el proceso
de la creacin del certificado digital.

6. Ahora con el comando cat ca.csr visualizamos lo que

acabamos de crear y vemos que se encuentra encriptada la
informacin.

7. Para finalizar la creacin de nuestro certificado digital

ejecutamos el comando openssl x509 req days 365 in
../ssl.csr/ca.csr signkey ../ssl.key/ca.key out ca.crt.

8. Para visualizar nuestro certificado recin creado ejecutamos el

comando cat ca.crt y cmo podemos observar la informacin
se encuentra cifrada.

9. Despus de haber creado el certificado, accedemos al directorio

conf que se encuentra en /etc/httpd/conf y copiamos los
archivos que creamos anteriormente con los siguientes
comandos.
cp.ssl.crt/ca.crt /etc/pki/tls/certs/
cp.ssl.key/ca.key /etc/pki/tls/private/
cp.ssl.csr/ca.csr /etc/pki/tls/private/

10. Ahora configuraremos los archivos httpd.conf y ssl.conf

para poder usar el certificado digital. Para que nuestro servidor
Web pueda usar el certificado digital debemos realizar algunos
cambios en el archivo de configuracin de Apache y del
archivo de configuracin SSL.
Tendremos que modificar el archivo que se encuentra en
etc/httpd/conf.d/ssl.conf, para poder especificar las direcciones en
donde hemos guardado los certificados digitales que hemos creado.

11. Abrimos el archivo y modificamos los siguientes valores,

descomentamos la lnea que dice listen 443.

12. Ahora escribiremos el nombre del dominio del servidor

virtual, el puerto de escucha y la ruta donde est alojado el
dominio /var/www.html/ y colocamos el nombre de nuestro
dominio o la direccin IP de nuestro servidor.

13. Agregamos al archivo los certificados digitales que creamos.

SSLCertificateFile /etc/pki/tls/certs/ca.crt.

 SSLCertificateKeyFile /etc/pki/tls/private/ca.key

14. Ahora reiniciamos el servidor http para que se efecte la

relacin con el servidor ssl con el siguiente comando service

httpd restart.

15. A nuestra mquina cliente le asignamos una direccin IP y el

servidor DNS que tendr.

16. Ahora abrimos el navegador de la mquina cliente y

tecleamos la direccin IP del servidor que en nuestro caso es
192.168.1.201 y nos mostrara el siguiente mensaje.

Captura en wireshark. Podemos observar en la captura el

inicio de sesin.

Ahora ponemos ver la fase de intercambio de claves. El servidor

web enva informacin de la llave pblica y autoridad del
certificado.

Ahora podemos observar la fase de produccin de clave de sesin.

El navegador verifica el certificado y al mismo tiempo enva una
clave de sesin encriptada.

Por ltimo podemos observar la fase de finalizacin en donde se

indica que se puede comenzar la sesin de transferencia de
informacin segura.

PREGUNTAS
QU DIFERENCIA EXISTE ENTRE UNA VPN Y UN SERVICIO
HTTPS?
La diferencia entre HTTPS (SSL/TLS) y VPN es que en HTTPS slo se
cifran los datos reales de un paquete. Con VPN se puede cifrar y
encapsular todo el paquete todo el paquete para crear un tnel
seguro. Ambas tecnologas se pueden utilizar en paralelo, aunque no se
recomienda, ya que cada tecnologa aadir una carga adicional que
puede disminuir el rendimiento del sistema.

CULES ALGORITMOS SON SOPORTADOS POR SU PROPUESTA

DE SERVIDOR SEGURO? DEMUSTRELO.
La versin ms actual de SSL es la 3.0. que usa los algoritmos simtricos
de encriptacin DES, TRIPLE DES, RC2, RC4 e IDEA, el asimtrico RSA, la
funcin hash MD5 y el algoritmo de firma SHA-1.
EXISTE EVIDENCIA DE UN ATAQUE EXITOSO A ESTE SISTEMA?
1995
En septiembre de 1995 se publica por primera vez una advertencia
sobre la posibilidad de romper en un tiempo computacional moderado
las claves de 40 bits usadas por algunos de los algoritmos de la versin
2.0 de SSL. El problema reside en el generador de nmeros aleatorios
usado por el navegador (PRNG) y los artfices del descubrimiento fueron
David Wagner e IanGolberg quienes lograron obtener la clave de sesin
en unas pocas horas usando para ello un simple ordenador de los de
aquella poca.
1998
Enero de 1998. Varios errores que posibilitan provocar un buffer overflow
en distintos mdulos de Apache (cfg_getline, mod_proxy, logresolve)
permitiran leer las claves SSL que permanecen sin cifrar en la memoria
del servidor web.
En junio de 1998, el CERT (Coordination Center) publica un extenso
report denunciando una vulnerabilidad en algunas implementaciones de
productos que usan PKCS#1 (Public-Key Cryptography Standard #1) de
RSA que permitira obtener informacin confidencial de una sesin
cifrada mediante SSL. PKCS#1 se usa durante la fase de negociacin de
la sesin SSL.
1999
En agosto de 1999, L0pht denuncia a travs de Security Focus que
pueden explotarse ciertas debilidades en el diseo del protocolo IRDP
(ICMP Router DiscoveryProtocol) para realizar ataques de diferentes tipos
sobre un host, y en particular en el caso que nos atae posiblitar un
ataque de Man-in-the-Middle sobre un servidor SSL.

En noviembre de 1999 se publica en Security Focus un exploit que

permite tirar un servidor Netscape Enterprise Server a travs de un bug
en el cdigo del mecanismo de Handshake del servicio SSL.
En diciembre de 1999 se publica un error en la implementacin SSL del
Internet Information Server (IIS) de Microsoft en sus versiones 3.0 y 4.0
que permitira obtener texto en claro dentro de una conexin SSL

2000
En febrero de 2000, el CERT publica una advertencia sobre la posibilidad
de la inclusin de determinados scripts maliciosos en una pgina html
generada dinmicamente que provocan el envo de informacin hacia un
determinado servidor sin que el usuario lo advierta. En una conexin
SSL, si se logra introducir el script antes de que la conexin sea
establecida entre cliente y servidor, podemos usarlo para robar
informacin de dicha conexin o para enviar informacin maliciosa al
servidor SSL
En marzo de 2000 se publican numerosos errores capaces de provocar
un buffer overflow en Lynx, un popular navegador web que slo admite
texto disponible en diferentes versiones para varios sistemas operativos
y con posibilidad de entablar sesiones SSL que se ven afectadas por esta
vulnerabilidad. Las versiones afectadas son las anteriores a la
2.8.3pre.5.
En mayo de 2000 el CERT publica un error que afecta a la forma de
validacin de una sesin SSL por parte del navegador de Netscape. El
problema afecta a las versiones del navegador iguales o inferiores a la
4.72. El error permite que el navegador acepte un certificado invlido al
entablar una sesin SSL sin mostrar un mensaje de advertencia al
usuario.
Tambin en mayo de 2000 se publica un nuevo error en los navegadores
de Netscape que permitira a un posible atacante explotar nuevos
errores en el tratamiento y validacin de los certificados por parte del
mismo. En esta ocasin la vulnerabilidad afecta a la versin 4.73 e
inferiores del navegador.
En junio de 2000 se descubre un problema similar al anterior pero que,
en esta ocasin, afecta al navegador de Microsoft (Internet Explores). En
esta ocasin el error desvela que cuando realizamos una conexin sobre

un servidor SSL a travs de un link situado en un frame o en una

imagen, el Internet Explorer verifica que el certificado recibido ha sido
firmado por una autoridad vlida pero, incomprensiblemente, no
comprueba si el nombre del servidor que lo enva corresponde con el
que aparee en el certificado ni si la fecha de validez del certificado ha
expirado. El problema afecta a las versiones 4.x y 5.x del navegador y
fue corregido a partir de la versin 5.5 o mediante Services Packs para
algunas de las versiones anteriores.
En junio de 2000 se publica una nueva vulnerabilidad en la versin 4.72
de Netscape Navigator que puede comprometer la informacin de una
sesin SSL. El problema es corregido por la versin 4.73 del navegador.
Junio de 2000. Se detecta la omisin de las librerias de generacin de
nmeros pseudo aleatorios en algunas versiones del sistema operativo
FreeBSD para mquinas basadas en procesadores Alpha de Digital. El
problema puede afectar de forma impredecible a cualquier aplicacin
que realice cifrados y utilice esas libreras, entre ellas todas las
implementaciones de SSL. Las versiones de FreeBSD para plataformas
Intel no estaban afectadas.
Agosto de 2000. Se detectan dos errores en STRONG, el componente
que realiza las veces de servidor web en el servidor PKI de NAI (Network
Associates Inc.). Por un lado, la posibilidad de explotar una
vulnerabilidad de buffer overflow sobre dicho servidor web y por otro la
posibilidad de que un cualquier usuario se conecte al puerto 444 del
servicio PKI sin que se requiera su autenticacin.
En octubre de 2000 se denuncia la posibilidad de explotar un buffer
overflow sobre las versiones de curl y curl-ssl distribuidas con la versin
2.2 de Debian GNU/Linux. Curl es un popular cliente que facilita la
obtencin de ficheros y documentos de un servidor, diseado para
trabajar sin necesidad de interaccin con el usuario.
Octubre de 2000. Una nueva vulnerabilidad en las versiones 4.0 y 5.0 de
IIS (Internet Information Server) permite que, bajo un muy restringido
conjunto de circunstancias, un usuario malintencionado pueda robar a
otro el control de una sesin SSL contra el servidor afectado.
En noviembre de 2000 se descubre un error en el servicio LDAP sobre
SSL de las implementaciones que acompaan a las versiones 5.2, 6.x y
7.0 de Red Hat Linux.
En diciembre de 2000 se encuentra un error en todas las
implementaciones VPN de la empresa VPNet. El cliente de dichas
implementaciones. El cual usa SSL para negociar las conexiones,

responde en claro en alguno de los mensajes que deberan de ir cifrados

desvelando informacin sensible.
Para cerrar el ao 2000 se descubren varios errores (uno de ellos con la
disponibilidad de un exploit remoto) en las versiones inferiores a la 3.9
de stunnel, un popular paquete que ofrece un servicio de conexin SSL
genrico para envolver con el otros protocolos TCP, tales como pop3,
ldap, etc.
2001
En abril de 2001 se desvelan un grupo de potenciales problemas de
seguridad en OpenSSL, la ms popular de las implementaciones libres
de SSL usadas, entre otros, por los servidores web Apache. Las versiones
de OpenSSL anteriores a la 0.9.6.a sufren de importantes errores en el
mecanismo de intercambio de claves de la versin 3.0 del protocolo,
errores en la generacin de nmeros pseudo aleatorios, errores en los
permisos de ciertos archivos sensibles, etc.
En junio de 2001 se denuncia un bug sobre el paquete SSL de fetchmail
susceptible de ser explotado de forma remota.
En junio de 2001 asimismo se detecta un error en la implementacin de
LDAP sobre SSL de los productos de Microsoft.
En agosto de 2001 se detecta la posibilidad de explotar un buffer
overflowwn el paquete de Telnet sobre SSL versin 0.16.3-1 distribuido
junto con Debian GNU/Linux de nombre clave Potato
En septiembre de 2001 CISCO System hace pblica una vulnerabilidad
en la implementacin de SSL de la versin 2.0 de su librera iCND
mediante la cual es posible establecer una sesin SSL con el servidor
afectado sin necesidad de contar con un certificado vlido en el cliente a
pesar de que este sea requerido por el servidor. La vulnerabilidad es
corregida en la versin 2.0.1 de dicha implementacin.
Octubre de 2001. Se detecta un error en w3m y w3m-ssl, las funciones
que manejan las cabeceras de MIME para la implementacin de este
protocolo y distribuidas con la versin 2.2 de Debian Linux.
En octubre de 2001 se denuncia una vulnerabilidad en la
implementacin de SSL en Stronghold, un servidor web basado en
Apache y distribuido junto con algunas versiones de Red Hat Linux.
En diciembre de 2001 se detecta una nueva vulnerabilidad en STunnel.

2002
En febrero de 2002 se descubre un error en la librera mod_ssl de
OpenSSl, utilizada por Apache.
En julio de 2002 se encuentra un nuevo error sobre la misma librera
mencionada anteriormente (mod_ssl).
En agosto de 2002 se denuncia un error que afecta a la librera de SSL
que maneja Konqueror, el navegador web del popular escritorio de Linux
KDE. El error provoca que el mencionado navegador no verifique al
establecer una conexin SSL si el certificado del Servidor es vlido para
la actividad que realiza contentndose con recibir un certificado firmado
por una autoridad vlida, independientemente de la actividad que se
autorice en el.
Agosto de 2002. Se denuncia una vulnerabilidad en la implementacin
de SSL de Internet Explorer que permite realizar fcilmente un ataque de
Man-in-the- Middle. Las versiones afectadas son las 5.x y 6.x de este
navegador.
Agosto de 2002. Hewlett Packart advierte de que sus sistemas HP Tru64
UNIX & HP OpenVMS se ven afectados por los errores encontrados en la
implementacin de las libreras de OpenSSL.
Septiembre de 2002. Importante error en la validacin de certificados
realizada por Microsoft y que afecta a todas las versiones de sus
sistemas operativos (exceptuando a windows95) y las implementaciones
de sus navegadores web y sistemas de correo para ordenadores Mac.
Septiembre de 2002. El da 16 aparece la anunciada primera versin de
Slapper, un gusano que se difunde automticamente por la red a travs
de la vulnerabilidad de OpenSSL denunciada el 30 de julio y que afecta a
la gran mayora de implentaciones del servidor web Apache, el ms
popular de la red. Slapper utiliza para introducirse en la mquina un
exploit que provoca un desbordamiento de buffer en las
implementaciones de Apache Web Server sobre mquinas Linux. Slapper
es capaz de realizar ataques distribuidos de denegacin de servicio a
travs del puerto UDP 2002 de las mquinas infectadas. Su peligrosidad
es muy baja puesto que su cdigo no posee ningn payload daino.
Durante los siguientes das aparecieron tres nuevas variantes de este
virus que se detectaron por primera vez los das 23 y 24 de septiembre y
el da 1 de octubre respectivamente. Actalmente no se encuentra en
circulacin.

En septiembre de 2002 aparece una nueva vulnerabilidad en las librerias

de OpenSSL usadas por Apache.
Octubre de 2002. Varios errores que son susceptibles de ser explotados
mediante buffers overflows que afecta anfetchmail-ssl.
En octubre de 2002 se detecta un nuevo error en el mdulo mod_ssl de
la librera OpenSSL usada por Apache susceptible de posibilitar un
ataque por Cross-Site Scripting. El Croos-Site Scripting es una tcnica
mediante la cual es posible conseguir que un servidor web legtimo
enve una pgina web falsa que contenga cdigo malintencionado como
respuesta a una peticin del cliente.
Noviembre de 2002. Nuevos errores en la validacin de certificados por
parte de la implementacin SSL del escrtitorio KDE.

CONCLUSIN
A lo largo del desarrollo de esta prctica lo primer que se hizo fue crear
una llave de autenticacin para que desde la maquina cliente se pudiera
acceder a la pgina web alojada en nuestro servidor de forma segura
mediante el protocolo https. Para la mquina que iba a ser el servidor
hicimos un certificado digital el cual ser vlido por un ao.

BIBLIOGRAFA
http://www.axis.com/es/products/video/about_networkvideo/sec
urity.htm
http://pics.unlugarenelmundo.es/hechoencasa/ssl%20secure
%20sockets%20layer%20y%20otros%20protocolos%20seguros
%20para%20el%20comercio%20electronico.pdf
http://www.educastur.princast.es/fp/hola/hola_bus/cursos/curso1
7/documentos/seguras.pdf