Domanda:
Come sostituire SSL / TLS?
Tloz
2015-12-16 20:28:34 UTC
view on stackexchange narkive permalink

Devo creare un sito web per una ONG (Organizzazione Non Governativa) e loro hanno le opzioni minime dal loro provider, quindi non possono avere SSL / TLS (a malapena solo HTML / PHP / MySQL / JS)

I dati che vanno da e verso il server non sono molto sensibili, ma non voglio che le loro password, nome e indirizzo vengano inviati in modo chiaro sul web.

Ho pensato sulla cifratura dei dati all'interno del JavaScript che chiama le funzioni API con RSA (non sono un esperto, ma questa libreria sembra piuttosto efficiente), ma ho letto un articolo che consiglia vivamente di non utilizzare JavaScript per crypto (sono francese e forse non ho capito tutto bene, ma ho capito il punto principale).

Quindi cosa dovrei usare per cifrare i dati sulla rete? Se JS non è davvero una cattiva idea, cosa posso fare per garantire la massima sicurezza con la tecnologia che posso usare su questo server (ancora una volta, no HTTPS, purtroppo), a parte importare la lib sul mio server e non fare affidamento durante l'importazione da un server diverso?

L'articolo è corretto; semplicemente non esiste un buon modo per implementare la crittografia tra un server Web e un client senza utilizzare SSL / TLS. Senza un'infrastruttura a chiave pubblica per verificare l'identità del server, gli attacchi [MITM] (https://en.wikipedia.org/wiki/Man-in-the-middle_attack) sarebbero banalmente facili. Inoltre, chiunque può semplicemente rimuovere / modificare il javascript in transito.
Potresti essere interessato al programma Let'sEncrypt: https://letsencrypt.org/. Potrebbe non essere l'opzione migliore, ma è meglio di niente.
Sembra che abbiano bisogno di un nuovo provider ...
Che senso ha crittografare i dati quando il codice Javascript che esegue la crittografia viene inviato in modo chiaro e non firmato? Gli hacker configureranno un server falso che avrà la tua interfaccia, ma nessuno del tuo codice Javascript protettivo, e semplicemente registrerà le password.
Fornire un client grasso FIRMATO per compenetrarsi con il servizio. Il servizio non è raggiungibile tramite browser web.
@Ohnana, No, Let's Encrypt è semplicemente un fornitore di certificati SSL / TLS gratuiti. Ciò non aiuta se il provider utilizzato non consente SSL / TLS.
@MartijnHeemels ci ho pensato, ma ho anche considerato che il costo può essere un fattore ("opzioni minime dal fornitore"), visto che le ONG non sono famose per grandi somme di denaro.
@Ohnana Ah, capisco. Come un modo per aiutarlo a creare un business case per un aggiornamento del piano di hosting. Anche se questo può aiutare, i certificati gratuiti esistevano prima di Let's Encrypt, ad es. da StartSSL.com e i certificati a pagamento partono da pochi $ / anno. Meno anche di un mese di hosting economico.
Passaggio 1: conferma che il provider * davvero * non consente alcun TLS / SSL nel piano "di base". Sarebbe spaventoso se non lo permettessero quando ti danno un archivio dati (e anche degno di vergogna pubblica). Probabilmente dovrai acquistare un certificato, ma negare la possibilità di ottenerlo è davvero assurdo.
@jpmc26 Se non supportano SNI e se non supportano IPv6, avranno bisogno di un indirizzo IPv4 separato per dominio. Oggigiorno le opzioni di hosting più economiche sono in realtà più economiche del costo del noleggio per un singolo indirizzo IPv4. Quindi, da quella prospettiva, ha senso non supportare la crittografia sul piano più economico. Ovviamente quello che dovrebbero fare è supportare sia SNI che IPv6 in modo che possano fornire TLS senza avere un indirizzo IPv4 per dominio.
@jpmc26 Non vedo nulla di spaventoso sulla disabilitazione delle funzionalità per i piani ** gratuiti **. L'intento della maggior parte dei piani gratuiti è farti appassionare quanto basta per passare a un piano a pagamento. * Non * dovresti aspettarti che il piano gratuito sia sufficiente per qualsiasi hosting serio. Il web hosting economico è nel regno di $ 10 al mese: esattamente quanti soldi ha questa organizzazione?
Molti provider di hosting, anche se non offrono servizi SSL individuali, dispongono di certificati condivisi che possono essere utilizzati da qualsiasi account utente. Quindi invece di https://www.mydomain.com/login.html useresti qualcosa come https://hostingdomain.com/~mydomain/login.html (quegli pseudo link hanno https davanti a loro, semplicemente non " t visualizzare sulla pagina) Non è così semplice come avere un proprio certificato ma offre un'opzione SSL / TLS adeguata senza alcun costo aggiuntivo. Vale la pena controllare se questa opzione è disponibile.
@Mark_1 lo controllerò sicuramente. Penso che propongano "SSL mutualizzato", potrebbe essere un indizio
Stiamo parlando di un server web che servirà le pagine web? O un server per qualcos'altro? (Forse un server Node.js per un gioco desktop)
Vale la pena scoprire se qualcuno donerà l'hosting. Se non gestisci un'attività a scopo di lucro, alcuni fornitori possono essere piuttosto generosi.
Qualche strana idea: considera una situazione in cui PHP gestisce solo i dati e tutto il resto sono file statici. Non è possibile che quei file statici possano essere ospitati in un server statico HTTPS (GitHub Pages + CloudFlare, ad esempio), fornendo l'autenticazione e prevenendo qualsiasi possibilità MITM e la comunicazione con il backend PHP insicuro crittografato con JavaScript? Il blocco "meglio sicuro" da HTTPS a HTTP XHR può essere aggirato con GD e "".
Potresti prendere in considerazione l'utilizzo di Cloudflare, poiché forniscono certificati gratuiti. Ovviamente questo proteggerà solo `client -> CDN` e non` CDN -> il tuo server`, ma dovrebbe essere sufficiente contro la maggior parte delle situazioni MITM.
Se il servizio di hosting dell'operazione fornisce un certificato condiviso, puoi utilizzare Cloudflare (commento @Marcelo's sopra) per terminare la connessione SSL in modo da poter ancora utilizzare il dominio della ONG mantenendo la sicurezza end-to-end. Vedi https://www.cloudflare.com/ssl/
Sebbene il PO non dichiari di risiedere nell'Unione Europea, la loro nazionalità è indicata come francese e se loro o (probabilmente di maggiore rilevanza) l'ONG si trovano all'interno dell'Unione Europea, allora hanno un dovere legale di protezione " qualsiasi informazione relativa a una persona fisica identificata o identificabile "ai sensi della direttiva 95/46 / CE del Parlamento europeo. Nel Regno Unito, ad esempio, ciò è stato approvato dalla legge nazionale attraverso il Data Protection Act 1998 (non sono sicuro della legislazione in Francia). Nome e indirizzo sono certamente informazioni personali e dovrebbero essere protetti.
@Tloz Se le ONG non sono in grado o non vogliono implementare una protezione adeguata come SSL, è necessario richiedere che ottengano un'adeguata consulenza legale, farlo per iscritto e conservarne una copia per i propri archivi.
Sette risposte:
Thomas Pornin
2015-12-16 21:11:05 UTC
view on stackexchange narkive permalink

