HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 침해가 발생하기 쉽습니다. 이러한 경우에는 암호화된(보안) 프로토콜을 사용해야 합니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 통해 데이터를 전송합니다.

...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...

수신 HttpResponse 개체인 res는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 MiTM(Man-in-The-Middle) 공격이 발생하기 쉽습니다.

예제 1: 다음 코드는 HTTPS를 사용하는 대신 안전하지 않은 HTTP 프로토콜을 사용합니다.

    var account = new CloudStorageAccount(storageCredentials, false);

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 침해가 발생하기 쉽습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 데이터를 읽습니다.

  ...
  String url = 'http://10.0.2.2:11005/v1/key';
  Response response = await get(url, headers: headers);
  ...

수신 응답 response는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 손상이 발생하기 쉽습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 웹 서버를 설정합니다.

	helloHandler := func(w http.ResponseWriter, req *http.Request) {
		io.WriteString(w, "Hello, world!\n")
	}

	http.HandleFunc("/hello", helloHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 침해가 발생하기 쉽습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 데이터를 읽습니다.

var http = require('http');
...
http.request(options, function(res){
  ...
});
...

수신 http.IncomingMessage 개체인 res는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

HTTP를 통해 전송된 모든 데이터는 클리어에 전송되므로 손상될 수 있습니다.

예제 1: 다음 예제는 HTTPS가 아닌 HTTP 프로토콜을 통해 데이터를 보냅니다.

NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 손상이 발생하기 쉽습니다.

예제 1: 다음 예제에서는 소켓에서 암호화를 비활성화합니다.

...
stream_socket_enable_crypto($fp, false);
...

안전하지 않은 프로토콜, 암호화되지 않은 프로토콜 또는 일반 텍스트 프로토콜을 사용하여 전송하는 모든 통신 내용은 손상될 수 있습니다.

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 손상될 수 있습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 데이터를 읽습니다.

require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...

수신 스트림 in은 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

HTTP, FTP 또는 gopher를 통한 모든 통신은 인증되지도 암호화되지도 않습니다. 따라서 장치가 빈번하게 WiFi 연결을 통해 보안되지 않은 공용 무선 네트워크에 접속하는 모바일 환경에서 특히 침해가 발생하기 쉽습니다.

예제 1: 다음 예제는 HTTPS를 사용하는 대신 HTTP 프로토콜을 사용하여 데이터를 읽습니다.

   val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
   val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))

수신 응답 responseFuture는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.

HTTP를 통해 전송된 모든 데이터는 클리어에 전송되므로 손상될 수 있습니다.

예제 1: 다음 예제는 HTTPS가 아닌 HTTP 프로토콜을 통해 데이터를 보냅니다.

let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)

암호 집합은 보안 통신을 설정하는 데 사용되는 알고리즘 집합입니다. 서버와 클라이언트 간에 연결을 설정하는 동안 서버는 상호 지원되는 비밀번호 집합 중에서 어떤 것을 사용할지 대체적으로 결정합니다. 서버와 클라이언트는 지원되는 암호 집합이 다를 수 있습니다. 일반적으로 이전 암호 집합은 권장되지 않으며 응용 프로그램에 보안 취약성이 발생할 수 있습니다. 알려진 보안 취약성이 없는 강력한 암호 집합을 사용하는 것이 일반적으로 권장됩니다.

서버가 선호하는 암호 집합에는 알려진 약점이 있는 암호 집합이 포함될 수 있습니다. 그러한 취약한 암호 집합 중에 하나를 사용자가 선택할 경우, 보안 취약점을 공격하기 위한 알려진 약점이 있는 암호 집합을 선택하게 되는 것입니다.

예제 1: 다음 Paramiko 코드를 사용하면 공격자가 비활성화된 알고리즘 목록을 설정하여 암호를 다운그레이드할 수 있습니다.

    client = SSHClient()
    algorithms_to_disable = { "ciphers": untrusted_user_input }
    client.connect(host, port, "user", "password", disabled_algorithms=algorithms_to_disable)

Paramiko를 사용하면 개발자가 역암호 집합을 선택할 수 있습니다. Paramiko가 선호하는 알고리즘은 AES128-CTR, AES192-CTR, AES256-CTR, AES128-CBC, AES192-CBC, AES256-CBC 그리고 마지막으로 3DES-CBC입니다. 어떤 알고리즘이 비활성화되는지를 공격자가 제어할 수 있으면 SSHClient.connect(...)가 상대적으로 약한 알고리즘인 3DES-CBC를 사용하도록 강제할 수 있습니다.

