TLS, SSL, 인증서는 뭐가 다를까요?¶

주소창의 자물쇠는 단순히 "내용을 숨긴다" 는 뜻만이 아니라, 브라우저가 "지금 내가 접속한 도메인에 맞는 상대와 이야기 중인가?" 도 확인했다는 뜻에 더 가까워요.

HTTP와 HTTPS는 뭐가 다를까요?에서 우리는 HTTP 와 HTTPS 의 차이를 봤어요. HTTP는 브라우저와 서버가 주고받는 대화 규칙이고, HTTPS는 그 대화를 더 안전하게 감싸서 보내는 방식이라고 했죠.

근데요, 여기서 또 궁금해져요.

"HTTPS가 안전하다고 하는데, 그 보호된 통로는 대체 어떻게 만들어지는 걸까요?"

좋은 질문이에요. 브라우저는 그냥 "자, 이제부터 안전 모드예요" 하고 막 시작하지 않아요. TLS로 대화를 준비해가는 과정 안에서 상대 인증서도 확인하고, 서로 어떻게 보호해서 이야기할지도 맞춘 뒤, 그 안에서 HTTP를 시작해요.

여기서도 헷갈리기 쉬운 포인트가 하나 있어요. 앞에서 본 TCP의 연결 시작 인사와, 지금 볼 TLS의 보호 준비 과정은 비슷해 보여도 같은 일은 아니에요. TCP 쪽은 연결을 여는 준비, TLS 쪽은 그 연결 위에서 누구와 얼마나 안전하게 말할지 맞추는 준비에 더 가까워요.

바로 그때 등장하는 게 TLS, SSL, 그리고 인증서예요.

일단 비유로 시작해볼게요¶

은행 상담실에 들어간다고 상상해볼까요?

• 그냥 빈 방에 들어가서 돈 이야기를 하면 좀 불안하잖아요
• 먼저 직원이 진짜 은행 직원인지 확인해야 하고
• 그다음에 문이 닫힌 상담실로 들어가야 안심이 되죠

만약 이 확인 과정이 없다면 어떨까요?

겉모습만 비슷한 가짜 창구에 앉을 수도 있겠죠.

그래서 보통은 이런 순서가 필요해요.

1. 상대가 진짜인지 확인해요
2. 안전하게 이야기할 자리를 준비해요
3. 그다음에 본론을 말해요

HTTPS도 완전히 비슷해요.

• 인증서는 TLS 과정 안에서 서버가 "제가 이 도메인에 맞는 서버예요" 하고 보여주는 신분증 비슷한 거고
• TLS 는 그 인증과 합의를 포함해서 안전한 통로를 준비하는 규칙이고
• 그 안에서 HTTP 대화가 시작돼요

flowchart LR
    A[💻 브라우저] --> B[🌍 웹 서버]
    B --> C[📋 인증서 확인<br/><small>접속한 상대가 맞는지 검사</small>]
    C --> D[🔒 보호된 통로 준비<br/><small>TLS</small>]
    D --> E[📄 HTTP 요청/응답 시작]

이 그림에서 핵심은 간단해요. HTTPS는 처음부터 끝까지 한 덩어리가 아니라, 확인 → 준비 → 대화 순서로 이해하면 훨씬 쉬워요.

TLS, SSL, 인증서는 각각 뭐가 다를까요?¶

이름이 셋이나 나오니까 벌써 헷갈릴 수 있어요. 근데 역할을 나눠 보면 생각보다 단순해요.

• SSL 은 예전 이름에 가까워요
• TLS 는 지금 실제로 중심이 되는 현대 버전이라고 보면 돼요
• 인증서 는 그 과정에서 서버가 자기 신원을 보여줄 때 쓰는 증표예요

그러니까 이렇게 이해하면 편해요.

• SSL/TLS = 안전하게 이야기하는 규칙
• 인증서 = "제가 진짜 누구예요" 하고 증명하는 표식

여기서 중요한 반전 하나.

인증서가 곧 TLS 전체는 아니에요.

인증서는 어디까지나 "지금 접속한 상대가 누구인지 보여주는 단서" 에 가깝고, TLS는 그 확인을 바탕으로 보호된 통로를 준비하는 전체 과정에 더 가까워요.

근데 왜 굳이 이런 확인 과정이 필요할까요?¶

"그냥 암호처럼 가려서 보내기만 하면 되는 거 아닌가?" 싶죠? 사실은 아니에요. 누구랑 이야기하는지도 모르면, 안전하게 숨겨도 소용이 없을 수 있거든요.

1. 진짜 서버인지 먼저 확인해야 하니까요¶

여러분이 example.com에 접속했다고 해볼게요. 근데 중간에서 누가 그럴듯한 가짜 서버를 내밀면 어떨까요?

• 주소창에는 비슷하게 보이고
• 화면도 얼핏 비슷하게 보이고
• 여러분은 그대로 비밀번호를 넣을 수도 있겠죠

