Na presença de 'certificados de confiança' e outros atributos. Quão importante é isso?
O OpenSSL o implementa agora e se não, por que o OpenSSL não o implementa?
Responder1
Na maioria dos protocolos/aplicativos que usam SSL, o cliente precisa verificar AMBOS (1) se o servidor apresenta um certificado válido, ou seja, um certificado emitido por uma CA confiável e não expirado, revogado ou adulterado E (2) esse certificado é para o servidor que você deseja, não outra pessoa para quem sua conexão foi roteada por engano ou por ataque deliberado. (Há casos raros em que você não precisa apenas da confidencialidade da autenticação do servidor, mas provavelmente é melhor usar os ciphersuites "anon" ou "aNULL" que explicitamente não autenticam.)
OpenSSL até o momento faz (1), mas não (2)e normalmente oferece suporte apenas a certificados raiz de CA em seu armazenamento confiável; uma raiz de CA pode ser 'responsável' por milhares ou milhões de certificados de servidor e se, por exemplo, a Verisign emitiu certificados para ambos, bigbank.comisso localdiner.comnão significa que quero dar minhas contas do bigbank ao localdiner. Portanto, o aplicativo precisa fazer (2), em verify_callback ou após a conclusão do handshake, mas antes de enviar dados (confidenciais). A próxima versão principal 1.0.2 está planejada para conter melhorias na validação da cadeia de certificados e acredito que também nomeie a validação em pelo menos alguns casos. Observação para HTTPS usando RFC 2818 ou outros protocolos baseados em TLS usando RFC 6125, você precisa verificar CommonName em Subject e a extensão SubjectAlternativeNames, se presente.
Não seipor que OpenSSL(e antes disso SSLeay)não faz issojá. Pode-se dizer que alguns aplicativos SSL/TLS incomuns desejam algo diferente do CN/SAN padrão - mas há outras áreas onde o OpenSSL lida com casos comuns e fornece retornos de chamada ou opções para casos raros. Acho que provavelmente foi muito trabalho e poucas pessoas (até muito recentemente).