Keyless SSL의 작동 원리는 무엇일까요?

Keyless SSL을 이용하면 개인 키를 공유할 수 없는 조직도 SSL/TLS 암호화를 유지한 채로 클라우드로 옮겨갈 수 있습니다.

학습 목표

이 글을 읽은 후에 다음을 할 수 있습니다:

  • TLS 핸드셰이크의 단계, 그리고 세션 키와 개인 키의 차이를 설명
  • Keyless SSL이 개인 키를 사용하는 TLS 핸드셰이크 파트를 나머지 핸드셰이크 파트와 어떻게 구별하는지 이해
  • Diffie-Hellman 핸드셰이크와 RSA 핸드셰이크의 차이를 이해
  • FS(Forward Secrecy, 순방향 비밀성)가 무엇인지 이해

관련 콘텐츠


계속 알아보시겠어요?

인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!

Cloudflare가 개인 데이터를 수집하고 처리하는 방법은 Cloudflare의 개인정보 취급방침을 참조하세요.

글 링크 복사

Keyless SSL이란 무엇일까요?

Keyless SSL

Keyless SSL은 SSL 암호화에 클라우드 벤더를 이용하는 회사를 위한 서비스입니다. 이는 보통 클라우드 벤더가 그 회사의 개인 키를 알고 있어야 한다는 의미이지만, Keyless SSL을 이용하면 그럴 필요가 없습니다. 규제상의 이유로 많은 조직이 개인 키를 공유할 수 없습니다. 이러한 조직은 Keyless SSL을 이용하여 키를 안전하게 관리하면서도 계속해서 TLS를 이용하고 클라우드를 활용할 수 있습니다.

SSL, 보다 정확하게는 TLS는 네트워크를 통한 커뮤니케이션을 인증 및 암호화하기 위한 프로토콜입니다. SSL/TLS를 이용하려면 이른바 공개 키와 개인 키를 사용해야 하며, 웹 사이트와 주고 받는 트래픽을 안전하게 관리하기 위해 이 프로토콜을 사용 중인 회사의 경우(HTTPS 참조) 개인 키가 보통 회사의 소유로 유지됩니다. 하지만 회사가 클라우드로 옮겨가고, 벤더가 TLS 암호화를 제공하는 경우에는 벤더가 대신 그 개인 키를 소유합니다.

개인 키와 관련된 핸드셰이크 부분을 벤더의 서버 외부로 옮기면 개인 키는 회사에서 안전하게 소유할 수 있습니다. 클라우드 벤더에서는 개인 키를 직접 사용하여 벤더의 서버를 인증하는 대신, 이를 위해 회사 서버로 데이터를 전달하고 회사 서버로부터 데이터를 수신합니다. 이 통신은 안전한 암호화된 채널을 통해 이루어집니다. 따라서 개인 키는 여전히 사용되지만, 회사 외부의 누구와도 공유되지 않습니다.

예를 들어, Acme Co.에서 TLS를 구현한다고 가정해 보겠습니다. Acme Co.에서는 직접 소유하고 관리하는 서버에 개인 키를 안전하게 저장하고 있습니다. Acme Co.에서 클라우드로 옮겨 가서 웹 호스팅을 위해 클라우드 서비스 벤더를 이용한다면 이 벤더가 개인 키를 소유하게 됩니다. 하지만 Acme Co.에서 클라우드로 옮겨 가면서 대신 Keyless SSL/TLS를 구현하는 벤더를 이용한다면 비-클라우드 TLS 구현 환경에서와 마찬가지로 개인 키가 Acme Co.에서 소유하고 관리하는 서버에 그대로 남게 됩니다.

Keyless SSL의 작동 원리는 무엇일까요?

Keyless SSL은 TLS 핸드셰이크 중에는 개인 키가 한 번만 사용된다는 점을 기반으로 합니다. TLS 핸드셰이크는 TLS 커뮤니케이션 세션 시작 시 발생합니다. Keyless SSL은 TLS 핸드셰이크의 단계를 지리적으로 분할하여 작동합니다. Keyless SSL을 제공하는 클라우드 벤더는 프로세스의 개인 키 부분을 다른 서버, 즉 보통 고객이 온프레미스로 보유하고 있는 서버로 옮깁니다.

핸드셰이크 중에 데이터 해독하거나 서명하기 위해 개인 키가 필요해지면 벤더의 서버에서 필요한 데이터를 고객의 개인 키 서버로 전달합니다. 개인 키가 데이터를 해독하거나 서명하고, 고객의 서버에서 다시 데이터를 벤더의 서버로 전송하면 TLS 핸드셰이크가 평소대로 계속 진행됩니다.