이 응용 프로그램은 암호화되지 않은 채널을 통해 데이터베이스 서버와 통신하므로 해당 응용 프로그램의 회사 및 사용자에게 심각한 보안 위험을 초래할 수 있습니다. 이 경우, 공격자는 사용자가 입력한 데이터를 수정하거나 데이터베이스 서버에 대해 임의의 SQL 명령을 실행할 수도 있습니다.

예제 1: 다음 코드는 응용 프로그램이 암호화되지 않은 채널을 통해 데이터베이스 서버와 통신하도록 합니다.

  ...
  insecure_config = {
        'user': username,
        'password': retrievedPassword,
        'host': databaseHost,
        'port': "3306",
        'ssl_disabled': True
    }

    mysql.connector.connect(**insecure_config)
  ...

암호화를 지정하지 않거나 인증을 지원하지 않거나 연결 ID의 용량이 포함되지 않은 Google Remote Procedure Call(gRPC) 채널 보안 설정을 사용하는 경우 채널이 다양한 형태의 공격에 노출될 수 있습니다. 이러한 비보안 채널을 통해 전송하는 데이터는 신뢰할 수 없습니다.

예제 1: 다음 코드는 비보안 채널 자격 증명을 사용하는 gRPC 채널 설정을 보여줍니다.

    ...
    using var channel = GrpcChannel.ForAddress("https://grpcserver.com", new GrpcChannelOptions { 
        Credentials = ChannelCredentials.Insecure
    });
    ...
    

지정되지 않은 Google Remote Procedure Call(gRPC) 채널 자격 증명을 사용하는 경우 보안 설정이 안전하지 않은 기본값인 None으로 설정됩니다. 이처럼 안전하지 않은 채널 자격 증명 설정을 사용하여 주고받는 데이터는 신뢰할 수 없습니다.

예제 1: 다음 코드에는 모든 기본 매개 변수를 사용하여 생성한 gRPC 채널 자격 증명 개체가 나와 있습니다. 이로 인해 모든 채널 자격 증명 보안 설정이 안전하지 않은 기본값으로 설정됩니다. 여기서 root_certificates 매개 변수의 값은 None으로, private_key 매개 변수의 값은 None으로, certificate_chain 매개 변수의 값은 None으로 설정됩니다.

...
channel_creds = grpc.ssl_channel_credentials()
...

지정되지 않은 Google Remote Procedure Call(gRPC) 서버 자격 증명을 사용하는 경우 보안 설정이 안전하지 않은 기본값인 None 또는 False로 설정됩니다. 이처럼 안전하지 않은 서버 자격 증명 설정을 사용하는 서버와 주고받는 데이터는 신뢰할 수 없습니다.

예제 1: 다음 코드에는 기본 매개 변수를 사용하여 생성한 gRPC 서버 자격 증명 개체가 나와 있습니다. 이로 인해 클라이언트 인증이 비활성화됩니다.

...
pk_cert_chain = your_organization.securelyGetPrivateKeyCertificateChainPairs()
server_creds = grpc.ssl_server_credentials(pk_cert_chain)
...

HTTPS 스트리핑 공격은 MITM(Man-In-The-Middle) 공격의 한 유형으로, 이를 통해 공격자는 모든 HTTP 트래픽에서 위치 헤더를 확인한 후 참조하는 HTTPS를 연결하고 이를 HTTP 버전으로 바꿉니다. 공격자는 피해자가 HTTPS 요청을 서버에 다시 보낼 수 있도록 생성된 모든 HTTP 대체 항목을 목록으로 유지합니다. 스트리핑된 모든 HTTP 연결은 프록시를 사용하여 HTTPS를 통해 서버로 전송됩니다. 피해자와 공격자 간의 모든 트래픽은 HTTP를 통해 전송되어 사용자 이름, 암호 및 기타 민감한 정보가 공개되지만 서버는 여전히 공격자로부터 예상되는 HTTPS 트래픽을 수신하므로 아무것도 잘못된 것처럼 보이지 않습니다.

HTTP Strict Transport Security(HSTS)는 브라우저가 항상 HSTS 헤더를 헤더 자체에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 http://를 입력하더라도 HTTPS 연결로 자동으로 바뀝니다.

