[Web Application] No SSL no party?

[PGI-Bis]

Ho un... coso fatto per girare in locale e sto pensando se portarlo sul web - così che uno possa usare il coso ad esempio da un internet-point.

Le comunicazioni tra server e client sono protette dalla classica password. Il protocollo di comunicazione client-server è classico:

-il client manda il nome utente in chiaro e il messaggio cifrato con una password
-il server piglia dal suo database la password associata al nome utente, decifra il messaggio, crea la risposta, la cifra con la password e la spedisce al client
-il client riceve il messaggio cifrato, lo decifra con la sua password e ottiene la risposta.

Funziona finchè qualcuno non estorce la password all'utente.

Il problema è l'autenticazione: come faccio io pippo a sapere che sto parlando con il coso?

Vale a dire, prima di dare duemila dollari a verisign per un certificato ssl che poi so già che per installarlo sul server dovrò piangere in bustrofedico, non c'è una procedura alternativa?

Detto altrimenti, COSOWEB2000 può evitare che Tony Famoafidasse vada a scrivere la sua password sul front-end di www.physing.com anziche su quello di www.cosoweb2000.com?

Ho un paio di mezze idee che mi circolano in testa. Una è quasi allo stadio di tre quarti di idea:

l'utente invia un messaggio al server, il server risponde con una parola chiave nota solo all'utente e al server, l'utente umano verifica che la parola chiave corrisponda a quella che sa: se sì allora il pannello di login che vedo mi è stato inviato dal server e posso scriverci dentro la mia password, sapendo che non sarà inviata. Altrimenti quel campo password che vedo molto probabilmente invierà la mia password alle seichelles.

Lo chiedo anche perchè a me questa necessità di dipendere da un'autorità terza per determinare l'identità di uno dei due web-dialoganti sembra un controsenso (e chi mi dice che l'autorità terza sia veramente terza?).

Ringrazio in trepidante attesa.

[Mettiu_]

Ciao!

Originariamente inviato da PGI-Bis

Ho un paio di mezze idee che mi circolano in testa. Una è quasi allo stadio di tre quarti di idea:

l'utente invia un messaggio al server, il server risponde con una parola chiave nota solo all'utente e al server, l'utente umano verifica che la parola chiave corrisponda a quella che sa: se sì allora il pannello di login che vedo mi è stato inviato dal server e posso scriverci dentro la mia password, sapendo che non sarà inviata. Altrimenti quel campo password che vedo molto probabilmente invierà la mia password alle seichelles.

Se ho ben capito, hai solo spostato il problema. Se parliamo di sicurezza, un eventuale attaccante potrebbe sniffare questa 'parola d'ordine' e spacciarsi comunque per il server!
Se partiamo dal presupposto che client e server hanno una password condivisa puoi basare l'autenticazione su una sfida simmetrica cioè per esempio:
1) Server manda una sfida al client (un numero random utilizzato SOLO una volta);
2) Il client concatena la sfida ricevuta con la password condivisa e calcola l'hash di tutto. Invia il risultato al server;
3) Il server esegue lo stesso calcolo e lo confronta con quanto ricevuto. Se uguale autentica l'utente altrimenti no;
4) Si ripete la procedura anche per autenticare il server con un'altra sfida simmetrica da parte del client contro il server.
In questo modo la conoscenza della password viene dimostrata indirettamente senza mai trasmetterla in rete quindi le parti si possono fidare. Rimangono due problemi:
- come viene concordata la password comune (se viene mandata in chiaro anche solo la prima volta non abbiamo concluso nulla);
- se male implementato, questo metodo è passibile di attacco man in the middle.
Non so se ho centrato l'argomento...

[PGI-Bis]

Le comunicazioni sono cifrate, il protocollo è lo stesso di un key pair dove il nome utente è la parte pubblica.

Il problema è l'applicazione lato client. L'utente apre la pagina di login ma non è il mio login, è un physing di Sniffone84.

Non può scrivere la sua password in quella pagina perchè come clicca "invia" anzichè usare la password per cifrare la comunicazione Sniffone84 all'invio ci mette un bel "mandamela per e-mail".

