SSL / TLS è inutile per IRC?

Question

SSL / TLS è inutile per IRC?

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Supponendo una rete che non ha assolutamente alcun supporto per SSL / TLS, come razionalizzato da questo post del blog , è possibile garantire la sicurezza delle connessioni degli operatori privilegiati?

~~Esistono già dei meccanismi che ci permettono di operare usando gli hash delle password salate, che non dovrebbero essere attaccabili.~~ ¹ Come ho capito, il traffico viene instradato tra i dispositivi su cui non ho alcun controllo, e quei dispositivi potrebbero in modo triviale dirottare una connessione già stabilita. Dovrei essere preoccupato che qualsiasi router tra il mio client IRC a casa e il mio server ospitato in un altro paese potrebbe rubare la mia connessione autenticata, ma non sicura, e usarla per provocare il caos?

Inoltre, sono consapevole che gli indirizzi IP sono spesso assegnati dinamicamente alle connessioni Internet di casa come la mia, e quindi il mio indirizzo IP potrebbe cambiare in occasioni. Quando si verifica un tale evento di rinnovo DHCP, è possibile che qualche altro utente del mio ISP sia in grado di rubare una connessione autenticata, ma in chiaro (non sicura)?

^{Nota: ho scelto di lasciarlo lì per mantenere pertinenti le risposte precedenti, ma ho capito che non vale la pena menzionarlo. Se si desidera includere attacchi contro l'autenticazione salted oper, questa sarebbe probabilmente una discussione valida, ma in caso contrario qualsiasi cosa apparentemente rilevante per gli attuali IRC che non supportano SSL / TLS (come ircu) dovrebbe andare bene.}

tcp irc tls dhcp

posta autistic 02.02.2018 - 03:45

fonte

3 risposte

Leggi altre domande sui tag tcp irc tls dhcp

Ottimo modo per proteggere molte chiavi private Chiarimento su come funzionano gli attacchi di fissazione della sessione

score 3 · Answer 1

No, non è inutile. L'esempio più semplice: vuoi che nessuno sappia qual'è il tuo nickname, in quale canale sei e cosa stai scrivendo nelle query (messaggi privati).

Per rispondere alla domanda concreta

Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

In teoria dovresti essere preoccupato, come ogni router può farlo. In pratica dipende da chi potrebbe voler farlo e cosa può fare. Penserei che le persone che entrambi potrebbero volerlo e possano farlo sono all'interno della tua LAN.

Il tuo amministratore di rete potrebbe prendere il controllo della tua connessione e questo non sarà troppo complicato. Non è necessario pensare a fare confusione con i pacchetti TCP del tuo stream. Potrebbe semplicemente avere un proxy TCP in esecuzione, che può essere semplice come due istanze di netcat e una regola del firewall.

score 1 · Answer 2

La risposta breve è NO, non è inutile. Dovresti usare TLS.

Cosa impedirebbe a una persona cattiva di vedere il tuo hash salato passare e riutilizzarlo? O semplicemente riutilizzando o come attacco MitM.

'Meccanismi per operare usando hash delle password salate', solo grida come 'roll your own crypto'. (Potrei sbagliarmi ma,) Ricorda che la prima regola di Crypto è: Stai sbagliando.

La protezione dagli attacchi replay o MitM, senza l'utilizzo di meccanismi di canale sicuri standard è più che probabile:

Estremamente complesso
sfoglia
Insicuro

<Sarcasm>

Maybe you could do it with some public-private crypto (or shared secret (which you shared over a secure channel right?!?...)), signing each message, oh and don't forget to add a non repeating nonce.

</Sarcasm>

Oh, ma sarebbe 1. Molto complesso 2. Sfarfallio e ancora 3. Insicuro!

TLS è standard, ben compreso, testato in battaglia e facile da implementare. Questo è praticamente l'unico modo per proteggere in modo affidabile da replay e / o attacchi MitM qui.

Ora forse non ti fidi delle CA TLS (perché attori di stato), beh, la mia risposta è questa: Non usare IRC per le cose, che infastidiranno gli attori di stato, oltre il testo in chiaro !!!

Modifica: per indirizzare i commenti:

Se l'installazione è corretta (certificati firmati da una CA attendibile), TLS dovrebbe funzionare correttamente. Solo perché alcuni utenti non la useranno correttamente non significa che dovresti renderlo insicuro per tutti gli utenti, specialmente quelli privilegiati. (Il post del blog sembra descrivere un sistema configurato in modo errato, quindi il suo punto è moot)
Lì sono attacchi fattibili a password (correttamente) salate * utilizzate in questo modo (Replay e MitM). Quindi qualsiasi router (o qualcuno che ascolta mentre usi una connessione wifi aperta) lungo il percorso potrebbe pasticciare.
Le modifiche agli indirizzi IP (o agli indirizzi IP nativi) avranno effetto solo se il server sta utilizzando un elenco di indirizzi IP bianchi. Che è insufficiente proteggerti nello scenario che hai descritto.

Quindi in conclusione: usa TLS configurato correttamente per proteggere tutte le tue comunicazioni, incluse le informazioni di autenticazione. Altrimenti potresti essere bruciato da una persona cattiva. Inoltre, istruisci i tuoi utenti a non solo cliccare ciecamente su OK in ogni momento.

Guarda letsencrypt.org come modo per ottenere certificati certificati CA certificati gratuitamente. (nota che dovrai configurare un meccanismo di rinnovo in quanto devono essere aggiornati ogni 90 giorni)

* (La salatura ti protegge davvero solo quando perdi dati a riposo, non i dati in volo come questo)

score 0 · Answer 3

Utilizzando il protocollo IRC standard, no, non è possibile garantire la sicurezza su un canale in chiaro. Con un comando OPER modificato impostato usando una sorta di comandi firmati, si sarebbe in grado di impedire ad altri di falsificare i comandi.

Come prendere il controllo della connessione a causa di un cambiamento di IP, questo sarebbe incredibilmente improbabile. Il tuo IP dovrebbe essere passato a un utente malintenzionato quasi immediatamente (quindi la connessione non scade). L'utente malintenzionato dovrebbe essere in grado di rispondere al primo pacchetto in ingresso e dovrebbe essere un pacchetto ACK (per ottenere i numeri di sequenza corretti). Qualsiasi altra cosa causerebbe un reset della connessione.