SE si utilizza un SRP per l'autenticazione dell'applicazione client / server senza TLS. Sarà vulnerabile all'attacco man-in-middle, poiché se si utilizza SRP, le informazioni pubbliche non sono molto utili per calcolare la chiave di sessione.
SE si utilizza un SRP per l'autenticazione dell'applicazione client / server senza TLS. Sarà vulnerabile all'attacco man-in-middle, poiché se si utilizza SRP, le informazioni pubbliche non sono molto utili per calcolare la chiave di sessione.
SRP è un protocollo di scambio di chiavi basato su password , che implica l'autenticazione reciproca (il cliente ha la garanzia che ha parlato con il server giusto, il server ha la garanzia che abbia parlato con il cliente giusto). Per definizione, questo esclude qualsiasi uomo nell'attacco centrale . Questo vale per il complete protocollo SRP; se guardi la pagina di progettazione , vedi che client e server scambiano prima un paio di messaggi ( I,A dal client, s,B dal server), quindi eseguire alcuni calcoli che generano la chiave di sessione comune K per entrambi. Ma l'autenticazione non è completa a quel punto; come dice la pagina, il client e il server devono ancora "dimostrarsi reciprocamente che le loro chiavi corrispondono" quindi ci sono un paio di messaggi extra da scambiare.
A quel punto, client e server hanno "autenticazione reciproca" nel senso seguente:
K . K . (I messaggi extra "key match" sono necessari per rendere esplicita l'autenticazione, ma anche per rendere il protocollo robusto - i dettagli crittografici sono intricati.)
Ma questo non è abbastanza . In effetti, quando si desidera autenticazione , non si desidera solo una conoscenza in abstracto che il peer previsto esista e non sia ancora morto; vuoi autenticare una sessione , cioè scambiare dati successivamente. Un utente malintenzionato in grado di eseguire un attacco MitM può semplicemente lasciare passare i messaggi, quindi dirottare il mezzo di trasporto e iniettare i propri pacchetti di dati. Per autenticare la sessione , la chiave condivisa K deve quindi essere utilizzata per calcolare un Codice di autenticazione dei messaggi sui blocchi di dati che il client e il server quindi si scambiano l'un l'altro. In molti casi, sarà necessaria anche la crittografia . È noto che applicare un MAC e possibilmente la crittografia ai dati in streaming, in modo sicuro, è un compito difficile; ci sono dettagli .
Se si implementa SRP e quindi si aggiunge un livello di trasporto per i dati che calcolano il MAC e la crittografia e si fa tutto ciò che è necessario per rendere la sessione sicura (inclusa la diversificazione chiave per impedire a un utente malintenzionato di far parlare il server con se stesso; per impedire il riordino dei blocchi di dati, la terminazione verificata, per impedire il troncamento e così via ...), si finisce con qualcosa che è, in pratica, TLS. TLS con SRP riguarda il protocollo minimo che utilizza SRP per autenticare una sessione. Occorrerebbe una situazione molto speciale per giustificare l'idea di inventare il tuo protocollo (un'attività estremamente rischiosa) invece di usare solo TLS.
Leggi altre domande sui tag authentication passwords tls