TLS 동작 원리: 왜 처음만 비대칭키를 쓰고 나중엔 대칭키를 쓸까?

https://zandi123.tistory.com/427

SSL 인증서 파일 정리 (.crt, .pem, .key, fullchain.pem 차이)

이 이후로 이어지는 내용임.

 

HTTPS 통신 흐름

[1단계: Handshake (인증 및 암호 교환)] ➡️ 비대칭키 방식 (느림)

 

1. 서버: .pem (공개키 인증서)을 클라이언트에게 던짐.
2. 클라이언트: 이 인증서가 진짜인지 확인(브라우저가 알아서 함). 진짜면 그 안에서 서버의 공개키를 꺼냄.
3. 암호 합의: 클라이언트가 '일회성 대칭키'를 만들기 위한 재료를 서버의 공개키로 암호화해서 보냄.
4. 서버: 자기만 가진 .key (개인키)로 열어서 그 재료를 확인함. 이제 둘만 아는 비밀번호(대칭키)가 완성됨.

-> 이유 : 나중에 서버 인증키 뺐겨도 옛날 통신 기록 못보도록

 

 

[2단계: Data Transfer (진짜 통신)] ➡️ 대칭키 방식 (존나 빠름)

• 합의된 일회성 대칭키로 매 호출마다 데이터를 암복호화함.
• 공개키 방식보다 훨씬 빨라서 대용량 데이터 전송에 최적임.

 

---

 Fullchain이랑 중간 인증서가 왜 필요함?

서버 설정할 때 보통 .pem에 인증서가 줄줄이 엮여 있음. 이걸 Fullchain이라고 함.

• 구조: [내 도메인 인증서] + [중간 인증서(Intermediate CA)]
• 이유:
  • 신뢰의 사슬: 브라우저는 전 세계에서 제일 유명한 '대장 인증 기관(Root CA)'만 믿음.
  • 중간 관리자: 근데 대장이 모든 사이트를 직접 검증하기 힘드니까 '중간 관리자(Intermediate CA)'를 고용해서 대신 인증서를 발급해주라고 권한을 줌.
  • 문제점: 브라우저는 중간 관리자들을 일일이 다 모름. 그래서 서버가 "나는 이 중간 관리자한테 인증받았고, 이 중간 관리자는 대장한테 인증받은 정식 업체야!"라고 족보 전체를 보여줘야 함.
• 결론: 중간 인증서가 빠지면 브라우저가 족보 확인이 안 돼서 "주의 요함"이나 "인증서 신뢰 불가" 에러 띄움.

 

---

요약 정리

• Handshake: 처음 한 번만 수행. 서버 신분 확인하고 비밀번호(대칭키) 정하는 단계. (비대칭키 사용)
• 통신: 정해진 대칭키로 미친듯이 데이터 주고받는 단계. (대칭키 사용)
• Fullchain: 브라우저한테 내 인증서가 대장 인증기관(Root)까지 연결되는 정식 족보임을 증명하기 위해 필요함.