¿Por qué no se pueden modificar los protocolos en las capas más altas?

Deberías pensar en las capas OSI como empaquetado.

Digamos que quiero enviarte un vaso. Elegí un paquete original para fines publicitarios, que muestra lo bueno que es mi producto y lo que puede comprar para agregar a su experiencia de "vidrio". Esa es la capa alta de mi protocolo.

Luego coloco este paquete en una caja llena de cositas blandas porque no quiero que se rompa con el transporte. Esta es una segunda capa.

Luego, mi departamento de envíos encierra esta caja en un paquete más grande, con una etiqueta para enviar a su casa. De nuevo, otra capa.

Luego, el transportista puso esta caja en un camión con muchas otras cajas y le indicó al conductor que fuera a otro centro de entrega, otra capa más.

Por lo que sabemos, el conductor del camión no necesita saberlo:

• a dónde van exactamente las cajas en su casa, solo necesita saber su dirección
• qué tipo de protección hay en las cajas, solo tiene que conducir de manera tan segura como se indica en su contrato
• qué es exactamente lo que hay en las cajas

Digamos ahora que quiero proporcionar confidencialidad a mi envío. Porque, un curioso conductor podría intentar manipular los paquetes para saber qué hay dentro, o robarlo y revenderlo.

Puedo usar un protocolo donde tu vidrio con revestimiento blando empaquetado también se coloca en una caja de metal con un armario. Lo protegerá de la manipulación indebida del conductor del camión, ya que no podrá echar un vistazo al interior ni tomar la mercancía. No protege las capas inferiores, aún podría tirar todo el traste en un lago, esto es una denegación de servicio. Además, a mi casillero no le importa lo que hay dentro. Podría ser su vaso, podría ser flores o podría estar vacío. Pero todavía tiene el propósito de evitar que alguien más que usted (y el remitente de la empresa) sepan lo que hay dentro.

Va igual para los protocolos en el OSI. Las capas inferiores no se preocupan por lo que está sucediendo en las capas superiores. Esto se deja para que otro agente lo descifre / maneje.

Edite para aclarar: cuando decimos "sin cambios" no significa que la información no sea procesada. En particular, para SSL, la carga útil de la capa SSL es un cifrado del paquete de la capa superior. Pero cuando SSL funcionó en el otro lado, descifrará el paquete original sin ninguna modificación.

Si bien OSI es solo un modelo, y en realidad las capas pueden ser borrosas o inexistentes, el concepto de protocolos de capas es específicamente para permitir que un cambio en una capa en particular deje las capas por encima y por debajo solo.

Como ejemplo:

• Físico: ¿a un paquete básico le importa si viaja por cobre, fibra o inalámbrico? Podría viajar sobre los tres en algún momento de su viaje. No desea tener que volver a escribir http en sabores específicos para cada uno de estos medios físicos, por lo que debe hacerlo una vez.

Por lo tanto, las piezas importantes son cómo cada capa interactúa con las adyacentes.

La metáfora de M'vy sobre el transporte de un objeto físico es muy apropiada aquí.

TCP proporciona a las aplicaciones una interfaz de flujo. Hay algunas excepciones en las que los detalles se filtran, pero generalmente se abre un socket TCP, y luego cada lado envía una serie de bytes al otro. Esos bytes se entregarán intactos y en orden, hasta el punto en que el extremo remoto cierre la conexión (de lo que se le informará). Las aplicaciones solo necesitan saber acerca de la interfaz de transmisión. No necesitan conocer los detalles del hardware de red subyacente, no necesitan conocer el control de congestión, el tamaño de las ventanas, la retransmisión de paquetes o incluso que hay paquetes .

TLS se encuentra sobre TCP, y proporciona servicios de autenticación y cifrado, y también proporciona a las aplicaciones una interfaz de flujo. Hay un montón de cosas adicionales bajo el capó, un montón de nuevas posibles condiciones de error y un montón de nuevos metadatos para los que una aplicación puede realizar una consulta (por ejemplo, información sobre el certificado remoto y su problema), pero Las operaciones básicas son las mismas: conectarse a una dirección determinada, enviar bytes, recibir bytes, cerrar la conexión y recibir información sobre un cierre remoto.

