Homebrewing qualcosa come SSL

Naviga le tue risposte
1

Quindi io e altri otto amici abbiamo fondato una "compagnia" (non ufficiale, ci piace chiamarci così) chiamata sDev e stiamo facendo un gioco di strategia. Abbiamo 16-17 anni e abbiamo circa 3-5 anni di esperienza nella codifica, principalmente da lezioni scolastiche. Tanto per il contesto di questa domanda

Per quanto riguarda la comunicazione di rete nel nostro gioco, abbiamo preso la decisione (piuttosto ragionevole) di usare il traffico encrypred; il gruppo è d'accordo su questo. Il modo di farlo? Ecco dove le nostre opinioni divergono. La maggior parte di noi concorda sul fatto che sarebbe utile per noi utilizzare una libreria di sicurezza prefabbricata (l'unica che nessuno di noi conosce SSL) mentre il nostro entusiasta (in senso buono) collega Martin è a favore di un'alternativa.

Martin pensa che sarebbe positivo per noi creare il nostro SSL per una serie di motivi:

  • tempo di compilazione
  • dimensione del repository
  • codifichiamo solo le cose di cui abbiamo bisogno
  • esperienza
  • materiale di licenza
  • sarebbe bello

Nota a margine, a questo punto l'idea di martins di rendere il nostro SSL è diventato un meme. Mentre siamo in grado di identificare con le sue opinioni ci sono alcuni problemi che vedo in questo, principalmente il fatto che non vorrei avere la responsabilità per la sicurezza dei nostri potenziali clienti. Molti di noi sarebbero anche turbati dal compito di trovare la motivazione per apprendere e implementare RSA, AES e quant'altro necessario. La mia più grande preoccupazione è che la mancanza di un semplice controllo può rovinare tutto (esempio migliore, senza problemi) e non mi fido di me o del team per codificare un software così perfetto che possa eguagliare le prestazioni e la sicurezza di SSL ( non che io abbia problemi di fiducia). Se abbiamo già questa bellissima libreria con anni di sforzi e un strong team competente dietro di esso che è anche aperto e ha una licenza molto gentile da usare, perché rischiare di crearne uno nostro?

Quindi, qui alla mia domanda attuale, ad alcune persone che sono più in campo:

Quanto sarebbe vantaggioso rendere davvero il nostro SSL, quanto rischioso è se roviniamo e quanto sono validi gli argomenti per entrambe le parti?

A proposito, Martin mostrerà questa domanda nel prossimo futuro

    
posta 7H3_H4CK3R 11.09.2017 - 16:23
fonte

2 risposte

3

TL; DR: Non trovo davvero alcun punto positivo per registrare la tua sicurezza. Puoi provare a implementare i concetti di base di SSL in alcune applicazioni fittizie per imparare come funziona, ma oltre a questo non dovresti nemmeno prenderne in considerazione l'utilizzo in Productive. Per il tuo bene e per quello di ogni utente che dovrebbe usare la tua applicazione.

Accanto al punto di "non rollare il tuo" (che è sempre un argomento che elimina la necessità di una propria implementazione perché uno sviluppatore "normale" non può svilupparlo correttamente) secondo i punti di Martin:

  • tempo di compilazione - > non compilerai l'intera libreria SSL, la userai. Quindi usarne uno esterno è più veloce del tuo
  • dimensione del repository - > tu usi la Libreria, la tua implementazione sarebbe molto più grande
  • codifichiamo solo le cose di cui abbiamo bisogno - > fai esattamente questo;)
  • esperienza - > ok, imparerai le basi di SSL. Ma se poi programmi qualcosa che è rotto all'inizio e pensi che questo codice sia corretto, imparerai qualcosa di sbagliato e penserai che sia corretto. È molto peggio, quindi impara come usare una libreria ben nota
  • roba di licenza - > sì forse dovresti inserire del testo nella tua applicazione che dice che usi quella libreria. Ma poi vai a diverse grandi applicazioni (ad esempio può essere Android OS) e vai alla loro parte di licenza. Se (si usa SSL) vedrai sempre il testo della licenza della libreria openSSL
  • sarebbe bello - > cosa è bello costruire qualcosa che non va bene;)

