Servicios WEB SEGURIDAD

1. WEB:
a. Presente un cuadro comparativo de las categoras de amenazas a los servicios Web
(sugerencia > Tabla 17.1 Pag 626 Cryptography and Network Security 4th Edition) e
investigue un tipo de ataque documentado en la Internet para cada categora (Integridad
Confidencialidad Denegacin de Servicio Autenticacin).

Integridad

Confidencialidad

Denegacin de Servicio

Autenticacin

AMENAZAS
Modificacin de los
datos de usuario.
Troyanos
en
el
navegador.
Modificacin
de
memoria.
Modificacin
de
mensajes durante el
trfico en trnsito.
Interceptando la red.
Robo de informacin
de servidor.
Robo
de
datos
desde el cliente.
Informacin
sobre
configuracin de red.
Informacin acerca
de lo hablado entre
cliente servidor.
Muerte de hilos de
usuario.
Inundacin
de
mquinas con falsas
peticiones.
Llenado de disco o
memoria.
Aislamiento
de
mquinas
por
ataques DNS.
Suplantacin
de
usuarios legtimos.
Falsificacin
de
datos.

CONSECUENCIAS
Perdida
de
informacin.
Maquina
comprometida.
Vulnerabilidad
de
otras amenazas.

Perdida
informacin.
Perdida
privacidad.

de

CONTRAMEDIDAS
Sumas
de
comprobacin
criptogrfica.

Cifrado, proxi.

de

Disruptivo.
Molestias.
Evita que el usuario
obtenga el trabajo
realizado.

Difcil de prevenir.

La tergiversacin de
usuario.
La creencia de que
informacin falsa es
vlida.

Tcnicas
criptografa.

Tipos de Ataque
1. Integridad: Los tipos de ataque ms conocido que afectan la integridad de los datos,
podemos tener en cuenta los cdigos maliciosos o Malware, los cuales son programas que
causan algn tipo de dao en el sistema informtico. Los tipos de Malware ms
comnmente conocidos son los troyanos, gusanos, virus informticos, spyware,
BackDoors, rootkits, Keyloggers, entre otros.

de

El tipo de cdigo malicioso ms utilizado es el troyano, segn el Informe sobre malware en

Amrica Latina, de ESET Latinoamrica, representa el 80% de los ataques informticos
reportados en el estudio.
Los troyanos son una aplicacin comn que ingresa al sistema de forma sigilosa y activan
una carga maligna denominada Payload que contiene el cdigo con las instrucciones
dainas. Dicho cdigo puede contener instrucciones para daar el disco duro, eliminar
archivos, monitorear el trfico de red, contar el nmero de clics, el nmero de pulsaciones
en el teclado entre otras.
Junto con los troyanos, los atacantes pueden agregar otra clase de intrusiones que
aprovechan la brecha abierta que ha dejado ya el troyano. Ataques como rootkits para
borrar las huellas que han dejado en el sistema y as poder seguir efectuando nuevas
intrusiones sin ser descubiertos.
2. Confidencialidad: Un ejemplo de este tipo de ataque es el sniffing. Es un ataque
realmente efectivo, ya que permite la obtencin de gran cantidad de informacin sensible
enviada sin encriptar, como por ejemplo usuarios, direcciones de e-mail, claves, nmeros
de tarjetas de crdito. El Sniffing consiste en emplear Sniffers u olfateadores en entornos
de red basados en difusin, como por ejemplo Ethernet (mediante el uso de
concentradores o Hubs). El anlisis de la informacin trasmitida permite a su vez extraer
relaciones y topologas de las redes y organizaciones.
Los Sniffers operan activando una de las interfaces de red del sistema en modo
promiscuo. En este modo de configuracin, el Sniffers almacenar en un log todo el trfico
que circule por la tarjeta de red, ya sea destinado o generado por el propio sistema o
desde/hacia cualquiera de los sistemas existentes en el entorno de red compartido
(segmento Ethernet). Asimismo, pueden ser instalados tanto en sistemas como en
dispositivos de red.
La efectividad de esta tcnica se basa en tener acceso (habitualmente es necesario
adems disponer de dicho acceso como administrador o root) a un sistema interno de la
red; por tanto, no puede ser llevado a cabo desde el exterior. Antes de la instalacin de un
Sniffers, normalmente se instalarn versiones modificadas (Trojanos) de comandos como
ps o netstat en entornos (Unix) para evitar que las tareas ejecutadas en el Sniffers sean
descubiertas.
3. Denegacin de Servicio: La mayora de estos tipos de ataque van asociados al
funcionamiento de los protocolos protocolos TCP y UDP. Escaneo de puertos,
inundaciones UDP, DoS por sobrecarga de conexiones, son algunos de los ataques a
dicha capa.
4.
Un ejemplo de ataque es el ataque de inundacin UDP, que es una Denegacin de
Servicio (DoS) mediante el User Datagram Protocol (UDP). El uso de UDP para ataques
de denegacin de servicio no es ms sencillo que el uso de TCP para el mismo fin.
El ataque de inundacin UDP puede ser iniciado por el envo de un gran nmero de
paquetes UDP a puertos aleatorios en un host remoto. Para un gran nmero de paquetes
UDP, los sistemas de las vctimas se vern obligados a enviar muchos paquetes ICMP.
Esto impide que el ICMP sea alcanzable por otros clientes. Adems, el atacante puede
falsificar la direccin IP de los paquetes UDP, garantizando que los ICMP de retorno no
lleguen a su fin.

5. Autenticacin: Dentro de este grupo podemos tener en cuenta el IP Spoofing, el cual es

un tipo de ataque que aqueja a la capa de red. Muchas empresas dentro de su gama de
servicios ofrecidos, asignan un rango de direcciones IP autorizadas a recibir algn tipo de
servicio; por medio del IP Spoofing, el atacante puede hacerse pasar por una direccin IP
vlida dentro de la red y usurpar el servicio de manera gratuita sin generar ninguna
sospecha. De esta manera estara estafando a la empresa y al usuario a quien le
correspondera realmente el servicio. Se puede entonces definir el impacto de los ataques
en la capa red de una red de una organizacin prestadora de servicios al tener en cuenta
los siguientes aspectos:

Perdida de informacin y suplantacin de identidad

Prestacin de servicios a usuarios falsos y denegacin a verdaderos
QoS (Calidad del Servicio) reducida en gran medida.

2. HTTP/HTTPS:
a. Cules son las caractersticas del protocolo HTTP y cul es su rol en el servicio Web?
Http es uno de los protocolos del modelo TCP/IP en su capa de aplicacin, el cual por sus
siglas traduce protocolo de transferencia de Hipertexto, es un sencillo protocolo cliente
servidor que articula los intercambios de informacin entre los clientes web y los
servidores HTTP.
Las principales caractersticas HTTP son:

Toda la comunicacin entre los clientes y servidores se realiza a partir de

caracteres US-ASCII de 7 bits.
Permite la transferencia de objetos multimedia, codificndolos archivos binarios
en cadena de caracteres. El contenido de cada objeto intercambiado esta
identificado por su clasificacin MIME.
Existen 8 verbos que permiten que un cliente pueda dialogar con el servidor. Los
tres mas utilizados son: GET, para recoger un objeto, POST, para enviar
informacin al servidor y HEAD, para solicitar las caractersticas de un objeto (por
ejemplo, la fecha de modificacin de un documento HTML).
Cada operacin HTTP implica una conexin con el servidor, que es liberada al
termino de la misma, Es decir, en una operacin se puede recoger un nico
objeto.
No mantiene estado. Cada peticin de uncliente a un servidor no es influda por
las transacciones anteriores. El servidor trata cada peticin como una operacin
totalmente independiente del resto.
Cada objeto al que se aplican los verbos del protocolo esta identificado a travs
de un localizador uniforme de recurso (URL) nico.

ROL EN EL SERVICIO WEB

