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).

AMENAZASCONSECUENCIASCONTRAMEDIDAS

Integridad Modificacin de los datos de usuario. Troyanos en el navegador. Modificacin de memoria. Modificacin de mensajes durante el trfico en trnsito. Perdida de informacin. Maquina comprometida. Vulnerabilidad de otras amenazas. Sumas de comprobacin criptogrfica.

Confidencialidad 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. Perdida de informacin. Perdida de privacidad.

Cifrado, proxi.

Denegacin de Servicio Muerte de hilos de usuario. Inundacin de mquinas con falsas peticiones. Llenado de disco o memoria. Aislamiento de mquinas por ataques DNS. Disruptivo. Molestias. Evita que el usuario obtenga el trabajo realizado. Difcil de prevenir.

Autenticacin Suplantacin de usuarios legtimos. Falsificacin de datos. La tergiversacin de usuario. La creencia de que informacin falsa es vlida. Tcnicas de 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.

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.

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.

4. 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.0Meidante 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.0Accept-EncodingHost: www.cibernetia.comReferer: http://www.cibernetia.com/index.phpUser-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows Me)Connection: closeContent-Type: application/x-www-form-urlencodedContent-Length: 36numero_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.0Mediante 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 vlidaLos 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 = *

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.47Nombres 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.46Hay 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 bsicoA 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-CBC-SHA256, 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 on-line 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 TarjetaLos tarjetahabientes deben registrarse con una CA antes de que SET pueda enviar mensajes a los comerciantes.

Registro de ComercianteLos comerciantes deben inscribirse en una CA antes de que SET pueda intercambiar mensajes con clientes y pasarelas de pago.

Solicitud de CompraMensaje del cliente a comerciante que contiene OI para comerciante y PI para el banco.

Autorizacin de pago

Intercambio entre comerciante y pasarela de pago para autorizar una compra dada la cantidad en una cuenta de tarjeta de crdito.

Captura de PagoPermite al comerciante para solicitar el pago de la pasarela de pago.

Consulta de Certificado y el estadoSi 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.

Investigacin de la CompraPermite 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.

Revocacin de AutorizacinPermite 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.

Reversin de captura

Permite a un comerciante para corregir errores en las solicitudes de captura como cantidades de transacciones que se introdujeron incorrectamente por un empleado.

Crdito

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.

Registro del titular de la tarjetaLos tarjetahabientes deben registrarse con una CA antes de que SET pueda enviar mensajes a los comerciantes.

Reversin de crditoPermite a un comerciante corregir una solicitud de crdito previamente.

Solicitud de certificado de Pasarela de pagoPermite 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.

Loteadministracin

Permite a un comerciante para comunicar la informacin a la pasarela de pago con respecto a los lotes comerciales.

Mensaje de error

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 entradaque 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 aencontrar 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 "*" enla 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 (BID1013).

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 MITIGACIONUna 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 cdigoCVE-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 debfer que permite que un atacante remoto ejecute cdigo arbitrario en elservidor, con privilegios de administrador o "root".Las versiones de Samba anteriores a la 2.2.8 contienen un desbordamientode bfer que permite que un atacante remoto ejecute cdigo arbitrario enel servidor, tpicamente con privilegios de administrador o "root".

La vulnerabilidad reside en el demonio "smbd", concretamente en elre-ensamblado de fragmentos "SMB/CIFS". Si un atacante enva datagramasconvenientemente formateados, puede producir sobreescritura de memoria y,potencialmente, la ejecucin de cdigo arbitrario. El ataque puedeexplotarse de forma remota y annima.

ESQUEMA DE MITIGACION

La recomendacin es que todos los administradores de sistemas SAMBAactualicen 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, alos usuarios y redes que lo necesiten. En particular, no deberan seraccesibles desde Internet.