TLS에서 RSA와 ECDHE, 그리고 mTLS(Istio)까지:

들어가며

TLS를 이해할 때 가장 헷갈리는 지점은 “RSA냐 ECDHE냐”가 한 가지 차이로 끝나지 않는다는 점입니다. TLS는 핸드셰이크에서 동시에 두 가지를 해결합니다.

• 인증(Authentication): “이 서버(또는 클라이언트)가 진짜 누구인지”
• 키 합의(Key Agreement / Key Exchange): “앞으로 쓸 대칭키(세션키)를 양쪽이 똑같이 만들기”

RSA와 ECDHE는 주로 “키 합의” 방식의 차이를 말하고, mTLS는 “인증을 서버뿐 아니라 클라이언트까지 하느냐”의 차이를 말합니다.

---

TLS는 왜 대칭키가 필요한가

HTTPS에서 실제 데이터(HTTP 본문)는 결국 AES-GCM, ChaCha20-Poly1305 같은 대칭키 암호로 보호됩니다. 이유는 간단합니다.

• 대칭키 암호가 빠르다 (대용량 데이터 처리에 유리)
• 공개키 암호(RSA/ECDSA 등)는 느리고 “키 합의/서명” 같은 제어에 적합

그래서 TLS의 핵심은 “대칭키를 안전하게 합의해서 공유하는 과정”입니다.

---

RSA 키 교환(TLS_RSA): 비밀을 서버 공개키로 “한 번” 보내는 방식

 

흐름(개념)

 

1. 서버는 인증서를 보냅니다(안에 RSA 공개키가 들어있음).
2. 클라이언트는 PMS(Pre-Master Secret)라는 비밀값(난수)을 생성합니다.
3. 클라이언트는 PMS를 서버 RSA 공개키로 암호화해서 서버로 보냅니다.
4. 서버는 자기 RSA 개인키로 복호화해서 PMS를 얻습니다.
5. 이제 클라이언트와 서버는 “같은 PMS”를 갖게 되었으므로, 서로가 합의된 규칙(PRF/KDF)으로 각자 동일한 세션 대칭키를 계산합니다.
6. 이후 트래픽은 이 세션키로 암호화됩니다.

중요한 포인트는 이것입니다.

• 서버가 “대칭키를 만들어서 클라이언트에 다시 보내는” 구조가 아닙니다.
• 양쪽이 같은 재료(PMS와 핸드셰이크 난수들)를 가지고 각자 똑같이 계산해서 같은 키를 얻습니다.

RSA 키 교환의 약점: PFS(Forward Secrecy) 부재

RSA 키 교환에서는 서버의 RSA 개인키가 “과거 세션의 비밀을 풀 수 있는 열쇠” 역할을 하게 됩니다. 즉, 어떤 공격자가 트래픽을 녹화해두었다가 나중에 서버 개인키가 유출되면, 과거 통신이 위험해질 수 있습니다(구성/상황에 따라).

요즘 RSA “키 교환”은 사실상 비권장이고, TLS 1.3에서는 제거되었습니다.

---

ECDHE 키 교환(TLS_ECDHE): 비밀은 안 보내고 “공개값”만 교환하는 방식

 

ECDHE는 (EC)DH(Diffie-Hellman) 키 합의를 타원곡선 위에서 수행하는 방식입니다. 직관적으로는 다음과 같습니다.

• 클라이언트는 비밀값 a를 만듭니다(절대 네트워크로 안 나감).
• 서버는 비밀값 b를 만듭니다(절대 네트워크로 안 나감).
• 대신 각자 공개값만 만들어 교환합니다.

개념식으로 쓰면:

• 클라이언트 공개값: A = a * G
• 서버 공개값: B = b * G
• 공유 비밀:
  • 클라이언트는 S = a * B
  • 서버는 S = b * A
  • 수학적으로 둘이 같은 S가 됩니다.

여기서 자주 나오는 질문: A, B는 어떤 걸로 암호화해서 보내나?

핵심 결론은 이렇습니다.

• A와 B(공개값)는 보통 암호화하지 않고 그대로(평문으로) 교환합니다.
• 공개값은 “노출되어도 괜찮도록” 설계된 값이고, 진짜 비밀은 a, b입니다.

그럼 안전은 어떻게 보장하느냐?

• “도청”은 공개값만으로 공유 비밀을 만들기 어렵게 설계되어 막고,
• “변조/사칭(중간자 공격, MITM)”은 서명(Signature) 으로 막습니다.

ECDHE에서 인증(서버가 진짜인지)은 어떻게 하나?

ECDHE 자체는 “키 합의”만 제공하고, “상대가 진짜인지”는 보장하지 못합니다. 그래서 TLS는 다음을 합니다.

• 서버는 자신이 보낸 ECDHE 파라미터/공개값에 대해 서버 인증서 개인키로 서명합니다.
• 클라이언트는 서버 인증서(공개키)로 서명을 검증해서 “이 ECDHE 공개값은 진짜 서버가 보낸 것”임을 확인합니다.

즉,

• RSA 키 교환에서는 서버 개인키가 “복호화”에 직접 참여했고
• ECDHE에서는 서버 개인키가 “서명”에 참여합니다

ECDHE의 장점: PFS 제공

ECDHE는 매 연결마다 일회성(ephemeral) 비밀값을 쓰는 것이 일반적이라, 나중에 서버 인증서 개인키가 유출되더라도 과거 세션키를 재구성하기가 훨씬 어렵습니다. 이 특성이 PFS입니다.

---