b. Cmo funciona el mecanismo transaccional de HTTP?
1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML
o introducindola directamente en el navegador.
2. El cliente web descodifica la URL, separando sus diferentes partes. Asi identifica
el protocolo de acceso, la direccin DNS o IP del servidor, el puerto (de carcter
opcional; el valor por defecto es 80) y el objeto requerido del servidor.
3. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP
correspondiente.

4. Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST,

HEAD), la direccin del ojeto requerido, la versin del protocolo HTTP
empleada y u conjunto variable de informacin, que incluye datos sobre las
capacidades del navegador, datos opcionales para el servidor.
5. El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el
tipo de dato MIME de la informacin de retorno, segido de la propia informacin.
6. Se cierra la conexin TCP. Si no se utiliza el modo HTTP Keep Alive, este
proceso se repite para cada acceso al servidor HTTP.

c. Cul es el formato de mensajes HTTP [Request Response]?

Solicitud (Request)
Esta cabecera indica:

El mtodo utilizado por el cliente para solicitar el dcumento.

Mtodo GET
Es el ms habitual. Permite, adems de indicar la pgina que se solicita, "pasar"
variables en la solicitud. Por ejemplo:
GET /fotos.php?foto=40&altura=300 HTTP/1.0
Meidante esta cabecera, se solicita el fichero fotos.php y se "pasa" al servidor las
variable numero_de_foto y altura_de_foto, con valores de 40 y 300 respectivamente.
Mtodo POST

Se utiliza habitualmente cuando se envan datos a travs de un formulario. Permite,

igual que GET, enviar variables, pero lo hace de forma distinta.
POST /fotos.php HTTP/1.0
Accept-Encoding
Host: www.cibernetia.com
Referer: http://www.cibernetia.com/index.php
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows Me)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
numero_de_foto=40&altura_de_foto=300

El fichero que solicita el cliente

La versin del protocolo HTTP que se emplea en la conexin. Las versiones
actualmente en uso son la 1.0 y la 1.1. No todos los servidores (aunque s la
mayora) soportan la versin 1.1.

Por ejemplo:
GET /index.php HTTP/1.0
Mediante esta cabecera, el cliente indica que solicita, utilizando el mtodo GET y la
versin 1.0 del protocolo HTTP, el fichero index.php.
Response
Despus de recibir e interpretar un mensaje de solicitud, el servidor responde con un
mensaje de respuesta HTTP.
Respuesta = Estado-Line; Seccin 6.1
* ((Encabezado general; Seccin 4.5
| Respuesta de cabecera; Seccin 6.2
| Entidad cabecera) CRLF); Seccin 7.1
CRLF
[Mensaje-cuerpo]; Seccin 7.2
Status-Line
La primera lnea de un mensaje de respuesta es la lnea de estado, que consiste en la
versin del protocolo seguido por un cdigo de estado numrico y su frase textual
asociado, con cada elemento separado por caracteres sp. No se permite CR o LF
excepto en la secuencia CRLF final.
Status-Line = HTTP-Versin SP Status-Code SP Razn Frase CRLF
Cdigo y la Razn de estado Frase
El elemento Status-Code es un cdigo de resultado entero de 3 dgitos del intento de
comprender y satisfacer la solicitud. Estos cdigos estn completamente definidos en la
seccin 10. La Razn Frase pretende dar una breve descripcin textual del cdigo de
estado. El Cdigo del Estatuto est destinado para su uso por los autmatas y la Razn
Frase est pensado para el usuario humano. No se requiere el cliente para examinar o
mostrar la Frase Motivo-.
El primer dgito del Cdigo de Estado define la clase de respuesta. Las dos ltimas cifras
no tienen ningn papel categorizacin. Hay 5 valores para el primer dgito:
- 1xx: Informativo - Solicitud recibida, proceso continuo
- 2xx: xito - La accin fue recibida con xito,
entendido y aceptado

- 3xx: redireccin - Adems hay que tomar medidas con el fin de

completar la solicitud
- 4xx: Error de cliente - La solicitud contiene sintaxis incorrecta o no puede
cumplirse
- 5xx: Error del servidor - El servidor no pudo cumplir con una aparentemente
solicitud vlida
Los valores individuales de los cdigos de estado numricos definidos para HTTP / 1.1, y
un sistema de ejemplo de correspondiente Razn Frase de, se presentan a continuacin.
Las frases de razn mostrados aqu son slo recomendaciones - que podrn ser
sustituidos por sus equivalentes locales sin afectar el protocolo.
Status-Code =
"100"; Seccin 10.1.1 : Continuar
| "101"; Seccin 10.1.2 : Cambiar Protocolos
| "200"; Seccin 10.2.1 : OK
| "201"; Seccin 10.2.2 : Creado
| "202"; Seccin 10.2.3 : Aceptado
| "203"; Seccin 10.2.4 : Informacin no autorizada,
| "204"; Seccin 10.2.5 : Sin contenido
| "205"; Seccin 10.2.6 : Restablecer contenido
| "206"; Seccin 10.2.7 : Contenido parcial
| "300"; Seccin 10.3.1 : Multiple Choices
| "301"; Seccin 10.3.2 : Movido permanentemente
| "302"; Seccin 10.3.3 : Encontrado
| "303"; Seccin 10.3.4 : Ver Otros
| "304"; Seccin 10.3.5 : Not Modified
| "305"; Seccin 10.3.6 : Uso de Proxy
| "307"; Seccin 10.3.8 : redireccin temporal
| "400"; Seccin 10.4.1 : Solicitud incorrecta
| "401"; Seccin 10.4.2 : no autorizado
| "402"; Seccin 10.4.3 : Pago Obligatorio
| "403"; Seccin 10.4.4 : Prohibida
| "404"; Seccin 10.4.5 : no encontrado
| "405"; Seccin 10.4.6 : Mtodo no permitido
| "406"; Seccin 10.4.7 : No aceptable
| "407"; Seccin 10.4.8: Autentificacin de poder
| "408"; Seccin 10.4.9 Pregunta: Hora de salida
| "409"; Seccin 10.4.10 : Conflicto
| "410"; Seccin 10.4.11 : Gone
| "411"; Seccin 10.4.12 : Longitud Obligatorio
| "412"; Seccin 10.4.13 : Requisito Failed
| "413"; Seccin 10.4.14 : Solicitud Entidad demasiado grande
| "414"; Seccin 10.4.15 : Request-URI demasiado grande
| "415"; Seccin 10.4.16 : no compatible Tipo de soporte
| "416"; Seccin 10.4.17 : solicitada no cubre la satisfiable
| "417"; Seccin 10.4.18 : Expectativa Fall
| "500"; Seccin 10.5.1 : Error interno del servidor
| "501"; Seccin 10.5.2 : no implementado
| "502"; Seccin 10.5.3 : Bad gateway
| "503"; Seccin 10.5.4 : Servicio no disponible
| "504"; Seccin 10.5.5 : Pasarela fuera
| "505"; Seccin 10.5.6 : Versin de HTTP no compatible
|-Cdigo de extensin
-cdigo de extensin = 3digit
Razn Frase = * <TEXT, excluyendo CR, LF>

Cdigos de estado HTTP son extensibles. Aplicaciones HTTP no estn obligados a