Niente SSL, niente sicurezza. Le cose nel mondo reale sono raramente semplici, ma qui è il caso. Questo si vede facilmente come segue: qualunque cosa tu faccia in Javascript, sarà fatta in Javascript inviato dal server . Qualsiasi utente malintenzionato che sia in grado di guardare i dati può anche modificarli a piacimento (ad esempio, il modo più semplice per spiare il WiFi è eseguire il tuo falso punto di accesso, e poi naturalmente puoi modificare tutti i dati man mano che vanno e vengono) ; quindi, un tale utente malintenzionato può semplicemente rimuovere o modificare qualsiasi soluzione basata su Javascript che potresti trovare e disattivarla. Oppure aggiungi un hook per anche inviare la password in chiaro come parametro aggiuntivo.

Ora, anche se potresti ottenere "Javascript sicuro" sul browser client, ti imbatteresti in tutti i problemi che comporta la crittografia Javascript e che sono descritti in dettaglio nell'articolo a cui ti colleghi. Ma questa è solo una considerazione secondaria, rispetto al difetto fondamentale spiegato sopra: senza SSL, non puoi assicurarti che ciò che viene eseguito sul browser client sia il tuo codice.

Provando a gestire la password in modo sicuro su un sito Web non SSL è come tentare di eseguire un intervento chirurgico al cervello in sicurezza con solo un cucchiaino da tè e un piede di porco arrugginito. Basta non farlo. Se sono presenti dati sensibili che fluiscono al sito Web (ad esempio nomi e indirizzi), è NECESSARIO applicare meccanismi di protezione ragionevoli. Se i dati non sono sensibili, perché avresti bisogno di password?

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/33179/discussion-on-answer-by-thomas-pornin-how-to-replace-ssl-tls).
symcbean
2015-12-16 21:16:07 UTC
view on stackexchange narkive permalink

