¿Necesito un certificado SSL firmado por una CA para aplicaciones móviles híbridas?

  

Por lo tanto, un certificado openssl autofirmado debería ser suficiente, ¿no?

Solo si su aplicación móvil solo acepta ese certificado y ningún otro. Es decir, deberá actualizar su aplicación móvil si el certificado SSL de su sitio web / servicio web y su sitio web / servicio web será rechazado por los navegadores normales como no confiable. Por lo tanto, ahorra una pequeña cantidad de dinero en un certificado comercial al costo de que ningún navegador o sistema operativo predeterminado acepte el sitio web.

  

¿Debo ingresar algún código en la aplicación cliente para validar el certificado?

La mayoría de las bibliotecas HTTPS buscarán en una variedad de lugares CA confiables. Entonces, siempre que haya agregado el certificado autofirmado o la CA que lo firmó en el almacén de confianza de la aplicación o la biblioteca, el proceso de validación se realizará automáticamente.

  

¿Cuál sería la mejor manera de implementar ssl para una aplicación híbrida?

Responder a cada faceta de esta pregunta sería ... bastante grande. Así que sugiero estos conceptos básicos:

• Compre un certificado SSL de larga duración normal de un proveedor normal. Obviamente, una cuya CA raíz se incluye en el almacén de confianza predeterminado del teléfono.
• Si desea bloquear la confianza solo para su certificado, hay formas de hacerlo, pero deberá solicitar el intercambio de la pila de Android. No debe requerir más que unas pocas líneas de código con una biblioteca / cliente HTTPS adecuado.
• Si desea bloquear el servicio web solo para su aplicación móvil, genere un certificado de cliente para incrustarlo dentro de su aplicación. No es infalible pero sí eleva el nivel.
• No cultives el tuyo. Si existe una biblioteca de código abierto algo pesada para este propósito, úsela. Al menos, si se enfrenta a problemas, tendrá una comunidad de desarrolladores decente para hacer preguntas. No puedo decir cuántas veces he visto preguntas de fragmentos de código en StackOverflow que podrían haberse evitado si el desarrollador estuviera utilizando una llamada estándar de una línea a una biblioteca popular.

Oh. Y con respecto a "modificar el código de validación de certificado en la aplicación cliente" , sí, no tiene una forma fácil de detenerlo, ya que tiene que lidiar con los mismos problemas de piratería e ingeniería inversa que cualquier otro estudio de software que proporciona al cliente. aplicaciones de lado tiene que lidiar con.

La URL encarna con qué servidor el cliente quiere hablar; no garantiza que el cliente realmente hable con ese servidor. El modelo de ataque aquí es que el cliente tiene la URL correcta, pero su conexión es redirigida por el atacante a un servidor controlado por el atacante. El atacante intenta hacerse pasar por el servidor. Esto es bastante fácil incluso para un atacante de baja potencia en contextos WiFi (el atacante simplemente ejecuta un punto de acceso "WiFi abierto", por ejemplo) o con DNS envenenamiento .

Para derrotar al atacante, el cliente debe conocer la clave pública correcta para el servidor deseado. Ahí es donde entran en juego los certificados: como una forma de distribuir claves públicas y hacer valer el nombre del servidor que posee cada clave pública.

Si desea hacerlo sin una CA, puede codificar el propio certificado del servidor en el cliente. De esa manera, el cliente conocerá "inherentemente" la clave pública del servidor y no será engañado por el atacante. Las CA son de hecho una indirección en este modelo: el cliente codifica algunos "CA raíz de confianza" y acepta como verdad lo que estos hayan firmado.

Otra opción, si los usuarios tienen contraseñas y necesitan autenticarse con un servidor a través de su aplicación, es usar SRP : client y server se autentican mutuamente con respecto a la contraseña compartida, y no hay ningún certificado en absoluto. Sin embargo, el código de cliente y servidor que puede hacer eso aún no se ha implementado ampliamente.