Insecure SSL: Server Identity Verification Disabled

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서가 기본적으로 확인되지 않습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다. 다른 경우에는 의도에 관계없이 명시적으로 비활성화할 수 있습니다.

예제 1: 이 응용 프로그램은 항상 인증서 체인이 올바른지 확인하여 모든 인증서를 신뢰합니다.

...
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();
...

"https://www.myTrustedSite.com"에 연결하려고 하면 이 응용 프로그램은 "hackedserver.com"에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서 확인을 비활성화할 수 있습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 응용 프로그램에서는 인증서 확인을 명시적으로 비활성화합니다.

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

유효한 호스트에 연결하려고 하면 이 응용 프로그램은 "hackedserver.com"에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서가 기본적으로 확인되지 않습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 응용 프로그램은 서버 인증서를 명시적으로 확인하지 않습니다.

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

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

example.com에 연결하려고 하면 이 응용 프로그램이 서버에서 발급한 모든 인증서를 즉시 수락합니다. 이 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서가 기본적으로 확인되지 않습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 서버에서 클라이언트 연결을 확인하기 위한 잘못된 시도를 수행합니다.

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

이 https.Server 개체가 생성될 때 requestCert 설정이 true로 지정되지만 rejectUnauthorized가 설정되지 않습니다. 이는 false에 대한 기본값입니다. 이렇게 되면 SSL을 통해 클라이언트를 확인하기 위해 서버를 생성해도, 제공된 CA 목록으로 인증서가 인증되지 않은 경우에도 연결이 수락되지 않습니다.

예제 2: 이 응용 프로그램에서 SSL을 통해 서버에 연결하려고 합니다.

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

이 예제에서는 rejectUnauthorized가 false로 설정되었으므로 인증되지 않은 인증서가 수락되고 확인되지 않은 서버로의 보안 연결도 생성됩니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 호출하는 일부 라이브러리에서는 서버 인증서를 기본적으로 확인하지 않습니다(또는 확인하지 않도록 명시적으로 구성할 수도 있음). 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 코드에서는 모든 HTTPS 인증서를 수락하도록 NSURLConnectionDelegate를 구성합니다.

implementation NSURLRequest (IgnoreSSL)

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

@end

Example 1의 NSURLRequest 구현을 사용하여 SSL을 통해 보안이 유지되는 서버에 연결하려고 하면 요청된 서버의 인증서가 자체 서명된 인증서인 경우 확인되지 않으므로 경고나 오류가 생성되지 않습니다. 따라서 응용 프로그램이 이제 손상된 SSL 연결을 통해 민감한 사용자 정보를 누출하게 될 수도 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서 확인을 비활성화할 수 있습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 응용 프로그램은 기본적으로 서버 인증서를 확인하지 않습니다.

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

유효한 호스트에 연결하려고 하면 이 응용 프로그램은 "hackedserver.com"에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 사용하는 일부 라이브러리에서는 서버 인증서 확인을 비활성화할 수 있습니다. 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 응용 프로그램에서는 인증서 확인을 명시적으로 비활성화합니다.

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

유효한 호스트에 연결하려고 하면 이 응용 프로그램은 "hackedserver.com"에 발급된 인증서를 즉시 수락합니다. 그러면 이제 응용 프로그램은 해킹당한 서버에 대한 손상된 SSL 연결에서 민감한 사용자 정보를 누출할 가능성이 있습니다.

이로 인해 SSL 연결을 설정할 때 서버 ID 확인이 비활성화됩니다.

SSL 연결을 호출하는 일부 라이브러리에서는 서버 인증서를 기본적으로 확인하지 않습니다(또는 확인하지 않도록 명시적으로 구성할 수도 있음). 이것은 모든 인증서를 신뢰하는 것과 같습니다.

예제 1: 이 코드에서는 모든 HTTPS 인증서를 수락하도록 NSURLConnectionDelegate를 구성합니다.

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)
    }
}

Example 1의 NSURLConnectionDelegate 구현을 사용하여 SSL을 통해 보안이 유지되는 서버에 연결하려고 하면 요청된 서버의 인증서가 자체 서명된 인증서인 경우 확인되지 않으므로 경고나 오류가 생성되지 않습니다. 따라서 응용 프로그램이 이제 손상된 SSL 연결을 통해 민감한 사용자 정보를 누출하게 될 수도 있습니다.

예제 2:NSURLSession 클래스에서 SSL/TLS 체인 검증은 응용 프로그램의 인증 대리자 메서드에 의해 처리되지만, 사용자(또는 응용 프로그램)를 서버에 인증하기 위해 자격 증명을 제공하는 대신 응용 프로그램은 SSL/TLS 핸드셰이크 도중 서버가 제공하는 자격 증명을 확인한 다음 해당 자격 증명의 수락/거부 여부를 URL 로딩 시스템에 알립니다. 다음 코드는 수신한 챌린지의 proposedCredential을 세션에 대한 자격 증명으로 다시 전달함으로써 서버 확인을 실제로 우회하는 NSURLSessionDelgate를 보여 줍니다.

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