TLS
Transport Layer Security · TLS 1.3
는 통신 상대를 인증하고 두 끝점 사이의 데이터 변조와 도청을 줄이는 프로토콜이다. 에서는 핸드셰이크로 합의한 키와 레코드 보호를 구분하여 읽어야 한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 서버 인증서와 서명으로 상대 신원을 검증한다.
- 임시 키 합의에서 통신용 비밀값과 방향별 키를 도출한다.
- 레코드의 암호화와 인증 태그로 전송 내용을 보호한다.
02어떤 순서로 동작하나
클라이언트가 지원 버전·스위트·그룹·서명 방식과 를 보낸다.
서버가 선택 결과와 를 보낸다. 양쪽은 임시 공유 비밀과 문맥으로 방향별 핸드셰이크 키를 도출한다.
- 암호화된 서버 정보
서버가 EncryptedExtensions와 Certificate를 핸드셰이크 키로 보호해 보낸다. 클라이언트는 이름·인증서 경로를 검증한다.
- 서버의 두 증명
서명으로 개인키 소유를 확인하고 로 공유 비밀·누적 핸드셰이크 문맥의 일치를 검증한다.
- 클라이언트
클라이언트가 자신의 를 보내고 서버가 검증한다. mTLS나 재개 연결은 이 기본 메시지 흐름과 다르다.
- 애플리케이션 보호
별도 트래픽 키와 로 HTTP 등을 보호한다. 서버 데이터는 허용된 상태에서 클라이언트 보다 먼저 전송될 수도 있다.
03먼저 알아둘 용어와 구성요소
- 지원 버전·알고리즘·키 공유값 등을 제시하는 시작 메시지.
- 핸드셰이크 문맥에 서명하여 인증서 개인키 소유를 증명하는 메시지.
- 핸드셰이크 비밀과 를 바탕으로 무결성을 확인하는 메시지.
- 암호문과 추가 인증 데이터를 태그로 검증하는 인증 암호화.
- 서버가 협상 결과와 해당 핸드셰이크의 키 공유 정보를 전달하는 메시지.
- 임시 키 합의에 사용할 공개 정보를 담는 확장.
- 에 기반하여 입력 비밀에서 목적별 키 자료를 도출하는 함수.
- 핸드셰이크 메시지들의 순서 있는 기록으로 해시·검증의 입력이 된다.
- 이전 연결 또는 사전 배포로 공유한 비밀키 자료.
- 재개 시 초기에 데이터를 보내는 기능으로 재생 공격 위험을 따로 다뤄야 한다.
- 레코드 보호에서 키와 함께 쓰는 입력값으로 같은 키에서의 재사용을 피해야 한다.
핸드셰이크의 암호화 경계와 인증 실패 위치 찾기
메시지 순서를 패킷 관찰 가능 범위와 연결하고, 인증서 오류가 발생하는 단계를 설명한다.
실습 구성과 전제
- 자신의 실습 서버에 정상 HTTPS 연결을 한 번 만들고 PCAP를 저장한다.
- 전체 핸드셰이크 도해를 기준으로 하되 재개 연결·· 1.2는 별도로 구분한다.
암호화되기 전 협상 필드를 찾는다
- 에서 와 의 supported_versions, cipher suite, 를 비교한다. 구버전 호환 필드만 보고 1.2라고 단정하지 않는다.
- 는 제안, 는 선택 결과다. 양쪽이 합의한 키 공유로 이후 핸드셰이크 보호 키를 도출한다.
texttls.handshake.type == 1 || tls.handshake.type == 2표시 필터 예시. 저장된 자신의 실습 PCAP에서 사용한다.
원본 크기로 보기 ↗- ClientHello와 ServerHello 다음에 'Handshake 암호화 키 생성' 경계가 표시된다.
- CertificateVerify와 Finished는 서로 다른 메시지로 그려져 있어 키 소유 증명과 핸드셰이크 무결성 확인을 나누어 읽을 수 있다.
확인 기준같은 .stream에서 협상 버전과 키 공유를 확인한다.
안 보이는 메시지와 실패한 메시지를 구분한다
- 에서는 뒤의 인증서 메시지도 보통 암호화돼 보인다. 키 로그가 없는 캡처에서 Certificate가 보이지 않는다는 이유만으로 서버가 인증서를 생략했다고 단정하지 않는다.
- 실습 클라이언트의 브라우저 오류와 패킷 시각을 연결한다. 인증서 경고는 전송 암호화의 유무와 다른 판단이다.
원본 크기로 보기 ↗- HTTPS 주소에서도 CA 신뢰 오류가 표시된다.
- 경고 화면에는 협상 cipher suite나 Finished 성공 여부가 나타나지 않는다. 이 정보는 패킷·클라이언트 진단으로 보완해야 한다.
확인 기준캡처 가시성 한계와 실제 인증 실패를 보고서에서 분리한다.
인증 성공 후 애플리케이션 동작을 확인한다
- 핸드셰이크가 끝나도 HTTP 인가나 로그인 성공이 보장되지는 않는다. 연결 성립→서버 신뢰→애플리케이션 응답을 각각 판정한다.
- 복호화 가능한 실습 PCAP에서는 정상 요청의 응답을 확인하고, 키 로그 파일은 학습 후 별도로 보호·정리한다.
확인 기준성공과 HTTP 상태 코드를 같은 항목으로 합치지 않는다.
실습에서 확인한 동작 원리
- 의 암호화 경계는 이후에 생긴다.
- 신뢰 오류·복호화 자료 부재·애플리케이션 오류는 다른 현상이다.
04예제로 따라가기
- 조건 고정: 의 16바이트 태그를 사용하고 content는 100바이트, 추가 패딩은 없다고 가정한다.
- 내부 길이: Content 100바이트와 실제 유형 1바이트를 합쳐 입력 평문은 101바이트다.
- 암호화 길이: 암호문과 태그는 101+16=117바이트이며 외부 length 필드는 이 값을 표현한다.
- 전송 크기: 헤더 5바이트를 더하면 레코드는 122바이트다. ·IP· 오버헤드는 포함하지 않은 계산이다.
- 관찰 한계: PCAP의 세그먼트 하나가 반드시 122바이트인 것은 아니다. 분할·병합·추가 레코드 때문에 경계가 달라질 수 있다.
05혼동하기 쉬운 점과 확인 기준
- Handshake 문맥: · 실패는 서로 다른 키와 입력을 검증한다. 인증서 경로 오류와 누적 메시지 불일치를 분리한다.
- Record 오류: 실패는 키··헤더 AAD·암호문의 조합이 맞지 않다는 뜻이다. 악의적 변조 외에 잘못된 세션 비밀·누락 레코드도 분석 실패 원인이다.
- 방향·세대: 클라이언트·서버의 트래픽 키를 뒤집거나 KeyUpdate 이후에도 이전 키를 적용하지 않았는지 확인한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
RFC 8448: TLS 1.3의 실제 바이트 추적
3절의 1-RTT 교환에서 메시지 구성·키 도출·레코드 보호가 어떤 순서로 이어지는지 바이트 예와 비교할 수 있다.
- 메시지 길이와 레코드 길이의 차이
- 클라이언트·서버 방향별 handshake traffic secret
- 와 가 등장하는 위치
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.