entender el significado de todos los cdigos de estado registrados, aunque tal
entendimiento es obviamente deseable. Sin embargo, las aplicaciones deben entender la
clase de cualquier cdigo de estado, como lo indica el primer dgito, y tratar cualquier
respuesta no reconocida como equivalente al cdigo de estado x00 de esa clase, con la
excepcin de que una respuesta no reconocida, no debern almacenarse en cach. Por
ejemplo, si un cdigo de estado no reconocido de 431 es recibida por el cliente, se puede
asumir con seguridad que haba algo malo con su solicitud y tratar la respuesta como si
hubiera recibido un cdigo 400 de estado. En tales casos, los agentes de usuario deben
presentar al usuario la entidad volvi con la respuesta, ya que esa entidad es probable
que incluya la informacin legible humanidad que explicar la situacin inusual.
Respuesta Campos de cabecera
Los campos de cabecera de respuesta permiten al servidor para pasar informacin
adicional acerca de la respuesta que no puede ser colocado en la lnea de Status-. Estos
campos de cabecera dan informacin sobre el servidor y acerca an ms el acceso al
recurso identificado por el Request-URI.
respuesta-header = Accept-Ranges; Seccin 14.5
| Edad; Seccin 14.6
| ETag; Seccin 14.19
| Lugar; Seccin 14.30
| Proxy-Authenticate; Seccin 14.33
| Volver a intentar-Despus; Seccin 14.37
| Server; Seccin 14.38
| Vary; Seccin 14.44
| WWW-Identificacin; Seccin 14.47
Nombres de los campos de cabecera de respuesta se pueden extender de forma fiable
slo en combinacin con un cambio en la versin del protocolo. Sin embargo, los campos
de cabecera nuevos o experimentales se puede dar la semntica de los campos de
cabecera respuesta- si todas las partes en la comunicacin a reconocer a ser campos de
respuesta de cabecera. Campos de cabecera no reconocidos se tratan como campos
entidad cabecera.

d. Cules son las caractersticas tcnicas de HTTPS?

Hypertext Transfer Protocol Secure (en espaol: Protocolo seguro de transferencia de
hipertexto), ms conocido por sus siglas HTTPS, es un protocolo de aplicacin basado en el
protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir, es la
versin segura de HTTP.
El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo
nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) ms
apropiado para el trfico de informacin sensible que el protocolo HTTP. De este modo se
consigue que la informacin sensible (usuario y claves de paso normalmente) no pueda ser
usada por un atacante que haya conseguido interceptar la transferencia de datos de la
conexin, ya que lo nico que obtendr ser un flujo de datos cifrados que le resultar
imposible de descifrar.
El puerto estndar para este protocolo es el 443.

Netscape Communications cre HTTPS en 1992 para su navegador Netscape Navigator.1

Originalmente, HTTPS era usado solamente para cifrado SSL, pero esto se volvi obsoleto
ante TLS. HTTPS fue adoptado como un estndar web con la publicacin de RFC 2818 en
mayo del 2000.2
Diferencias con HTTP
En el protocolo HTTP las URLs comienzan con "http://" y utilizan por omisin el puerto 80, las
URLs de HTTPS comienzan con "https://" y utilizan el puerto 443 por omisin.
HTTP es inseguro y est sujeto a ataques man-in-the-middle y eavesdropping que pueden
permitir al atacante obtener acceso a cuentas de un sitio web e informacin confidencial.
HTTPS est diseado para resistir esos ataques y ser ms seguro.

Capas de red
HTTP opera en la capa ms alta del modelo OSI, la capa de aplicacin; pero el protocolo de
seguridad opera en una subcapa ms baja, cifrando un mensaje HTTP previo a la transmisin
y descifrando un mensaje una vez recibido. Estrictamente hablando, HTTPS no es un
protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de Conexin
Segura cifrada Secure Sockets Layer (SSL) o una conexin conSeguridad de la Capa de
Transporte (TLS).
Configuracin del servidor
Para preparar un servidor web que acepte conexiones HTTPS, el administrador debe crear
un certificado de clave pblica para el servidor web. Este certificado debe estar firmado por
una autoridad de certificacinpara que el navegador web lo acepte. La autoridad certifica que
el titular del certificado es quien dice ser. Los navegadores web generalmente son distribuidos
con los certificados raz firmados por la mayora de las autoridades de certificacin por lo que
estos pueden verificar certificados firmados por ellos.
Adquisicin de certificados
Adquirir certificados puede ser gratuito3 (generalmente slo si se paga por otros servicios) o
costar entre US$134 y US$1,5005 por ao.
Las organizaciones pueden tambin ser su propia autoridad de certificacin, particularmente
si son responsables de establecer acceso a navegadores de sus propios sitios (por ejemplo,
sitios en una compaa intranet, o universidades mayores). Estas pueden fcilmente agregar
copias de su propio certificado firmado a los certificados de confianza distribuidos con el
navegador.
Tambin existen autoridades de certificacin peer-to-peer.
Usar un control de acceso
El sistema puede tambin ser usado para la de clientes con el objetivo de limitar el acceso a
un servidor web a usuarios autorizados. Para hacer esto el administrador del sitio tpicamente
crea un certificado para cada usuario, un certificado que es guardado dentro de su
navegador. Normalmente, este contiene el nombre y la direccin de correo del usuario
autorizado y es revisado automticamente en cada reconexin para verificar la identidad del
usuario, potencialmente sin que cada vez tenga que ingresar una contrasea.
En caso de claves privadas comprometidas

Un certificado puede ser revocado si este ya ha expirado, por ejemplo cuando el secreto de la
llave privada ha sido comprometido. Los navegadores ms nuevos como son Firefox,6
Opera,7 e Internet Explorersobre Windows Vista8 implementan el Protocolo de Estado de
Certificado Online (OCSP) para verificar que ese no es el caso. El navegador enva el nmero
de serie del certificado a la autoridad de certificacin o, es delegado va OCSP y la autoridad
responde, dicindole al navegador si debe o no considerar el certificado como vlido.9
Limitaciones
El nivel de proteccin depende de la exactitud de la implementacin del navegador web, el
software del servidor y los algoritmos de cifrado actualmente soportados. Vea la lista en Idea
Principal.
Tambin, HTTPS es vulnerable cuando se aplica a contenido esttico de publicacin
disponible. El sitio entero puede ser indexado usando una araa web, y la URI del recurso
cifrado puede ser adivinada conociendo solamente el tamao de la peticin/respuesta.10
Esto permite a un atacante tener acceso al texto plano (contenido esttico de publicacin), y
al texto cifrado (La versin cifrada del contenido esttico), permitiendo un ataque
criptogrfico.
Debido a que SSL opera bajo HTTP y no tiene conocimiento de protocolos de nivel ms alto,
los servidores SSL solo pueden presentar estrictamente un certificado para una combinacin
de puerto/IP en particular11Esto quiere decir, que en la mayora de los casos, no es
recomendable usar Hosting virtual name-based con HTTPS. Existe una solucin llamada
Server Name Indication (SNI) que enva el hostname al servidor antes de que la conexin sea
cifrada, sin embargo muchos navegadores antiguos no soportan esta extensin. El soporte
para SNI est disponible desde Firefox 2, Opera 8, e Internet Explorer 7 sobre Windows
Vista.

3. Secure Socket Layer / Transport Layer Security:

a. Cules son las caractersticas y aspectos de seguridad relevantes de SSL v3.0?
SSL 3.0 mejor SSL 2.0 mediante la adicin de cifrado SHA-1 y soporte para autenticacin
de certificados.
Desde el punto de vista de seguridad, SSL 3.0 debera considerarse menos deseable que
TLS 1.0. Las suites de cifrado de SSL 3.0 tienen un proceso de derivacin de claves
dbiles, la mitad de la llave maestra que se establece es totalmente dependiente de la
funcin hash MD5, que no es resistente a los choques y, por lo tanto, no es considerado
seguro. Bajo TLS 1.0, la llave maestra que se establece depende tanto MD5 y SHA-1 por
lo que su proceso de derivacin no est actualmente considerado dbil. Es por esta razn
que las implementaciones SSL 3.0 no pueden ser validados bajo FIPS 140-2.46
Hay algunos ataques contra la implementacin en lugar del propio protocolo:47 En las
implementaciones anteriores, algunas entidades emisoras48 no establecieron
explcitamente basicConstraintsCA=False para losnodos hoja. Como resultado, estos
nodos hoja podan firmar certificados piratas. Adems, algunos programas de (incluyendo
IE6 y Konqueror) no comprob este campo para nada. Esto puede ser explotado en
ataques man-in-the-middle a todas las conexiones posibles SSL. Algunas
implementaciones (incluyendo versiones anteriores de la API de cifrado de Microsoft,
Network Security Services y GnuTLS) dejan de leer los caracteres que siguen al carcter
nulo en el campo del nombre del certificado, lo que puede ser explotado para engaar al
cliente en la lectura del certificado como si fuera originado en el sitio autntico. (Por

ejemplo, PayPal.com\0.badguy.com sera confundido como proveniente del sitio

PayPal.com en lugar de badguy.com). Los navegadores implementaron mecanismos de
degradacin del protocolo a una versin anterior en SSL/TLS por razones de
compatibilidad. La proteccin ofrecida por los protocolos SSL/TLS contra un downgrade a
una versin anterior de un ataque man-in-the-middle activo puede ser inutilizados por tales
mecanismos
b. Describa la arquitectura de SSL v3.0 y stack de protocolos.
La arquitectura presenta bsicamente dos niveles:

