Technolifeandmore: Tarea 1: Protocolo RFC 2818

El RFC 2818 original lo puden encontrar en éste link, éste estandar describe como se emplea TLS (Transport Layer Securiity) para asegurar la transferencia de hipertexto (HTTP) de las conexiones a través de internet. También lo que hace es distinguir el tráfico, del inseguro por el uso de un puerto de diferente servidor.

[http://www.techpresentations.org/w/images/graphviz/506e126c81c2108588c955a74dfdf400.png]

Con éste estanadar, se deriban otros o se complementan como el protocolo de comunicación por sockets que va muy relacionada a ella.

El estandar 2818 nace del HTTP [RFC2616] donde fue utilizado originalmente abierto en Internet. Sin embargo, el aumento del uso de HTTP para aplicaciones sensibles ha requerido medidas de seguridad. SSL y TLS sus sucesores fueron diseñados para proporcionar canales orientados hacia la seguridad.

Este tipo de protocolo proporciona autenticación y privacidad de la información entre extremos sobre Internet. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

Algunso casos:
Algunos casos donde nos podemos encotrar éste tipo de problemas, viene siendo principalmente en la comunicación de servicios web al emplear algún puerto específico de conexión. Un caso a mencionar en el ambito laboral és en el desarrollo de aplicaciones, donde un determinado puerto tiene que estar habilitado para la correcta comunicación con el servidor.

Otro de los casos como se mencionó es en los servicios web, hace dos semanas estaba implementando la lectura de una comunicación y me encontraba con el problema que el usuario no estaba identificado, ya que lo estaba haciendo con JQuery (cliente) y despues de estar investigando descubrí que en el servicio web, no se puede hacer una comunicación si del lado del cliente no ésta identificado, necesitando en si un certificado o empleando otra forma de servidor.

Teoría:

Conexión de Sesión:
El agente que actúa como cliente HTTP también debe actuar como el cliente del TLS. Se debe iniciar una conexión con el servidor en el puerto apropiado y luego enviar el ClientHello TLS. Cuando conexión de TLS se ha terminado, el cliente puede entonces iniciar la primera solicitud HTTP. Todos los datos HTTP debe ser enviada como "datos de aplicaciones" TLS.

Conexión de Cierre

TLS debe iniciar un intercambio de alertas de cierre antes de cerrar la conexión. Una implementación TLS puede, después de enviar una alerta de cierre, cerrar la conexión sin tener que esperar a que el cliente envía su alerta de cierre, generando un "cierre incompleto". Esto sólo se debe hacer cuando la aplicación sabe que ha recibido todos los datos de los mensajes que le importa.

Número de puerto

Los primeros datos que un servidor HTTP espera recibir del cliente es la producción Request-Line. Los primeros datos que un servidor TLS espera recibir es la ClientHello. Por consiguiente, la práctica común ha sido la de ejecutar HTTP / TLS a través de un puerto separado con el fin de distinguir a qué protocolo se está utilizando. Cuando HTTP / TLS se ejecuta a través de una conexión TCP / IP, el puerto que es empleado es 443.

Identidad del Servidor

En general, HTTP / TLS son peticiones generadas por eliminación de referencias a un URI. Como consecuencia de ello, el nombre de host del servidor es conocido por el cliente. Si el nombre está disponible, el cliente deberá comprobar que en contra de la identidad del servidor.

Identidad del cliente

Normalmente, el servidor no tiene conocimiento de lo externo la identidad del cliente. Si un servidor tiene tal conocimiento éste es comprobando por una cadena de certificado que tiene el usuario

Formato URI

HTTP / TLS se diferencia de HTTP URI utilizando el identificador 'https' protocolo en lugar del identificador 'http' protocolo. Un URI que especifica ejemplo HTTP / TLS es:

https://www.example.com/ ~ smith / home.html

Otros:
Navegadores que emplean TLS