PROGRAMACIÓN EN RED

ACTIVIDAD N°: FECHA ENVIO:

19/10/2015

FECHA ENTREGA:

21/10/2015

TEMA: Seguridad o Vulnerabilidad del Protocolo HTTP

UNIDAD N°1: Fundamentos de la programación en Red

OBJETIVO: Profundizar la investigación sobre la seguridad o vulnerabilidad del protocolo HTTP

PROBLEMA: Desconocimiento de la seguridad o vulnerabilidad del protocolo HTTP

INDICADOR DE EVALUACION: CALIFICACIÓN: Habilidad para aplicar el conocimiento de las ciencias básicas de la

profesión e ingeniería en sistemas. Identificar, formular y resolver problemas de ingeniería de sistemas.

CRITERIOS DE EVALUACIÓN: Siempre(2)

A veces(1)

CAPACIDAD DE COMUNICACIÓN. EN IMPRESOS Entrega documentación impresa y digital. (Siguiendo las normas y convenciones para la escritura y sin falta

de ortografía). La redacción del documento debe ser clara. Debe incluir todas las fuentes de donde tomó la información.

Cumple con el formato, normas y estructura para la elaboración del documento. APLICACIÓN DE VALORES. Puntualidad. Entrega de trabajo a tiempo Responsabilidad ética. El trabajo es inédito y respeta la propiedad intelectual Responsabilidad profesional. Cumple con las normas técnicas.USO DE RECURSOS: Recursos bibliográficos fidedignos y con validez científica Recursos tecnológicos adecuadosCAPACIDAD DE REFLEXIÓN. Incluye ejemplos claros que permiten un mejor entendimiento del tema.CONOCIMIENTO TÉCNICO. Destreza con las herramientas informáticas.

TIPO DE ACTIVIDADLUGAR ALCANCE FORMA

□Intraclase

▪Extraclase▪Individual □Grupal

□Taller □Síntesis, esquemas□Caso de estudio

▪Investigativa□Vinculación con la colectividad

□Práctica en laboratorio□Práctica en clase□Resolución de problemas, ejercicios□Ensayo, artículo□Informe de exposición

CALIFICACIÓN

ROLES Y RESPONSABILIDADES DE LOS PARTICIPANTES EN LA TAREA:NOMBRE ROL DESCRIPCIÓNJorge Vinicio Torres Ramírez

ESTUDIANTE Realiza la investigación

DESARROLLO DE LA ACTIVIDAD:

Consideraciones de Seguridad

Según (RFC2616, s.f.), en la sección 15 indica:

En esta sección se habla acerca de las limitaciones de seguridad en el protocolo HTTP/1.1

Información Personal:

Los clientes HTTP están siempre implicados en grandes cantidades de información personal y deberían ser prevenidas de inintencionadas fugas de información vía el protocolo HTTP hacia otras fuentes, es conveniente dar al usuario una interfaz conveniente que pueda diseminar este tipo de información, y que los desarrolladores sean muy cuidadosos en esta área.

Transferencia de Información Sensible:

El protocolo HTTP no puede regular el contenido que es transferido, este control debe ser impuesto por las aplicaciones.

Integrar Información Sensitiva en URIs:

Los desarrolladores no deben usar el método GET del protocolo HTTP en formularios para subir información sensible, porque esto causa que los datos sean integrados en la URI de petición, los servidores deben usar formularios POST en vez.

Ataques basados en Archivos y Nombres de Rutas:

Servidores que implementan el protocolo HTTP deben ser cuidadosos de restringir los documentos regresados por una petición HTTP, estos deben ser únicamente los destinados por los administradores, si un servidor http traduce directamente URI en rutas del sistema, el servidor debe tener un especial cuidado en no proporcionar archivos que no fueron destinados para los clientes HTTP.

Proxies y Caching:

Por naturaleza, los Proxies HTTP han sido man-in-the-middle, y representan una oportunidad para ataques de este tipo, que haya un ataque a un servidor proxy puede resultar en un serio problema de seguridad y privacidad, los Proxies tiene acceso a información de seguridad, información personal de cada individuo, es por este que se debe implementar seguridades dentro de este tipo de mecanismos.

Como resultado se entiende que se deben implementar seguridades dentro del protocolo HTTP, algunas de ellas vienen a ser otros protocolos que se desarrollaron específicamente para resolver problemas de privacidad y robo de información, haciendo uso de encriptación como por ejemplo el protocolo https, ssl y tsl.

HTTPS

Conocido como HTTP seguro o HTTP sobre SSL, es el uso de SSL o TSL como una subcapa debajo del protocolo HTTP, HTTPS encripta y des encripta las peticiones de los usuarios y también las páginas que son regresadas por el servidor, el uso de este protocolo es eficiente en contra de los ataques como man-in-the-middle y eavesdropping, este protocolo fue desarrollado por NETSCAPE.

¿Cómo Funciona?

Como se mencionó el protocolo HTTP utiliza uno de dos protocolos de conexión segura para encriptar las comunicaciones, SSL o TSL. Ambos protocolos usan lo que se conoce como un sistema de Infraestructura de llave pública “asimétrico”. Un sistema asimétrico usa dos llaves para encriptar comunicaciones, una llave pública y una llave privada. Algo

encriptado con la llave pública solo puede ser des encriptado por la llave privada y viceversa.

Certificado HTTPS

Cuando tú solicitas una conexión HTTPS a una página web, este inicialmente envía un certificado SSL a tu navegador. Este certificado contiene la llave pública para iniciar la sesión segura. Basado en el intercambio inicial, tu navegador y el sitio web inicia el “SSL Handshake”, este envuelve la generación de “shared secrets” para establecer una conexión única entre tú y el sitio web.

Cuando un certificado SSL verificado es usado durante la conexión HTTPS, los usuarios podrán ver un icono de candado en la barra de búsqueda del navegador, cuando un certificado de validación extendido está instalado, la barra se volverá verde.

¿Por qué es necesario un certificado SSL?

Todas las comunicaciones enviadas a través de HTTP están en texto plano y pueden ser accedidas por cualquier hacker que quiera irrumpir la conexión entre tu navegador y el sitio

web, esto representa un claro riesgo si las comunicación es por ejemplo una orden de compra e incluye tus detalles de la tarjeta de crédito o tu número de seguro social. Con una conexión HTTPS, todas las comunicaciones están encriptadas.

Beneficios:

Información de los clientes, como los números de tarjeta, están encriptados y no deben ser interceptados.

Los visitantes pueden verificar que tienes un negocio verificado y el dominio es tuyo.

Los clientes son más propensos a completar una compra de sitios que usan HTTPS.

BIBLIOGRAFÍAComodo. (11 de Agosto de 2013). Instant SSL. Obtenido de https://www.instantssl.com/ssl-

certificate-products/https.html

RFC2616. (s.f.). w3.org. Obtenido de http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html