Protocolo de registro SSL, proporciona un nivel seguro por encima de TCP de canal
fiable.

En la capa de aplicacin junto a los objetivos de seguridad de SSH2 son: El servidor

casi siempre se autentica en el protocolo de nivel de transporte, normalmente por un
mtodo de firma de clave pblica. Las claves pblicas soportadas por certificados
X.509, PKI/SPKI/OpenPGP o distribuidas manualmente a los clientes. El
usuario/computador cliente se autentica normalmente en el protocolo de autenticacin
de usuario, por mtodo de clave pblica (soporta muchos mtodos) o por simple
contrasea para una aplicacin concreta sobre canal seguro o va mtodo basado en
computador. Establecimiento de un secreto compartido fresco, utilizando intercambio
de clave Diffie-Hellman. Secreto compartido utilizado para obtener claves adicionales
similar a SSL/ IPSec. Para confidencialidad y autenticacin en el protocolo de nivel de
transporte SSH. Negociacin de la familia de mecanismos criptogrficos seguros:
cifrado, MAC y algoritmos de compresin. Autenticacin de servidor y mtodos de
intercambio de claves.

c.

Cules son las caractersticas y aspectos de seguridad relevantes de TLS v1.0?

El protocolo TLS intercambia registros- los que encapsulan los datos que se intercambian
en un formato especfico (ver ms abajo). Cada registro puede ser comprimido, acolchado,
aadido con un cdigo de autenticacin de mensaje (MAC), o cifrado, todo dependiendo
del estado de la conexin. Cada registro tiene un campo de tipo de contenido que designa
el tipo de datos encapsulados, un campo de longitud y un campo de versin TLS. Los
datos encapsulados pueden ser mensajes de control o de procedimiento de la propia TLS,
o simplemente los datos de las aplicaciones que necesitan ser transferidos por TLS. Las
especificaciones (suite de cifrado, claves, etc.) necesarios para el intercambio de datos de
la aplicacin por TLS, se han acordado en el "apretn de manos TLS" entre el cliente que
solicita los datos y el servidor que responde a las solicitudes. Por tanto, el protocolo define
tanto la estructura de cargas tiles transferidos en TLS y el procedimiento para establecer
y supervisar la transferencia.
Apretn de manos TLS
Cuando se inicia la conexin, el registro encapsula un protocolo de "control"- el protocolo
de mensajera de apretones de manos (contenido de tipo 22). Este protocolo se utiliza para
el intercambio de toda la informacin requerida por las dos partes para el intercambio de
los datos de las aplicaciones reales por TLS. En l se definen los mensajes de formato o
que contengan esta informacin y el orden de su intercambio. Estos pueden variar en
funcin de las demandas del cliente y del servidor, es decir, existen varios procedimientos
posibles para establecer la conexin. Este intercambio inicial resulta en una conexin
exitosa TLS (ambas partes listas para transferir datos de la aplicacin con TLS) o un
mensaje de alerta (como se especifica ms adelante).
Apretn de manos bsico
A continuacin, un ejemplo simple de conexin, que ilustra un apretn de manos en el que
el servidor (pero no el cliente) es autenticado por su certificado:
a. Fase de negociacin:

Un cliente enva un mensaje ClientHello especificando la versin ms alta de

protocolo TLS que soporta, un nmero al azar, una lista de conjuntos de cifrado

sugeridas y mtodos de compresin sugeridos. Si el cliente est intentando

realizar un apretn de manos reanudado, puede enviar un ID de sesin.
El servidor responde con un mensaje ServerHello, que contiene la versin del
protocolo elegido, un nmero aleatorio, CipherSuite y mtodo de compresin de
las opciones ofrecidas por el cliente. Para confirmar o permitir apretones de manos
reanudado el servidor puede enviar un ID de sesin. La versin del protocolo
elegido debe ser el ms alto que tanto el soporte de cliente y servidor. Por
ejemplo, si el cliente es compatible con la versin 1.1 y el servidor es compatible
con la versin 1.2, la versin 1.1 se debe seleccionar; 1.0 no se debe seleccionar.
El servidor enva su mensaje de certificado (dependiendo de la suite de cifrado
seleccionado, esto puede ser omitido por el servidor).95
El servidor enva su mensaje ServerKeyExchange (en funcin del conjunto de
cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se
enva a todos los conjuntos de cifrado DHE y DH_anon.2
El servidor enva un mensaje ServerHelloDone, lo que indica que termin con la
negociacin del apretn de manos.
El cliente responde con un mensaje ClientKeyExchange, que puede contener una
PreMasterSecret, la clave pblica, o nada. (Una vez ms, esto depende de la cifra
seleccionada.) Esta PreMasterSecret se cifra utilizando la clave pblica del
certificado del servidor.
El cliente y el servidor a continuacin utilizan los nmeros aleatorios y
PreMasterSecret para calcular un secreto comn, llamado el "secreto principal"
(master secret). Todos los dems datos clave para esta conexin se deriva de este
secreto principal (y los valores aleatorios generados tanto por cliente y por
servidor), que se pasan a travs de una funcin pseudoaleatoria cuidadosamente
diseado.

b. El cliente ahora enva un registro ChangeCipherSpec, esencialmente diciendo al

servidor, "Todo lo que yo te diga de ahora en adelante ser autenticado (y cifrada si los
parmetros de encriptacin estaban presentes en el certificado del servidor)." El
ChangeCipherSpec es en s mismo un protocolo a nivel de registro con el tipo de
contenido 20.
a. Por ltimo, el cliente enva un mensaje autenticado y encriptado de Finished
(terminado), que contiene un hash y MAC sobre los mensajes de apretn de
manos anteriores.
b. El servidor intentar descifrar el mensaje Finished del cliente y verificar el hash y
MAC. Si el descifrado o verificacin falla, el apretn de manos se considera que ha
fracasado y la conexin debe ser derribada.

c. Por ltimo, el servidor enva un ChangeCipherSpec, dicindole al cliente, "Todo lo que

yo te diga de ahora en adelante ser autenticado (y cifrado, si el cifrado se negoci)."

El servidor enva su mensaje Finished autenticado y encriptado.

El cliente realiza el mismo descifrado y verificacin.

d. Fase de aplicacin: en este punto, el "apretn de manos" est completado y el

protocolo de aplicacin est activada, con el tipo de contenido de 23. Los mensajes de
aplicacin intercambiados entre el cliente y el servidor tambin sern autenticados y
opcionalmente encriptada exactamente igual que en su mensaje final. De lo contrario,
el tipo de contenido contestar 25 y el cliente no va ser autenticado.
Apretn de manos TLS autenticado por el cliente

El siguiente ejemplo completo muestra un cliente siendo autenticado (adems del

servidor como el de ms arriba) a travs de TLS mediante certificados intercambiados
entre ambos interlocutores.
a.

Fase de Negociacin:

Un cliente enva un mensaje ClientHello especificando la versin ms alta de

