Perché i protocolli sugli strati superiori possono essere lasciati invariati?

Dovresti pensare ai livelli OSI come a un packaging.

Diciamo che voglio spedirti un bicchiere. Ho scelto un pacchetto originale a scopo pubblicitario, mostrando quanto è bello il mio prodotto e cosa puoi acquistare per aggiungere alla tua esperienza di "vetro". Questo è l'alto livello del mio protocollo.

Poi metto questo pacchetto in una scatola piena di cose morbide perché non voglio che si rompa con il trasporto. Questo è un secondo livello.

Quindi il mio reparto spedizioni racchiude questa scatola in un pacchetto più grande, con un'etichetta da spedire a casa tua. Di nuovo, un altro livello.

Quindi il trasportatore mette questa scatola in un camion con molte altre scatole e ordina al conducente di recarsi in un altro centro di consegna, ancora un altro strato.

Per quello che sappiamo, il camionista non ha bisogno di sapere:

• dove le scatole vanno esattamente a casa tua, ha solo bisogno di sapere il tuo indirizzo
• quali sono le protezioni nelle scatole, deve solo guidare in modo sicuro come indicato nel suo contratto
• che cosa è esattamente nelle caselle

Diciamo ora che voglio fornire riservatezza alla mia spedizione. Perché un pilota curioso potrebbe provare a manomettere i pacchetti per sapere cosa c'è dentro, o rubarlo e rivenderlo.

Posso usare un protocollo in cui il vostro vetro impacchettato morbido viene anche inserito in una scatola di metallo con un armadietto. Lo proteggerà dalle manomissioni del camionista, poiché non sarà in grado di sbirciare all'interno o prendere la merce. Non protegge gli strati inferiori, potrebbe ancora scaricare tutto il filo in un lago, questo è negare il servizio. Inoltre, il mio armadietto non si interessa di cosa c'è dentro. Potrebbe essere il tuo bicchiere, potrebbe essere un fiore o potrebbe essere vuoto. Ma ha ancora lo scopo di evitare che altri che te (e lo spedizioniere di c) sappiano cosa c'è dentro.

È lo stesso per i protocolli nell'OSI. Gli strati inferiori non si preoccupano di ciò che sta accadendo negli strati superiori. Questo è lasciato a un altro agente per decodificarlo / gestirlo.

Modifica per chiarimenti: quando diciamo "lasciato invariato" ciò non significa che l'informazione non sia stata elaborata. In particolare per SSL, il carico utile del livello SSL è una crittografia del pacchetto del livello superiore. Ma quando SSL opera nell'altro lato, decodifica il pacchetto originale senza alcuna modifica.

Mentre OSI è solo un modello, e in realtà gli strati possono essere sfocati o inesistenti, il concetto di protocolli di stratificazione è specificamente per consentire un cambiamento in un particolare livello di lasciare gli strati sopra e sotto di esso da solo.

Ad esempio:

• Fisico - un pacchetto base è importante se viaggia su rame, fibra o wireless? Potrebbe viaggiare su tutti e tre ad un certo punto del suo viaggio. Non vuoi dover riscrivere http in specifici sapori per ciascuno di questi supporti fisici, quindi fallo una volta.

Quindi i pezzi importanti sono il modo in cui ogni livello si interfaccia con quelli adiacenti.

La metafora di M'vy sul trasporto di un oggetto fisico è molto appropriata qui.

TCP fornisce alle applicazioni un'interfaccia di flusso. Ci sono alcune eccezioni in cui i dettagli filtrano, ma generalmente viene aperto un socket TCP, e quindi ogni lato invia una serie di byte all'altro. Questi byte saranno consegnati intatti e in ordine, fino al punto in cui il terminale remoto chiude la connessione (di cui verrai informato). Le applicazioni devono solo conoscere l'interfaccia del flusso. Non hanno bisogno di conoscere i dettagli dell'hardware di rete sottostante, non hanno bisogno di conoscere il controllo della congestione, le dimensioni delle finestre, la ritrasmissione di pacchetti, o anche che ci siano sono pacchetti.

TLS si trova sulla parte superiore del TCP e fornisce servizi di autenticazione e crittografia, e anche fornisce alle applicazioni un'interfaccia di streaming. C'è un mucchio di roba aggiuntiva in corso di sviluppo, un sacco di nuove potenziali condizioni di errore e un sacco di nuovi metadati che un'applicazione esegue una query su un socket per (ad esempio, informazioni sul certificato remoto e il suo problema), ma il le operazioni di base sono le stesse: connettersi a un dato indirizzo, inviare byte, ricevere byte, chiudere la connessione e essere informati di una chiusura remota.

