Todas as conexões entre aplicativos TeamViewer usam certificados para autenticar a identidade de ambos os participantes. Esses certificados são emitidos para IDs TeamViewer individuais pela CA TeamViewer e impedem que esses dispositivos possam se passar por outro. O recurso bring your own certificate (BYOC) permite que os usuários do TeamViewer usem seus próprios certificados para autenticar os dispositivos envolvidos em uma conexão TeamViewer. Isso é independente e sempre adicional à autenticação dos certificados TeamViewer.
TeamViewer As instalações podem ser configuradas para exigir autenticação de certificado personalizado para conexões de entrada, conexões de saída ou ambas. Quando a autenticação de certificado personalizado é exigida, a conexão só pode ser bem-sucedida se o outro lado tiver uma chave privada para um certificado assinado pela autoridade de certificação configurada. Essa é uma maneira eficaz de restringir as conexões TeamViewer a um conjunto específico de dispositivos.
Este artigo se aplica a todos os clientes do TeamViewer Tensor.
O uso do BYOC requer uma única autoridade de certificação (CA) para assinar os certificados de todos os dispositivos que precisam se autenticar. Todos os dispositivos que exigem autenticação de certificado de outros dispositivos devem ter acesso ao certificado da CA. Todos os dispositivos que desejarem se autenticar em outros dispositivos devem ter acesso a um certificado assinado pela CA, à chave privada correspondente e a todos os certificados intermediários (se houver). O site TeamViewer é compatível com certificados X.509 e pode importá-los e suas chaves privadas de arquivos ou do armazenamento confiável Windows.
Os certificados e as chaves privadas carregados do repositório de confiança Windows devem ser instalados no repositório de confiança de toda a máquina. Esse armazenamento pode ser acessado por meio do certlm.msc
.
O certificado da CA deve ser instalado no diretório "Trusted Root Certification Authorities". O certificado de CA específico usado para autenticação é identificado por sua impressão digital exclusiva, codificada em hexadecimal. A impressão digital pode ser encontrada como "Impressão digital" dentro da guia "Detalhes" ao clicar duas vezes no certificado desejado.
O certificado do dispositivo deve ser instalado no diretório "Personal" dos certificados do computador local. Ele deve ter uma chave privada disponível; isso pode ser verificado clicando duas vezes no certificado, onde será exibido um pequeno ícone de chave.
Por conveniência, o recurso BYOC pode ser configurado para usar o certificado do aplicativo com o mesmo nome da máquina local. Isso permitirá usar a mesma configuração para todas as máquinas e é a maneira recomendada de configurar os certificados do aplicativo.
Os certificados e as chaves privadas carregados de arquivos devem ser X.509 binários codificados em DER ou X.509 codificados em base-64 (formato PEM). Não há suporte para outros formatos, como PFX.
Se houver algum certificado intermediário entre o dispositivo e os certificados de ca raiz, ele deverá ser incluído no arquivo de certificado do dispositivo. Isso só é compatível com arquivos de formato PEM; os arquivos de formato DER não podem conter cadeias de certificados.
O arquivo que contém a chave privada deve ser suficientemente protegido usando os controles de acesso do sistema operacional. Se o serviço TeamViewer estiver em execução, ele acessará a chave privada, portanto, em Windows, somente o acesso do usuário SYSTEM é necessário.
Por padrão, o recurso BYOC está desativado, e nem as conexões de entrada nem as de saída exigem autenticação de certificado. Por outro lado, também não é possível se conectar ou receber conexões de qualquer máquina que exija autenticação de certificado.
Para ativar o recurso BYOC e exigir autenticação de certificado, uma string de configuração deve ser colocada nas configurações de TeamViewer. Elas estão localizadas dentro do registro Windows. O local exato depende da combinação das versões de 32 ou 64 bits de Windows e TeamViewer que estão sendo usadas:
A configuração do BYOC está dentro da subchave Security. Essa chave de registro deve ser criada se ainda não existir. Em seguida, para ativar o recurso BYOC, deve ser criado um novo valor com o tipo String e o nome BYOC_Configuration.
Se esse valor existir e não estiver vazio, o recurso BYOC estará ativo, mesmo que a configuração não seja válida. Com uma configuração inválida, nenhuma conexão será possível.
O PowerShell pode ser usado para criar esse valor a partir da linha de comando:
New-Item -Force ` -Path HKLM:\SOFTWARE\TeamViewer\Security New-ItemProperty -Force ` -Path HKLM:\SOFTWARE\TeamViewer\Security ` -Name BYOC_Configuration
A configuração em si usa o formato JSON. O JSON pode ser digitado diretamente ou copiado no Editor do Registro, mas a interface do usuário permite apenas uma linha, portanto, o JSON deve ser removido de todas as novas linhas. Como alternativa, a chave do registro também pode ser definida a partir de um arquivo por meio do PowerShell. Supondo que a configuração esteja salva em um arquivo chamado TeamViewerBYOC.json no diretório atual, ela pode ser carregada desta forma:
New-ItemProperty -Force ` -Path HKLM:\SOFTWARE\TeamViewer\Security ` -Name BYOC_Configuration ` -Value $(Get-Content TeamViewerBYOC.json)
O conteúdo do JSON determina quando a autenticação do certificado é necessária e onde encontrar os certificados. As seções a seguir mostram alguns exemplos de configurações.
Os certificados e as chaves privadas podem ser carregados do repositório de confiança Windows em todo o computador. Para identificar o certificado correto, o TeamViewer pode procurar um certificado com o mesmo nome do computador local. Esse certificado é chamado de certificado host neste documento.
A configuração para carregar o certificado host tem a seguinte aparência:
{ "cert": { "windows": { "use_host_certificate": true } } }
Isso usará o certificado host para autenticar esse dispositivo e usará a CA que assinou o certificado host para autenticar outros dispositivos. Ao identificar o certificado correto pelo nome do host, essa configuração pode ser usada em diferentes dispositivos e usar o certificado específico do dispositivo.
Como alternativa, o certificado CA também pode ser explicitamente especificado por meio de sua impressão digital:
{ "cert": { "windows": { "use_host_certificate": true } }, "root_ca": { "windows": { "fingerprint": "d2dcdd02666b6335736c137fbbecff84730837af" } } }
Como alternativa, os certificados também podem ser carregados de arquivos. Para o certificado do aplicativo, a chave também deve estar disponível como um arquivo, usando o mesmo formato (PEM ou DER) do próprio certificado. Somente o serviço TeamViewer precisa ter acesso à chave; em Windows, esse processo é executado como o usuário SYSTEM
. Recomenda-se limitar o acesso ao arquivo de chave privada.
Se houver algum certificado intermediário, ele deverá ser anexado ao arquivo de certificado do aplicativo. Nesse caso, um arquivo PEM deve ser usado; não é possível usar uma cadeia de certificados com arquivos DER.
A configuração para carregar arquivos PEM tem a seguinte aparência:
{ "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" } } }
Como alternativa, para carregar arquivos DER binários, o procedimento é o seguinte:
{ "cert": { "der": { "path": "/etc/teamviewer/certs/client.der", "key_path": "/etc/teamviewer/certs/client.key" } }, "root_ca": { "der": { "path": "/etc/teamviewer/certs/ca.der" } } }
Por padrão, a autenticação é necessária para as conexões de entrada e de saída. Isso pode ser desativado individualmente na seção root_ca.
Para exigir certificados apenas para conexões de entrada:
{ "cert": { ... }, "root_ca": { "dont_validate_outgoing": true } }
Como alternativa, para exigir certificados apenas para conexões de saída:
{ "cert": { ... }, "root_ca": { "dont_validate_incoming": true } }
Ambas as opções podem ser combinadas para não exigir autenticação de certificado para conexões de entrada ou de saída. Isso pode ser útil, pois ainda permite que o aplicativo se autentique com outros dispositivos que exigem autenticação de certificado.
Além disso, um recurso de segurança aprimorado permite a verificação de certificados usando Listas de revogação de certificados (CRLs), se houver suporte para elas. Por padrão, a opção de verificação de CRL não está ativada. Isso significa que, além dos métodos existentes, agora existe um mecanismo para revogar e supervisionar certificados usando LCRs (Listas de revogação de certificados).
{ "cert": { ... }, "root_ca": { "verify_crl": true } }
(O certificado de emissão nesta seção refere-se ao certificado RootCA ou aos certificados IntermediateCA, que emitem o próximo certificado na cadeia. Por exemplo, RootCA ➜ IntermediateCA ➜ Client, RootCA emite IntermediateCA e IntermediateCA emite RootCA)
(O certificado emitido nesta seção refere-se a certificados IntermediateCA ou certificados de cliente, que são emitidos pelo certificado anterior na cadeia. Por exemplo, RootCA ➜ IntermediateCA ➜ Client, o IntermediateCA é emitido pela RootCA e o Client é emitido pela IntermediateCA)
Qualquer certificado emissor pode revogar um certificado emitido por motivos que são atualizados na LCR com o número de série do certificado revogado.
A LCR é baixada de um URL disponível no certificado como pontos de distribuição de LCR. É permitido que os certificados ofereçam suporte a vários URLs nos pontos de distribuição de LCR e, portanto, a várias LCRs para um certificado. Há suporte para as LCRs nos formatos PEM e DER. Por enquanto, somente as LCRs básicas são compatíveis; não há suporte para LCRs delta.
Para uma cadeia de certificados, seja ela RootCA ➜ Cliente ou RootCA ➜ IntermediateCA ➜ Cliente, para cada certificado emitido, por meio de pontos de distribuição (URL/s), é feito o download de CRLs. Os certificados emitidos são então verificados em relação às LCRs.
A verificação falha; portanto, a autenticação falha em qualquer um dos cenários a seguir:
Esse recurso ainda está em desenvolvimento e tem algumas limitações conhecidas no momento: