c# - true - Mejores prácticas para usar ServerCertificateValidationCallback

servercertificatevalidationcallback c#

Question

Estoy trabajando en un proyecto que utiliza alguna comunicación HTTP entre dos servidores de servicios de fondo. Los servidores están utilizando certificados X509 para la autenticación. No hace falta decir que cuando el servidor A (cliente) establece conexión con el servidor B (servidor), hay un error de validación de SSL / TLS, ya que los certificados utilizados no son de una autoridad de terceros de confianza.

Normalmente, la forma de manejarlo es mediante ServicePointManager.ServerCertificateValidationCallback , como:

ServicePointManager.ServerCertificateValidationCallback +=
(sender, cert, chain, error) =>
{
return cert.GetCertHashString() == "xxxxxxxxxxxxxxxx";
};

Ese enfoque funciona, excepto que no es ideal. Lo que esencialmente hace es anular el procedimiento de validación para CADA solicitud http realizada por la aplicación. Por lo tanto, si otra clase intentará ejecutar la solicitud HTTP, fallará. Además, si otra clase anula ServicePointManager.ServerCertificateValidationCallback para sus propios fines, entonces mi comunicación comienza a fallar repentinamente.

La única solución que viene a la mente es crear un AppDomain separado para realizar las solicitudes HTTP del cliente. Eso funcionaría, pero en realidad, es una tontería tener que hacerlo solo para que uno pueda realizar solicitudes HTTP. La sobrecarga será asombrosa.

Teniendo esto en cuenta, ¿alguien ha investigado si existe una mejor práctica en .NET, que permitiría acceder a los servicios web, mientras maneja la validación SSL / TLS del cliente sin afectar a otros clientes web?

Answer 1

El enfoque directo para este escenario debe ser instalar los dos certificados autogenerados en los almacenes raíz de confianza en las máquinas cliente. Recibirá una advertencia de seguridad cuando haga esto porque los certificados no se pueden autenticar con Thawte o similar, pero después de eso, la comunicación regular y segura debería funcionar. IIRC, necesita instalar la versión completa (tanto de clave pública como privada) en una raíz confiable para que esto funcione.

Answer 2

Una alternativa para el código que no usa HttpWebRequest y para los entornos en los que no puede instalar certificados de confianza en el almacén de certificados: compruebe el parámetro de error de la devolución de llamada, que contendrá cualquier error que se detectó antes de la devolución de llamada. De esta manera, puede ignorar los errores para cadenas de hash específicas, pero aún así aceptar otros certificados que pasen la validación.

ServicePointManager.ServerCertificateValidationCallback +=
(sender, cert, chain, error) =>
{
if (cert.GetCertHashString() == "xxxxxxxxxxxxxxxx")
{
return true;
}
else
{
return error == SslPolicyErrors.None;
}
};

Referencia: https://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs.110).aspx

Tenga en cuenta que esto seguirá afectando a otras instancias de cliente web en el mismo dominio de aplicación (todos aceptarán la cadena de hash especificada), pero al menos no bloqueará otros certificados.

Answer 3

Una metodología aceptable (segura) que funciona en .NET 4.5+ es usar HttpWebRequest . ServerCertificateValidationCallback ServerCertificateValidationCallbackHttpWebRequest . ServerCertificateValidationCallback . Asignar esa devolución de llamada en una instancia específica de solicitud cambiará la lógica de validación solo para la solicitud, sin influir en otras solicitudes.

var request = (HttpWebRequest)WebRequest.Create("https://...");
request.ServerCertificateValidationCallback +=
(sender, cert, chain, error) =>
{
return cert.GetCertHashString() == "xxxxxxxxxxxxxxxx";
};