No trabalho, fui solicitado a adicionar suporte ao mapeamento de várias chaves para um único IP (ou mesmo par) para o que é essencialmente um sniffer HTTP passivo. Ele suporta descriptografia SSL com chaves enviadas pelo usuário. Atualmente, ele suporta um mapeamento de um IP para um, ou um mapeamento de IP para várias chaves. O problema está no aspecto de notificação disso. Atualmente, enviamos traps SNMP e / ou e-mail se a chave não estiver mais funcional. Com um mapeamento muitos-para-muitos, não terei como saber se a falha se deve a um módulo que foi alterado para uma das chaves mapeadas (por isso, uma chave foi alterada) ou é simplesmente uma chave adicional que foi adicionada, ou o administrador do sistema não está interessado em descriptografar. O maior problema está aqui porque a maneira como ele será implementado, a menos que uma reescrita completa seja permitida, também interromperá a notificação atual para mapeamentos de IP / chave um-para-um.
Eu acho que isso está errado, e aqui está o meu argumento. Alguém pode me ajudar apoiando esse argumento com os chefes? Ou, se estiver errado, mostre-me onde está o meu erro no raciocínio.
Essa funcionalidade é necessária porque, aparentemente, há um caso de uso em que vários nós em um webapp usam chaves diferentes, embora todos estejam mapeados para um único VIP. A pessoa que solicita essa funcionalidade insiste que a viu em ação em um ambiente de cliente. Eu gostaria de confirmar que esta é uma observação equivocada, mas não tenho tcpdumps para fazer isso. Eu mantenho que para um único IP, a negociação SSL sempre enviará o mesmo certificado e, portanto, a mesma chave será usada, porque nenhum HTTPS foi feito ainda, ele só sabe de uma conexão com um IP, nenhum conhecimento de qual host : header está presente neste estágio para o webapp / server determinar qual aplicativo irá responder. Assim, em minha mente, não pode haver nenhum caso de uso. Existe um balanceador de carga que permita colocar duas chaves em um único VIP?
Além disso, mesmo que fosse possível fazer isso, com base no modo de negociação SSL, não haveria como controlar se o usuário final está recebendo o certificado correto. Isso seria essencialmente uma configuração quebrada. Não consigo pensar em um caso de uso válido para isso, no qual isso não envolva erros aleatórios de incompatibilidade de SSL no lado do cliente.
Então, estou louco por pensar que isso não é algo que deve ser apoiado? Se assim for, gostaria de saber quando ter várias chaves mapeadas para um único IP é um caso de uso válido. Se não, por favor, forneça argumentos construtivos adicionais para esse fim - como eu fui vencido com os argumentos acima. As respostas até o momento estão no tom de "não é problema nosso se um administrador de sistemas não é competente, devemos apoiá-lo"
Editar: eu quebrei o título