Todas las conexiones entre clientes de TeamViewer utilizan certificados para autenticar la identidad de ambos participantes. Estos certificados los emite la CA TeamViewer para cada TeamViewer ID y evitan que esos dispositivos puedan suplantar a otro. La función "trae tu propio certificado" (BYOC) permite a los usuarios de TeamViewer utilizar sus propios certificados para autenticar los dispositivos implicados en una conexión TeamViewer. Esto es independiente y siempre adicional a la autenticación de los certificados de TeamViewer.

TeamViewer pueden configurarse para requerir autenticación de certificado personalizada para conexiones entrantes, conexiones salientes, o ambas. Cuando se requiere autenticación de certificado personalizada, la conexión sólo puede tener éxito si el otro lado tiene una clave privada para un certificado firmado por la autoridad de certificación configurada. Esta es una forma eficaz de restringir las conexiones de TeamViewer a un conjunto específico de dispositivos.

Este artículo se aplica a tod@s l@s clientes de una licencia Tensor de TeamViewer

Certificados

El uso de BYOC requiere una única autoridad de certificación (CA) para firmar los certificados de todos los dispositivos que necesitan autenticarse. Todos los dispositivos que necesiten autenticarse ante otros dispositivos deben tener acceso al certificado de la CA. Todos los dispositivos que deseen autenticarse ante otros dispositivos deben tener acceso a un certificado firmado por la CA, la clave privada correspondiente y todos los certificados intermedios (si los hay). TeamViewer admite certificados X.509 y puede importarlos junto con sus claves privadas desde archivos o desde el almacén de confianza de Windows.

Utilización del almacén de confianza Windows

Los certificados y claves privadas cargados desde el almacén de confianza Windows deben instalarse en el almacén de confianza de toda la máquina. Se puede acceder a este almacén mediante certlm.msc.

El certificado CA debe instalarse en el directorio "Entidades de certificación raíz de confianza" (Trusted Root Certification Authorities). El certificado CA específico utilizado para la autenticación se identifica por su huella digital única, codificada en hexadecimal. La huella digital se puede encontrar como "Huella digital" (Thumbprint) dentro de la pestaña "Detalles" (Details) al hacer doble clic en el certificado deseado.

El certificado del dispositivo debe estar instalado dentro del directorio "Personal" de certificados del ordenador local. Debe tener una clave privada disponible; esto se puede comprobar haciendo doble clic en el certificado, donde se mostrará un pequeño icono de una llave.

Para mayor comodidad, la función BYOC puede configurarse para utilizar el certificado de cliente con el mismo nombre que la máquina local. Esto permitirá utilizar la misma configuración para todas las máquinas y es la forma recomendada de configurar los certificados de cliente.

Uso de archivos de certificado

Los certificados y claves privadas cargados desde archivos deben ser X.509 binarios con codificación DER o X.509 con codificación base-64 (formato PEM). No se admiten otros formatos como PFX.

Si hay certificados intermedios entre el dispositivo y los certificados ca raíz, deben incluirse en el archivo de certificado del dispositivo. Esto solo es compatible con archivos de formato PEM; los archivos de formato DER no pueden contener cadenas de certificados.

El fichero que contiene la clave privada debe estar suficientemente protegido mediante los controles de acceso del sistema operativo. Si el servicio TeamViewer está en ejecución, accederá a la clave privada, por lo que en Windows, sólo se requiere acceso para el usuario SYSTEM.

Configuración

Por defecto, la función BYOC está desactivada, y ni las conexiones entrantes ni las salientes requieren autenticación de certificado. A la inversa, tampoco es posible conectarse ni recibir conexiones de ninguna máquina que requiera autenticación de certificado.

Para activar la función BYOC y requerir la autenticación mediante certificado, debe colocarse una cadena de configuración en los ajustes de TeamViewer. Estos se encuentran dentro del registro Windows. La ubicación exacta depende de la combinación de versiones de 32 o 64 bits de Windows y TeamViewer que se utilice:

La configuración de BYOC se encuentra dentro de la subclave "Seguridad". Esta clave de registro debe crearse si aún no existe. A continuación, para activar la función BYOC, debe crearse un nuevo valor con el tipo "String" y el nombre "BYOC_Configuration".

Si este valor existe y no está vacío, entonces la función BYOC está activa, aunque la configuración no sea válida. Con una configuración no válida, no será posible ninguna conexión.

Se puede utilizar PowerShell para crear este valor desde la línea de comandos:

New-Item -Force `
         -Path HKLM:\SOFTWARE\TeamViewer\Security
New-ItemProperty -Force `
                 -Path HKLM:\SOFTWARE\TeamViewer\Security `
                 -Name BYOC_Configuration

La propia configuración utiliza el formato JSON. El JSON puede escribirse directamente o copiarse en el Editor del Registro, pero la interfaz de usuario sólo permite una línea, por lo que debe eliminarse toda nueva línea del JSON. Alternativamente, la clave del registro también se puede establecer desde un archivo a través de PowerShell. Suponiendo que la configuración se guarda en un archivo llamado TeamViewerBYOC.json en el directorio actual, se puede cargar de la siguiente manera:

New-ItemProperty -Force `
                 -Path HKLM:\SOFTWARE\TeamViewer\Security `
                 -Name BYOC_Configuration `
                 -Value $(Get-Content TeamViewerBYOC.json)

El contenido del JSON determina cuándo se requiere autenticación de certificado y dónde encontrar los certificados. Las siguientes secciones muestran algunas configuraciones de ejemplo.

Utilización del almacén de confianza Windows

