SSL vs TLS

SSL/TLS는 대칭키의 '속도'와 비대칭키의 '안전성'을 결합한 현대 암호학의 결정체입니다. 우리가 웹사이트 주소창에서 보는 '자물쇠 아이콘(HTTPS)'의 정체가 바로 이것이죠.

---

1. SSL과 TLS, 뭐가 달라?

사실 같은 녀석이라고 보셔도 됩니다.

• SSL (Secure Sockets Layer): 넷스케이프에서 처음 만든 조상님입니다.
• TLS (Transport Layer Security): SSL의 취약점을 보완해서 새로 만든 표준 이름입니다.
• 결론: 지금은 다들 TLS를 쓰지만, 관습적으로 SSL/TLS라고 섞어서 부릅니다. (마치 '포크레인'이 브랜드명이지만 굴착기를 통칭하는 것과 비슷해요!)

---

2. 하이브리드 전략: 왜 섞어서 쓸까?

앞에서 배운 내용을 떠올려보세요.

• 비대칭키(RSA/ECC): 안전하지만 느리다.
• 대칭키(AES): 빠르지만 키 전달이 위험하다.

그래서 TLS는 이 둘을 기가 막히게 섞었습니다.

1. 처음 만날 때만 비대칭키를 써서 아주 짧게 대화하고, 서로만 아는 '대칭키'를 비밀리에 생성합니다.
2. 그다음부터는 그 대칭키로 실제 데이터를 빛의 속도로 주고받습니다.

---

3. TLS 핸드쉐이크 (Handshake) - 악수 과정

데이터를 주고받기 전, 브라우저와 서버가 "우리 어떤 방식으로 암호화할까?"라고 협상하는 과정입니다. 제로베이스에서 쉽게 풀어볼게요.

1. Client Hello (나 왔어!): 브라우저가 서버에 인사하며 "나 이런 암호화 방식(알고리즘) 지원해!"라고 목록을 보냅니다.
2. Server Hello (반가워!): 서버가 목록 중 하나를 고르고, 본인의 '인증서'를 건넵니다.
3. 인증서 검증: 브라우저는 이 인증서가 진짜인지 확인합니다. (이때 비대칭키가 사용됩니다.)
4. 비밀번호 공유: 브라우저가 무작위 숫자를 만들어 서버의 공개키로 잠가서 보냅니다. 이제 서버와 브라우저 둘만 아는 '비밀 대칭키'가 생겼습니다!
5. 데이터 전송: 이제부터 이 대칭키로 암호화해서 통신합니다.

---

4. 인증서(Certificate)는 왜 필요해?

비대칭키가 아무리 안전해도, "상대방이 진짜 그 사이트가 맞나?"라는 문제는 남습니다. 해커가 가짜 공개키를 주면서 "나 네이버야!"라고 속일 수 있거든요.

그래서 CA(Certificate Authority)라는 신뢰할 수 있는 기관이 등장합니다.

• 서버는 CA에게 "나 진짜 네이버 맞아"라고 인증을 받고 인증서를 발급받습니다.
• 브라우저는 이 인증서에 찍힌 CA의 '디지털 서명'을 보고 "아, 이건 진짜 네이버가 맞구나!"라고 믿고 통신을 시작하는 거죠.

---

📊 요약: SSL/TLS의 핵심

단계	사용하는 방식	목적
인증서 확인	비대칭키 (서명 검증)	상대방이 가짜가 아님을 확인
키 교환	비대칭키	대칭키(비밀번호)를 안전하게 전달
데이터 전송	대칭키 (AES)	실제 데이터를 빠르고 안전하게 주고받음

---

🔗 다음 질문 (공부의 연결고리)

이제 통신 구간은 안전해졌습니다. 그런데 로그인을 하고 나면, 서버는 매번 이 복잡한 핸드쉐이크를 다시 할까요? 아니면 사용자가 로그인했다는 사실을 어떻게 계속 기억하고 있을까요?

이 지점에서 나오는 키워드가 바로 [JWT]와 Session입니다.

SSL/TLS의 '하이브리드 전략'이 이해되셨나요? 이해되셨다면 이제 로그인 이후의 세계인 JWT로 넘어가 볼까요?