HTTPS 스트리핑 공격은 MITM(Man-In-The-Middle) 공격의 한 유형으로, 이를 통해 공격자는 모든 HTTP 트래픽에서 위치 헤더를 확인한 후 참조하는 HTTPS를 연결하고 이를 HTTP 버전으로 바꿉니다. 공격자는 피해자가 HTTPS 요청을 서버에 다시 보낼 수 있도록 생성된 모든 HTTP 대체 항목을 목록으로 유지합니다. 스트리핑된 모든 HTTP 연결은 프록시를 사용하여 HTTPS를 통해 서버로 전송됩니다. 피해자와 공격자 간의 모든 트래픽은 HTTP를 통해 전송되어 사용자 이름, 암호 및 기타 민감한 정보가 공개되지만 서버는 여전히 공격자로부터 예상되는 HTTPS 트래픽을 수신하므로 아무것도 잘못된 것처럼 보이지 않습니다.

HTTP Strict Transport Security(HSTS)는 브라우저가 항상 HSTS 헤더를 헤더 자체에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 http://를 입력하더라도 HTTPS 연결로 자동으로 바뀝니다.

HTTPS 스트리핑 공격은 MITM(Man-In-The-Middle) 공격의 한 유형으로, 이를 통해 공격자는 모든 HTTP 트래픽에서 위치 헤더를 확인한 후 참조하는 HTTPS를 연결하고 이를 HTTP 버전으로 바꿉니다. 공격자는 피해자가 HTTPS 요청을 서버에 다시 보낼 수 있도록 생성된 모든 HTTP 대체 항목을 목록으로 유지합니다. 스트리핑된 모든 HTTP 연결은 프록시를 사용하여 HTTPS를 통해 서버로 전송됩니다. 피해자와 공격자 간의 모든 트래픽은 HTTP를 통해 전송되어 사용자 이름, 암호 및 기타 민감한 정보가 공개되지만 서버는 여전히 공격자로부터 예상되는 HTTPS 트래픽을 수신하므로 아무것도 잘못된 것처럼 보이지 않습니다.

HTTP Strict Transport Security(HSTS)는 브라우저가 항상 HSTS 헤더를 헤더 자체에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 http://를 입력하더라도 HTTPS 연결로 자동으로 바뀝니다.

HTTPS 스트리핑 공격은 MITM(Man-In-The-Middle) 공격의 한 유형으로, 이를 통해 공격자는 모든 HTTP 트래픽에서 위치 헤더를 확인한 후 참조하는 HTTPS를 연결하고 이를 HTTP 버전으로 바꿉니다. 공격자는 피해자가 HTTPS 요청을 서버에 다시 보낼 수 있도록 생성된 모든 HTTP 대체 항목을 목록으로 유지합니다. 스트리핑된 모든 HTTP 연결은 프록시를 사용하여 HTTPS를 통해 서버로 전송됩니다. 피해자와 공격자 간의 모든 트래픽은 HTTP를 통해 전송되어 사용자 이름, 암호 및 기타 민감한 정보가 공개되지만 서버는 여전히 공격자로부터 예상되는 HTTPS 트래픽을 수신하므로 아무것도 잘못된 것처럼 보이지 않습니다.

HTTP Strict Transport Security(HSTS)는 브라우저가 항상 HSTS 헤더를 헤더 자체에 지정된 기간 동안 SSL/TLS를 통해 반환하는 사이트에 연결하도록 지시하는 보안 헤더입니다. HTTP를 통해 서버로 전송되는 모든 연결은 사용자가 브라우저의 URL 표시줄에 http://를 입력하더라도 HTTPS 연결로 자동으로 바뀝니다.

암호화되지 않은 채 전송되는 민감한 데이터는 네트워크 트래픽을 가로챌 수 있는 공격자가 읽거나 수정할 수 있습니다.

예제 1: 다음 SmtpClient는 SMTP 서버와 통신할 때 SSL/TLS를 사용하지 않도록 올바르지 않게 구성되어 있습니다.

  string to = "bob@acme.com";
  string from = "alice@acme.com";
  MailMessage message = new MailMessage(from, to);
  message.Subject = "SMTP client.";
message.Body = @"응용 프로그램에서 매우 쉽게 전자 메일을 전송할 수 있습니다.";
  SmtpClient client = new SmtpClient("smtp.acme.com");
  client.UseDefaultCredentials = true;
  client.Send(message);

