Aggiornamento delle applicazioni relative alla privacy / sicurezza [chiuso]

Question

Aggiornamento delle applicazioni relative alla privacy / sicurezza [chiuso]

#1 da (1 voti)

2

Diciamo che abbiamo un client di chat p2p open source decentralizzato per comunicazioni sicure. Il vettore di attacco principale sembra essere il meccanismo di aggiornamento (centralizzato). Quali metodi e / o tecniche possono essere utilizzati per minimizzare gli attacchi durante il processo di aggiornamento. Alla fine uno sviluppatore malintenzionato può sempre introdurre codice dannoso, quindi il meglio che possiamo fare è minimizzare quelle possibilità.

Alcuni problemi a cui stavo pensando solo per far girare la palla (ma non sentirti obbligato a rispondere a quelli o limitarti a quelli):

Dovrebbero essere usati gli aggiornamenti automatici? E dovrebbero essere applicati istantaneamente o vale la pena aspettare un periodo di tempo fisso per poterlo ritirare nel caso di un hack (a costo di bug di sicurezza che si trovano all'aperto per x giorni)?
È sufficiente una semplice connessione https (con certificato in sospeso?) per impedire attacchi MITM sul file di download o si dovrebbero verificare elementi aggiuntivi come un checksum scaricato da un altro server?
Si possono prendere provvedimenti contro il governo (l'unica parte che può farlo legalmente) a prendere il server e caricare una nuova versione? (Stavo pensando sulla falsariga di una sorta di sistema in cui il file deve essere ospitato in diverse giurisdizioni o qualcosa del genere)
Ci sono forse modi per richiedere almeno n di m parti (sviluppatori) per firmare la nuova versione?

network updates

posta David Mulder 16.04.2015 - 19:47

fonte

1 risposta

Leggi altre domande sui tag network updates

Per il rilevamento delle intrusioni, tripwire, utilizzando il controllo dell'integrità dell'hash crittografico: cosa ci si può aspettare? Un utente malintenzionato sta esaminando la partizione non avviata crittografata in grado di stabilire se si tratta di VeraCrypt, TrueCrypt o DiskCryptor?

score 1 · Answer 1

Qualunque sia la tua strategia, penso che il primo passo sia firmare le tue patch. Non importa quanti MITM ci sono, se gli utenti possono controllare la tua firma in un modo che si fida che fornirà già una quantità enorme di certezza.

HTTPS è buono, ma in realtà non fa tanto quanto la firma sulla tua patch, HTTPS renderà il MITM più difficile, ma non impossibile.

Se apri gli aggiornamenti automatici (configurabili, ovviamente), significa che apri anche un vettore di attacco. A seconda della tua filosofia, puoi scegliere di minimizzare i vettori di attacco per aumentare la certezza, o potresti ritenere che ottenere gli aggiornamenti di sicurezza nelle patch in modo ampio e rapido giustifichino l'aumento di complessità.

Puoi anche esaminare i modi per fornire checksum fuori banda, ad es. su domini esterni o su SMS. È molto più difficile per MITM il tuo dominio e il tuo numero di modem che per MITM solo il tuo dominio. Gli utenti che vogliono la certezza potrebbero usare questi checksum per vedere se il programma che stanno eseguendo è quello giusto o se la patch che stanno accettando è valida. Se qualcuno dei checksum non è d'accordo con un altro, questo è un segnale che sta succedendo qualcosa di strano.

Per quanto riguarda la protezione delle patch all'interno del tuo server, presa abbastanza lontano stai in realtà cercando di proteggere da intrusioni "autorizzate" e vuoi che questa protezione sia verificabile dai tuoi utenti. Questa è una cosa abbastanza complicata da fare.

Se il tuo progetto è open-source, potresti esaminare le build deterministiche, che Tor cerca di fare. In questo modo un utente può ispezionare il codice (ma nessuno lo fa) e confrontare la sua build con la tua. Potrebbe essere molto lavoro e / o incompatibile con la tua attuale piattaforma.

Se continui a utilizzare più portachiavi o server potresti finire sottoterra in Tolleranza agli errori bizantini , che tu e i tuoi utenti potrebbero trovare uno sforzo piacevole, o potresti trovarlo difficile e noioso con cui lavorare.

Qualunque cosa tu scelga di fare qui, cerca semplicemente di mantenerla semplice. In base alla legge di AviD:

Security at the expense of usability comes at the expense of security.