Keyless SSL은 클라우드 벤더의 관점에서 볼 때에만 "keyless"입니다. 벤더는 고객의 개인 키를 절대 볼 수 없지만, 고객은 그대로 개인 키를 소유하고 사용할 수 있습니다. 한편, 공개 키는 평소처럼 그대로 클라이언트 측에서 사용됩니다.

Keyless SSL은 RSA 키 교환 TLS 핸드셰이크와 어떻게 작동할까요?

RSA 핸드셰이크에서 TLS 핸드셰이크의 단계는 다음과 같습니다.

  1. 클라이언트가 사용하려는 프로토콜 버전, 지원되는 암호 제품군 목록, "클라이언트 무작위"라는 짤막한 무작위 데이터 문자열을 포함하는 일반 텍스트 "헬로" 메시지를 서버로 전송합니다.
  2. 서버가(일반 텍스트로 이루어진) SSL 인증서, 선호하는 암호 제품군, "서버 무작위"라고 하는 또 다른 짤막한 무작위 데이터 문자열로 응답합니다.
  3. 클라이언트가 "예비 마스터 암호"라고 하는 또 다른 무작위 데이터 세트를 생성합니다. 서버의 SSL 인증서에서 공개 키를 가져온 클라이언트가 예비 마스터 암호를 암호화하여 서버로 전송합니다. 이 개인 키를 가진 사람만 예비 마스터 암호를 해독할 수 있습니다.
  4. 서버가 예비 마스터 암호를 해독합니다. 개인 키는 바로 이때에만 사용됩니다.
  5. 이제 클라이언트와 서버 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 갖고 있습니다. 클라이언트와 서버는 서로 독립적으로 이 세 가지 입력 정보를 통합하여 세션 키를 생성합니다. 둘 모두 같은 결과에 도달해야 하며, 세션 중에 이루어지는 이후의 모든 통신은 이 새로운 세션 키로 암호화됩니다.
Keyless SSL 없이 이루어지는 SSL 핸드셰이크(RSA)

Keyless SSL은 4단계에 개입합니다. Keyless SSL을 이용하면 예비 마스터 암호 자체를 해독하는 대신 클라우드 벤더는 이를 안전한 채널을 통해 고객이 호스팅하거나 관리하는 서버로 암호화된 형태로 전송합니다. 고객의 개인 키가 예비 마스터 암호를 해독하고, 그러면 해독된 예비 마스터 암호가 다시 클라우드 벤더에게 전송됩니다. 클라우드 벤더의 서버는 이를 사용해서 세션 키를 도출하고, TLS 통신은 평소대로 계속 진행됩니다.

Cloudflare Keyless SSL 핸드셰이크(RSA)

Keyless SSL은 임시 Diffie-Hellman 키 교환과 어떻게 작동할까요?

DHE(임시 Diffie-Hellman) 핸드셰이크(같은 키가 절대 두 번 사용되지 않기 때문에 "임시"라고 함)가 안전하지 않은 채널을 통해 키를 교환하는 방식인 Diffie-Hellman 알고리즘을 사용하여 세션 키를 생성합니다. 이러한 유형의 TLS 핸드셰이크를 이용하는 개인 키 인증은 세션 키 생성과 별도로 이루어지는 프로세스입니다.

사용하는 알고리즘을 제외하고 DHE 핸드셰이크와 RSA 핸드셰이크의 가장 큰 차이는 예비 마스터 암호가 생성되는 방식입니다. RSA 핸드셰이크에서는 예비 마스터 암호가 클라이언트가 생성하는 무작위 데이터로 이루어져 있다면 DHE 핸드셰이크에서는 클라이언트와 서버가 상호 합의한 매개변수를 사용하여 동일한 예비 마스터 암호를 따로 계산합니다.

  1. RSA 핸드셰이크에서와 마찬가지로 클라이언트가 사용하려는 프로토콜 버전, 지원되는 암호 제품군 목록, 클라이언트 무작위를 전송합니다.
  2. 서버는 선택한 암호 그룹, 서버 무작위, SSL 인증서로 응답합니다. 이 지점에서 DHE 핸드셰이크가 RSA 핸드셰이크와 달라지기 시작합니다. 여기에서는 서버가 예비 마스터 암호 계산에 사용되는 DH(Diffie-Hellman) 매개변수도 전송합니다. 여기에는 인증을 위한 디지털 서명도 포함됩니다. 개인 키는 이때에만 사용되며, 서버가 인증서에 명시된 서버라는 것을 인증합니다.
  3. 클라이언트에서는 서버의 디지털 서명을 확인하고 SSL 인증서를 인증합니다. 그러면 클라이언트가 DH 매개변수로 응답합니다.
  4. 클라이언트의 DH 매개변수와 서버의 DH 매개변수를 사용하여 양측 모두 각자 따로 예비 마스터 암호를 계산합니다.
  5. 그런 다음 이 예비 마스터 암호를 클라이언트 무작위 및 서버 무작위와 혼합하여 세션 키를 생성합니다.
