[CS] HTTPS와 TLS Handshake 이해하기

우리가 매일 주소창에 치는 https://에서 'S'는 단순한 문자가 아니라, 데이터가 암호화되어 안전하게 전송되고 있음을 의미한다.

만약 HTTP를 그대로 사용한다면, 카페의 공용 와이파이 등을 통해 누군가 내 비밀번호나 개인정보를 그대로 훔쳐볼 수 있다.

이를 방지하기 위해 브라우저와 서버가 통신을 시작하기 전, 서로의 신원을 확인하고 암호화 방식을 합의하는 과정이 바로 TLS Handshake다.

TLS Handshake: 신뢰를 쌓는 3단계 대화

• TLS(Transport Layer Security) 핸드쉐이크는 복잡해 보이지만, 본질은 "너 믿을 만한 사람이야?"라고 묻고 "이 열쇠로 우리끼리만 암호화해서 얘기하자"라고 약속하는 과정이다.

• Client Hello

  • 브라우저가 서버에 "나 접속하고 싶어.
  • 내가 지원하는 암호화 방식은 이런 것들이 있어"라고 인사를 건넨다.

• Server Hello & Certificate

  • 서버는 암호화 방식을 하나 선택하고, 자신의 신분을 증명하는 CA 인증서를 브라우저에 보낸다.

• Key Exchange

  • 브라우저는 받은 인증서가 진짜인지 확인한 후, 앞으로 데이터를 암호화할 때 사용할 '대칭키'를 안전하게 전달한다.

공개키와 대칭키: 보안과 성능의 조화

보안은 철저하게, 속도는 빠르게 유지하는 영리한 설계다.

• TLS는 보안성을 위해 비대칭키(공개키) 방식을 사용하고, 실제 통신의 속도를 위해 대칭키 방식을 혼합하여 사용한다.

• 비대칭키

  • 처음 서로를 확인하고 대칭키를 안전하게 공유할 때만 사용한다.
  • (자물쇠는 누구나 열 수 있지만, 열쇠는 주인만 가진 방식)

• 대칭키

  • 연결이 확정된 후, 실제 데이터를 주고받을 때 사용한다.
  • (암호화 속도가 매우 빠르다)

프론트엔드 개발에서 보안을 알아야 하는 이유

안전한 통신 위에 세워진 서비스만이 사용자의 신뢰를 얻을 수 있다.

• 웹 보안은 백엔드만의 영역이 아니다.
• 우리가 어제 공부한 TTFB(Time to First Byte) 지표에는 이 TLS 핸드쉐이크 과정이 포함되어 있다.
• 핸드쉐이크가 너무 오래 걸리면 사용자 경험은 저하된다. 따라서 최신 프로토콜인 HTTP/3 등을 통해 이 과정을 얼마나 단축할 수 있는지 고민하는 것은 프론트엔드 성능 최적화의 중요한 한 축이다.

네트워크의 흐름을 이해하는 것은 단순히 지식을 쌓는 것을 넘어, 더 견고하고 빠른 서비스를 만드는 밑거름이 된다.

네트워크 기초와 최근 깊이 있게 파고든 브라우저의 동작 원리를 결합하여, 성능과 보안이라는 두 마리 토끼를 모두 잡는 개발자로 성장해 나가고자 한다.