protocolo TLS que soporta, un nmero al azar, una lista de conjuntos de cifrado
sugeridos y mtodos de compresin.
El servidor responde con un mensaje ServerHello, que contiene la versin elegida
del protocolo, un nmero al azar, una suite de cifrado y el mtodo de compresin
de las opciones ofrecidas por el cliente. El servidor tambin puede enviar un
identificador de sesin como parte del mensaje para realizar un apretn de manos
reanudado.
El servidor enva su mensaje de certificados (dependiendo de la suite de cifrado
seleccionado, esto puede ser omitido por el servidor).95
El servidor enva su mensaje ServerKeyExchange (en funcin del conjunto de
cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se
enva a todos los conjuntos de cifrado DHE y DH_anon.2
El servidor solicita un certificado desde el cliente, de modo que la conexin pueda
ser mutuamente autenticada, utilizando un mensaje CertificateRequest.
El servidor enva un mensaje ServerHelloDone, lo que indica que termin con la
negociacin apretn de manos.
El cliente responde con un mensaje de certificado, que contiene el certificado del
cliente.
El cliente enva un mensaje ClientKeyExchange, que puede contener un
PreMasterSecret, clave pblica, o nada. (Una vez ms, esto depende del cifrado
seleccionado.) Esta PreMasterSecret se cifra utilizando la clave pblica del
certificado del servidor.
El cliente enva un mensaje CertificateVerify, que es una firma en los mensajes de
reconocimiento anteriores utilizando la clave privada del certificado del cliente.
Esta firma puede ser verificada utilizando la clave pblica del certificado del
cliente. Esto permite al servidor saber que el cliente tiene acceso a la clave privada
del certificado y por lo tanto posee el certificado
El cliente y el servidor a continuacin, utilizar los nmeros aleatorios y
PreMasterSecret para calcular un secreto comn, llamado el "secreto principal".
Todos los dems datos clave para esta conexin se derivan de este secreto
maestro (y los valores aleatorios cliente-y generados por el servidor), que se pasa
a travs de una funcin pseudoaleatoria cuidadosamente diseada.

b.

El cliente ahora enva un registro ChangeCipherSpec, esencialmente diciendo al

servidor, "Todo lo que yo te diga de ahora en adelante ser autenticado (y cifrada
si el cifrado se negoci)." El ChangeCipherSpec es en s mismo un protocolo a
nivel de registro y es tipo 20 y no 22.

Por ltimo, el cliente enva un mensaje cifrado de Finished, que contiene un hash y
MAC sobre los mensajes de apretn de manos anteriores.
El servidor intentar descifrar el mensaje final del cliente y verificar el hash y MAC.
Si el descifrado o verificacin falla, el apretn de manos se considera que ha
fracasado y la conexin debe ser derribada.
c. Por ltimo, el servidor enva un ChangeCipherSpec, dicindole al cliente, "Todo lo
que yo te diga de ahora en adelante ser autenticado (y cifrada si el cifrado se
negoci)."

El servidor enva su propio mensaje cifrado de Finished.

El cliente realiza el mismo descifrado y verificacin.

d.

Fase de aplicacin: en este punto, el "apretn de manos" est completado y el

protocolo de aplicacin est activado, con el tipo de contenido 23. Los mensajes
de la aplicacin intercambiados entre el cliente y el servidor tambin sern
encriptados exactamente igual que en su mensaje Finished.

Apretn de manos reanudado

Las operaciones de clave pblica (por ejemplo, RSA) son relativamente costosas en
trminos de clculo computacional. TLS proporciona un acceso directo seguro en el
mecanismo de apretn de manos para evitar estas operaciones: reanudar sesiones.
Las sesiones reanudadas se implementan utilizando los identificadores (IDs) de sesin
o tickets de sesin.
Aparte de la ventaja de rendimiento, reanudando las sesiones tambin se puede
utilizar para inicio de sesin nico, ya que se garantiza que tanto la sesin original, as
como cualquier sesiones reanudada se originan desde el mismo cliente. Esto es de
particular importancia para el FTP sobre el protocolo TLS/SSL, ya que de lo contrario
podra sufrir de un ataque man-in-the-middle en el que un atacante podra interceptar
el contenido de las conexiones de datos secundarias.
IDs de sesin
En un apretn de manos normal completo, el servidor enva un ID de sesin como
parte del mensaje ServerHello. El cliente asocia este ID de sesin con la direccin IP
del servidor y el puerto TCP, para que cuando el cliente se conecte de nuevo a ese
servidor, puede utilizar el ID de sesin para acortar el apretn de manos. En el
servidor, el ID de sesin se asigna a los parmetros criptogrficos negociados
anteriormente, especficamente el "secreto maestro". Ambas partes deben tener el
mismo "secreto maestro" o el apretn de manos reanudado fallar (esto evita que un
espa utilice un ID de sesin). Los datos aleatorios en los mensajes ClientHello y
ServerHello prcticamente garantizan que las claves de conexin generadas sern
diferentes de la conexin anterior. En las RFC, este tipo de apretn de manos se llama
un protocolo de enlace abreviado. Tambin se describe en la literatura como un
reinicio de apretn de manos.

1. Fase de Negociacin:

Un cliente enva un mensaje ClientHello especificando la versin ms alta de

protocolo TLS que soporta, un nmero al azar, una lista de conjuntos de cifrado
sugeridos y mtodos de compresin. Incluye en el mensaje el ID de sesin de la
conexin TLS previa.

El servidor responde con un mensaje ServerHello, que contiene la versin elegida

del protocolo, un nmero al azar, una suite de cifrado y el mtodo de compresin
de las opciones ofrecidas por el cliente. Si el servidor reconoce el ID de sesin,
responde con la misma ID de sesin. El cliente usa esto para reconocer que se
est llevando a cabo una sesin reanudada. Si el servidor no reconoce el ID de
sesin enviado por el cliente, responde con un valor diferente para la ID de sesin,

lo cual le dice al cliente que no se llevar a cabo una reanudacin de sesin. En

este punto, tanto el cliente como el servidor tienen el "secreto maestro" y datos
aleatorios para generar la clave usada para esta conexin.
2. El servidor enva un ChangeCipherSpec, dicindole al cliente, "Todo lo que yo te
diga de ahora en adelante ser autenticado (y cifrada si el cifrado se negoci)."
Por ltimo, el servidor enva un mensaje cifrado de Finished, que contiene un hash
y MAC sobre los mensajes de apretn de manos anteriores.
El cliente realiza el mismo descifrado y verificacin.
3. El cliente ahora enva un registro ChangeCipherSpec, esencialmente diciendo al
servidor, "Todo lo que yo te diga de ahora en adelante ser autenticado (y cifrada si el
cifrado se negoci)."

El cliente enva su propio mensaje cifrado de Finished.

El servidor intentar descifrar el mensaje final del cliente y verificar el hash y MAC.

4. Fase de aplicacin: en este punto, el "apretn de manos" est completado y el

protocolo de aplicacin est activado, con el tipo de contenido 23. Los mensajes de la
aplicacin intercambiados entre el cliente y el servidor tambin sern encriptados
exactamente igual que en su mensaje Finished.
Tickets de sesin
El RFC 5077 extiende TLS a travs de la utilizacin de tickets de sesin, en lugar de
los IDs de sesin. Define una forma de reanudar una sesin TLS sin necesidad de
almacenar el estado especfico de la sesin en el servidor TLS.
Al utilizar tickets de sesin, el servidor TLS almacena su estado especfico de la sesin
en un ticket de sesin y enva el ticket de sesin al cliente TLS para ser almacenado.
El cliente se reanuda una sesin TLS mediante el envo del ticket de sesin al servidor,
y el servidor reanuda la sesin TLS en el estado especfico de la sesin en el ticket. El
ticket de sesin est cifrado y autenticada por el servidor, y el servidor verifica su
validez antes de utilizar su contenido.
Una debilidad particular de este mtodo con OpenSSL es que siempre limita el cifrado
y la autenticacin de seguridad del ticket de sesin TLS transmitido a AES128-CBCSHA256, no importa qu otros parmetros TLS sean negociados para la sesin actual
TLS. Esto significa que la informacin de estado (el ticket de sesin TLS) no est tan
bien protegido como la sesin TLS misma. De particular preocupacin es el
almacenamiento de OpenSSL de las claves en un contexto de aplicacin (SSL_CTX),
es decir, que se mantiene durante la duracin de la aplicacin, y no permite el
reingreso de informacin de los tickets de sesin AES128-CBC-SHA256 TLS sin
reiniciar el contexto a nivel de aplicacin OpenSSL (lo que es raro, propenso a errores
y a menudo requiere intervencin administrativa manual).