El punto de esto es que cualquier protocolo de nivel de aplicación que pueda operar sobre las transmisiones proporcionadas por TCP puede también operar sobre las transmisiones proporcionadas por SSL, sin ningún cambio fundamental en el aplicación en sí. De hecho, en los casos en que no se considera importante que la aplicación reciba información sobre el cifrado utilizado, el certificado de la parte remota, o cualquiera de ellos, puede usar un proxy como stunnel para traducir entre una conexión TCP cifrada con TLS y una no cifrada. Por ejemplo, Stunnel en una máquina cliente podría permitir que un cliente de correo regular (no compatible con TLS) apuntado al servidor IMAP localhost:143 se conecte al servidor IMAPS mymailserver:993 ; o stunnel en una máquina servidor podría escuchar las conexiones HTTPS en externalip:443 y enviarlas a internalserver:80 , permitiendo que internalserver (un servidor HTTP) tenga comunicaciones seguras con el mundo aunque no implemente TLS. / p>     

Esto es como mover vehículos en la carretera. Como la carretera es el medio fijo y en ella pueden correr muchos tipos de vehículos, por lo que si fabrica un vehículo nuevo para que funcione en la carretera, el vehículo debe tener llantas que puedan correr en esa carretera.

Del mismo modo, si considera Ethernet como un medio, podría llevar a varios protocolos de red como IPv4 o IPv6. Entonces, el punto aquí es que el modelo de red se hace tan modular que puede reemplazar las cosas como quiera, siempre y cuando cumplan con ciertas especificaciones de interfaz.

Por lo tanto, el diseño modular especifica que cualquiera que sea su trabajo interno, no importa lo que importa, se le da entrada de cierta manera, procese en él y genere una salida comprensible para el siguiente módulo.

Después de establecer una conexión segura, un navegador web seguirá haciendo el mismo tipo de pregunta, como

GET /som/page.html HTTP/1.1
host: www.example.com

y el servidor web seguirá respondiendo de la misma manera

200 OK
Content-Type text/html
...

La única diferencia es que debajo de esta conversación no tenemos una conexión TCP directa, sino un cifrado. Al igual que las capas superiores son "inconscientes" de lo que normalmente hace TCP (como la retransmisión de paquetes, el reconocimiento, el ajuste de la ventana, ...), también son "inconscientes" del cifrado subyacente que tiene lugar.

Bueno, hablando estrictamente, hay alguna interdependencia: la capa de cifrado se basa en el uso de un certificado que pertenece específicamente al FQDN www.example.com, que tradicionalmente el servidor no conoce hasta que recibiendo el encabezado host: . Esa es la razón por la que las implementaciones más antiguas podrían tratar con múltiples vhosts de http en una sola ip, pero solo un https-vhost por ip. Esto fue remediado por SNI.

Los protocolos de alto nivel pueden no ser seguros cuando se usan, sin cambios, con SSL. Existe la posibilidad de ataques de canal lateral.

Como otros lo han explicado bien, SSL le permite envolver un flujo no cifrado en uno cifrado. En teoría, no se debe filtrar ninguna información sobre los datos que se transmiten. En la práctica, hay una pieza de datos que siempre se filtra: la cantidad de datos transmitidos.

Esto suena como una fuga aceptable, y en algunos casos lo es. Sin embargo, hay varios ataques, como el ataque CRIME , y este ataque en VOIP , que aprovecha el hecho de que los datos están comprimidos y los índices de compresión varían según el contenido del mensaje, para recopilar Información sobre el contenido de los mensajes.

Otros ataques de canal lateral también pueden ser posibles utilizando otros datos filtrados, como la sincronización precisa de las solicitudes y respuestas.

Http                    Https

+------------------+    +------------------+
|7 http  methods   |    | http methods     |  <---same No change needed
+------------------+    +------------------+
|6 data:ex)"$1000" |    | data:ex)"kf4d3s1"|  <---data encrypted
+------------------+    +------------------+
|5 Sock:           |    | Sock:            |
+------------------+    +------------------+
|4 TCP :           |    | TCP:             |
+------------------+    +------------------+
|3 IP :            |    | IP :             |
+------------------+    +------------------+
|2 PPP:            |    | PPP:             |
+------------------+    +------------------+
|1 RJ45:           |    | RJ45:            |
+------------------+    +------------------+


7.  Application Layer  -> Http
6.  Presentation Layer -> MIME SSL TLS XDR <---- This is what you want
5.  Session Layer      -> Sockets
4.  Transport Layer    -> TCP UDP SCTP DCCP
3.  Network Layer      -> IP IPsec ICMP IGMP OSPF RIP
2.  Data link Layer    -> PPP,SBTV,SLIP
1.  Physical Layer     -> FDDI, B8ZS, V.35, V.24, RJ45.

Solo las formas de negociación / cambio de protocolo de enlace para el cifrado adicional.

HTTPS cifra un mensaje HTTP (datos) antes de la transmisión y lo descifra a su llegada