SSL garantisce l'autenticità della pagina di login se l'utente va a guardare il certificato (altrimenti può benissimo essere una pagina di Sniffone84 distribuita tramite https, con un certificato validissimo che però non è il mio).

E senza SSL?.

E' vero però che il problema è spostato nel protocollo all'amatriciana perchè quando il server invia la sua password non può farlo in chiaro e se non lo fa in chiaro per decifrarlo l'utente deve mettere la sua password da qualche parte, non ha modo di distinguere la mia pagina da quella di Sniffone e quindi sono fregato.

[Mettiu_]

Originariamente inviato da PGI-Bis

SSL garantisce l'autenticità della pagina di login se l'utente va a guardare il certificato (altrimenti può benissimo essere una pagina di Sniffone84 distribuita tramite https, con un certificato validissimo che però non è il mio).

E senza SSL?.

Bhè però l'attaccante non avrà mai un certificato per il dominio www.cosoweb2000.com (o meglio la chiave privata associata) quindi se gli utenti guardano la URL si rendono conto che è il server sbagliato (sebbene abbia un certificato valido). Qualcuno che ci casca probabilmente ci sarà ma basterebbe guardare la URL...

[PGI-Bis]

Allora sono a cavallo.

Se l'url non può che apparire legittimo - cioè se necessariamente un physer deve usare un url diverso, ancorchè simile - allora l'identità del server è accertabile dall'utente in virtù del suo indirizzo web.

Dunque SSL è superfluo ergo c'è qualcosa che non torna.

[Mettiu_]

Originariamente inviato da PGI-Bis

Dunque SSL è superfluo ergo c'è qualcosa che non torna.

No che non è superfluo... Se un server usa un certificato X.509 su TLS l'identità che è riportata sulla barra degli indirizzi è garantita! Se non usassi TLS con certificati pubblici, chiunque potrebbe avvelenare la cache di un DNS server e farti credere di essere su www.cosoweb200.com (quindi nella barra vedresti l'URL corretto pur essendo sul server dell'attaccante). Con TLS questo non è possibile... Ovviamente se l'utente riceve una mail di fishing e clicca sul link www.tirubolapass.com e mette la pass fine della sicurezza, non penso si possa fare niente...
Spero di non aver detto qualche fesseria...

[PGI-Bis]

Sono andato a guardare un po' di "DNS spoofing" e sono caduto da cavallo.

[PGI-Bis]

Di bene in meglio. Ho appena scoperto che si può far vedere un url e caricare tutt'altro. Poi ho letto di un tipo di man in the middle chiamato "man in the browser" che buonanotte... bella la sicurezza delle web application.

[SerMagnus]

ma non puoi usare un certificato non necessariamente verificato da verisign & co?

[Mettiu_]

Originariamente inviato da SerMagnus

ma non puoi usare un certificato non necessariamente verificato da verisign & co?

No perchè i browser si fidano solo di certificati che fanno parte della catena di certificazione di qualche root CA (tipo Verisign, ecc ecc...) quindi se non hai un certificato rilasciato da loro ti ritrovi il classico errore di certificato scaduto e/o non fidato...

[SerMagnus]

lo so, però dipende anche dal tipo di utilizzo, se è per uso interno puoi installare il certificato a mano sulle macchine e risolvi il problema

[Mettiu_]

Originariamente inviato da PGI-Bis

Ho un... coso fatto per girare in locale e sto pensando se portarlo sul web - così che uno possa usare il coso ad esempio da un internet-point.

Dubito abbia voglia di portarsi appresso il certificato e installarlo su una macchina di un internet-point che magari userà solo 5 minuti...

[PGI-Bis]

Per come l'ho capita io il problema dell'autocertificazione è che la provenienza del certificato non è controllabile dal client - perchè l'identità del terzo confermante non è presente tra le CA installate nel browser. Siccome non c'è può essere chiunque, nel senso che io potrei anche dargli il link per installare il certificato del terzo ma a quel punto il man-in-the-middle darebbe il suo.

Che bolle, dovrò prendere un certificato. Come dal notaio: lei è lei, fanno mille euro. Azz... che bel lavorino che si è trovato.

[Dolcezeus]

