Ho bisogno del certificato SSL firmato da una CA per le app mobili ibride?

So a self signed openssl certificate should be enough right?

Solo se la tua app mobile accetta solo quel certificato e nessun altro. Ovvero, dovrai aggiornare la tua app per dispositivi mobili se il certificato SSL del tuo sito Web / servizio Web cambia e il tuo sito web / servizio web verrà rifiutato dai normali browser come non attendibile. Così puoi risparmiare una piccola somma di denaro su un certificato commerciale al costo di nessun browser o sistema operativo predefinito che accetta il sito web.

Do i need to put in some code in the client application to actually validate the certificate?

La maggior parte delle librerie HTTPS guarderà in una varietà di posti per le CA di fiducia. Quindi, se hai aggiunto il certificato autofirmato o la CA che lo ha firmato all'applicazione o al negozio di fiducia della biblioteca, il processo di convalida avverrà automaticamente.

What would be the best way to implement ssl for a hybrid app?

Rispondere ad ogni aspetto di questa domanda sarebbe ... piuttosto grande. Quindi suggerisco queste basi:

• Acquista un normale certificato SSL di lunga durata da un normale provider. Ovviamente uno le cui CA radice sono incluse nell'archivio di fiducia predefinito del telefono.
• Se vuoi bloccare il trust solo per il tuo certificato, ci sono modi per farlo, ma dovrai chiedere allo stack stack Android. Non dovrebbe richiedere più di poche righe di codice con una libreria / client HTTPS appropriata.
• Se si desidera bloccare il servizio Web solo sulla propria app mobile, generare un certificato client da incorporare all'interno della propria app. Non infallibile, ma alza il livello.
• Non farti crescere da solo. Se esiste una libreria open source un po 'pesante per questo scopo, usala. Almeno se ti imbatti in problemi, avrai una comunità di sviluppatori decente da porre domande. Non posso dirti quante volte ho visto domande sullo snippet di codice su StackOverflow che sarebbero state evitabili se lo sviluppatore stesse utilizzando una chiamata standard su una libreria popolare.

Oh. E riguardo a "modifica il codice di convalida del certificato nell'applicazione client" - sì, non hai un modo semplice per fermarlo poiché devi affrontare gli stessi problemi di pirateria e di reverse engineering che ogni altro studio di software fornisce al cliente le applicazioni a lato deve fare i conti.

L'URL incarna il server con il quale il client desidera parlare; non garantisce che il client parli davvero con quel server. Il modello di attacco qui è che il client ha l'URL giusto, ma la sua connessione viene reindirizzata dall'attaccante a un server controllato da un utente malintenzionato. L'utente malintenzionato tenta di impersonare il server. Questo è piuttosto facile anche per un attaccante a bassa potenza in contesti WiFi (l'attaccante esegue solo un punto di accesso "WiFi aperto", per esempio) o con Avvelenamento DNS .

Per sconfiggere l'attaccante, il client deve conoscere la chiave pubblica corretta per il server previsto. È qui che entrano in gioco i certificati: un modo per distribuire le chiavi pubbliche e affermare il nome del server proprietario di ogni chiave pubblica.

Se vuoi farlo senza una CA, allora puoi il certificato del server stesso nel client. In questo modo, il client conoscerà "intrinsecamente" la chiave pubblica del server e non verrà ingannato dall'attaccante. CA è in realtà un punto di riferimento indiretto in questo modello: il client esegue l'hardcode di alcune "CA radice attendibili" e accetta come true qualunque sia stato firmato.

Un'altra opzione, se gli utenti hanno password e devono autenticarsi con un server attraverso la tua app, usa SRP : il server e del client si autenticano reciprocamente in relazione alla password condivisa e non vi è alcun certificato. Tuttavia, il codice client e server che può farlo potrebbe non essere ancora ampiamente implementato.