d. Cules son las principales diferencias, a nivel funcional y seguridad entre SSL v3.0 y
TLS v1.0?
.
Tanto el TLS (Transport Layer Security) como el SSL (Secure Sockets Layer) son
protocolos que proporcionan cifrado de datos y autenticacin entre aplicaciones y
servidores en escenarios en los que estn enviando datos a travs de una red insegura,
como por ejemplo, en este caso, revisar su correo electrnico.

Los trminos SSL y TLS se usan indistintamente o en combinacin uno con otro (TLS /
SSL), pero una es la predecesora de la otra. SSL v3.0 sirvi como base para TLS v1.0 que
incluso a veces se le denomina como SSL v3.1.
Cul es ms seguro. SSL o TLS?
TLS v1.0 es ligeramente ms seguro que la versin 3.0 de SSL, su predecesor. Sin
embargo, las versiones posteriores de TLS (v1.1 y v1.2) son significativamente ms
seguras ya que se corrigieron muchas vulnerabilidades presentes en la versin 3.0 de
SSL y TLS v1.0. Por ejemplo el ataque beast que puede romper por completo los sitios
web que se ejecutan en los protocolos ms antiguos como SSL v3.0 y TLS 1.0.
Si est configurado correctamente, las versiones ms recientes de TLS evitan el ataque
beast y otros tipos de ataque y adems proporcionan muchos sistemas de cifrado y
encriptacin ms fuertes.
Desafortunadamente, hoy en da la mayora de los sitios web no utilizan las nuevas
versiones de TLS.
Si SSL y TLS no son elecciones de seguridad. Qu lo es?
Hay dos formas distintas en que un programa puede iniciar una conexin segura:
1. Por puerto, conexin a puerto especfico significa que se debe utilizar una conexin
segura. Por ejemplo, el puerto 443 para https (web segura), 993 para IMAP seguro, 995
para POP seguro, etc. Estos puertos se configuran en el servidor dispuestos a interactuar
en una conexin segura en primer lugar, y hacer el resto de las funcionalidades de tu
programa en segundo lugar.
2. Por protocolo. Estas conexiones primero comienzan con un inseguro hola al servidor.
Entonces solo cambia a una comunicacin segura luego de un acuerdo entre el cliente y
el servidor. Si este acuerdo falla por alguna razn, se corta la conexin. Un buen ejemplo
de esto es el comando starttls utilizado en conexiones de correo saliente (SMTP).
El mtodo por puerto es comunmente denominado como SSL y el mtodo por protocolo
como TLS en muchas reas de la configuracin de programas. A veces, solo se tiene la
opcin de especificar el puerto y si usted debe hacer una conexin segura o no, y el
propio programa determina que mtodo debera utilizar. Muchos programas de correo
electrnico como versiones de Outlook viejas o Mac Mail, lo hicieron.
En los programas de correo electrnico y otros sistemas donde se puede seleccionar SSL
o TLS junto con el puerto:

SSL significa una conexin por puerto que espera la sesin para comenzar a
negociar la seguridad.
TLS significa una conexin por protocolo donde el programa se conectar
inseguramente primero y luego utilizar comando especiales para habilitar el
cifrado.
El uso de cualquiera de los dos mtodos (SSL o TLS) podra dar lugar a una
conexin cifrada.
Ambos mtodos de conexin dan como resultado una conexin segura.

Cul debo elegir, SSL o TLS?

Si est configurando un servidor, debe instalar un software que soporta la ltima

versin de la norma TLS y configurarlo correctamente. Esto asegura que las
conexiones que el usuario hace sean lo ms segura posibles. El uso del cifrado de
seguridad bueno tambin va a ayudar mucho, por ejemplo uno con claves de 2048
bits o ms.
Si vas a configurar un programa y tiene la opcin de elegir conectarse de forma
segura a travs de SSL o TLS, debe sentirse libre de elegir cualquiera de ellos,
siempre y cuando su eleccin sea soportada por su servidor.

Qu sucede si no selecciono uno de ellos?

Si no se utiliza SSL o TLS, entonces la comunicacin entre usted y el servidor pueden
convertirse fcilmente vulnerable. Sus datos y su informacin de inicio de sesin se
enviarn como texto sin formato para que cualquiera la pueda ver, no hay garanta de que
el servidor se conecte.

4.

Secure Electronic Transaction SET:

a. Que es SET, cul es su utilidad y cuales servicios provee?
El protocolo SET es un conjunto de especificaciones desarrolladas por Visa y MasterCard,
con el apoyo y asistencia de GTE, IBM, Microsoft,Netscape,SAIC,Terisa y Verisign con la
finalidad de permitir las tranferencias y pagos seguros a travs de Internet o de cualquier
otra red. Dichas especificaciones surgen de la necesidad de dotar al comercio electrnico
de una estructura confiable para las transacciones on-line; es decir que a travs de la
combinacin de los mtodos criptogrficos existentes se pueda lograr una transaccin online bajo un concepto de absoluta seguridad, en la que se contemple la garanta de la
confidencialidad, la autenticidad de las partes, la integridad del documento y el no rechazo
de la operacin. Cada una de estas salvaguardias queda acreditada, con la utilizacin del
protocolo SET.
En esencia, SET ofrece tres servicios:

Proporciona un canal de comunicacin seguro entre todas las partes involucradas

en una transaccin.
Proporciona confianza mediante el uso de certificados digitales X.509v3.
Asegura la privacidad porque la informacin slo est disponible para las partes en
una transaccin cuando y donde sea necesario.

b. Cules son los requerimientos de un implementacin SET y cuales caractersticas

clave incluye la especificacin para satisfacer esos requerimientos?
Requerimientos:

Proporcionar confidencialidad de pago e informacin sobre pedidos: Es necesario

asegurar los tarjetahabientes que esta informacin es segura y accesible slo a la
intencin destinatario. La confidencialidad tambin reduce el riesgo de fraude por
parte de cualquiera de las partes a la transaccin o por terceros maliciosos. SET
utiliza el cifrado para proporcionar confidencialidad.

Asegurar la integridad de todos los datos transmitidos: Es decir, asegurarse de que

no hay cambios en el contenido durante la transmisin de los mensajes. Las firmas
digitales se utilizan para proporcionar integridad.

Proporcionar autenticacin que un titular de la tarjeta es un usuario legtimo de una

tarjeta de crdito: Un mecanismo que vincula un titular de tarjeta a una cuenta
especfica nmero reduce la incidencia del fraude y el coste global de procesamiento
de pagos. Las firmas digitales y certificados se usan para verificar que un titular de la
tarjeta es un usuario legtimo de una cuenta vlida.

Proporcionar autenticacin que un comerciante puede aceptar transacciones de

tarjetas de crdito a travs de su relacin con una institucin financiera: Este es el
complemento del anterior requisito. Los titulares de tarjetas deben ser capaces de
identificar los comerciantes con los cuales que pueden llevar a cabo transacciones
seguras. Una vez ms, las firmas digitales y certificados utilizados.

Asegurar el uso de las mejores prcticas de seguridad y tcnicas de diseo de

sistemas de proteger a todas las partes legtimas en una transaccin de comercio
electrnico: SET es una especificacin bien probado basado en algoritmos
criptogrficos de alta seguridad y protocolos.

Crear un protocolo que no depende de los mecanismos de seguridad de transporte ni

impide su uso: SET segura puede operar sobre una pila TCP / IP "en bruto". Sin
embargo, SET no interfiere con el uso de otros mecanismos de seguridad, tales como
IPSec y SSL / TLS.