IMHO il generatore di numeri casuali è l'ultima delle tue preoccupazioni qui. Poiché il codice per invocare l'enceyption viene inviato in chiaro, è banale per qualcuno MITM l'interazione.

Se il servizio richiede il livello di sicurezza fornito dalla crittografia ed è fornito da un sito web, allora DEVE usare HTTPS (e idealmente tutte le cose di sicurezza associate come secure + httponly cookies e HSTS).

L'unico modo per aggirare questo sarebbe scrivere un'app HTML5 (dove il il codice viene scaricato di rado), ma anche questo ha svantaggi significativi.

Sì, ma un'app HTML5 non sarebbe sicura poiché non ci sarebbe un buon modo per autenticarsi, ovvero scaricare l'app dal server corretto e che non è stata modificata.
Sì, come ho detto, ha degli svantaggi significativi e non è all'altezza di un servizio HTTPS implementato correttamente, ma è leggermente migliore che provare a farlo su HTTP. Esistono modi perfettamente validi per l'autenticazione (ma senza protezione della sessione). Sembra che tu sia a tuo agio con l'autenticazione qui su Stackexchange, Martijn: P
Probabilmente sarebbe possibile ospitare l'app HTML5 altrove (su HTTPS) ed eseguire CORS AJAX crittografato sul sito, ma questo è irto di insidie ​​anche per un esperto. Potresti entrare in orbita se avessi una scala abbastanza grande, ma non è un modo sensato per risolvere il problema.
Bruno
2015-12-17 13:04:29 UTC
view on stackexchange narkive permalink

La soluzione migliore, come è stato affermato, è ottenere un vero e proprio piano di web hosting che consenta https. Non dovrebbe essere troppo costoso, anzi dovrebbe anche essere possibile trovare un provider gratuito per fornirlo.

In caso contrario, qual è il tuo caso d'uso? Sembra che tu abbia in mente un determinato gruppo di utenti per il tuo sito web. Se è così e non offri solo un servizio di notifica degli eventi basato su abbonamento a persone casuali su Internet, valuta la possibilità di fornire le basi per una connessione "sicura" su un canale diverso.

per me che ottenere il codice sulla loro macchina da un'altra fonte affidabile (inviando CD tramite posta ordinaria e informandoli via e-mail, inviando semplicemente il software come allegato a un'e-mail con firma digitale, ecc.) consente di precaricare il software con una chiave pubblica crittografica.

È quindi possibile negoziare una connessione sicura su un metodo di connessione non sicuro (come http) poiché il codice che determina se il server ha decrittografato in modo soddisfacente i dettagli crittografati con la sua chiave pubblica vive il cliente. Il risultato è un flusso di dati di applicazioni http "in chiaro", con la grinza che i dati dell'applicazione stessa siano crittografati.

Si tratta di molti problemi e di un metodo non standard. Si verificano problemi con l'implementazione poiché poche persone lo avranno provato per offrire consigli e con la sicurezza poiché poche persone hanno verificato la sua affidabilità *.

Il canale alternativo stesso potrebbe avere problemi di sicurezza. La posta può essere intercettata? I truffatori potrebbero impersonare la tua organizzazione e inviare la loro versione "sicura" del tuo software? I tuoi utenti sono abbastanza esperti da controllare le firme digitali sulle e-mail che invii? Queste sono tutte preoccupazioni che dovrai considerare e accettare come rischi o tentare di mitigare con nuove soluzioni, poiché hai meno indicazioni non solo su come implementare, ma anche su quali domande devi porre (dovrai chiedere più di questi tre!).

