¿Está utilizando Diffie-Hellman para verificar el certificado SSL?

No creo que entiendas completamente lo que estás haciendo, así que trato de explicar tus pasos:

  

... comience por establecer una conexión segura entre la aplicación y el servidor web utilizando Diffie-Hellman ..

Esto sería una conexión DH anónima porque no verificas la identidad del par. Y no puede verificar su identidad porque todavía no tiene un ancla de confianza. Como no verifica la identidad, no puede estar seguro de con quién está hablando. Esto también significa que los ataques MITM son posibles, por lo que no debe confiar en ningún dato que obtenga dentro de esta conexión.

  

... para transferir el certificado, de modo que cuando se establezca la conexión SSL, pueda verificar si el certificado es correcto.

Esto significa que transfiere un ancla de confianza para futuras conexiones utilizando una conexión no confiable que está abierta a ataques MITM. No hay forma de verificar que el certificado que recibió es realmente el certificado del par con el que le gustaba hablar y no el certificado del atacante.

En resumen: reemplaza "ninguna verificación porque no hay un ancla de confianza" por "verificación contra un ancla de confianza en la que no se confía".

Usted escribe:

  

Dado que no hay conexión a Internet, el certificado SSL en el servidor web está autofirmado y no se puede verificar con una CA.

Hay algunos conceptos erróneos aquí. Repasemos algunos elementos fundamentales sobre los certificados:

• Los certificados no obtienen ni pierden valor dependiendo de cómo los obtenga. Lo que importa para un certificado es quién lo firmó.
• No necesita ninguna conexión a Internet. De hecho, ese es el punto central de los certificados: son una forma de vincular nombres a claves públicas de una manera que puede validarse sin tener que hablar con un sistema de terceros . Los certificados están destinados para funcionar con sistemas sin conexión.
• Un certificado se valida con respecto a un a priori conocido como "ancla de confianza" (también conocido como "CA raíz"). Un certificado autofirmado es un certificado que pretende ser su propia CA raíz.
• Hacer un intercambio de clave Diffie-Hellman anterior no cambia nada a ninguno de los anteriores. Ninguna de las firmas en todos estos certificados crea confianza alguna; la confianza se transfiere pero aún debe comenzar en algún lugar, es decir, los anclajes de confianza. No puedes evocar la confianza de la nada, ya sea con Diffie-Hellman o con cualquier otro algoritmo criptográfico.
• Incluso si sus sistemas tuvieran alguna conexión a Internet, no se cambiaría nada.

En su caso, desea que el cliente (aplicación iOS) pueda verificar que habla con el servidor original (su servidor web). El método más simple para eso es usar un certificado autofirmado en el servidor y codificar una copia de ese certificado en la aplicación. Solo para evitar cualquier malentendido: el certificado contiene la clave pública pero no la clave privada; El servidor tendrá tanto el certificado como la clave privada, la aplicación solo conocerá el certificado. Con el certificado codificado, la aplicación puede asegurarse de que habla con el servidor correcto mediante el uso de la clave pública en ese certificado codificado; en otras palabras, la aplicación valida el certificado que envía el servidor al compararlo, bit a bit, con el que ya está incluido en las aplicaciones.

Un método un tanto más complejo pero quizás más flexible es ejecutar su propia CA. Usted crea una CA raíz autofirmada e instala el certificado correspondiente en la aplicación como un ancla de confianza. También emite (es decir, firma) con ese CA un certificado para el servidor. La aplicación aplicará la validación X.509 normal, es decir, verificará que el certificado enviado por el servidor esté firmado por uno de sus anclajes de confianza.

Lo que quiere hacer viola fundamentalmente el "Principio Fundamental de Confianza" según lo establecido por Rajput que indica que "Para establecer la confianza entre dos partes en un no confiable, se necesita un canal de confianza" externo "(como un tercero)".

Si el problema es que realmente no confía en el certificado, agregar el certificado al almacén de confianza no es una opción. Una solución es emitir todos los certificados utilizando una única CA y luego mantener ese certificado en todos los dispositivos o instalarlo en el momento de "inicialización de Trust". La inicialización de Trust es siempre el momento más riesgoso y solo debe realizarse a través de una de las siguientes opciones (el correo electrónico no es seguro):

1. Lleve físicamente el dispositivo a una "zona de confianza".
2. A través de un tercero en el que ambos confían (es decir, entregue el certificado por FedEx o entregue en mano)

etc.

Debería poder usar certificados de una autoridad confiable incluso sin una conexión a Internet. Deberá tener una conexión a Internet para obtener el certificado (y cualquier certificado de CA intermedio relevante), pero una vez que lo haya comprado, puede transferirlo a la intranet e instalarlo en el servidor web.

La única fuente potencial de problemas es que el cliente no podrá verificar el estado de revocación del certificado sin una conexión a Internet, pero tengo entendido que iOS permitirá que las conexiones SSL / TLS pasen incluso si no se puede alcanzar. el servidor de revocación (CRL o OCSP).

EDITAR: pensé en otro posible problema: el cliente debe llegar al servidor utilizando un nombre de dominio adecuado que esté realmente registrado en la empresa, sin "server.local", "server.private" o dirección IP. Tenga en cuenta que si bien los servidores DNS normales de la empresa no estarán disponibles en la intranet, en general es posible configurar un servidor DNS privado en la intranet (de hecho, es posible que ya tengan uno).

Puede agregar el certificado a la lista de certificados de confianza del dispositivo; este sitio tiene una descripción de cómo hacerlo, pero básicamente, puede enviar el certificado por correo electrónico a cada dispositivo, o puede usar Apple Herramientas de administración de iPhone para agregarlas a muchos dispositivos. Parece que su producto incluirá instrucciones de configuración (ya que el servidor debe configurarse, no pueden simplemente descargar la aplicación), por lo que podría agregarlo a las instrucciones.

EDITAR: Diffie-Hellman, además de ser susceptible a los ataques del hombre en el medio, es totalmente inadecuado para tus objetivos. Lo que DH hace es permitir que las partes negocien un secreto compartido a través de un canal inseguro sin tener que haber compartido un secreto a través de un canal seguro. Ninguna de las partes puede controlar de manera significativa lo que es ese secreto compartido; DH es no una técnica de encriptación, porque eso requiere que Alice pueda enviarle a Bob algo de su elección, y todo lo que DH hace es darles a ambos algo que ellos saben y nadie más lo hace. Puede aplicar un cifrado simétrico después de hacer DH (ElGamal es básicamente eso), pero DH no puede transferir la información de su elección.

Además, DH tiene protección no contra los ataques MitM, por lo que la información transmitida debe ser confiable de alguna manera (ya sea empaquetándola en la aplicación [aunque haya rechazado el uso de la misma cert para todos, y el mismo problema aparece al reutilizar las credenciales de DH], o al firmarlo [esto es literalmente cómo funcionan algunos modos SSL]). Así que no, DH no es lo que estás buscando.