Il punto è che qualsiasi protocollo a livello di applicazione che può operare in cima ai flussi forniti da TCP può anche operare sopra i flussi forniti da SSL, senza alcuna modifica fondamentale al applicazione stessa. Infatti, nei casi in cui non è considerato importante che l'applicazione riceva informazioni sulla crittografia utilizzata, o sul certificato della parte remota o su una di queste, è possibile utilizzare un proxy come stunnel per tradurre tra una connessione TCP crittografata con TLS e una non cifrata. Ad esempio, stunnel su un computer client potrebbe consentire a un normale client di posta (non supportato da TLS) puntato sul server IMAP localhost:143 di connettersi al server IMAPS mymailserver:993 ; o stunnel su un computer server potrebbe ascoltare le connessioni HTTPS su externalip:443 e proxy su internalserver:80 , consentendo a internalserver (un server HTTP) di avere comunicazioni protette con il mondo anche se non implementa TLS stesso.

Questo è proprio come i veicoli in movimento sulla strada. Come la strada è il mezzo fisso e su di esso possono scappare molti tipi di veicoli e quindi se si crea un nuovo veicolo per farlo correre su strada il veicolo deve avere pneumatici che potrebbero correre su quella strada.

Allo stesso modo, se consideri Ethernet come un mezzo, potrebbe trasportare vari protocolli di rete come IPv4 o IPv6. Quindi il punto qui sopra è che il modello di rete è reso così modulare che è possibile sostituire le cose a proprio piacimento purché siano conformi a determinate specifiche dell'interfaccia.

Quindi il design modulare specifica che qualunque sia il tuo lavoro interno non importa ciò che importa che ti viene dato un input in un certo modo processarlo e generare un output comprensibile dal prossimo modulo.

Dopo aver stabilito una connessione sicura, un browser Web chiederà comunque lo stesso tipo di domanda, come

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

e il web server risponderà allo stesso modo

200 OK
Content-Type text/html
...

L'unica differenza è che sotto questa conversazione non abbiamo una connessione TCP diretta ma invece una crittografia. Proprio come i livelli superiori sono "inconsapevoli" di ciò che normalmente fa TCP (come la ritrasmissione dei pacchetti, il riconoscimento, l'aggiustamento delle finestre, ...), sono anche "inconsapevoli" della crittografia sottostante in atto.

Beh, in senso stretto è una certa interdipendenza: il livello di crittografia è basato sull'utilizzo di un certificato che appartiene specificamente al FQDN www.example.com, che tradizionalmente il server non conosce fino a ricevendo l'intestazione host: . Questo è anche il motivo per cui le vecchie implementazioni potrebbero gestire più http-vhost su un singolo IP, ma solo un https-vhost per ip. Questo è stato risolto da SNI.

I protocolli di alto livello potrebbero non essere sicuri se usati, invariati, con SSL. C'è la possibilità di attacchi ai canali laterali.

Come altri hanno spiegato bene, SSL ti permette di avvolgere un flusso non criptato in uno criptato. In teoria, nessuna informazione sui dati trasmessi dovrebbe essere trapelata. In pratica, c'è un pezzo di dati che perde sempre: la quantità di dati trasmessi.

Sembra una perdita accettabile, e in alcuni casi lo è. Tuttavia, vi sono numerosi attacchi, come l'attacco CRIME e questo attacco a VOIP , che sfrutta il fatto che i dati sono compressi, e i rapporti di compressione variano a seconda del contenuto del messaggio, da spigolare informazioni sul contenuto dei messaggi.

Gli altri attacchi ai canali laterali possono anche essere possibili utilizzando altri pezzi di dati trapelati, come ad esempio la tempistica precisa delle richieste e delle risposte.

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 le modalità di negoziazione / handshake cambiano per la crittografia aggiunta.

HTTPS crittografa un messaggio HTTP (dati) prima della trasmissione e lo decodifica all'arrivo

I protocolli di livello superiore non si preoccupano dei dettagli dei livelli inferiori . Assumono che gli strati inferiori siano stati implementati in qualche modo e procedono da lì. Se seguiamo il modello TCP / IP, ci sono quattro di questi livelli:

