SSL/TLS, Unicode 공부하면서 생긴 의문점 정리
SSL/TLS 보안 및 핸드셰이크 관련 질의 응답
Q1. 핸드셰이크 과정에서 클라이언트와 서버가 난수를 주고받는 진짜 이유는 무엇인가?
A. 크게 두 가지 목적이 있다.
- 예측 불가능한 값: 매 접속마다 예측 불가능한 난수를 섞어 매번 다른 세션키(비밀번호)를 만들기 위해서
- 재전송 공격 방지: 해커가 예전에 가로챘던 통신 데이터를 그대로 다시 보내서 로그인 등을 시도하는 것을 막기 위해서 (난수가 다르면 서버가 거부함)
Q2. '임시 키(Pre-Master Secret)'와 '세션 키(Master Secret)'는 같은 건가?
A. 아니다. 임시 키(PMS)는 클라이언트가 생성해 서버의 공개키로 안전하게 전달하는 비밀 재료와 같은 것
- 세션 키: 이 임시 키에 클라이언트 난수와 서버 난수를 믹서기에 넣고 돌려 만든 최종 완성형 비밀번호로, 실제 데이터 암호화에는 이 세션 키만 사용됨
Q3. TLS 1.3은 왜 1.2보다 속도가 훨씬 빠른가?
A. 핵심은 "미리 주고, 동시에 보내기"
- 1-RTT: 1.2는 두 번 왕복해야 했지만, 1.3은 첫 인사 때 키 재료를 미리 던져서 단 한 번의 왕복으로 끝낸다.
- 데이터 동시 전송: 암호화 설정을 마치는 메시지(Finished)와 함께 실제 데이터(HTTP 요청 등)를 바로 실어 보내기 때문에 대기 시간이 거의 없다.
Q4. TLS 1.3의 키 교환 방식에서 왜 RSA가 퇴출되었나?
A. RSA 방식은 서버의 개인키만 훔치면 과거에 저장해둔 모든 통신 내용을 다 풀 수 있는 취약점이 있다. 반면 1.3에서 사용하는 Diffie-Hellman(ECDHE) 방식은 매번 일회용 키를 써서 서버 키가 털려도 과거 데이터는 안전하기 때문이다.
문자 인코딩 (ASCII / 유니코드) 관련 질의응답
Q1. '인코딩 방식'이라는 게 정확히 무엇을 의미하나?
A. 문자를 컴퓨터가 이해하는 숫자로 바꾸는 '암호 교환 규칙'이다. 예를 들어 "A는 65번으로 저장하자"라고 약속하는 과정으로, 이 약속이 서로 다르면 우리가 흔히 보는 '글자 깨짐' 현상이 발생한다.
Q2. 유니코드와 UTF-8, UTF-16은 각각 어떤 관계인가?
A. 유니코드는 전 세계 글자에 번호를 매긴 '번호표 사전'이고, UTF-8/16은 그 번호표를 메모리에 '저장하는 방식'이다.
- UTF-8: 영어는 1바이트, 한글은 3바이트로 저장하는 가변 방식 (웹 표준).
- UTF-16: 대부분의 글자를 기본 2바이트로 저장하는 방식 (OS/언어 내부용).
Q3. UTF-16은 한글/한자가 많은 아시아권에서 더 유리한가?
A. 반은 맞고 반은 틀리다.
- 용량 측면: 한글 텍스트만 따지면 2바이트인 UTF-16이 3바이트인 UTF-8보다 작아서 유리하다.
- 실제 활용: 하지만 우리가 사용하는 웹 소스(HTML/JS 등)는 영어와 기호 비중이 매우 높다. 영어는 UTF-8에서 단 1바이트면 충분하기 때문에, 전체적인 효율과 전 세계적 호환성을 고려해 아시아권에서도 UTF-8을 전송 표준으로 사용한다.
'SeSac) DevOps > 내용 정리' 카테고리의 다른 글
| [2주차 - 네트워크 (TCP/IP) 및 데이터 통신 기본] 세션 계층 (L5) (0) | 2025.12.31 |
|---|---|
| [2주차 - 네트워크 (TCP/IP) 및 데이터 통신 기본] 전송 계층 (L4) (0) | 2025.12.31 |
| [2주차 - 네트워크 (TCP/IP) 및 데이터 통신 기본] WireShark를 이용한 ARP 프로토콜 실습 (0) | 2025.12.30 |