Los protocolos de capa superior no se molestan con los detalles de las capas inferiores . Simplemente asumen que las capas inferiores se han implementado de alguna manera, y proceden de allí. Si seguimos el modelo TCP / IP, hay cuatro de estas capas:

OSI define una capa física, que se ocupa de conectar dos máquinas juntas; TCP / IP no lo hace, pero es útil pensar aquí . Las ondas de par trenzado, coaxial, CAT6 y de radio son algunas formas comunes de conectar máquinas, pero puede usar casi cualquier cosa, incluidos rayos láser, ondas de sonido y, sí, palomas mensajeras .

La capa de enlace, que se encarga de obtener una señal a través de dos máquinas conectadas directamente . La familia 802.11 (Wi-Fi), la familia 802.3 (Ethernet) y PPP (módems) son probablemente los protocolos de capa de enlace más populares en la actualidad, pero hay otros.

La capa de Internet, que recibe una señal a través de dos máquinas que no están conectadas directamente a través de una cadena de máquinas que están . Aquí es donde vive IP, tanto en IPv4 como en IPv6.

La capa de transporte, que maneja la logística de convertir las señales en un flujo de datos utilizable . TCP y UDP viven aquí, al igual que algunos protocolos menos conocidos.

La capa de aplicación, que interpreta los datos recopilados por la capa de transporte . Aquí es donde la mayoría de los protocolos que comúnmente escuchamos sobre -HTTP, FTP, POP, IMAP, y así sucesivamente- en vivo.

HTTP vive en la capa de aplicación . Se asume que ya tiene una manera significativa de obtener un flujo de datos a través de máquinas que podrían no estar directamente conectadas entre sí. Mientras tengas eso, a HTTP no le importa de dónde proviene el flujo de datos. Técnicamente, ni siquiera tiene que usar TCP / IP en el transporte subyacente, aunque en la práctica casi todos lo hacen.

Para fines cotidianos, SSL / TLS vive en la capa de Transporte (la verdad técnica del asunto es más complicada, pero no afecta a los usuarios finales). Es decir, le da un flujo de datos para enviar y recupera un flujo de datos cuando lo recibe, como TCP / IP. En particular, a SSL / TLS no le importa el contenido de su flujo de datos: puede pasarlo como desee y hará su trabajo.

Debido a que a ninguna capa le importa lo que hace la otra, puedes intercambiarlas libremente . HTTP está contento siempre que obtenga las secuencias que desea, y no le importa lo que hagan los protocolos subyacentes a esas secuencias mientras tanto, por lo que puede usar cualquier protocolo de capa de transporte debajo. TCP / IP (y SSL / TLS) no se preocupan por el contenido de los datos, excepto cuando sea necesario para asegurarse de que los datos resultantes en el otro extremo sean exactamente iguales a los que envió el usuario, por lo que puede usar cualquier aplicación protocolo de doble capa con ellos

  

Conozco las capas OSI

Está bien, primero hay un error, pero como ha visto en las otras respuestas, este es un error común. TCP / IP no es OSI. Es anterior a OSI, pero varios años. Y ni siquiera pretende ser lo mismo. TCP / IP es (algunas de las capas de) un protocolo de red, OSI es un modelo de cómo diseñar un protocolo de red completo. Trate de explicar TCP / IP en términos de OSI y pronto se despegará, por ejemplo. HTTP / 2 sobre TCP / IP? 4 capas de sesión diferentes, la compresión se realiza en al menos 2 capas separadas de la pila.

SSL o TLS es un método de implementación de comunicación asimétrica sobre cualquier interfaz de flujo bidireccional. Eso significa que puede ejecutarse en TCP / IP, IPX / SPX, sockets de dominio Unix, tuberías con nombre (dúplex completo), RS-232 ... ¿Pero cuándo fue la última vez que usó una red de datos que no sea TCP / IP? / p>

Luc no se equivoca al decir que SSL / TLS puede ejecutarse sobre UDP, simplemente no está contando toda la historia; para tal arquitectura hay una capa adicional entre las partes TLS y UDP que implementa el reensamblado de la secuencia, la recuperación de errores y gestión de ancho de banda.

  

En su primera oración, él dice que los protocolos en capas superiores   se puede dejar sin cambios.

Esto es falso, punto.

Las capas superiores deben indicar de alguna manera que se debe usar SSL / TLS; en la Web, esto se hace con el esquema HTTPS: URL, con el indicador de seguridad en las cookies HTTP y con una política de HSTS (Seguridad de transporte estricta de HTTP).