Ulteriori:  Cerca sempre di utilizzare le librerie che sono ben note. Non è necessario correggere bug all'interno di essi, vengono esaminati da più occhi che puoi permetterti e i bug sono trovati molto più velocemente rispetto al tuo codice (i tuoi 10.000 utenti contro i loro 1 milione di utenti, ad esempio). Ulteriori informazioni sono ben note Librerie di sicurezza molto spesso controllate da esperti che sanno cosa stanno facendo;)

Il codice migliore è quello che non scrivi.

    
risposta data 11.09.2017 - 17:14
fonte
3

@Serverfrog ha colpito molti dei punti, ma l'unico valido motivo per scrivere il proprio protocollo di crittografia oggi sarebbe quello di imparare dall'esperienza.

Il problema con la scrittura tua è che non puoi vedere i suoi difetti. Schnier disse una volta con disinvoltura: "Chiunque può creare un algoritmo di crittografia che non possono rompere". Lo stesso vale per i protocolli. Quindi per favore non sentirti male, perché questo è un problema ben compreso nello sviluppo del protocollo crittografico.

Un problema è che non si è a conoscenza di tutti i problemi di sicurezza che hanno afflitto tutti i precedenti tunnel di crittografia e semplicemente non si conoscono tutte le vulnerabilità di cui si dovrebbe difendere. Ad esempio, sapevi che se non si codifica perfettamente l'algoritmo di crittografia, è possibile che vi siano informazioni che non si riescono nemmeno a vedere? Un utente malintenzionato può inviare migliaia di richieste crittografate alla tua macchina, cronometrare le risposte e utilizzare le variazioni dei tempi per impara i bit delle tue chiavi segrete . O se crittografate messaggi compressi, un utente malintenzionato può misurare la lunghezza delle risposte per estrarre il contenuto di un messaggio? Sai perché il mondo utilizza TLS 1.2, perché i ricercatori stanno lavorando su TLS 1.3 e cosa è successo a TLS 1.1, TLS 1.0 , SSLv3, SSLv2 e SSLv1 ? E questi sono solo alcuni esempi delle centinaia di difetti che sono stati trovati.

La storia della crittografia è costellata da centinaia di dolorose, costose e talvolta fatali lezioni su come gli hacker possono scoprire nuovi difetti e sfruttarli; anche se i principali studiosi ed esperti del settore non li hanno mai trovati, nonostante anni di ricerca.

Se vai avanti, quali esperti ti sei allineato per studiare i tuoi protocolli crittografici per i punti deboli? Dove sono questi studiosi che stanno andando a scrivere la tesi del loro master sui tuoi protocolli, dimostrando che non ci sono difetti nascosti? Nel peggiore dei casi, la tua crittografia funzionerà contro alcuni semplici attaccanti finché non avrai un grande successo, che è il momento peggiore per loro di attaccarti.

Immaginiamo che il tuo gioco abbia un grande successo - World of Warcraft ha avuto successo. Milioni di clienti da tutto il mondo stanno spendendo centinaia di milioni di dollari per gli acquisti in-game, e tu stai facendo il pieno di soldi come Scrooge McDuck. Si tratta di un sacco di soldi, e più soldi hai, più potenti motivano i ladri a rubarli. Un giorno ti metti al lavoro e scopri che qualcuno ha violato la tua criptografia, rubato ogni artefatto da ogni cliente, capito come emettere 10 miliardi di pezzi d'oro non rintracciabili, rubato numeri di carta di credito e password dai database dei tuoi clienti, e hanno cestinato il tuo in -game economia. La reputazione della tua azienda è in rovina. Un protocollo preparato in casa vale il rischio?

    
risposta data 11.09.2017 - 19:38
fonte

Leggi altre domande sui tag

Come difendersi da un CSRF dallo stesso sito web? utilizzando oAuth2 auth dance vs oAuth1 signing