I protocolli personalizzati sono insicuri?

Sospetto che tu abbia già risposto alla tua domanda.

Il semplice fatto che si desidera proteggere i dati implica che sia sensibile e non dovrebbe essere modificato o trapelato. Se questo non è il caso, perché preoccuparsi di proteggere affatto?

Se è vero il contrario (i dati devono essere protetti), la "regola" indica che l'uso di protocolli personalizzati e algoritmi di crittografia non è consigliato.

Modifica: dati i tuoi chiarimenti - Sebbene leggero, c'è sempre la possibilità di introdurre vulnerabilità sul server / client quando si usano protocolli personalizzati (il grado di possibilità dipenderà ovviamente completamente da ciò che si fa e da come si fa a farlo) . Dato che ora abbiamo stabilito che la lista della spesa è "senza valore", sembrerebbe inutile cercare di proteggerla in un modo che potrebbe potenzialmente aprire ulteriori vettori di attacco sul client / server.

Non avrebbe senso cercare di proteggere qualcosa "senza valore" data anche la minima possibilità che il meccanismo di protezione potesse esporre qualcosa di prezioso.

Alla fine, tutto dipende dalla tua propensione al rischio e da ciò che ritieni più rischioso: i dati della lista della spesa sono trapelati o potenzialmente creano più vulnerabilità?

Questo presume che tu possa andare senza i protocolli personalizzati.

Per definizione, se non importa se qualcuno ha accesso o modifica i tuoi dati, allora non è sensibile e non deve essere sicuro. Per cose che devono essere sicure, allora è sconsigliato utilizzare un protocollo personalizzato a meno che non si possa investire l'enorme quantità di tempo e risorse necessarie per garantirne la sicurezza (milioni).

Si noti tuttavia che esiste anche una differenza tra i protocolli di sicurezza e dati. È possibile utilizzare qualcosa come SSL e utilizzare qualsiasi protocollo che si desidera per lo scambio di dati. Allo stesso modo, potresti avere il tuo sistema per verificare le credenziali dell'utente, ma gli algoritmi di hash e gli algoritmi di crittografia e qualsiasi altra cosa che possa utilizzare gli standard dovrebbero farlo.

C'è molta più flessibilità nel modo in cui si usano gli standard insieme che nel tentativo di creare il proprio standard. Certamente è preferibile utilizzare un sistema standard completo, se possibile, ma è molto meno oneroso dimostrare la sicurezza quando si utilizzano componenti che si possono assumere per svolgere il proprio lavoro in modo sicuro e ben compreso.

Devi fare una distinzione tra il protocollo applicativo e il protocollo di trasporto . SSL / TLS è un protocollo di trasporto: garantisce alcune garanzie legate alla sicurezza (riservatezza, integrità, qualche autenticazione) per un flusso bidirezionale di byte. Ciò che questi significano è ciò che definisce il "protocollo applicativo". Per esempio. in HTTPS, HTTP è il protocollo applicativo e SSL è il protocollo di trasporto.

Definire il proprio protocollo applicativo dipende interamente da te. È possibile eseguire il botch della propria implementazione e, ad esempio, buffer overflow; ma, diversamente, non c'è nulla nella definizione del protocollo applicativo che metterà in pericolo le garanzie di sicurezza offerte dal protocollo di trasporto: dal punto di vista di SSL, i byte sono byte. Tuttavia, c'è un piccolo avvertimento: SSL garantisce la riservatezza per i valori di byte, ma la lunghezza dei dati criptati trapelano. La perdita di lunghezza dei dati è stata fonte di problemi, ad es. il cosiddetto attacco CRIME .

La definizione del tuo protocollo di trasporto è una cattiva idea . O i dati applicativi non hanno bisogno di nessuna delle proprietà di sicurezza di SSL come protocollo di trasporto, nel qual caso il metodo più semplice ed efficiente non è affatto l'uso di SSL, ma solo TCP non elaborato; O hai ancora bisogno di sicurezza e "rolling your own" è una ricetta conosciuta per il disastro. Il tono di fondo è che, contrariamente a una convinzione diffusa, c'è poco spazio per l'ottimizzazione aggiuntiva in SSL: ci sono pochissime parti del protocollo che possono essere rimosse senza interrompere totalmente la sicurezza.

(Ciò che puoi fare, però, è eliminare le funzionalità: supporta solo una suite di crittografia su client e server, rimuovi le estensioni non necessarie e così via. Questo è ancora SSL / TLS standard, e utilizza ancora le librerie SSL / TLS esistenti, che è il punto.)

Penso che tu stia chiedendo se un hacker potrebbe causare problemi ai tuoi server di casa se stai utilizzando un protocollo non sicuro per i dati. Ciò dipende completamente dal modo in cui gestisci i dati e da come utilizzi l'analisi dei pacchetti di informazioni.

Se utilizzi SOLO il protocollo personalizzato per dati non sensibili e implementa buone pratiche di sicurezza (come il blocco di richieste troppo lunghe e il corretto troncamento di stringhe con terminazione nulla, la chiusura e il timeout delle connessioni, ecc.) potresti essere inviare i dati nel formato desiderato.

Puoi anche chiederti quanto è probabile la minaccia di un attacco. A seconda della posizione e della situazione, potrebbe essere sicuro di non aver bisogno di preoccuparsi troppo. Ma personalmente non vorrei correre un'opinione del genere se non dovessi farlo.

Da un punto di vista ingegneristico, ti conviene risparmiare un ton di tempo usando un protocollo standard e librerie decenti, ma se vuoi fare le tue cose, divertiti con esso.