Quando parli con la direzione della ONG, considera di delineare la situazione in questi termini:

  1. Quest'ultimo metodo comporta un rischio significativo e finirà per costare loro più del tuo tempo da implementare rispetto a quanto semplicemente pagare per l'hosting: il programma deve essere aggiornato, soprattutto se il server (o la coppia di chiavi del server) cambia e viene continuamente distribuito a nuovi utenti dopo la distribuzione iniziale.
  2. Non fare nulla e utilizzare una password http con indirizzi e nomi (e potenzialmente indirizzi e-mail) potrebbe essere un disastro delle pubbliche relazioni se qualsiasi informazione trapelasse (e lo sarà), un rischio significativo. Ciò è aggravato dal fatto che le persone riutilizzano le password e la tua cattiva pratica potrebbe essere collegata a violazioni successive.
  3. In quanto tale hai riflettuto in modo significativo sulla situazione e non hai solo intenzione di suggerire la soluzione delineata in passaggio 4 perché "lo fanno tutti" (sebbene, nel caso in cui lo facciano tutti perché è la migliore pratica, non è certo una cosa negativa). Essere in grado di proporre la soluzione alternativa (se contorta ed eccessiva) delineata nei passaggi 1 & 2 è la prova di questa due diligence in corso.
  4. Sulla base di ciò, l'hosting https con un costo continuo basso (o nullo) è sia l'approccio meno costoso CHE meno rischioso.

* Jonathan Gray spiega il perché incontrerai problemi nella codifica di un sistema sicuro nella sua risposta, guarda la sezione che inizia con "TLS è anche un sistema molto più intrinseco"

Se sei al punto in cui stai pensando di affrontare il problema della pre-distribuzione delle chiavi di crittografia, penso che * molto * un'idea migliore rispetto a lanciare la tua crittografia JS sarebbe creare la tua autorità di certificazione SSL ( CA) e distribuire il certificato CA ai client. Allora avrai tutti i vantaggi di un SSL corretto, senza dover pagare un certificato, ma a costo della pre-distribuzione e dell'onere di gestire correttamente la CA.
Buon punto, e supponendo che il motivo per cui si afferma che https non può essere utilizzato sul provider sia solo problemi di provisioning dei certificati, questo sarà molto più semplice. Anche se il provider blocca completamente la porta 443, non c'è motivo per cui https://www.example.com:80 non funzioni (a meno che non stiano effettuando l'ispezione dei pacchetti). Mi chiedo se ci sono siti supportati da una CA di grandi nomi in cui puoi ospitare un certificato radice con alcuni controlli intorno a cui potresti indirizzare i tuoi clienti in modo che possano scaricare la chiave pubblica? Probabilmente no, competerebbe con il loro modello di business di vendita di certificati.
ARau
2015-12-16 21:44:44 UTC
view on stackexchange narkive permalink

Per prima cosa sostituisci il tuo host.

Ottenere i certificati SSL è più facile che mai grazie alle CA gratuite. LetsEncrypt, ad esempio, offre certificati di convalida del dominio SSL / TLS gratuiti in modo automatico a condizione che tu possieda il nome di dominio. C'è più spiegazione nella risposta di StackzOfZtuff sulle sue capacità.

Ci sono istruzioni su come impostarlo sul loro sito della comunità con domande frequenti e un forum di assistenza .

