Couchbase Móvil 2.0 soporta certificate pinning en todas las plataformas móviles de Couchbase. La vinculación de certificados es una técnica utilizada por las aplicaciones para "vincular" un host a su certificado/clave pública. La comunicación entre Couchbase Lite y Sync Gateway está encriptada y asegurada usando SSL/TLS. El protocolo SSL/TLS se basa en una infraestructura de clave pública (PKI) mediante un mecanismo Certificado X.509 para establecer la identidad del servidor Sync Gateway. El certificado suele emitirlo/firmarlo una autoridad de certificación de confianza y se instala en el Sync Gateway.
En un entorno de desarrollo, este certificado puede ser autofirmado.
Si la fiabilidad del certificado se ve comprometida de alguna manera o si se está utilizando un certificado autofirmado, entonces la identidad del servidor no se puede establecer de forma fiable y no puede haber garantías de confidencialidad en la comunicación entre el cliente y el servidor. Para aliviar estos problemas, Couchbase Lite soporta prendido del certificado. Para lograr la vinculación de certificados, el certificado de clave pública se suele entregar a la aplicación cliente a través de un canal fuera de banda y se incluye con la aplicación cliente. Al anclar el certificado, la aplicación cliente verificadora ya no necesita depender de una CA de terceros para verificar la firma. Esta técnica también es necesaria para comunicarse con Sync Gateway configurada con certificados autofirmados.
En este artículo se explica cómo fijar certificados en Coucbase Lite. Versión 2.0 habilitada para Android. Versión 1.4 de Couchbase Lite sólo era compatible con la fijación de certificados en iOS y que se discutió en este entrada del blog.
Puede descargar las últimas versiones preliminares de Couchbase Mobile 2.0 en aquí.
Fondo
Si está familiarizado con SSL/TLS o ha leído esto entrada del blogpuedes saltar a la sección "Soporte de Certificate Pinning con Couchbase Mobile" de esta entrada de blog.
La comunicación entre Couchbase Lite y Sync Gateway se encripta utilizando SSL/TLSA muy alto nivel, el protocolo TLS funciona de la siguiente manera.
En la puerta de enlace de sincronización se instala un certificado X.509 que contiene la clave pública y la identidad del servidor. Este certificado de clave pública puede estar firmado por una autoridad de certificación externa de confianza o puede estar autofirmado, lo que suele ser el caso en entornos de desarrollo.
Durante el establecimiento de la conexión, la aplicación cliente que ejecuta Couchbase Lite verifica la identidad de la puerta de enlace de sincronización utilizando el certificado del servidor. Couchbase Lite usa el certificado raíz de la CA de confianza para validar el certificado. Una vez verificado, el cliente procede con el intercambio de clave secreta. El secreto compartido se utiliza entonces para cifrar la comunicación entre el cliente y Sync Gateway.
Consulte el RFC para obtener información específica sobre el protocolo SSL/TLS.
Este enfoque plantea algunos problemas :-
- Aunque en la mayoría de las circunstancias es razonable confiar en la fiabilidad de la CA, es posible que la propia CA se vea comprometida. Si esto ocurre, no hay forma fiable de autenticar la puerta de enlace de sincronización porque la propia CA utilizada para la verificación no es de confianza.
- La comunicación cliente-servidor puede ser objeto de un ataque de intermediario (Man-in-the-Middle, MiTM) por el que un servidor fraudulento que se haga pasar por Sync Gateway puede emitir un certificado falso que represente a Sync Gateway, firmado por una CA falsa. Si el cliente es engañado de algún modo para que incluya el certificado de la CA falsa en su almacén de Autoridades de Certificación raíz de confianza, entonces el cliente confiará en el certificado falso firmado por la CA falsa. El resultado será que el cliente se comunicará con una puerta de enlace de sincronización falsa.
- Si utiliza certificados autofirmados en su entorno de desarrollo, no hay forma de que el cliente valide de forma fiable la identidad del servidor.
Entrega de certificados
Una forma común de manejar los problemas mencionados anteriormente es "fijar" el servidor Sync Gateway a su certificado/clave pública. En esta técnica, Couchbase Lite está preconfigurado con el certificado de confianza de Sync Gateway. Así, durante el establecimiento de la conexión, Couchbase Lite utiliza este certificado preconfigurado para verificar la identidad del servidor. Esto elimina la dependencia de una tercera CA externa para la verificación del certificado.
En Sitio web de OWASP es una buena referencia sobre la fijación de certificados.
Advertencia:
Es importante tener en cuenta que, dado que las aplicaciones se incluyen con el certificado, cada vez que este caduque habrá que actualizar la aplicación con el nuevo certificado. Esto puede ser un poco más difícil en entornos móviles, donde la responsabilidad de actualizar las aplicaciones recae en los usuarios. Por lo tanto, hay que estar al tanto de cuándo caducan los certificados y hacer los planes adecuados para publicar las aplicaciones con los nuevos certificados antes de que caduquen.
Soporte de Certificate Pinning con Couchbase Mobile
Este post asume que estás familiarizado con el desarrollo de aplicaciones Android y la configuración de tu aplicación para utilizar Couchbase Lite 2.0. Si no es así, por favor revisa este Primeros pasos guía. Utilizaremos Pasarela de sincronización 1.5 en la nube respaldado por un Servidor Couchbase persistencia de los datos en la nube. El servidor Couchbase no es relevante para las discusiones en este post.
Instalación del certificado en la puerta de enlace de sincronización
Siga las instrucciones del Portal para desarrolladores de Couchbase para generar / instalar el correspondiente certificado de servidor en su Sync Gateway
Un par de puntos a tener en cuenta durante la generación del certificado:-
- El certificado y la clave privada correspondiente deben estar en formato .pem
- Instale los certificados en una ubicación accesible para Sync Gateway. De lo contrario, se producirá un error al iniciar Sync Gateway con el archivo de configuración.
|
1 2 3 4 5 |
2017–12–10T16:05:21.303–05:00 Using metadata purge interval of 3.00 days for tombstone compaction. 2017–12–10T16:05:21.305–05:00 Starting admin server on 127.0.0.1:4985 2017–12–10T16:05:21.310–05:00 Starting server on :4984 … 2017–12–10T16:05:21.310–05:00 HTTP: Protocols enabled: [http/1.1] on 127.0.0.1:4985 2017–12–10T16:05:21.311–05:00 FATAL: Failed to start HTTP server on 127.0.0.1:4985: open cert.pem: no such file or directory – rest.(*ServerConfig).Serve() at config.go:716 |
- Si está generando un certificado autofirmadoprobablemente el campo más importante sea el
Nombre común. Debe ser el FQDN de su Sync Gateway. Si su Sync Gateway no tiene uno, debe especificar el uso de10.0.2.2para localhost o la dirección IPA estática de su Sync Gateway.
Archivo de configuración de la pasarela de sincronización
Confirme que el archivo de configuración de Sync Gateway incluye las siguientes propiedades
|
1 2 |
"SSLCert": "ssl/cert.pem", "SSLKey": "ssl/privkey.pem", |
Verificación de la configuración SSL en su Sync Gateway
Para comprobar que puede conectarse a su Sync Gateway a través de SSL, ejecute lo siguiente rizo en un comando de terminal. Sustituya localhost en el comando de abajo con la dirección IP de su puerta de enlace de sincronización.
|
1 |
curl -k -X GET https://localhost:4984 -H 'cache-control: no-cache' –verbose |
Si la configuración es correcta, debería ver algo como esto en la salida
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
* Rebuilt URL to: https://localhost:4984 / * Trying ::1… * TCP_NODELAY set * Connected to localhost (::1) port 4984 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /Users/priya.rajagopal/anaconda/ssl/cacert.pem CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=Michigan; O=Couchbase; CN=localhost * start date: Dec 8 14:00:33 2017 GMT * expire date: Dec 7 14:00:33 2020 GMT * issuer: C=US; ST=Michigan; O=Couchbase; CN=localhost * SSL certificate verify result: self signed certificate (18), continuing anyway. > GET / HTTP/1.1 > Host: localhost:4984 > User-Agent: curl/7.52.1 > Accept: / > cache-control: no-cache > < HTTP/1.1 200 OK < Content-Length: 130 < Content-Type: application/json < Server: Couchbase Sync Gateway/1.5.1 < Date: Fri, 08 Dec 2017 14:27:07 GMT < * Curl_http_done: called premature == 0 * Connection #0 to host localhost left intact {"couchdb":"Welcome","vendor":{"name":"Couchbase Sync Gateway","version":1.5},"version":"Couchbase Sync Gateway/1.5.1(4;cb9522c)"} |
- Convierta el certificado PEM en formato der utilizando el siguiente comando
|
1 |
openssl x509 -inform PEM -in cert.pem -outform DER -out cert.cer |
Puede consultar este Hoja de trucos SSL para más detalles sobre los distintos comandos de openSSL.
- Copie el
cert.pemen su Activos carpeta. La carpeta del proyecto de Android Studio debe ser similar a la siguiente
- Fijación del certificado del servidor Sync Gateway
- Para fijar el certificado, primero debemos cargar el certificado que se incluye con la aplicación Activos carpeta.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
private byte[] getPinnedCertFile(Context context) { AssetManager assetManager = context.getAssets(); InputStream is = null; byte[] bytes = new byte[0]; try { is = assetManager.open("cert.cer"); return (IOUtils.toByteArray(is)); } catch (IOException e) { e.printStackTrace(); } return null; } |
En este ejemplo, estamos utilizando las clases de utilidad IOUtils de [Apache Commons IO](https://commons.apache.org/proper/commons-io/description.html) para convertir el certificado leído del flujo de entrada de archivos a byte array. Puede elegir cualquier otra herramienta/método para la conversión.
- Configure el Replicador con el certificado fijado. En una aplicación real, tendrás que hacer una comprobación de nulos en el certificado antes de fijarlo. Omitimos las comprobaciones aquí por brevedad.
|
1 2 3 4 5 6 7 8 9 10 |
ReplicatorConfiguration config = new ReplicatorConfiguration(database, new URLEndpoint(url)); config.setReplicatorType(ReplicatorConfiguration.ReplicatorType.PUSH_AND_PULL); config.setContinuous(true); config.setAuthenticator(new BasicAuthenticator(username, password)); // Get the certificate bundled in with the app byte[] pinnedServerCert = this.getPinnedCertFile(context); // Set pinned certificate. config.setPinnedServerCertificate(pinnedServerCert); Replicator replicator = new Replicator(config); |
Ya está. Con sólo un par de pasos, puedes habilitar la fijación de certificados en tu aplicación Android con Couchbase Mobile 2.0.
¿Qué sigue?
Esta entrada del blog discutió los beneficios de la fijación de certificados dentro de tus aplicaciones móviles y cómo puedes habilitar la fijación de certificados con Couchbase Lite 2.0. El ejemplo trataba de una aplicación Android, pero el enfoque sería similar en otras plataformas también.
Si tiene alguna pregunta o sugerencia, deje un comentario a continuación o póngase en contacto conmigo en Twitter @rajagp o envíeme un correo electrónico priya.rajagopal@couchbase.com. En Foros de Couchbase son otro buen lugar para plantear preguntas.
