Insecure SSL: Server Identity Verification Disabled

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada. Esto equivale a confiar en todos los certificados. En otros casos, esto se puede deshabilitar de forma explícita, ya sea intencionalmente o no.

Ejemplo 1: Esta aplicación siempre comprueba que la cadena de certificados sea correcta, por lo que confía en todos los certificados.

...
private bool CertificateCheck(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
  ...
  return true; 
}
...
  HttpWebRequest webRequest = (HttpWebRequest) WebRequest.Create("https://www.myTrustedSite.com");
  webRequest.ServerCertificateValidationCallback = CertificateCheck;
  WebResponse response = webRequest.GetResponse();
...

Al intentar conectarse a "https://www.myTrustedSite.com", esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación deshabilita explícitamente la verificación del certificado:

...
  SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_callback);
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación no comprueba expresamente el certificado de servidor.

    ...
    config := &tls.Config{
        // Set InsecureSkipVerify to skip the default validation
        InsecureSkipVerify: true,
        ...
    }

    conn, err := tls.Dial("tcp", "example.com:443", conf)
    ..
    

Al intentar establecer una conexión con example.com, esta aplicación aceptará sin objeciones cualquier certificado emitido por el servidor. Esta aplicación puede filtrar información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada. Esto equivale a confiar en todos los certificados.

Ejemplo 1: este servidor intenta verificar las conexiones del cliente de forma incorrecta:

...
var options = {
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  requestCert: true,
  ...
}
https.createServer(options);
...

Cuando se crea el objeto https.Server, el parámetro requestCert se define como true, pero no se establece rejectUnauthorized, lo que establece false de forma predeterminada. Esto significa que, aunque el servidor se creó con la intención de verificar clientes en SSL, se seguirán aceptando conexiones incluso si el certificado no está autorizado con la lista de entidades de certificación proporcionadas.

Ejemplo 2: esta aplicación intenta conectarse con un servidor en SSL:

var tls = require('tls');
...
tls.connect({
  host: 'https://www.hackersite.com',
  port: '443',
  ...
  rejectUnauthorized: false,
  ...
});

En este ejemplo, como rejectUnauthorized se estableció en el valor false, significa que se aceptarán certificados no autorizados y que de todas formas se creará una conexión segura con el servidor no identificado. La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada (o se puede configurar de forma explícita para que así sea). Esto equivale a confiar en todos los certificados.

Ejemplo 1: este código configura NSURLConnectionDelegate para que acepte cualquier certificado HTTPS:

implementation NSURLRequest (IgnoreSSL)

+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
  return YES;
}

@end

Al intentar conectarse a un servidor protegido con SSL usando la implementación de NSURLRequest del Example 1, no aparecerá ningún error o advertencia si el certificado del servidor que recibe la solicitud se ha firmado automáticamente (y, por lo tanto, no está verificado). Como resultado, la aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: Esta aplicación no comprueba el certificado de servidor de forma predeterminada:

...
import ssl
ssl_sock = ssl.wrap_socket(s)
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, es posible deshabilitar la verificación del certificado de servidor. Esto equivale a confiar en todos los certificados.

Ejemplo 1: esta aplicación deshabilita explícitamente la verificación del certificado:

require 'openssl'
...
ctx = OpenSSL::SSL::SSLContext.new
ctx.verify_mode=OpenSSL::SSL::VERIFY_NONE
...

Al intentar la conexión con un host válido, esta aplicación aceptará sin objeciones un certificado emitido para "hackedserver.com". La aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida en el servidor pirateado.

La comprobación de la identidad del servidor se desactiva al establecer conexiones SSL.

En algunas bibliotecas que utilizan conexiones SSL, el certificado de servidor no se comprueba de forma predeterminada (o se puede configurar de forma explícita para que así sea). Esto equivale a confiar en todos los certificados.

Ejemplo 1: este código configura NSURLConnectionDelegate para que acepte cualquier certificado HTTPS:

class Delegate: NSObject, NSURLConnectionDelegate {
    
    ...

    func connection(connection: NSURLConnection, canAuthenticateAgainstProtectionSpace protectionSpace: NSURLProtectionSpace?) -> Bool {
        return protectionSpace?.authenticationMethod == NSURLAuthenticationMethodServerTrust
    }

    func connection(connection: NSURLConnection, willSendRequestForAuthenticationChallenge challenge: NSURLAuthenticationChallenge) {
        challenge.sender?.useCredential(NSURLCredential(forTrust: challenge.protectionSpace.serverTrust!), forAuthenticationChallenge: challenge)
        challenge.sender?.continueWithoutCredentialForAuthenticationChallenge(challenge)
    }
}

Al intentar conectarse a un servidor protegido con SSL usando la implementación de NSURLConnectionDelegate del Example 1, no aparecerá ningún error o advertencia si el certificado del servidor que recibe la solicitud se ha firmado automáticamente (y, por lo tanto, no está verificado). Como resultado, la aplicación podría filtrar entonces información de usuario confidencial en una conexión SSL interrumpida.

Ejemplo 2: en una clase NSURLSession, la validación de la cadena SSL/TLS se controla a través del método de delegación de autenticación de la aplicación, pero en lugar de proporcionar al servidor las credenciales para autenticar al usuario (o aplicación), la aplicación comprueba las credenciales que proporciona el servidor durante el intercambio SSL/TLS e indica al sistema de carga de URL si debe aceptar o rechazar esas credenciales. El siguiente código muestra un NSURLSessionDelgate que devuelve la proposedCredential del desafío recibido como una credencial para la sesión, lo que en la práctica permite eludir la verificación del servidor:

class MySessionDelegate : NSObject, NSURLSessionDelegate {
    ...
    func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void) {
        ...
        completionHandler(NSURLSessionAuthChallengeDisposition.UseCredential, challenge.proposedCredential)
        ...
    }
    ...
}