Los certificados y las claves privadas pueden cargarse desde el almacén de confianza Windows de toda la máquina. Para identificar el certificado correcto, el cliente TeamViewer puede buscar un certificado con el mismo nombre que la máquina local. En este documento, este certificado se denomina certificado host.

La configuración para cargar el certificado host tiene el siguiente aspecto:

{
 "cert": {
  "windows": {
   "use_host_certificate": true
  }
 }
}

Esto utilizará el certificado host para autenticar a este dispositivo y utilizar la CA que firmó el certificado host para autenticar otros dispositivos. Al identificar el certificado correcto por el nombre de host, esta configuración se puede utilizar en diferentes dispositivos y utilizar el específico del dispositivo.

Alternativamente, el certificado CA también puede especificarse explícitamente a través de su huella digital:

{
 "cert": {
  "windows": {
   "use_host_certificate": true
  }
 },
 "root_ca": {
  "windows": {
   "fingerprint": "d2dcdd02666b6335736c137fbbecff84730837af"
  }
 }
}

Uso de archivos de certificado

Alternativamente, los certificados también pueden cargarse desde archivos. Para el certificado de cliente, la clave también debe estar disponible como archivo, utilizando el mismo formato (PEM o DER) que el propio certificado. Sólo el servicio TeamViewer debe tener acceso a la clave; en Windows, este proceso se ejecuta como usuario SYSTEM. Se recomienda limitar el acceso al fichero de la clave privada.

Si hay certificados intermedios, deben añadirse al archivo de certificado del cliente. En ese caso, debe utilizarse un archivo PEM; no es posible utilizar una cadena de certificados con archivos DER.

La configuración para cargar archivos PEM tiene el siguiente aspecto:

{
 "cert": {
  "pem": {
   "path": "/etc/teamviewer/certs/client_chain.pem",
   "key_path": "/etc/teamviewer/certs/client.key"
  }
 },
 "root_ca": {
  "pem": {
   "path": "/etc/teamviewer/certs/ca.pem"
  }
 }
}

Alternativamente, para cargar ficheros DER binarios se hace así:

{
 "cert": {
  "der": {
   "path": "/etc/teamviewer/certs/client.der",
   "key_path": "/etc/teamviewer/certs/client.key"
  }
 },
 "root_ca": {
  "der": {
   "path": "/etc/teamviewer/certs/ca.der"
  }
 }
}

Desactivación de la verificación de certificados

Por defecto, la autenticación es necesaria tanto para las conexiones entrantes como salientes. Estas se pueden desactivar individualmente dentro de la sección root_ca.

Para exigir certificados sólo a las conexiones entrantes:

{
 "cert": {
  ...
 },
 "root_ca": {
  "dont_validate_outgoing": true
 }
}

Alternativamente, para exigir certificados sólo para las conexiones salientes:

{
 "cert": {
  ...
 },
 "root_ca": {
  "dont_validate_incoming": true
 }
}

Ambas opciones pueden combinarse para no requerir autenticación de certificado ni para las conexiones entrantes ni para las salientes. Esto puede ser útil, ya que permite al cliente autenticarse con otros dispositivos que sí requieren autenticación de certificado.

Seguridad mejorada con la verificación de revocación de certificados mediante CRL

Además, una función de seguridad mejorada permite la verificación de certificados mediante listas de revocación de certificados (CRL), si son compatibles. Por defecto, la opción de verificación CRL no está activada. Esto significa que, además de los métodos existentes, ahora existe un mecanismo para revocar y supervisar certificados mediante CRL (listas de revocación de certificados).

{ 
"cert": { 
... 
}, 
"root_ca": { 
"verify_crl": true 
} 
} 

(Certificado emisor en esta sección se refiere al certificado RootCA o a los certificados IntermediateCA, que emiten el siguiente certificado de la cadena. Por ejemplo, RootCA->IntermediateCA->Client, RootCA emite IntermediateCA e IntermediateCA emite RootCA).

(Certificado emitido en esta sección se refiere a certificados IntermediateCA o certificados de cliente, que son emitidos por el certificado anterior en la cadena. Por ejemplo, RootCA->IntermediateCA->Client, IntermediateCA es emitido por RootCA, y Client es emitido por IntermediateCA)

Cualquier emisor de certificados puede revocar un certificado emitido por razones que se actualiza en CRL con el número de serie del certificado revocado.

La CRL se descarga desde una URL disponible en el certificado como puntos de distribución de CRL. Los certificados pueden admitir varias URL en los puntos de distribución de CRL y, por tanto, varias CRL para un certificado. Se admiten CRL en formato PEM y DER. Por ahora, sólo se admiten CRL básicas; no se admiten CRL delta.

¿Cómo se realiza la verificación de certificados?

Para una cadena de certificados, ya sea RootCA->Cliente o RootCA->IntermediateCA->Cliente, por cada certificado emitido, a través de puntos de distribución (URL/s), se descargan CRLs. A continuación, los certificados emitidos se verifican con las CRL.

La verificación falla; por lo tanto, la autenticación falla para cualquiera de los siguientes escenarios:

  • si una cadena de certificados no es verificable o los certificados han caducado
  • si una URL no es accesible o no permite descargar CRL
  • si una CRL no está en el formato CRL correcto o es un archivo vacío o le faltan bytes
  • si una CRL ha caducado
  • si el certificado emisor de una URL de certificado no genera una CRL
  • si se revoca un certificado emitido

Limitaciones

Esta función aún está en desarrollo y tiene algunas limitaciones conocidas en este momento:

  • Las reuniones, por su diseño, no están cubiertas por las restricciones BYOC.
  • Actualmente, esta función sólo es compatible con Windows.