Salve... sono completamente daccordo con Mettiu per il phinshing non esistono soluzioni bisogna solo fare training degli utenti.. per quanto riguarda la sicurezza della tua web app l'unica soluzione sicura e versatile è usare TLS e comprarsi un certificato X.509..
lato browser non è possibile cifrare nulla direttamente usando un form comune.. quindi o TLS+certificato o no party

[SerMagnus]

oppure con javascript potresti inviare direttamente degli hash md5 di user e pass dal client. il punto è capire poi cosa succede con js disabilitato

[PGI-Bis]

Ci sono un tot di librerie per la cifratura lato client-browser - quella che uso adesso è sjcl. Il punto non è la cifratura ma l'autenticazione, è quella che mi frega.

L'applicazione sarebbe integralmente javascript: non è previsto che l'utente lo disabiliti.

Autenticazione del server: quella del client non è un problema.

[Dolcezeus]

anche se le info di autenticazione vengono inviate cifrate non sarai mai protetto da:
phishing
sniffing
no-replay
la cosa importante da capire è che quando si parla di sicurezza non bisogna inventarsi nulla.

[Dolcezeus]

quando avrai finito potresti postare il link.. che vorrei divertirmi?

[PGI-Bis]

Uno può sniffare quanto vuole ma di quel che sniffa vede solo il nome utente. Il resto è un pacchetto di dati cifrati: se non azzecca la password può solo rispedire un vecchio messaggio ma sarebbe rifiutato - il protocollo dei messaggi include ovviamente la vecchiaia.

Non c'è bisogno di avere un programma da testare, basta il protocollo. Questa è una simulazione dei passaggi:

<!DOCTYPE html>
<html>
    <head>
        <title></title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <script type="text/javascript" src="sjcl.js"></script>
        <script type="text/javascript">
            function dologin() {
                var username = document.getElementById("username").value
                var userpass = document.getElementById("userpass").value
                var loginMessage = createLoginMessage()
                var cryptedMessage = sjcl.encrypt(userpass, loginMessage)
                var messageSentToServer = username + "," + cryptedMessage;
                serverProcess(messageSentToServer);
            }
            
            function createLoginMessage() {
                return "login request"
            }
            function serverProcess(message) {
                var userName = getUserNameFromClientMessage(message)
                var body = getCryptedBodyFromClientMessage(message)
                var password = readUserPasswordFromDatabase(userName);
                var cleartext = sjcl.decrypt(password, body);
                console.log("Server gets: " + cleartext);
            }
            function getUserNameFromClientMessage(message) {
                var i = message.indexOf(",");
                return message.substring(0, i);
            }
            function getCryptedBodyFromClientMessage(message) {
                var i = message.indexOf(",");
                return message.substring(i + 1, message.length);
            }
            function readUserPasswordFromDatabase(userName) {
                return "pippo"
            }
        </script>
    </head>
    <body>
        <div>
            <table border="0" cellpadding="4">
                <tbody>
                    <tr>
                        <td>Nome utente:</td>
                        <td><input id="username" type="text" size="20"></input></td>
                    </tr>
                    <tr>
                        <td>Password</td>
                        <td><input id="userpass" type="password" size="20"></input></td>
                    </tr>
                    <tr>
                        <td colspan="2">
                            <input type="button" value="Invia" onclick="dologin()"></input>
                        </td>
                    </tr>
                </tbody>
            </table>

        </div>
    </body>
</html>

La libreria sjcl si trova qui:

http://crypto.stanford.edu/sjcl/

L'unico buco che vedo è il programma stesso, cioè la sua autenticità, che ssl risolverebbe.

Perchè se è vero che non bisogna inventarsi nulla (e non è vero), è anche vero che bisogna sapere il motivo per cui si usa quel che è già stato inventato: non è che io mi metta ad usare SSL perchè ciccio45 mi ha detto che è sicuro. Lo uso perchè so che risolve uno specifico problema che la logica mi dice che ho.

[Dolcezeus]

capisco.. e potrei sapere come identifichi i login e ti proteggi da replay?
Cmq se trovi la soluzione al phishing ti consiglio di scrivere un RFP e presentarlo all'IETF (non scherzo.. un italiano che elimina una piaga così grande al giorno d'oggi in rete)