Oculta a caixa de diálogo do certificado do cliente no navegador, enquanto ainda permite certificados do cliente

Question

Eu tenho uma instância nginx que atende a um aplicativo da Web em HTTPS. O aplicativo da Web serve tanto para navegadores quanto para aplicativos móveis nativos. Os aplicativos móveis nativos usam certificados de cliente como uma camada adicional de autenticação, enquanto o navegador usa apenas nome de usuário / senha. O navegador e os aplicativos móveis usam caminhos diferentes, mas o mesmo ponto de extremidade TCP (IP / port).

O problema é que o navegador da Web exibe uma caixa de diálogo solicitando que o usuário especifique um certificado de cliente. É perfeitamente correto cancelar este diálogo, pois ele está configurado para ser opcional no nginx e a validação do certificado é feita no lado do aplicativo. No entanto, isso é muito confuso para os usuários , e eu preciso descobrir uma maneira de não mostrar o diálogo.

Meus requisitos:

• Seria muito difícil ter terminais diferentes (precisa ser a porta 443 em ambos, e a alocação de um novo IP será difícil). Por favor, não sugira mudar endpoints. Estou bem ciente desta solução e este é o plano B, se tudo o mais for absolutamente impossível, mas isso envolverá muitas e muitas dores de cabeça. Vale facilmente alguns dias de desenvolvimento para evitar alterar os pontos finais.
• Além de alterar o endpoint, tenho controle total sobre o código do cliente (por exemplo, aplicativo móvel), bem como a implantação do servidor. Eu poderia alterar protocolos conforme necessário, mas ele precisa dar suporte a HTTPS em um navegador "normal".
• Se é difícil ter diferentes configurações de certificado do lado do cliente por caminho (o que este segmento antigo parece para indicar), eu poderia recorrer à seleção baseada em agentes do usuário. Isso não é um problema de segurança, pois o aplicativo verifica se um certificado foi usado para os caminhos "confidenciais".
• Se o Nginx não puder fazê-lo, eu ficaria feliz em mudar para outro proxy reverso que possa manipulá-lo. (Traefik, Apache, ...?)

Answer 1

EDIT: Como apontado por Krumelur, o protocolo TLS permite que a renegociação da sessão seja iniciada pelo servidor web, onde o cliente pode solicitar o certificado do cliente, se necessário. Portanto, a resposta original abaixo não é válida para o problema.

A autenticação do certificado ocorre durante o handshake do cliente-servidor TLS e o HTTP é executado somente quando o reconhecimento é executado.

A cadeia user-agent faz parte da solicitação HTTP que o cliente envia pelo túnel TLS. Não é conhecido pelo servidor antes de o túnel TLS ser estabelecido e o cliente enviou a sua primeira solicitação HTTP.

Portanto, a única opção é trabalhar com o TLS. Agora, olhando para o RFC 5246, capítulo 7.4, podemos ver a especificação das mensagens Hello, que iniciam o handshake TLS.

A mensagem do Cliente Hello contém:

• hora atual
• 28 bytes aleatórios
• Conjunto de cifras
• Uma lista de métodos de compactação suportados
• Extensões possíveis de TLS

O servidor envia de volta sua própria mensagem Hello e o certificado do servidor imediatamente após a mensagem Hello. Em seguida, ele envia uma mensagem de troca de chave do servidor e, em seguida, a solicitação de certificado do servidor, se configurada.

Agora, podemos ver que a única informação enviada pelo cliente não inclui nenhuma informação sobre o tipo de cliente. A única informação extra fornecida é a parte de extensão TLS, e a lista de extensões TLS atuais está em link .

Olhando para a lista, não há informações sobre o tipo de cliente, mesmo em extensões TLS. Mesmo que houvesse uma extensão desse tipo, todos os clientes móveis ou de área de trabalho devem suportar essa extensão antes que o sistema funcione corretamente.

Portanto, a conclusão é que você não pode atingir sua meta de usar certificados de cliente em dispositivos móveis e não em computadores, porque o servidor não pode saber quando solicitar um certificado de cliente.

Sua única opção é usar o SNI como sugerido por @Alexey Ten