View Full Version : [Web Application] No SSL no party?
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.
Ciao!
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...
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.
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...
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.
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...
Sono andato a guardare un po' di "DNS spoofing" e sono caduto da cavallo.
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
26-02-2012, 11:51
ma non puoi usare un certificato non necessariamente verificato da verisign & co?
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
26-02-2012, 14:47
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
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... :D :D
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
26-02-2012, 17:07
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
26-02-2012, 17:18
oppure con javascript potresti inviare direttamente degli hash md5 di user e pass dal client. il punto è capire poi cosa succede con js disabilitato
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
26-02-2012, 18:19
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
26-02-2012, 18:23
quando avrai finito potresti postare il link.. che vorrei divertirmi? :D
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
26-02-2012, 20:59
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)
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.
Se vuoi andare sul sicuro devi fargli arrivare la tua CA tramite un canale alternativo fidato. Potrebbe essere "a mano" (chiavetta usb) oppure se possiede gia' una tua chiave pubblica, tranquillamente via mail (opportunamente segnata).
Dipende ovviamente dal contesto... se e' un sito "pubblico" non ha senso, analogamenet se hai un sacco di clienti ti costa meno acquistare un certificato che non il lavoro di distribuire la tua CA. Non occorre per forza andare con le autorithy piu' diffuse, ce ne sono altre che costano relativametne poco.
Il funzionamento in principio è lo stesso di un public key dove la parte pubblica è il nome utente e la parte privata è la chiave di cifratura simmetrica.
Il client comunica al server il nome utente in chiaro e il messaggio cifrato.
Il server riceve il nome utente, recupera la password dal suo database interno decodifica il messaggio cifrato.
L'identità del client è confermata dalla presenza del suo nome utente nel database e dalla corrispondenza tra il messaggio decifrato e una richiesta di login. Ovvero il server rifiuta di rispondere se
1. il nome utente non è nel database
2. il messaggio non è decifrabile con la password associata a quell'utente
Chi sniffa la connessione vede il nome utente in chiaro e un messaggio cifrato. Può mandare tutte le richieste che vuole con quel nome utente ma non può cifrarle in modo che decifrate abbiano un senso per il server.
Il replay è un problema relativo perchè posso indicizzare i messaggio, aggiungergli un timestamp o generare password a tempo... quello è proprio il meno del meno. Il problema è il physing e chiaramente non ho la soluzione: altrimenti non avrei chiesto (e certamente lo saprebbero tutti).
Che bolle, dovrò prendere un certificato. Come dal notaio: lei è lei, fanno mille euro. Azz... che bel lavorino che si è trovato.
E se il certificato SSL fosse gratuito?
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.
In altre parole basta un attacco MITM o MITB per leggere la password dal codice js e replicare tutta la sessione di login
Il man in the browser sì, ma il man in the middle come legge il valore del campo password?
Se vuoi andare sul sicuro devi fargli arrivare la tua CA tramite un canale alternativo fidato. Potrebbe essere "a mano" (chiavetta usb) oppure se possiede gia' una tua chiave pubblica, tranquillamente via mail (opportunamente segnata).
Sì, questa era la seconda opzione. Anzichè dargli la password io gli do la chiavetta cifrata con dentro un'applicazione portable. Anche qui tutto dipende da dove va a infilarla ma non è in principio più rischioso dell'https.
Il man in the browser sì, ma il man in the middle come legge il valore del campo password?
Dove passa questa connessione? Sei sicuro dell'integrità del cavo dove passa la connessione? Sei sicuro che nessuno possa effettuare ARP poisoning ad esempio all'interno della rete? Sei sicuro che il PC stia utilizzando una connessione WiFi protetta e non aperta?
Serve anche a questo il protocollo SSL/TLS: a rendere la connessione punto-punto, in modo che chi sta in mezzo non può (o almeno tecnicamente non potrebbe) intercettare il traffico che è criptato punto-punto
La domanda non era quella.
Se c'è qualcuno attaccato al filo che va dal client al server che legge tutto quel che passa, riesce a leggere il valore del campo password?
Io direi di no perchè quel campo sta nella memoria del client però non sono un espertissimo di javascript, magari scopro che... be', qualcosa che francamente non immagino.
Dopodichè se mi chiedi quant'è sicuro l'ambiente in cui girerà il server ti dico subito che per me ci passano cani e porci ma non è un mio problema.
So cosa fa SSL (più che altro so quello che snauzer dice che fa), è il fatto che non sia ci modo di farlo senza SSL che mi perplime.
La domanda non era quella.
Se c'è qualcuno attaccato al filo che va dal client al server che legge tutto quel che passa, riesce a leggere il valore del campo password?
Io direi di no perchè quel campo sta nella memoria del client però non sono un espertissimo di javascript, magari scopro che... be', qualcosa che francamente non immagino.
Dopodichè se mi chiedi quant'è sicuro l'ambiente in cui girerà il server ti dico subito che per me ci passano cani e porci ma non è un mio problema.
So cosa fa SSL (più che altro so quello che snauzer dice che fa), è il fatto che non sia ci modo di farlo senza SSL che mi perplime.
E per stare nella memoria del client, come ci arriva?
Ce la scrive l'utente con le sue manine?
Ce la scrive l'utente con le sue manine?
Scusa, non mi è chiaro il processo che vuoi fare tu allora. Dal codice che hai fatto vedere prima in HTML/JavaScript la password è inclusa nel codice. Quel codice, che viene visualizzato nel client, come ci arriva nel client?
Lo scrive a mano l'utente?
Ahhh. No, nel codice ho messo anche la simulazione di quello che farebbe il server una volta ricevuto il messaggio ma quella parte lì starebbe sul server.
Il client finisce qui:
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;
...spara messageSentToServer al server con XMLHttpRequest
}
La password è nella mente dell'utente (cioè è su un post-it attaccato al monitor del suo portatile).
Ahhh. No, nel codice ho messo anche la simulazione di quello che farebbe il server una volta ricevuto il messaggio ma quella parte lì starebbe sul server.
Il client finisce qui:
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;
...spara messageSentToServer al server con XMLHttpRequest
}
La password è nella mente dell'utente (cioè è su un post-it attaccato al monitor del suo portatile).
Ok, ora ho capito meglio :)
La domanda allora diventa un'altra: si, non si vedrebbe la password. Ma si vedrebbe comunque lo stream criptato generato. Stream che rimane sempre lo stesso se la password è la stessa (vedo che la sjcl utilizza AES).
Basterebbe inviare lo stream crittografato e il nome utente, il server sarebbe comunque in grado di decodificare lo stream e farti loggare. O sbaglio?
La conversazione è sempre cifrata, anche dopo il login. A me il primo messaggio cifrato con la password X serve per farsi riconoscere, dopodichè il server risponderebbe con un secondo messaggio, sempre cifrato con X, contenente la password Y che server e client userebbero nel resto della comunicazione.
Questo solo per evitare che X sia usata troppo. Ma posso anche dare all'utente 10 password one-time e dirgli "toh, usane una diversa per ogni richiesta, quando le hai finite ripassa" e saltare il login a piè pari.
Se mi arriva una replica di un vecchio login, anche senza timestamping e cose così, la risposta è sempre un messaggio cifrato che dice "sì ti ho riconosciuto parliamoci".
Le repliche le eviterei o con le password a tempo o con i messaggi temporizzati, a quello ci penserei dopo. Non so neanche quanto sia necessario evitarle perchè il servizio è di sola lettura, non ci sarebbero comandi in grado di alterare lo stato del server: per quelli si deve usare il terminale intranet. Tra l'altro c'è una questione di tempi, nel senso che non so per quanto tempo i messaggi cifrati devano "resistere": sono contratti, bilanci, visure cerved, il genere di cose che potrebbero anche essere pubbliche ma è meglio se il pubblico le piglia da qualche altra parte e non dal mio programma.
In ogni caso il problema è nel modo in cui l'interfaccia di login arriva all'utente: essendo una pagina web l'utente la piglia dalla rete, in mezzo al cavo c'è pippo quindi pippo può passargli il contenuto che vuole quindi gli darà una pagina con uno script che scrive la password da qualche parte. Senza SSL. Con SSL il browser dovrebbe dirgli "occhio: questa pagina non proviene da chi pensi".
In altre parole stai replicando in-house il protocollo SSL/TLS. Utilizzando l'AES come scambio di dati in maniera simmetrica, saltando la prima parte del protocollo (lo scambio della chiave simmetrica per l'AES) perché la sanno a priori il server e il client.
Non conviene usare direttamente l'SSL che almeno ti garantisce anche altre cose ed è un protocollo ben progettato e ormai testato? :D
Giusto per aggiornare la situazione, fossi in te opterei per una soluzione simile:
1) Certificato SSL free (StartSSL (http://www.startssl.com/)class-1 verification) per garantire la connessione crittografata punto-punto. Il certificato utilizza chiavi RSA 2048 bit e crittografia simmetrica AES 256 bit
2) Implementazione lato server di un'autenticazione a due fattori gratuita (vedi mOTP (http://motp.sourceforge.net/)) e installi sullo smartphone il client che genera one-time password ogni 10 secondi. Un eventuale sito di phishing non avrebbe comunque accesso ai dati necessari per la generazione sincrona delle one-time password
Entrambe sono soluzioni free
A me 'sta cosa dei free e low cost puzza così tanto che non ti dico. Non per loro ma per la loro infrastruttura. Del genere "Era così free che tenevano la private key in uno sgabuzzino".
Se alla fine prendo un certificato lo prendo da verisign e morta lì.
Stavo invece pensando a generare il mio certificato e poi dare agli utenti una chiavetta con un browser embedded preconfigurato, però avrei il problema dell'aggiornamento del browser embedded (oggi è sicurissimo domani ti dicono che se non installi la patch sei in mutande di tela sdrucita). Al limite posso invalidare l'utente finchè non ho aggiornato io il browser sulla sua chiavetta.
Il piano C è usare il certificato in un'applicazione embedded che scriverei. Che mi costa in ore lavoro il triplo del certificato di verisign.
Che bolle...
Altra alternativa alla CA, te la lascio qui... http://convergence.io/
A me 'sta cosa dei free e low cost puzza così tanto che non ti dico. Non per loro ma per la loro infrastruttura. Del genere "Era così free che tenevano la private key in uno sgabuzzino".
Se alla fine prendo un certificato lo prendo da verisign e morta lì.
Stavo invece pensando a generare il mio certificato e poi dare agli utenti una chiavetta con un browser embedded preconfigurato, però avrei il problema dell'aggiornamento del browser embedded (oggi è sicurissimo domani ti dicono che se non installi la patch sei in mutande di tela sdrucita). Al limite posso invalidare l'utente finchè non ho aggiornato io il browser sulla sua chiavetta.
Il piano C è usare il certificato in un'applicazione embedded che scriverei. Che mi costa in ore lavoro il triplo del certificato di verisign.
Che bolle...
Ti assicuro che Startcom è una CA valida, riconosciuta a livello mondiale e aggiunta tra le poche CA che possono rilasciare anche certificati per code signing di kernel mode driver per Windows x64.
Inoltre ho esperienza personale a riguardo
Ah, aggiungo che negli attacchi alle CA degli ultimi mesi, StartCom è stata l'unica che hanno tentato di penetrare senza successo
The hackers behind the attack on StartCom failed to obtain any certificates that would allow them to spoof websites in a similar fashion, and they were also unsuccessful in generating an intermediate certificate that would allow them to act as their own certificate authority, Nigg said in an email. The private encryption key at the heart of the company's operations isn't stored on a computer that's attached to the internet, so they didn't get their hands on that sensitive document, either, he said.
GlobalSign è stato effettivamente attaccato, i certificati falsi sono stati messi online. Diginotar ugualmente. StartCom è l'unica che i cracker hanno detto di aver penetrato, ma nessun falso certificato digitale è stato mai rilasciato da lì. Stando ai pirati informatici, la motivazione è nel fatto che StartCom verifica a mano ogni singolo certificato rilasciato, quindi un'eventuale anomalia sarebbe venuta fuori
Faccio una prova col browser portabile su chiavetta. Faccio il mio certificato, lo schiaffo nel browser su chiavetta e via. Così se poi passo ad un certificato "vero" devo solo reimpostare il server.
Appena ho finito di fare altre settanta milioni di cose che tra un po' mi portan via con l'ambulanza...
Appena ho finito di fare altre settanta milioni di cose che tra un po' mi portan via con l'ambulanza...
Mi sa che sei in buona compagnia :D
Paracetamolo38
26-04-2012, 16:37
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...
Esatto, ho letto la stessa cosa anche io su un blog (http://sicurezzadigitale.wordpress.com/2012/04/23/certificati-ssl-attenzione-alle-autorita-emittenti/). Alla fine il problema di sti certificati SSL non è tanto nella società che li emette o li vende, quanto più nell'autorità che si prende la briga di darne valore, quindi in pratica l'autorità di certificazione. C'è un fornitore di certificati, credo anglofono (britannico o americano), che si chiama qualcosa come "VaiPapino" :D che ha prezzi molto bassi, più convenienti della concorrenza, poi quando vai a controllare l'autorità di certificazione ti si tatua un punto interrogativo in fronte :eek:
ergo, occhio alle autorità di certificazione emittenti! Quelli di verisign costano decisamente di più ma un motivo c'è!
Revan1988
20-01-2014, 00:58
Ciao! Provo a porre un interrogativo.
Per un esame devo mettere a confronto il protocollo openssl con il citato SJCL ..
Potete darmi qualche dritta?
Devo creare una pagina web che mi permetta di testare entrambi.. Ed effettuare bench sui browser piú diffusi.
tomminno
21-01-2014, 14:33
Ciao! Provo a porre un interrogativo.
Per un esame devo mettere a confronto il protocollo openssl con il citato SJCL ..
Potete darmi qualche dritta?
Devo creare una pagina web che mi permetta di testare entrambi.. Ed effettuare bench sui browser piú diffusi.
Necroposting a parte, direi che è meglio aprire un nuovo thread.
Ma sjcl non è una libreria per la cifratura in javascript?
Così come openssl è una libreria non un protocollo.
Se sjcl è testabile con un browser (ma non come alternativa al protocollo ssl), openssl non vedo come sia possibile testarla in un browser se non forse usando NaCl di Chrome.
Daniels118
21-01-2014, 15:29
C'è un modo molto semplice per evitare le fake login.
Al momento della registrazione l'utente inserisce il proprio numero di cellulare.
Quando l'utente vuole effettuare il login si collega al server ed inserisce il solo nome utente; alla ricezione del nome utente il server mostra una schermata per l'inserimento di un codice monouso che verrà inviato all'utente dal server tramite sms; l'utente inserisce il codice e il server verifica che corrisponda a quello generato.
In questo modo l'utente non ha nessuna password da sniffare o - peggio - spifferare, e l'autenticazione è garantita attraverso un canale abbastanza sicuro. Ovviamente non esiste la sicurezza al 100%, anche gli sms possono essere sniffati, ma l'attrezzatura è veramente costosa e non la trovi su ebay.
Inoltre inviare sms da internet costa molto meno di un certificato da 2000$ che va comunque rinnovato periodicamente.
Inoltre inviare sms da internet costa molto meno di un certificato da 2000$ che va comunque rinnovato periodicamente.
1) StartSSL, certificato SSL gratuito
2) Google Authenticator, two factor authentication gratuito previa installazione dell'app su uno smartphone.
Prima di pagare per gli sms valuterei queste due alternative gratuite e decisamente affidabili
C'è un modo molto semplice per evitare le fake login.
Al momento della registrazione l'utente inserisce il proprio numero di cellulare.
Quando l'utente vuole effettuare il login si collega al server ed inserisce il solo nome utente; alla ricezione del nome utente il server mostra una schermata per l'inserimento di un codice monouso che verrà inviato all'utente dal server tramite sms; l'utente inserisce il codice e il server verifica che corrisponda a quello generato.
In questo modo l'utente non ha nessuna password da sniffare o - peggio - spifferare, e l'autenticazione è garantita attraverso un canale abbastanza sicuro. Ovviamente non esiste la sicurezza al 100%, anche gli sms possono essere sniffati, ma l'attrezzatura è veramente costosa e non la trovi su ebay.
Inoltre inviare sms da internet costa molto meno di un certificato da 2000$ che va comunque rinnovato periodicamente.
Quello che dici tu viene fatto per autenticare il client... tra l'altro l'autenticazione con l'SMS è quasi sempre (se non sempre) affiancata da almeno un altro metodo di autenticazione, solitamente basato su password.
Comunque nel thread si parlava soprattutto di autenticazione del SERVER e si diceva che senza certificato non è banale ottenere le stesse proprietà di sicurezza che si hanno con la PKI classica (autenticazione, integrità dei dati e cifratura), il chè era vero allora e rimane vero anche oggi (sebbene vari attacchi hanno messo in luce che, a volte, non ci si può fidare nemmeno delle CA stesse).
Daniels118
21-01-2014, 16:11
1) StartSSL, certificato SSL gratuito
2) Google Authenticator, two factor authentication gratuito previa installazione dell'app su uno smartphone.
Prima di pagare per gli sms valuterei queste due alternative gratuite e decisamente affidabili
Sono sicuramente delle ottime soluzioni, ma non impediscono all'utente di inserire le proprie credenziali sul sito sbagliato.
Quello che dici tu viene fatto per autenticare il client... tra l'altro l'autenticazione con l'SMS è quasi sempre (se non sempre) affiancata da almeno un altro metodo di autenticazione, solitamente basato su password.
Comunque nel thread si parlava soprattutto di autenticazione del SERVER e si diceva che senza certificato non è banale ottenere le stesse proprietà di sicurezza che si hanno con la PKI classica (autenticazione, integrità dei dati e cifratura), il chè era vero allora e rimane vero anche oggi (sebbene vari attacchi hanno messo in luce che, a volte, non ci si può fidare nemmeno delle CA stesse).
E' vero, ma credo che la necessità di autenticare il server serva più per assicurarsi che non si tratti di una pagina di login fasulla che per altro. Eventualmente il server potrebbe inserire nell'sms anche una parola d'ordine nota solo all'utente, che non andrebbe assolutamente inserita per il login.
Sono sicuramente delle ottime soluzioni, ma non impediscono all'utente di inserire le proprie credenziali sul sito sbagliato.
Considerando almeno 5 utenti che si connettono due volte al giorno, indicativamente ti servirebbero 3650 sms in un anno. Indicativamente il prezzo si aggira intorno ai 300€ di sms.
Un certificato EV-SSL ti viene 215€ all'anno e ti garantisce l'identità grazie alla green bar che dà subito all'occhio, contrariamente ai certificati SSL domain-validated.
Con 215€/anno hai un canale crittografato, autenticato e la spesa è fissa, non variabile come l'utilizzo del provider SMS.
Dipende tutto da cosa si ha bisogno in verità
Considerando almeno 5 utenti che si connettono due volte al giorno, indicativamente ti servirebbero 3650 sms in un anno. Indicativamente il prezzo si aggira intorno ai 300€ di sms.
Un certificato EV-SSL ti viene 215€ all'anno e ti garantisce l'identità grazie alla green bar che dà subito all'occhio, contrariamente ai certificati SSL domain-validated.
Con 215€/anno hai un canale crittografato, autenticato e la spesa è fissa, non variabile come l'utilizzo del provider SMS.
Dipende tutto da cosa si ha bisogno in verità
Quoto tutto in pieno!! Se il business non giustifica nemmeno la spesa per un certificato del genere allora significa che magari va bene anche la password in chiaro su http standard :sofico:
Negli altri casi, mi sembra un investimento ragionevole, che risolve il problema e, in ultimo ma non per importanza, è allineato allo standard, a quello che fanno tutti... si sa che gli utenti, anche i non addetti ai lavori, sono abituati alla sigla HTTPS colorata in verde a segnalare che "è tutto apposto".
Daniels118
21-01-2014, 16:50
Su questo sono d'accordo, dipende sempre dalle necessità e dal contesto.
Personalmente mi sento abbastanza tranquillo da non dover installare nessun antivirus sul mio pc, di tanto in tanto ne installo uno e facendo una scansione non esce fuori nulla e di roba ne scarico da internet.
C'è gente poi che con i migliori antivirus a pagamento riesce comunque a farsi fregare centinaia di euro, non c'è da meravigliarsi se qualcuno non si affida al lucchetto verde. :cool:
tomminno
21-01-2014, 17:28
Anche se il business non permette di spendere 200 Euro per un certificato annuale, c'è sempre GoDaddy che ti vende certificati per 50 Euro/anno.
Non saranno certificati EV, ma sono pur sempre usabili per l'SSL!
Anche se il business non permette di spendere 200 Euro per un certificato annuale, c'è sempre GoDaddy che ti vende certificati per 50 Euro/anno.
Non saranno certificati EV, ma sono pur sempre usabili per l'SSL!
Beh, se non sei alla ricerca dell'EV-SSL, c'è StartSSL che te lo dà gratuitamente :D
Il problema qui è che all'utente interessa anche un modo per garantire l'identità del server in maniera semplice e rapida
Daniels118
21-01-2014, 18:34
Beh, veramente l'utente son 2 anni che non risponde, penso che abbia risolto diversamente, era giusto per proporre un'alternativa valida casomai servisse a qualcun altro :)
Beh, veramente l'utente son 2 anni che non risponde, penso che abbia risolto diversamente, era giusto per proporre un'alternativa valida casomai servisse a qualcun altro :)
:D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.