OSI definisce un livello fisico, che gestisce il collegamento di due macchine insieme; TCP / IP no, ma è utile pensarci qui . Twisted-pair, coassiale, CAT6 e onde radio sono alcuni modi comuni per connettere le macchine, ma puoi usare quasi tutto, inclusi raggi laser, onde sonore e, sì, piccioni viaggiatori .

Il livello Link, che gestisce l'acquisizione di un segnale su due macchine direttamente connesse . La famiglia 802.11 (Wi-Fi), la famiglia 802.3 (Ethernet) e PPP (modem) sono probabilmente i protocolli di livello link più popolari oggi, ma ce ne sono altri.

Il livello Internet, che riceve un segnale su due macchine che non sono collegate direttamente attraverso una catena di macchine che . È qui che risiede l'IP, sia in IPv4 che in IPv6.

Il livello di trasporto, che gestisce la logistica dei segnali di svolta in un flusso di dati utilizzabile . TCP e UDP vivono entrambi qui, così come alcuni protocolli meno conosciuti.

Il livello applicazione, che interpreta i dati assemblati dal livello di trasporto . Qui è dove la maggior parte dei protocolli che sentiamo comunemente su -HTTP, FTP, POP, IMAP e così via- live.

HTTP vive nel livello applicazione . Si presuppone che tu abbia già un modo significativo per ottenere un flusso di dati su macchine che potrebbero non essere direttamente collegate l'una con l'altra. Finché l'hai ottenuto, a HTTP non importa da dove provenga il flusso di dati. Tecnicamente non è nemmeno necessario utilizzare TCP / IP nel trasporto sottostante, anche se in pratica quasi tutti lo fanno.

Per scopi quotidiani, SSL / TLS vive nel livello di trasporto (la verità tecnica della questione è più complicata, ma non influisce sugli utenti finali). Vale a dire, gli dai un flusso di dati da inviare e recuperare un flusso di dati quando ricevi, proprio come TCP / IP. In particolare, SSL / TLS non si preoccupa del contenuto del suo flusso di dati: puoi passarlo come vuoi e farà il suo dovere.

Poiché nessuno dei due livelli si interessa di quello che fa l'altro, puoi cambiarli liberamente . L'HTTP è felice finché ottiene gli stream che vuole, e non si preoccupa di ciò che i protocolli sottostanti fanno a quei flussi nel frattempo, quindi puoi usare qualsiasi protocollo di livello di trasporto sottostante. TCP / IP (e SSL / TLS) non si preoccupano del contenuto dei dati, tranne se necessario per assicurarsi che i dati risultanti dall'altra parte siano esattamente uguali a quelli inviati dall'utente, quindi è possibile utilizzare qualsiasi applicazione -player protocollo con loro

I know the OSI layers

OK, per prima cosa sbagli - ma come hai visto dalle altre risposte, questo è un malinteso comune. TCP / IP non è OSI. Precede l'OSI ma un certo numero di anni. E non è nemmeno destinato a essere la stessa cosa. TCP / IP è (alcuni degli strati di) un protocollo di rete, OSI è un modello di come progettare un protocollo di rete completo. Prova a spiegare TCP / IP in termini di OSI e presto ti sbloccherai per es. HTTP / 2 su TCP / IP? 4 diversi livelli di sessione, compressione eseguita in almeno 2 livelli separati dello stack.

SSL o TLS è un metodo per implementare la comunicazione asimmetrica su qualsiasi interfaccia di flusso bidirezionale. Ciò significa che può essere eseguito su TCP / IP, IPX / SPX, socket di dominio Unix, pipe denominate (full duplex), RS-232 .... Ma quando è stata l'ultima volta che hai usato una rete dati diversa da TCP / IP?

Luc non ha torto nel dire che SSL / TLS può essere eseguito su UDP, semplicemente non sta raccontando l'intera storia: per tale architettura esiste un ulteriore livello tra le parti TLS e UDP che implementa il riassemblaggio del flusso, il recupero degli errori e gestione della larghezza di banda.

In his first sentence, he is saying that protocols on higher layers can be left unchanged.

Questo è falso, punto.

I livelli superiori devono indicare in qualche modo che SSL / TLS dovrebbe essere usato; nel Web ciò avviene con lo schema HTTPS: URL, con il flag di sicurezza sui cookie HTTP e con un criterio HSTS (HTTP Strict Transport Security).