Facilitar y fomentar la interoperabilidad entre el software y la red proveedores: Los

Protocolos de los formatos y son independientes de la plataforma de hardware,
sistema operativo y el software Web.

Caractersticas clave:

La confidencialidad de la informacin: El titular de la cuenta e informacin de pago es

asegurada a medida que viaja a travs de la red. Una caracterstica interesante e
importante de la SET es que evita que el comerciante se aprenda el nmero de tarjeta
de crdito del titular de la tarjeta; este slo se proporciona al banco emisor. El cifrado
convencional por DES se utiliza para proporcionar confidencialidad.

Integridad de datos: La informacin de pago enviada desde los titulares de tarjetas a

los comerciantes incluye ordenar la informacin, los datos personales, y las
instrucciones de pago. SET garantiza que el contenido del mensaje no se alteran
durante el trnsito. Las Firmas digitales RSA, utilizan cdigos hash SHA-1,
proporcionando la integridad del mensaje. Ciertos mensajes tambin estn protegidos
por HMAC utilizando SHA-1.

Autenticacin de la cuenta Titular: SET permite a los comerciantes verificar que el

titular de la tarjeta es un usuario legtimo y que el nmero de cuenta de tarjeta es
vlida. SET utiliza X.509v3 y certificados digitales con firma RSA para este propsito.

Merchant autenticacin: SET permite a los poseedores verificar que un comerciante

tiene una relacin con una institucin financiera que le permite aceptar tarjetas de
pago.

c.

Describa el tipo de transacciones soportadas en SET.

Registro Titular de la
Tarjeta
Registro
de
Comerciante
Solicitud de Compra
Autorizacin de pago
Captura de Pago
Consulta
de
Certificado y el estado

Investigacin
Compra

de

Revocacin
Autorizacin

la

de

Reversin de captura

Crdito

Registro del titular de

la tarjeta
Reversin de crdito
Solicitud de certificado
de Pasarela de pago
Lote
administracin
Mensaje de error

Los tarjetahabientes deben registrarse con una CA antes de que SET pueda
enviar mensajes a los comerciantes.
Los comerciantes deben inscribirse en una CA antes de que SET pueda
intercambiar mensajes con clientes y pasarelas de pago.
Mensaje del cliente a comerciante que contiene OI para comerciante y PI para
el banco.
Intercambio entre comerciante y pasarela de pago para autorizar una compra
dada la cantidad en una cuenta de tarjeta de crdito.
Permite al comerciante para solicitar el pago de la pasarela de pago.
Si la CA no puede completar la tramitacin de una solicitud de certificado
rpidamente, enviar una respuesta al titular de la tarjeta o el comerciante que
indica que el solicitante debe comprobar de nuevo ms tarde. El titular de la
tarjeta o comerciante enva el mensaje de consulta certificado para determinar
el estado de la solicitud de certificado y recibir el certificado si la solicitud tiene
sido aprobado.
Permite que el titular de la tarjeta compruebe el estado de la tramitacin de
una orden despus de que la respuesta de la compra haya sido recibida.
Tenga en cuenta que este mensaje no incluye informacin como el estado
ordenado de las mercancas, pero s indicar el estado de la autorizacin, la
captura y el crdito procesamiento.
Permite a un comerciante corregir las solicitudes de autorizacin previos. Si
no se completara, el comerciante revoca la totalidad autorizacin. Si no se
completara parte de la orden (por ejemplo, cuando los bienes se ordenan de
nuevo), el comerciante revoca parte de la cantidad de la autorizacin.
Permite a un comerciante para corregir errores en las solicitudes de captura
como cantidades de transacciones que se introdujeron incorrectamente por un
empleado.
Permite a un comerciante para emitir un crdito a la cuenta del titular de la
tarjeta como cuando los bienes sean devueltos o fueron daados durante el
envo. Tenga en cuenta que el mensaje SET crdito siempre es iniciada por el
comerciante, no el titular de la tarjeta. Todas las comunicaciones entre el titular
de la tarjeta y el comerciante que se traducen en un crdito en trmite ocurran
fuera del SET.
Los tarjetahabientes deben registrarse con una CA antes de que SET pueda
enviar mensajes a los comerciantes.
Permite a un comerciante corregir una solicitud de crdito previamente.
Permite a un comerciante para consultar la pasarela de pago y recibir una
copia de los certificados de intercambio de claves y firmas actuales de la
puerta de enlace.
Permite a un comerciante para comunicar la informacin a la pasarela de pago
con respecto a los lotes comerciales.
Indica que un respondedor rechaza un mensaje porque no formato o pruebas
de verificacin de contenido.

d. Que es Dual Signature y cmo se conforma?

La doble firma. El propsito de la doble firma es unir dos los mensajes que estn
destinados a dos receptores diferentes. En este caso, el cliente quiere enviar la
informacin del pedido (OI) para el comerciante y la informacin de pago (PI) a la banco.

El comerciante no necesita saber el nmero de tarjeta de crdito del cliente, y el banco no