암호화되지 않은 채 전송되는 민감한 데이터는 네트워크 트래픽을 가로챌 수 있는 공격자가 읽거나 수정할 수 있습니다.

예제 1: 다음 SMTP 클라이언트는 SMTP 서버와 통신할 때 SSL/TLS를 사용하지 않도록 올바르지 않게 구성되어 있습니다.

session = smtplib.SMTP(smtp_server, smtp_port)
session.ehlo()
session.login(username, password)
session.sendmail(frm, to, content)

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 메시지 MiTM(Man-in-the-Middle) 공격에 취약할 수 있으며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

데이터 전송의 신뢰성, 기밀성 및 무결성을 보장하기 위해 SSL/TLS를 사용하는 애플리케이션은 충분히 강력한 암호화 알고리즘을 선택하지 않으면 손상될 수 있습니다. 보호 메커니즘의 강도는 인증, 암호화 및 해싱 알고리즘(총칭하여 암호화 알고리즘 집합이라고 함)에 의해 결정됩니다. 암호화 알고리즘 집합은 TLS/SSL 채널을 통해 민감한 정보를 전송하는 데 사용됩니다.

서버가 다양한 강도의 암호화 알고리즘 집합을 지원하는 경우 약한 암호나 불충분한 길이의 암호화 키를 사용하면 공격자가 보호 메커니즘을 무력화하고 민감한 정보를 훔치거나 수정할 수 있습니다. 공격자는 안전하지 않게 구성된 웹 서버에 배포된 응용 프로그램을 조작하여 약한 암호 암호화 알고리즘 집합을 선택하도록 할 수 있습니다. 약한 암호 암호화 알고리즘 집합은 무차별 대입 공격 및 MiTM(Man-in-the-Middle) 공격에 취약하며, 이로 인해 민감한 데이터를 가로채고 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 이 Node.js 조각은 보안 연결이 있는 서버를 생성하려고 합니다.

...
var options = {
  port: 443,
  path: '/',
  key : fs.readFileSync('my-server-key.pem'),
  cert : fs.readFileSync('server-cert.pem'),
  ...
}
https.createServer(options);
...

Node.js는 secureProtocol의 기본값을 SSLv23_method로 설정하므로 서버는 secureProtocol이 특별히 오버라이드되지 않으면 본질적으로 안전하지 않습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결합니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호의 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

안전하지 않은 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 다음 예제에서는 기본 SSL 버전(SSL v3.0)을 사용합니다.

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration ephemeralSessionConfiguration];
[configuration setTLSMinimumSupportedProtocol = kSSLProtocol3];
NSURLSession *mySession = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:operationQueue];

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- 인증과 암호화에 동일한 키 사용
- 약한 메시지 인증 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

TLS(Transport Layer Security) 프로토콜과 SSL(Secure Sockets Layer) 프로토콜은 클라이언트와 웹 서버 사이에 전송되는 데이터의 신뢰성, 기밀성, 무결성을 보장하는 보호 메커니즘을 제공합니다. TLS와 SSL 모두 정기적인 버전 업데이트에 따라 여러 번 개정되었습니다. 새로운 개정 버전 각각은 이전 버전에서 발견된 보안 취약점을 해결하도록 설계되었습니다. TLS/SSL의 안전하지 않은 버전을 사용하면 데이터 보호 강도가 약화되고 공격자가 민감한 정보를 손상시키거나 도용하거나 수정할 수 있습니다.

보안이 취약한 버전의 TLS/SSL에는 다음과 같은 속성이 하나 이상 나타날 수 있습니다.

- MITM(Man-In-The-Middle) 공격에 무방비
- authentication과 암호화에 동일한 키 사용
- 약한 메시지 authentication 제어
- TCP 연결 차단에 무방비
- 약한 암호화 알고리즘 집합 사용

이러한 속성이 있으면 공격자가 민감한 데이터를 가로채거나 수정하거나 조작할 수 있습니다.

예제 1: 다음 예제에서는 SSL v3.0을 사용하도록 세션을 구성합니다.

let configuration : NSURLSessionConfiguration = NSURLSessionConfiguration.defaultSessionConfiguration()
let mySession = NSURLSession(configuration: configuration, delegate: self, delegateQueue: operationQueue)