Ciò non risponde alla domanda poiché il suo hoster non fornisce il supporto SSL / TLS. Che il certificato sia gratuito o meno non fa differenza.
Se il suo provider non supporta TLS / SSL ed è per una ONG, come amministratori della sicurezza dobbiamo incoraggiarlo e aiutarlo a trovare un provider di hosting che supporti le migliori pratiche di sicurezza. Non sono l'unico che ha suggerito LetsEncrypt su questo thread. LetsEncrypt è supportato da molte rinomate organizzazioni dedicate alla privacy e alla sicurezza. Dobbiamo rendere gli utenti consapevoli di questo come opzione disponibile per loro.
Contrassegnato per spam, poiché il richiedente non richiede un certificato SSL / TLS e fornisci un sito Web piuttosto losco che fornisce certificati ssl / tsl "gratuiti".
@ardaozkal Anche se sono d'accordo che questa risposta non è particolarmente utile in questo contesto, Let's Encrypt è tutt'altro che "losco". È molto noto nella comunità della sicurezza ed è supportato da Mozilla, Facebook, Cisco e Electronic Frontier Foundation, tra gli altri.
@blownie55 Sono d'accordo su ciò che dovremmo consigliare all'OP per trovare una soluzione migliore, come stanno facendo molti, tuttavia Let's Encrypt non fa nulla per aiutare in tal senso. Qualsiasi certificato SSL economico andrebbe bene, o anche uno gratuito da StartSSL.com. Il fatto che Let's Encrypt sia ora disponibile e gratuito è molto carino, ma alla fine non è il problema qui. Non sei davvero l'unico a suggerirlo. Questo non ti rende giusto, fa anche l'altro sbagliato.
Jonathan Gray
2015-12-16 21:01:29 UTC
view on stackexchange narkive permalink

Il problema con JS è la generazione di numeri casuali (che è vitale per la sicurezza della crittografia moderna). Sono disponibili librerie esistenti che aiutano a risolvere questo problema, ma devi assicurarti che la libreria utilizzi crypto.getRandomValues ​​ e la capacità di ottenere entropia dall'input umano (come l'attività del mouse o della tastiera) . Ciò è particolarmente complicato per i dispositivi mobili, tuttavia, soprattutto se si considera il fatto che l'hardware stesso è meno in grado di generare numeri casuali sicuri.

Vorrei anche aggiungere un ulteriore punto su RSA. È possibile crittografare solo piccole quantità di dati con esso e la quantità di dati è relativa alla lunghezza della chiave utilizzata. Non solo, ma RSA è lento. Se hai bisogno di una discreta quantità di dati o stai effettuando più richieste al server, ti consiglio di crittografare una chiave casuale (CSPRNG) con JS sul lato client utilizzando la chiave pubblica del server e utilizzando quella chiave per la crittografia simmetrica.

Modifica: TLS è anche un sistema molto più intrinseco che lavora molto duramente per proteggersi da ogni tipo di attacco. L'unico tipo di attacco da cui TLS non protegge efficacemente è una disconnessione forzata. Tutto, dall'autenticazione del server alla protezione man-in-the-middle alla protezione contro gli attacchi di replay, viene gestito automaticamente da TLS a un livello non visto nemmeno dal programmatore medio di alto livello. Nella tua situazione fai notare che non puoi utilizzare le connessioni TLS / (SSL) effettive, il che è un peccato. Ma vorrei chiarire che sconsiglio vivamente qualsiasi implementazione personalizzata progettata per sostituire TLS.

Michael
2015-12-18 01:32:50 UTC
view on stackexchange narkive permalink

Potenzialmente come ultima risorsa, poiché non sarà buono come TLS end-to-end ... ma potresti forse mettere qualcosa come CloudFlare in primo piano per almeno hai TLS sull'endpoint del client?

Funziona. Una volta ho utilizzato [Amazon Cloudfront] (https://aws.amazon.com/cloudfront/) "con successo" per aggirare i prezzi di sovrapprezzo SSL di Heroku. Ma tieni presente che offre agli utenti un falso senso di sicurezza, poiché il traffico dal punto di ingresso al tuo server non è crittografato.
Una possibilità * teorica * è configurare CloudFlare / Cloudfront per fornire i file JavaScript in modo sicuro (tramite HTTPS) da una CDN associata piuttosto che dal tuo server, e tutto il resto dal tuo server utilizzando la crittografia lato client JS. * Praticamente *, ottieni uno spazio web con SSL, come detto ...
rath
2015-12-18 17:26:53 UTC
view on stackexchange narkive permalink

Un'altra opzione è scrivere un plug-in del browser o uno script Tampermonkey (per ridurre i mal di testa multipiattaforma) e avere il codice JS pre-consegnato al browser. Lo cito puramente come ultima risorsa.

L'ovvio svantaggio è che i tuoi utenti sono limitati a utilizzare quei computer che hanno già il plug-in o a doverlo scaricare di nuovo ogni volta che utilizzano un nuovo dispositivo . Sarebbe anche difficile utilizzare i dispositivi mobili con esso.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...