그래서 브라우저는 먼저 "이 서버가 내가 접속하려던 도메인에 맞는 상대가 맞나?" 를 확인하려고 해요.

2. 중간에서 내용을 엿보거나 바꾸면 안 되니까요¶

우리가 로그인 정보나 결제 정보 같은 걸 보낼 때는, 중간에서 누가 내용을 슬쩍 읽거나 바꾸면 안 되잖아요.

TLS는 이 대화가 가는 동안 내용을 덜 노출되게 하고, 중간에서 함부로 바뀌지 않게 돕는 역할도 해요.

3. 브라우저도 "이제부터 안전하게 말하자"는 합의가 필요하니까요¶

그냥 한쪽만 갑자기 안전 모드로 들어갈 수는 없어요.

• 브라우저도 준비돼 있어야 하고
• 서버도 준비돼 있어야 하고
• 둘이 어떤 방식으로 대화를 보호할지 먼저 맞춰야 하죠

그래서 HTTPS에서는 실제 HTTP 요청을 보내기 전에, 대화 준비 단계가 먼저 있다고 이해하는 게 중요해요.

그럼 브라우저는 실제로 어떤 순서로 확인할까요?¶

너무 깊게 들어가면 복잡해져요. 초반에는 이 정도 흐름만 잡아도 충분해요.

sequenceDiagram
    participant 브라우저 as 💻 브라우저
    participant 서버 as 🌍 웹 서버

    브라우저->>서버: "안녕하세요, 연결할게요"
    서버-->>브라우저: "이게 제 인증서예요"
    브라우저->>브라우저: 도메인 / 발급자 / 유효 기간 확인
    브라우저->>서버: "좋아요, 보호된 통로로 이야기해요"
    브라우저->>서버: HTTP 요청
    서버-->>브라우저: HTTP 응답

여기서 브라우저가 대충 보는 포인트는 이런 느낌이에요.

1. 지금 접속한 이름과 인증서의 이름이 맞는지
2. 브라우저가 신뢰하는 발급 기관으로 이어지는지
3. 유효 기간이 지나지 않았는지

이 기본 확인이 지나가야 브라우저는 "좋아, 이 서버와 보호된 통로를 준비하자" 쪽으로 넘어가요.

즉, 자물쇠가 뜬다는 건 단순히 "글자가 숨겨진다"보다, "브라우저가 확인 절차를 통과하고 나서 대화를 시작했다" 는 의미에 더 가까워요.

flowchart LR
    A[🌍 example.com 접속] --> B[📋 인증서 받기]
    B --> C{이름이 맞나?}
    C -->|예| D{만료되지 않았나?}
    C -->|아니오| X[⚠️ 경고]
    D -->|예| E{믿을 만한 발급자인가?}
    D -->|아니오| X
    E -->|예| F[🔒 보호된 통로 준비]
    E -->|아니오| X

이 그림도 너무 세세하게 볼 필요는 없어요. 브라우저가 하는 일은 결국 "상대 확인" 과 "대화 준비" 라고 보면 돼요.

그럼 진짜 인증서는 어떻게 생겼을까요?¶

실제로는 훨씬 더 많은 정보가 들어 있어요. 근데 초반에는 이런 식으로만 봐도 감이 확 와요.

여기서 보면:

• 이름은 누구용 인증서인지 보여주고
• 발급 기관은 누가 이 신원을 확인해줬는지 보여주고
• 유효 기간은 아직 쓸 수 있는 증표인지 알려줘요

브라우저는 이런 걸 바탕으로 "좋아, 내가 접속하려던 상대와 이야기해도 되겠다" 는 판단을 하는 거예요.

자, 정리해볼까요?¶

어때요? 이제 주소창 자물쇠를 볼 때, 그냥 막연한 보안 표시가 아니라 "브라우저가 먼저 확인하고 나서 안전하게 말하기 시작했구나" 하는 감각이 조금 생기죠?

우리는 이제 패킷에서 시작해서, 길을 찾고, 전달 방식을 보고, 이름을 주소로 바꾸고, 앱을 찾고, 대화 규칙을 보고, 마지막으로 그 대화가 어떻게 보호되는지 까지 왔어요.

다음 글 예고¶

지금까지 우리는 패킷, IP, TCP, DNS, HTTP, 그리고 TLS까지 아주 많은 개념을 배웠어요. 근데 이 수많은 기술이 대체 어떤 식으로 층층이 쌓여서 움직이는 걸까요?

"이 모든 네트워크 기술을 한눈에 보여주는 지도는 없을까요?"

다음 글에서는 네트워크의 전체 지도, "OSI 7계층과 TCP/IP 모델" 이야기를 해볼게요. 우리가 배운 것들이 각각 어디에 살고 있는지 같이 확인해 봐요.