Keyless SSL 없이 이루어지는 SSL 핸드셰이크(Diffie-Hellman)

개인 키는 2단계에서만 사용되며, 이 단계에서 Keyless SSL이 개입합니다. 이때 SSL/TLS 벤더는 클라이언트 무작위, 서버 무작위, 서버의 DH 매개변수를 개인 키를 보유한 고객이 관리하는 서버로 전송합니다. 이 정보는 서버의 디지털 서명을 생성하는 데 사용되고, 클라우드 벤더에게 다시 전송되며, 클라우드 벤더는 이를 클라이언트에게 전달합니다. 클라이언트는 이 서명을 공개 키로 확인할 수 있고, 핸드셰이크가 진행됩니다. 이런 방식이므로 클라우드 벤더는 개인 키를 사용할 필요가 없습니다.

Cloudflare Keyless SSL(Diffie Hellman)

임시 Diffie-Hellman 핸드셰이크는 RSA 핸드셰이크보다 약간 더 오래 걸리기는 하지만, FS(Forward Secrecy, 순방향 비밀성)라고 하는 이점이 있습니다. 개인 키가 인증용으로만 사용되기 때문에 공격자가 이를 이용해 세션 키를 알아낼 수 없습니다.

세션 키란?

세션 키는 TLS 핸드셰이크가 완료된 후에 TLS를 통한 안전한 통신 양측에서 사용하는 대칭 키입니다. 양측이 세션 키 세트에 대해 합의하고 나면 더 이상 공개 키와 개인 키를 사용할 필요가 없습니다. TLS는 각각의 고유 세션에 대해 서로 다른 세션 키를 생성합니다.

FS(Forward Secrecy, 순방향 비밀성)란 무엇일까요? PFS(Perfect Forward Secrecy, 완벽한 순방향 비밀성)란 무엇일까요?

FS(Forward Secrecy, 순방향 비밀성)는 개인 키가 노출된다고 하더라도 암호화된 데이터가 암호화된 상태로 유지되도록 합니다. 이것을 "PFS(Perfect Forward Secrecy, 완벽한 순방향 비밀성)"라고도 합니다. FS(Forward Secrecy, 순방향 비밀성)는 각각의 통신 세션마다 고유한 세션 키를 사용하거나 세션 키를 개인 키와 별도로 생성하는 경우에 가능합니다. 어느 하나의 세션 키가 손상되더라도 공격자가 해당 세션만 해독할 수 있을 뿐 다른 세션은 모두 암호화된 상태로 유지됩니다.

순방향 비밀성(forward secrecy)을 위해 설정된 프로토콜에서는 개인 키가 최초 핸드셰이크 프로세스 중 인증용으로 사용될 뿐 다른 목적으로는 사용되지 않습니다. 임시 Diffie-Hellman 핸드셰이크는 개인 키와 별도로 세션 키를 생성하므로 순방향 비밀성을 갖추었다고 할 수 있습니다.

대조적으로, RSA는 순방향 비밀성이 없습니다. 개인 키가 손상되면 공격자가 예비 마스터 암호를 해독할 수 있고 클라이언트 무작위와 서버 무작위는 일반 텍스트이므로 과거의 대화에 대한 세션 키를 결정할 수 있습니다. 공격자는 이 셋을 조합하면 어떠한 세션 키든 도출할 수 있습니다.

Cloudflare는 Keyless SSL을 어떻게 구현할까요?

Cloudflare는 은행처럼 보안 제한 사항이 엄격한 기업이 클라우드로 옮겨 갈 수 있도록 Keyless SSL을 출시한 최초의 클라우드 벤더입니다. Cloudflare에서는 RSA 핸드셰이크와 Diffie-Hellman 핸드셰이크를 모두 지원하기 때문에 기업들은 FS(Forward Secrecy, 순방향 비밀성)를 통합하고, 공격자가 개인 키를 훔쳐갔다고 해도 데이터를 해독할 가능성을 차단할 수 있습니다.

Cloudflare 서버와 개인 키 서버 간의 모든 통신은 안전하게 암호화된 채널을 통해서 이루어집니다. 또한, Cloudflare는 Keyless SSL이 개인 키 서버로 여러 번 액세스하는데도 불구하고 성능에 미치는 영향은 무시해도 좋을 정도라는 것을 알아냈습니다.

Keyless SSL의 작동 원리에 대한 자세한 기술 정보는 이 블로그 게시물을 참고하세요. Cloudflare의 Keyless SSL에 대한 자세한 내용은 Keyless SSL 서비스에 대한 세부 정보를 참고하세요.