TLS 1.3 핸드셰이크: 인증서·ECDHE·0-RTT와 전방향 안전성

1장 개념과 보호 목표#

TLS 1.3은 통신 상대를 인증하고 전송 데이터의 기밀성과 무결성을 보호하는 프로토콜입니다. 인증서를 제시하는 것, 세션 키를 설정하는 것, 핸드셰이크가 변조되지 않았음을 확인하는 것은 서로 연결되지만 역할이 다릅니다.

2장 원리와 구분#

일반적인 인증서 기반 ECDHE 연결에서는 ClientHello와 ServerHello로 파라미터와 키 공유를 협상한 뒤 서버 인증서·CertificateVerify·Finished를 검증합니다. ServerHello 이후의 핸드셰이크 메시지는 암호화됩니다. TLS 1.3에서 RSA 인증서를 서명에 사용할 수는 있지만 과거 방식의 RSA 키 전송은 사용하지 않습니다. 인증된 임시 DH는 전방향 안전성에 기여하며 PSK만 사용하는 모드와 구분해야 합니다.

3장 TLS가 보호하는 것은 연결의 데이터다#

TLS는 의도한 상대를 인증하고 전송 데이터의 기밀성·무결성을 보호합니다. 서버의 DB 인가·입력 처리·저장 데이터 정책은 다른 영역입니다. HTTPS를 켰다는 사실로 서버 내부의 취약점을 안전하다고 판단하지 않습니다.

핸드셰이크는 사용할 파라미터·키 설정·인증과 대화 검증을 연결합니다. 연결 완료 뒤 데이터를 암호화하는 것과 상대의 인증서를 확인하는 일은 서로 다른 단계입니다.

4장 ClientHello와 ServerHello#

클라이언트는 지원 버전·알고리즘·키 설정 그룹과 필요한 정보를 제시하고 서버는 규약에 맞는 선택을 응답합니다. 일반적인 인증서 기반 ECDHE 연결에서는 양쪽의 임시 공개값으로 공유 비밀을 설정합니다. 실제 모드는 재개·PSK 등의 조건에 따라 다를 수 있습니다.

지원 목록을 무제한 늘리는 것보다 필요한 호환성과 안전한 허용 정책을 정합니다. 실제 배포 프록시·구형 클라이언트의 지원을 시험하고 협상 실패를 무검증 연결로 바꾸지 않습니다.

5장 인증서와 CertificateVerify#

인증서의 체인·이름·용도·시간을 검증하고, CertificateVerify를 통해 개인키 보유와 핸드셰이크 문맥의 서명을 확인합니다. 서버가 인증서 파일을 보냈다는 사실만으로 인증이 완료되지 않습니다. 잘못된 이름의 인증서가 통과하는 경로를 특히 점검합니다.

RSA 인증서를 쓸 수 있어도 TLS 1.3에서 옛 RSA 키 전송을 한다는 뜻은 아닙니다. 인증 서명과 키 설정을 별도 구성으로 읽어야 합니다.

6장 Finished는 대화와 비밀을 연결한다#

핸드셰이크 기록과 유도한 비밀을 연결해 검증합니다. 인증서가 유효하다는 사실만으로 협상과 대화의 모든 값이 정당하게 이어졌다고 보지 않습니다. 프로토콜은 각 단계의 검증을 결합해 연결을 완성합니다.

flowchart TB
 H["Hello와 파라미터 협상"] --> K["키 설정과 핸드셰이크 키"]
 K --> C["인증서·이름·서명 검증"]
 C --> F["Finished와 대화 검증"]
 F --> A["애플리케이션 트래픽 보호"]

7장 ServerHello 이후의 핸드셰이크 보호#

TLS 1.3에서는 ServerHello 이후의 핸드셰이크 메시지가 설정된 키로 암호화됩니다. 암호 스위트의 이름은 AEAD와 해시 조합을 중심으로 읽고 키 설정 그룹과 서명 방식은 별도로 확인합니다. 이름 하나로 인증서·키 교환의 모든 정책을 파악했다고 보지 않습니다.

로그와 관측에서는 필요한 버전·선택 파라미터·실패를 남기되 세션 비밀이나 평문 개인정보를 과도하게 기록하지 않습니다. 디버깅 설정이 운영에 남는 경로도 검토합니다.

8장 전방향 안전성의 조건#

장기 인증키가 나중에 노출되어도 과거 세션 비밀의 보호에 기여하려면 임시 비밀의 생성·재사용 방지·폐기 등 조건이 맞아야 합니다. 현재 실행 중인 서버가 탈취되어 평문을 읽는 위협과는 다릅니다. 안전성의 시간 범위와 공격 조건을 구분합니다.

PSK 재개와 키 설정 모드, 0-RTT는 별도의 성질을 갖습니다. 모든 TLS 1.3 메시지가 동일한 전방향 안전성을 갖는다고 단순화하지 않습니다.

9장 0-RTT에서 재전송을 생각해야 하는 이유#

재개 정보를 이용해 먼저 보내는 early data는 지연을 줄이지만 재전송 위험을 갖습니다. 결제·주문·권한 변경처럼 두 번 실행되면 피해가 나는 요청은 추가 보장 없이 허용하지 않습니다. 안전한 조회인지도 실제 업무 의미를 확인합니다.

요청: 주문 생성
재전송: 같은 주문 요청이 다시 도착
TLS의 전송 보호: 요청 내용의 보호
업무의 별도 요구: 중복 주문 방지와 사용자 의도 확인

10장 상호 TLS와 업무 권한#

