Perché i socket TCP non sono crittografati per impostazione predefinita?

4

Mi sono chiesto questo fino a quando ho iniziato a programmare, perché i socket TCP non sono crittografati per impostazione predefinita? Tutti dicono sempre che l'uso di socket non elaborati è pericoloso poiché tutti i pacchetti inviati sono suscettibili allo sniffing dei pacchetti.

Quindi, perché l'implementazione originale dei socket TCP non includeva una forma base di crittografia. Quello che ho notato fino ad ora, è che la maggior parte delle lingue non fornisce un'implementazione incorporata che ti obbliga a usare una libreria di terze parti o rendere così difficile per i "noobies" implementare SSL su tutti i socket, che la maggior parte non indossa t anche la briga di farlo in primo luogo.

Anche semplici certificati autofirmati sarebbero sufficienti per la forma di protezione più semplice, che potrebbe essere sottratta ai nuovi sviluppatori.

    
posta Paradoxis 20.12.2016 - 23:50
fonte

3 risposte

5

Il networking moderno segue il modello OSI a sette livelli che ha successo a causa del principio separazione delle preoccupazioni .

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

TCP / IP è il livello 4 ("Trasporto")

The transport layer provides the functional and procedural means of transferring variable-length data sequences from a source to a destination host via one or more networks, while maintaining the quality of service functions.

SSL / TLS è il livello 6 ("Presentazione")

This layer provides independence from data representation (e.g., encryption) by translating between application and network formats. The presentation layer transforms data into the form that the application accepts. This layer formats and encrypts data to be sent across a network. It is sometimes called the syntax layer.

In altre parole, è una scelta di design consapevole.

Inoltre, il protocollo TCP precede SSL da diversi decenni. Per quanto riguarda, SLL continua a cambiare perché vengono trovate debolezze; nel frattempo, TCP è rimasto per lo più lo stesso. Il modello OSI consente una più facile adozione delle modifiche mantenendo alcune cose costanti e variandone altre. Se abbiamo costruito la crittografia in TCP, allora sarebbe un protocollo molto meno stabile.

    
risposta data 21.12.2016 - 00:23
fonte
4

Perché la posta non viene fornita con la crittografia integrata?

Un socket è un concetto semplice che viene utilizzato per rendere possibile la comunicazione tra più parti, ovvero trasferire i messaggi. Pertanto è simile alla posta di lumaca, cioè hai un mittente e un destinatario e il messaggio e potresti avere una protezione minima (busta) che può essere facilmente aggirata. La protezione della comunicazione contro lo sniffing e la manomissione è un concetto molto più complesso e il tipo di protezione effettivamente necessario dipende dal caso d'uso specifico. Ad esempio, l'invio di messaggi a un altro processo sul sistema locale richiede una protezione diversa rispetto all'invio di messaggi a un altro host in una rete locale oa una parte dall'altra parte del pianeta in cui alcuni router intermedi sono controllati da organizzazioni governative.

Quindi ha senso solo gestire lo scambio di messaggi separato dalla protezione dei messaggi per semplificare la comunicazione ed essere flessibili nel tipo di protezione effettivamente necessaria.

Alcuni esempi dei diversi casi d'uso dovrebbero rendere più chiaro il motivo per cui la separazione di questi concetti ha senso:

  • I socket di dominio UNIX non hanno bisogno di crittografia perché è necessario disporre delle autorizzazioni del kernel per annusare i dati, nel qual caso si possono anche prendere i dati prima della crittografia.
  • Se ci si trova in una rete con un'implementazione IPSec completa, tutte le comunicazioni tra le parti della rete sono già crittografate, quindi non è necessario aggiungere un'altra crittografia.
  • La crittografia su Internet come HTTPS deve prima disporre di un'infrastruttura PKI implementata con ancore di trust locali in modo da poter effettivamente autenticare il peer prima di inviare messaggi.
  • La crittografia hop by hop come quella che hai con SMTP (recapito della posta) non protegge il messaggio dallo sniffing sugli hop, quindi hai anche bisogno di una crittografia end-to-end (ad es. PGP, S / MIME).
  • Le comunicazioni unidirezionali o multicast non possono avere il tipo di scambio di chiavi che hai con TLS perché ciò richiede comunicazione bidirezionale.
risposta data 21.12.2016 - 06:41
fonte
2

Carico delle prestazioni

La crittografia richiede uno sforzo maggiore rispetto alle reti di base. Innanzitutto, richiede potenza computazionale - l'esecuzione di tutto il traffico attraverso un canale simile a SSL negli anni '80, quando il TCP ha acquisito l'adozione su larga scala, non sarebbe stato pratico in quanto i processori erano molto più lenti di quelli attuali.

Tuttavia, un problema ancora più grande è il sovraccarico della rete dell'handshake SSL per le piccole richieste. Per i messaggi di piccole dimensioni, l'handshake per stabilire le chiavi di crittografia può facilmente essere più volte più grande del messaggio effettivo e richiede più round trip e può raddoppiare la latenza. Questo è un motivo per cui anche se gli standard fossero riprogettati oggi, avrebbe senso avere i livelli di base del socket di rete senza crittografia.

    
risposta data 21.12.2016 - 02:57
fonte

Leggi altre domande sui tag