necesita conocer los detalles de la orden del cliente. El cliente se le concede adicional
proteccin en trminos de intimidad al mantener estos dos elementos separados. Sin
embargo, los dos elementos deben vincularse de una manera que puede ser utilizada para
resolver disputas en caso de necesidad. Se necesita el enlace de manera que el cliente
puede probar que este pago est destinado para este fin y no para algunos otros bienes o
servicios.
Para ver la necesidad del enlace, supongamos que los clientes envan el comerciante dos
mensajes: uno firm OI y un IP firmado, y el comerciante pasa la PI en el banco. Si el
comerciante puede capturar otra OI de este cliente, el comerciante podra afirmar que
estas IS van con la PI en lugar de la OI originales. La vinculacin impide.
La figura muestra el uso de una firma dual para cumplir el requisito. El cliente toma el hash
(usando SHA-1) de la PI y el hash de la OI. Estos dos hashes se concatenan y se toma el
hash del resultado. Por ltimo, el cliente cifra el hash final con su clave privada de firma,
creando la firma dual. La operacin se puede resumir como: DS = E(PRc, [H(H(PI)||
H(OI)])
Donde PRC es clave privada de la firma del cliente. Supongamos ahora que el
comerciante est en posesin de la doble firma (DS), el OI, y el mensaje de digerir para el
PI (PIMD). El comerciante tambin tiene la clave pblica del cliente, tomada desde el
certificado del cliente, entonces el comerciante puede calcular las cantidades.
H(PIMS||H[OI]); D(PUc, DS)
Donde PUC es la clave de firma pblica del cliente. Si estas dos cantidades son iguales,
entonces el comerciante ha verificado la firma. Del mismo modo, si el banco est en
posesin de DS, PI, el mensaje debe digerir para la OI (OIMD), y la clave pblica del
cliente, entonces el banco puede calcular.

De nuevo, si estas dos cantidades son iguales, entonces el banco ha verificado la firma.
En resumen,
1. El comerciante ha recibido OI y verificado la firma.
2. El banco ha recibido PI y verificado la firma.
3. El cliente ha vinculado la OI y PI y puede demostrar la vinculacin.

Por ejemplo, supongamos que el comerciante quiere sustituir por otra OI en esta
transaccin, a su ventaja. Entonces tendra que encontrar otra OI cuyo hash de partidos el
OIMD existente.
Con SHA-1, este se considera que no es factible. De este modo, el comerciante no puede
vincular otra OI con este PI.

e. Describa los pasos de un escenario de transaccin comercial en SET.

SOLICITUD DE INICIO
RESPUESTA DE INICIO
SOLICITUD DE COMPRA
RESPUESTA DE COMPRA
AUTORZACION DE PAGO

a. Cuando se va a cerrar el pedido, el cliente recibe la firma digital de la tienda y

verifica su validez.
b. El cliente enva al comerciante la siguiente informacin firmada digitalmente:
Los datos del pedido (bsicamente: identificacin del comerciante, importe
y fecha)
La orden de pago, con una encriptacin que slo puede leer el banco.
La relacin entre el pedido y la orden de pago, que los liga
indisolublemente.
c. El comercio recibe el pedido y verifica la validez de la firma digital.
d. El comerciante pasa al banco la orden de pago (que l no ha podido leer) con su
firma digital.
e. El banco autoriza la transaccin y devuelve dos confirmaciones, una para el
comerciante y otra para el titular de la tarjeta.

5. Vulnerabilidades de Web Servers:

a. Describa las principales vulnerabilidades y ataques contra servidores Microsoft IIS, as
como el esquema de mitigacin.

ATAQUE CARCTER "~" PARA CONOCER NOMBRE CORTOS

El error por falta de filtrado de los parmetros de entrada que podra permitir revelar el nombre
de archivos y directorios existentes en el servidor. IIS permite utilizar el carcter " ~" para conocer
los nombres cortos de archivos y carpetas. Un atacante podra llegar a encontrar ficheros no
visibles en servidores web.
Los nombres cortos 8:3 es una infame herencia de los tiempos DOS, en los que los nombres de
fichero no podan superar los ocho caracteres ms tres de extensin. Hoy en da todava es
posible acceder a un fichero utilizando esta nomenclatura.

En principio, en IIS no es posible usar el nombre corto y tanto si el fichero se encuentra como si
no, se generar un error. Cuando se solicita un nombre acortado con comodines, el servidor
intentar acceder. El problema es que si lo encuentra, el servidor responder con un error " 404" y
si no, un "400" (Bad request). Jugando con estas dos respuestas, se pueden llegar a inferir
nombres de ficheros existentes (tomando una respuesta como "xito" y otra como "fracaso") hasta
comprobar la existencia de ficheros.

ESQUEMA DE MITIGACIN
Para solucionarlo se aconseja filtrar el uso de comodines "*" en la URL, y deshabilitar de la
creacin de nombres cortos.

VULNERABILIDAD DE DESBORDAMIENTO DEL BUFER

Se ha descubierto un desbordamiento de bfer en Microsoft Internet Information Server 5.0 ,

cuando se ejecuta en Windows 2000, que pone en riesgo a miles de servidores web.
IIS 5.0 es instalado y ejecutado de forma predeterminada en los sistemas Microsoft Windows
2000. La vulnerabilidad descubierta puede permitir a un intruso remoto ejecutar cdigo arbitrario
en la mquina afectada.

Adems la gravedad de este fallo aumenta ya que est disponible pblicamente un exploit para
aprovecharlo, por lo tanto los administradores deben actualizar inmediatamente sus servidores con
que Microsoft ya ha publicado, Segn Microsoft, el fallo solo afecta a Windows 2000 (no a
Windows XP ni a NT).
Un atacante puede explotar la vulnerabilidad enviando un paquete HTTP especialmente formado a
una mquina con IIS. La peticin puede hacer que el servidor caiga o permitir la ejecucin de
cdigo arbitrario bajo el contexto de seguridad local.

Este fallo es muy similar a la vulnerabilidad que aprovechaba el famoso gusano CodeRed, que en
el verano de 2001 infect miles de servidores.

La vulnerabilidad se origina en el uso de un protocolo llamado WebDAV (World Wide Web

Distributed Authoring and Versioning) que funciona bajo ISS. Se compone de un conjunto de

extensiones de HTTP que permiten a los usuarios manipular archivos almacenados en un servidor
Web (RFC2518).
Un desbordamiento de bfer existente en la librera "ntdll.dll" utilizada por el componente WebDAV
de IIS, permite que al enviar una solicitud al servidor, un intruso puede ser capaz de ejecutar
cdigo arbitrariamente en el contexto de seguridad local, menos crtico, dndole al atacante el
control completo sobre el sistema.
ESQUEMA DE MITIGACIN
Hasta que una actualizacin pueda ser aplicada, es posible deshabilitar IIS. Para determinar si IIS
se est ejecutando, Microsoft recomienda lo siguiente:
Ir a "Inicio | Configuraciones | Panel de Control | Herramientas Administrativas | Servicios". Si el
servicio "World Wide Web Publishing" est listado, entonces IIS est instalado.
Para deshabilitar IIS, se puede ejecutar la herramienta de IIS lockdown. Esta herramienta est
disponible en:

http://www.microsoft.com/downloads/release.asp?ReleaseID=43955

Si no es posible deshabilitar IIS, se debe considerar utilizar la herramienta IIS lockdown para
deshabilitar WebDAV (el remover WebDAV se puede especificar cundo se ejecuta la herramienta
IIS lockdown).

b. Describa las principales vulnerabilidades y ataques contra servidores Apache / Tomcat, as

como el esquema de mitigacin.

VULNERABILIDAD DE DENEGACION DE SERVICIO

CVE-2014-0117: Existe un error en el manejo de cabeceras HTTP Connection en el mdulo

'mod_proxy' que podra provocar una denegacin de servicio en un proxy inverso.
ESQUEMA DE MITIGACION
Una actualizacin elimina esta vulnerabilidad. Poniendo el filtro tcp/12345 en el firewall, es posible
mitigar el efecto del problema. El mejor modo sugerido para mitigar el problema es actualizar a la
ltima versin. La vulnerabilidad tambin est documentado en la base de datos SecurityFocus
(BID 1013).
AGOTAMIENTO DE MEMORIA

CVE-2014-3523: Denegacin de servicio debido a un fallo en la funcin 'winnt_accept' del mdulo

'WinNT MPM' que podra generar el agotamiento de la memoria disponible.
ESQUEMA DE MITIGACION
Una actualizacin elimina esta vulnerabilidad. Poniendo restricciones a la funcin 'winnt_accept'
del mdulo 'WinNT MPM' el cual permite que no se consuma la memoria a travs del atacante.

c. Describa las principales vulnerabilidades y ataques contra servidores Samba, as como el

esquema de mitigacin.
ATAQUE DENEGACION DE SERVICIO
La vulnerabilidad ha sido catalogada bajo el cdigo CVE-2013-4124. Esta vulnerabilidad permita a
un usuario, autentificado o annimo, realizara un ataque DoS. A travs de un paquete mal formado
se poda llegar a bloquear el servidor smbd que impedira cualquier accin de recuperacin o
estabilizacin.
ESQUEMA DE MITIGACION
Parchando todo el sistema deja de ser vulnerables ante este fallo de seguridad. Las
actualizaciones de Samba incluyen por defecto todos los parches y paquetes lanzados
anteriormente y mantienen la configuracin de los servidores, por lo que habra que descargarlos e
instalarlos en el sistema para estar protegidos.
ATAQUE DE DESBORDAMIENTO DE BUFFER
Las versiones no actualizadas de SAMBA contienen un desbordamiento de
bfer que permite que un atacante remoto ejecute cdigo arbitrario en el
servidor, con privilegios de administrador o "root".
Las versiones de Samba anteriores a la 2.2.8 contienen un desbordamiento
de bfer que permite que un atacante remoto ejecute cdigo arbitrario en
el
servidor,
tpicamente
con
privilegios
de
administrador
o
"root".
La
vulnerabilidad
reside
en
el
demonio
re-ensamblado
de fragmentos "SMB/CIFS".
Si
convenientemente
formateados,
puede
producir
potencialmente,
la
ejecucin
de
cdigo
explotarse de forma remota y annima.

"smbd",
concretamente
en
el
un atacante enva datagramas
sobreescritura
de
memoria
y,
arbitrario.
El
ataque
puede

ESQUEMA DE MITIGACION
La
recomendacin
es
que
todos
los
administradores
de
sistemas
SAMBA
actualicen con la mayor urgencia a la versin 2.2.8 del servidor. Adicionalmente, los puertos SMB
(UDP/137, UDP/138, TCP/139 y TCP/445) deben ser accesibles, exclusivamente, a
los
usuarios
y
redes
que
lo
necesiten.
En
particular,
no
deberan
ser
accesibles desde Internet.