Insecure SSL: Server Identity Verification Disabled

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, o certificado do servidor não é verificado por padrão. Isso é equivalente a confiar em todos os certificados. Em outros casos, isso pode ser explicitamente desativado, seja por intenção ou não.

Exemplo 1: Este aplicativo sempre verifica se a cadeia de certificados está correta, confiando assim em todos os 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();
...

Ao tentar se conectar a "https://www.myTrustedSite.com", o aplicativo pode aceitar facilmente um certificado emitido para "hackedserver.com". Agora, é possível que ele deixe vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, é possível desabilitar a verificação de certificados do servidor. Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este aplicativo desabilita explicitamente a verificação de certificados:

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

Ao tentar se conectar a um host válido, o aplicativo pode aceitar facilmente um certificado emitido para "hackedserver.com". Agora, é possível que ele deixe vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, o certificado do servidor não é verificado por padrão. Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este aplicativo não verifica explicitamente o certificado do servidor.

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

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

Ao tentar se conectar a example.com, esse aplicativo aceita prontamente qualquer certificado emitido pelo servidor. Potencialmente, esse aplicativo pode vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, o certificado do servidor não é verificado por padrão. Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este servidor tenta verificar conexões de cliente incorretamente:

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

Quando esse objeto https.Server é criado, a configuração requestCert é especificada como true, mas rejectUnauthorized não é definido, o que padroniza como false. Isso significa que, embora o servidor tenha sido criado com a intenção de verificar os clientes via SSL, as conexões ainda serão aceitas mesmo se o certificado não for autorizado com a lista de ACs fornecidas.

Exemplo 2: Este aplicativo tenta se conectar a um servidor via SSL:

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

Neste exemplo, uma vez que rejectUnauthorized foi definido como false, isso significa que os certificados não autorizados serão aceitos, e uma conexão segura com o servidor não identificado ainda será criada. Agora, é possível que ele deixe vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que envolvem conexões SSL, o certificado do servidor não é verificado por padrão (ou pode ser explicitamente configurado para fazê-lo). Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este código configura o NSURLConnectionDelegate para aceitar qualquer certificado HTTPS:

implementation NSURLRequest (IgnoreSSL)

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

@end

Ao tentar conectar-se a um servidor protegido por SSL utilizando a implementação de NSURLRequest do Example 1, nenhum aviso ou erro resultará se o certificado solicitado do servidor for autoassinado (e, portanto, não verificado). Como resultado, o aplicativo potencialmente vazaria agora informações confidenciais do usuário por meio da conexão SSL quebrada.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, é possível desabilitar a verificação de certificados do servidor. Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Esse aplicativo não verifica o certificado do servidor por padrão:

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

Ao tentar se conectar a um host válido, o aplicativo pode aceitar facilmente um certificado emitido para "hackedserver.com". Agora, é possível que ele deixe vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que usam conexões SSL, é possível desabilitar a verificação de certificados do servidor. Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este aplicativo desabilita explicitamente a verificação de certificados:

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

Ao tentar se conectar a um host válido, o aplicativo pode aceitar facilmente um certificado emitido para "hackedserver.com". Agora, é possível que ele deixe vazar informações confidenciais dos usuários em uma conexão SSL interrompida com o servidor invadido.

A verificação de identidade do servidor está desabilitada ao se estabelecer conexões SSL.

Em algumas bibliotecas que envolvem conexões SSL, o certificado do servidor não é verificado por padrão (ou pode ser explicitamente configurado para fazê-lo). Isso é equivalente a confiar em todos os certificados.

Exemplo 1: Este código configura o NSURLConnectionDelegate para aceitar qualquer 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)
    }
}

Ao tentar conectar-se a um servidor protegido por SSL utilizando a implementação de NSURLConnectionDelegate do Example 1, nenhum aviso ou erro resultará se o certificado solicitado do servidor for autoassinado (e, portanto, não verificado). Como resultado, o aplicativo potencialmente vazaria agora informações confidenciais do usuário por meio da conexão SSL quebrada.

Exemplo 2: Em uma classe NSURLSession, a validação de cadeia de SSL/TLS é manipulada pelo método delegado de autenticação do aplicativo, mas, em vez de fornecer credenciais para autenticar o usuário (ou seu aplicativo) no servidor, o aplicativo verifica as credenciais fornecidas pelo servidor durante o handshake SSL/TLS e informa o sistema de carregamento de URL se ele deve aceitar ou rejeitar essas credenciais. O seguinte código mostra um NSURLSessionDelgate que passa umaproposedCredential do desafio recebido de volta como uma credencial para a sessão, ignorando efetivamente a verificação do servidor:

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