“ECDHE_RSA” 같은 표기는 무엇을 의미하나

TLS에서 많이 헷갈리는 포인트입니다. 예를 들어 다음을 보겠습니다.

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

이 이름은 보통 다음을 함께 담습니다.

• ECDHE: 키 합의(세션키를 어떻게 만들까)
• RSA: 인증(서명)을 어떤 알고리즘으로 할까 (서버가 자신을 증명)
• AES_128_GCM: 실제 데이터 암호(대칭키)
• SHA256: 핸드셰이크 해시/파생에 사용

즉 “ECDHE를 쓴다”는 말은 “인증서가 ECDSA다”와 동의어가 아닙니다.
ECDHE + RSA 인증서(서명) 조합도 흔합니다.

---

mTLS(mutual TLS): 서버만 아니라 “클라이언트도” 인증한다

일반 TLS와 mTLS의 차이

• 일반 TLS: 클라이언트가 서버 인증서를 검증(서버만 신원 증명)
• mTLS: 서버도 클라이언트를 인증서로 검증(상호 인증)

mTLS에서는 클라이언트가 추가로 다음을 수행합니다.

• 클라이언트 인증서(공개키 포함)를 서버에 제시
• 핸드셰이크 내용에 대해 클라이언트 개인키로 서명해 “개인키 소유 증명(Proof of Possession)” 수행

여기서도 핵심은 이것입니다.

• mTLS라고 해서 “세션키를 클라이언트 공개키로 암호화해 준다” 같은 구조가 아닙니다.
• 키 합의(ECDHE 등)는 그대로 두고, 인증 단계에 ‘클라이언트 인증서+서명’이 추가되는 것입니다.

---

클라이언트가 CA에서 인증서를 받는 경우는 언제인가

클라이언트 인증서는 보통 “사람(브라우저)”이 아니라 다음 주체들에서 많이 사용됩니다.

1. 기업/기관 내부 보안

• VPN 접속(인증서 기반)
• 사내 Wi-Fi/유선 802.1X(EAP-TLS)
• 사내 프록시/관리 포털 접근 제한

1. 서비스 대 서비스 통신(마이크로서비스)

• 내부 API 호출에서 mTLS로 서비스 신원 확인
• API 키/JWT 대신 네트워크 레벨에서 강한 신원 보장

1. IoT/에이전트/장비

• 장비마다 고유 인증서를 심어 접속 주체를 강하게 식별

이 경우 “공개 CA”보다는 운영·폐기·회전 관리를 위해 사내 CA(Enterprise PKI) 를 쓰는 경우가 많습니다.

---

Istio에서 mTLS를 쓴다면 인증서 갱신은 누가 하나

결론부터 말하면, 범위를 나눠서 봐야 합니다.

• 워크로드(서비스) 인증서: 대부분 Istio가 자동 회전/갱신
• 루트/중간 CA(신뢰체인): 설치/연동 방식에 따라 운영 책임이 달라짐

1) 워크로드 인증서(사이드카가 쓰는 인증서)는 보통 자동으로 회전된다

Istio(istiod) + sidecar(Envoy/istio-agent)가 협력해서, 각 워크로드에 짧은 수명의 인증서를 발급하고 교체하는 흐름이 일반적입니다. 운영자가 매번 Pod에 수동으로 인증서를 배포하지 않아도 되도록 설계되어 있습니다.

2) “루트/중간 CA(신뢰체인)”는 설치 방식에 따라 달라진다

여기서 말하는 차이가 바로 “내장 CA vs 외부 CA 연동”입니다.

A. 내장 CA(기본 단순 구성)

• Istio가 클러스터 내부에서 자체 CA 역할을 수행합니다.
• 시작이 쉽지만, “조직의 PKI 표준(사내 루트/중간 CA)”과 일치시키기 어렵거나, 장기적으로 루트 만료/교체 전략을 고민해야 할 수 있습니다.

B. Plug-in CA(사내 체인을 Istio에 주입)

• “발급(서명) 동작은 Istio가 계속 수행”하지만,
• “어떤 루트/중간 CA 체인을 쓸지”를 운영자가 준비해서 Istio에 주입합니다.
• 조직 정책에 맞는 루트/중간 체인을 쓰고 싶을 때 선택합니다.

C. 외부 CA 연동(서명 자체를 외부 시스템이 수행)

• Istio는 CSR(서명 요청)을 만들고,
• 실제 서명(발급)은 cert-manager, Vault, 사내 PKI 같은 외부 발급 시스템이 담당합니다.
• 인증서 수명/회전/폐기 정책을 조직 PKI와 강하게 맞추고 싶을 때 유리합니다.

정리하면,

• 워크로드 인증서 “교체 작업”은 자동화되어 있는 편이지만,
• “무슨 루트/중간을 신뢰할지”는 조직 보안/운영 정책과 연결되어 설치 방식 선택이 중요합니다.

---

마치며

• RSA vs ECDHE는 본질적으로 “키 합의 방식”의 차이입니다.
• RSA 키 교환은 서버 개인키가 복호화에 참여하고 PFS가 약한 반면,
• ECDHE는 비밀값을 보내지 않고 공개값만 교환하며, 인증은 서명으로 수행하고 PFS를 제공합니다.
• mTLS는 키 합의 방식과 별개로 “클라이언트도 인증서로 인증하자”는 개념입니다.
• Istio mTLS에서는 워크로드 인증서 회전이 자동화되는 경우가 많지만, 루트/중간 CA 체인 관리는 설치/연동 방식에 따라 운영 범위가 달라집니다.