클라이언트 인증서를 검증하면 연결 상대의 키와 신원을 확인하는 데 활용할 수 있습니다. 어떤 서비스·사용자에 연결되는지와 API 기능·객체 권한을 별도로 판단합니다. 인증서를 가진 모든 주체에게 관리 API를 열지 않습니다.

회수된 인증서·키와 기존 세션의 처리도 정책에 넣습니다. 인증서 갱신·폐지·장비 교체가 업무 계정의 권한 변경과 일치하는지 확인해야 합니다.

11장 TLS 종료 지점 이후의 구간#

로드밸런서에서 TLS가 끝나면 그 뒤 애플리케이션·DB로 가는 구간은 다른 연결입니다. 내부라는 이유만으로 평문을 모두 허용할지, 재암호화·서비스 인증이 필요한지 데이터와 위협을 기준으로 결정합니다. 사용자의 인증정보가 프록시 헤더로 넘어갈 때의 신뢰도 확인합니다.

flowchart LR
 C["클라이언트"] -->|"외부 TLS"| L["로드밸런서"]
 L -->|"별도로 설계할 내부 연결"| A["애플리케이션"]
 A -->|"DB 연결과 인가"| D["데이터베이스"]

12장 실제 검증에서 볼 항목#

지원 버전·허용 파라미터·이름 검증·인증서 갱신·PSK·0-RTT 정책·프록시 이후 구간을 연결합니다. 잘못된 이름·만료·미신뢰 인증서와 지원하지 않는 그룹을 시험합니다. 정상 연결 성공만으로 설정 검토를 끝내지 않습니다.

클라이언트 실패율·갱신 누락·복구·장비 교체까지 검증해야 전송 보호가 운영에서 유지됩니다. 프로토콜 구현은 해당 규약과 유지보수되는 라이브러리를 사용하고 암호 연산을 자체 조합하지 않습니다.

13장 적용 사례와 운영 방법#

재개 연결의 0-RTT early data는 지연을 줄이지만 재전송과 전방향 안전성의 제약이 있습니다. 결제·주문 생성처럼 반복되면 피해가 나는 요청에는 별도 방어 없이 허용하지 않습니다. TLS 종료 지점 이후 내부 전송도 보호 대상인지 확인합니다.

14장 인증서 기반 TLS 1.3 개요#

sequenceDiagram
 participant C as 클라이언트
 participant S as 서버
 C->>S: ClientHello와 key share
 S-->>C: ServerHello와 key share
 Note over C,S: 핸드셰이크 키 설정
 S-->>C: 암호화된 인증서·서명·Finished
 C->>C: 체인·이름·서명·Finished 검증
 C->>S: 암호화된 Finished
 Note over C,S: 애플리케이션 트래픽 보호

15장 인증서 서명과 세션 암호키는 다른 역할이다#

TLS 1.3의 암호 스위트 이름은 AEAD와 해시 조합을 중심으로 표현하며 인증서 서명 방식과 키 설정 그룹을 모두 담고 있지는 않습니다. RSA 인증서를 사용해도 RSA로 세션 비밀을 전달하는 옛 방식이라는 뜻은 아닙니다. 설정 점검에서는 버전·키 설정 그룹·서명 알고리즘·인증서 검증을 나누어 확인해야 합니다.

CertificateVerify는 상대가 인증서에 연결된 개인키를 보유하고 대화 내용에 서명했음을 확인합니다. Finished는 유도한 비밀과 핸드셰이크 기록을 연결해 검증합니다. 서버 인증서의 체인이 유효해도 이름 불일치나 검증 우회가 있으면 의도한 상대를 인증하지 못합니다.

16장 0-RTT가 주문 API에 적합하지 않을 수 있는 이유#

0-RTT 데이터는 재개 연결의 이전 정보를 활용해 먼저 보낼 수 있지만 재전송 위험이 있습니다. 같은 요청이 두 번 실행되면 문제가 되는 주문·결제·권한 변경은 기본적인 전송 암호화만 믿고 허용해서는 안 됩니다. 멱등성, 재전송 처리와 서버 정책을 별도로 검토해야 합니다.

외부 TLS가 로드밸런서에서 끝난다면 내부 애플리케이션까지 어떤 경로로 전송되는지도 그려 봅니다. 인증서 갱신·클라이언트 호환성·핸드셰이크 실패·키 재사용을 시험하고, 문서 판본은 RFC 8446을 대체한 RFC 9846을 확인합니다.

17장 적용 전 확인할 사항#

지원 버전·암호 스위트·인증서 검증을 확인한다
PSK 재개와 0-RTT 허용 요청을 구분한다
프록시 종료 이후의 데이터 흐름도 점검한다

18장 자주 묻는 질문#

HTTPS이면 애플리케이션 취약점도 사라지나요?#

TLS는 전송 구간을 보호합니다. 잘못된 인가, SQL 인젝션이나 서버 내부의 데이터 노출은 별도 통제가 필요합니다.

TLS 1.3은 클라이언트 인증도 항상 수행하나요?#

서버 인증과 클라이언트 인증은 별도입니다. 상호 TLS를 구성한 경우에는 클라이언트 인증서의 검증과 신원의 업무 권한 연결도 필요합니다.

전방향 안전성이 있으면 서버가 탈취되어도 데이터가 안전한가요?#

과거 세션의 비밀 보호와 현재 서버의 평문·세션·권한 보호는 다릅니다. 실행 중인 서버가 탈취되면 처리 중인 데이터는 노출될 수 있습니다.