Come autorizzo i siti Web a chiamare la mia app desktop su HTTPS?

3

Sto costruendo un'app desktop. Mi piacerebbe che i siti web fossero in grado di comunicare con l'app su HTTPS. L'idea generale è che un sito Web possa eseguire una chiamata JSONP su https://127.0.0.1:8844 e inviare dati all'app desktop.

Il problema è che la maggior parte dei browser più recenti non ti consente di eseguire una chiamata in background a un sito HTTPS non autorizzato, quindi il mio certificato autofirmato impedisce ai browser di chiamare la mia app.

La soluzione che ho pensato è di registrare local.myapp.com , puntarlo a 127.0.0.1 e avere un'autorità di certificazione firmare il certificato per esso. Il kicker è l'app è open-source, quindi dovrò distribuire il certificato / chiave a tutti i client.

Quali sono le implicazioni per la sicurezza di avere queste informazioni completamente fuori all'aperto? C'è un altro modo per consentire ai moderni browser di inviare dati a un'app desktop?

    
posta andrew 21.03.2014 - 19:10
fonte

2 risposte

1

Le implicazioni sulla sicurezza a parte per un minuto, sembra che questa sia una cattiva idea o semplicemente non funzionerà in molte situazioni.

La mia soluzione, che fa schifo ma non è la fine del mondo, è quella di creare estensioni del browser per comunicare tra l'app e il browser. In questo modo l'estensione può raccogliere informazioni sulla pagina corrente, sia http che https, e inviarla tramite testo in chiaro http all'app desktop tramite ajax.

    
risposta data 22.03.2014 - 00:23
fonte
0

Ricerca utilizzando CORS prima anziché JSONP, è molto più facile da usare, più sicuro e più affidabile come puoi gestire gli errori con jQuery. Il supporto è discutibile per IE8 e IE9 ma tutti gli altri browser principali funzionano correttamente. Il tuo codice di back-end del server Web deve solo inviare alcune intestazioni HTTP e inizia a funzionare con richieste AJAX regolari.

Se si desidera che i browser accettino un certificato autofirmato prima di utilizzare il servizio, è necessario digitare manualmente l'indirizzo IP del server nella barra degli indirizzi del browser Web. In primo luogo, genererà un avvertimento ingiustificato, quindi verifica manualmente gli hash del certificato rispetto agli hash del certificato reale, quindi archivia l'eccezione (considera il certificato). In alternativa, puoi esportare il certificato dal server in un file, quindi gli utenti possono caricare manualmente il file del certificato nel trust store del browser che si trova nelle impostazioni / preferenze del browser.

Ricevere un certificato autofirmato direttamente dall'operatore del sito web (ad esempio di persona) quindi memorizzarlo nella cache del browser è molto più sicuro che affidarsi a una terza parte come una "Autorità di certificazione" firmarlo. Ciò elimina praticamente gli attacchi MITM attivi e i problemi con le CA compromesse che firmano certificati falsi. Tuttavia, affinché ciò funzioni, è necessario eliminare il browser da tutte le autorità dei certificati di olio di serpente pre-firmati in modo che solo il certificato autofirmato sia considerato attendibile. Se li lasci lì, un utente malintenzionato con accesso lungo uno degli hop del router al tuo server (think intelligence agency) può intercettare la tua connessione, creare un falso certificato al volo, presentarti con il certificato falso firmato dalla CA compromessa di cui il tuo browser si fida già, quindi MITM attivamente la tua connessione lasciandoti completamente inconsapevole, a meno che tu non verifichi manualmente i dettagli della connessione e ti rendi conto che non hai ricevuto Verisign per firmare il tuo certificato autofirmato .... Con le CA radice pre-attendibili rimosso dal browser, e il tuo autofirmato si è fidato esplicitamente di questo non è più possibile e riceverai un avviso spaventoso legittimo se il certificato cambia.

Visualizzazione obbligatoria: Moxie Marlinspike e il futuro dell'autenticità.

    
risposta data 02.05.2014 - 04:16
fonte

Leggi altre domande sui tag