SSL è più sicuro della codifica?

-8

Sto scrivendo una coppia di programmi client / server. Ho stabilito il mio protocollo e sto comunicando con TCP. Attualmente, quando il client invia un messaggio al server, aggiunge 42 a ciascun byte (looping, 127 + 1 = -128) e inverte l'array di byte da inviare. Il lato server sottrae 42 da ogni byte e inverte nuovamente l'array di byte. Ciò mi offre una sicurezza facile da implementare.

Rispetto al livello SSL SSH / HTTPS con handshake, chiavi private e pubbliche a 128 bit, eccetera, che è più sicuro? Cioè, se faccio HTTPS in qualche internet cafone losco, il proprietario può trarre qualche accorgimento per fare connessioni 'sicure' tra i loro computer in prestito e GMail, ad esempio, per rendere sniffable il mio traffico in stile Wireshark, mentre, se un internet cafè il proprietario guarda un pacchetto di cattura della codifica (+42, inversa), probabilmente sarebbe in perdita per decifrarlo.

    
posta Scruffy 18.12.2014 - 11:42
fonte

5 risposte

10

Ciò che hai definito non è sicurezza.

SSL può darti sicurezza.

Quindi ... la tua domanda è facile da rispondere:

Sì. SSL è fino al 100% più sicuro della codifica. Mentre gli elementi del tuo secondo paragrafo hanno una base di fatto (ci sono attacchi MITM malevoli, ecc.), Possono essere protetti, mentre la tua soluzione non ha alcuna protezione ed è facilmente decodificata da chiunque.

La tua ipotesi di "essere in perdita" è completamente falsa, temo. Tutto ciò che assomiglia alla codifica è incredibilmente facile da trovare e interrompere.

    
risposta data 18.12.2014 - 11:50
fonte
2

Sei nella situazione, che il tuo client e il tuo server condividono un segreto (il tuo algoritmo aggiunge 42 a ciascun byte). Sebbene si tratti di un'implementazione poco sicura, sarebbe possibile crittografare il contenuto con una chiave strong e il tuo messaggio sarebbe sicuro.

Il problema è che, non appena qualcuno ottiene il segreto (comunque lo fa), può leggere il tuo messaggio. Un testo codificato non è un problema per qualsiasi utente malintenzionato, la crittografia è.

SSL dall'altra parte è in grado di crittografare il tuo messaggio, anche se il tuo client non ha installato nulla (nessun segreto condiviso è disponibile). Lo fa con i certificati, che possono essere verificati con i certificati radice installati del tuo browser.

    
risposta data 18.12.2014 - 11:53
fonte
2

Non sono sicuro di chi sia l'intenzione di smettere - lo schema di codifica descritto è appena abbastanza strong da sconfiggere una minaccia di tipo "intercettatore senza tracce" ed è incapace di fermare o addirittura di rallentare in modo significativo un "piccolo fratello ficcanaso" -attaccante di classe. Qualcuno con le capacità tecniche per eseguire un attacco SSL "man-in-the-middle" come descritto nella domanda dovrebbe essere in grado di vederlo direttamente.

    
risposta data 18.12.2014 - 12:08
fonte
1

Ciò che hai implementato è qualcosa di molto simile al "codice di Cesare" che è già stato usato nell'VIII secolo. È facilmente infrangibile con carta e penna. Vedi questo articolo per maggiori informazioni: link

Quindi in pratica, nessun algoritmo non è paragonabile alle attuali implementazioni TLS. Vedi anche questo thread perché non dovresti pubblicare la tua crittografia: Perché non dovremmo tira il nostro?

    
risposta data 18.12.2014 - 17:08
fonte
-2

Si vedono molti strumenti per rompere protocolli specifici, ma ci sono strumenti generici per codifiche create a mano? In tal caso, questo potrebbe essere un metodo adeguato per il pubblico in generale.

    
risposta data 18.12.2014 - 14:38
fonte

Leggi altre domande sui tag