491. SMTPS, POP3S, IMAPS (보안 캡슐화)

핵심 인사이트 (3줄 요약)

본질: SMTPS(465번), POP3S(995번), IMAPS(993번)는 기존 이메일 프로토콜 자체를 뜯어고친 것이 아니라, 평문 텍스트 통신을 감싸는 **'전송 계층 보안(SSL/TLS) 터널'**을 덧씌워 데이터의 기밀성과 무결성을 확보한 캡슐화 프로토콜이다.

가치: 카페의 공용 와이파이 환경에서 해커가 패킷 스니핑(Sniffing) 툴(WireShark)을 돌려도 내 이메일 비밀번호와 본문 내용이 암호화된 쓰레기 값으로 보이게 만들어 기업 기밀 유출과 계정 탈취를 원천 차단한다.

융합: 초창기엔 아예 전용 포트를 새로 파서(Implicit TLS) 썼으나, 현재는 기존 포트(25, 110, 143)로 접속한 뒤 STARTTLS라는 명시적(Explicit) 명령어를 날려 그 즉시 통신 채널을 암호화 터널로 업그레이드하는 유연한 아키텍처로 진화 융합되었다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 이메일 통신의 3대장인 SMTP(발송), POP3(수신-다운로드), IMAP(수신-동기화) 프로토콜에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 암호화 계층을 씌워 보안을 강화한 확장 규격이다. 끝에 붙은 'S'는 Secure를 의미한다.
필요성: 1980년대에 만들어진 이메일 프로토콜들은 순진했다. 143번 포트로 서버에 접속해서 LOGIN my_id my_password 라고 키보드를 치면, 그 글자가 진짜로 100% 그대로 인터넷망을 타고 날아갔다. 악의적인 해커가 공유기 앞단에서 패킷을 낚아채면(Sniffing), 남의 이메일 비밀번호와 사내 기밀문서 첨부파일이 1초 만에 텍스트 파일로 술술 읽혔다. "편지봉투 안에 내용물만 암호화(PGP/SMIME)하는 건 너무 복잡하니, 아예 우체국으로 걸어가는 길(통신 채널) 전체를 까만 터널(SSL/TLS)로 덮어버리자!"라는 인프라적 보안의 절대적 요구가 이 'S' 삼형제를 탄생시켰다.
💡 비유: 일반 이메일 프로토콜(SMTP, POP3, IMAP)은 내용이 다 비치는 **'투명한 우편 봉투'**에 편지를 담아 배달하는 것과 같습니다. 지나가는 우체부나 나쁜 이웃이 마음만 먹으면 내용을 다 읽어볼 수 있습니다. SMTPS, POP3S, IMAPS는 편지를 **'절대 부서지지 않는 강철 금고(SSL/TLS 터널)'**에 넣고 자물쇠를 채워 배달하는 것입니다. 금고가 털리더라도, 열쇠(비밀키)가 없는 도둑은 안의 편지를 읽을 수 없습니다.
등장 배경:
1. 무선 인터넷(Wi-Fi)의 보급: 카페나 공항의 암호화되지 않은 공용 와이파이를 통해 이메일을 확인하는 모바일 인구가 폭발하면서 평문 탈취 위협이 극에 달했다.
2. SSL/TLS 생태계의 성숙: 웹 브라우저에서 HTTPS(443)가 대세가 되면서, 증명서(Certificate)와 비대칭키/대칭키 기반의 안전한 암호화 터널링 기술을 이메일 서버 데몬(Postfix, Dovecot)에도 쉽게 얹을 수 있게 되었다.

┌─────────────────────────────────────────────────────────────┐
│          평문 통신(Plain Text) vs 보안 통신(SSL/TLS 캡슐화) 아키텍처        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ [ ❌ 위험한 과거: 일반 POP3 (포트 110) ]                         │
│ 💻 (클라이언트) ─────────────── 와이파이 망 ───────────────▶ 🏢 (메일 서버) │
│ "USER alice"       👀 해커(WireShark)가 봄: "USER alice"     │
│ "PASS 1234!"       👀 해커가 가로챔: "아하! 비번은 1234! 털었다!" │
│                                                             │
│                                                             │
│ [ ✅ 안전한 현대: POP3S (포트 995) 또는 STARTTLS (포트 110) ]       │
│ 💻 (클라이언트) ════════════ SSL/TLS 암호화 터널 ════════════▶ 🏢 (메일 서버) │
│                                                             │
│ 1️⃣ (핸드셰이크) 서로 공개키를 교환하고 터널을 암호화할 '비밀 열쇠'를 만듦.   │
│ 2️⃣ (진짜 통신 시작) "USER alice", "PASS 1234!" 입력            │
│ 3️⃣ (터널 전송) ➔ ➔ ➔ #$%@!X*&^ ➔ ➔ ➔ (외계어로 변환되어 날아감)  │
│                                                             │
│ 👀 해커(WireShark)가 가로챔: "@#^&*!?! 무슨 말인지 하나도 모르겠네!"     │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이것이 전송 계층 보안의 정수다. 어플리케이션 계층(L7)의 메일 프로토콜(명령어 문법)은 단 한 글자도 바뀌지 않았다. 여전히 USER, PASS, RETR을 쓴다. 단지 그 밑의 전송 계층(L4 TCP)과 L7 사이에 TLS라는 '보안 장갑'을 한 겹 더 끼워 넣은 것뿐이다. 클라이언트 앱과 메일 서버가 최초 연결 시 TLS 핸드셰이크를 맺어 튼튼한 파이프(터널)를 완성하고 나면, 그 파이프 안으로 지나가는 이메일 명령어와 본문, 첨부파일 데이터는 모두 난수(Random) 쓰레기 값처럼 암호화되어 흐른다.

📢 섹션 요약 비유: 평문 통신이 엽서(Postcard)에 글을 써서 보내는 것이라면, 보안 캡슐화 통신은 엽서를 '특수 요원의 007가방' 안에 넣고 손목에 수갑을 채워 배달시키는 것과 같습니다. 내용 자체(이메일 문법)는 안 변했지만, 배달 수단(터널)이 철통 방어 모드로 바뀐 것입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 보안 이메일 포트 번호 (기술사 암기 0순위)

원래 이메일 통신은 포트가 3개뿐이었으나, 암호화용 전용 포트가 생기면서 인프라 담당자들이 방화벽에 뚫어줘야 할 포트가 배로 늘어났다.

프로토콜	역할	기존 평문 포트 (Insecure)	암호화 캡슐화 포트 (Secure)
SMTP / SMTPS	발송 및 중계 (Push)	TCP 25 (또는 587)	TCP 465 (SMTPS)
POP3 / POP3S	다운로드 수신 (Pull)	TCP 110	TCP 995 (POP3S)
IMAP / IMAPS	동기화 수신 (Sync)	TCP 143	TCP 993 (IMAPS)

2. 암호화 융합의 두 가지 사상: Implicit vs Explicit (STARTTLS)

보안 포트를 새로 파는 것은 방화벽 관리자에게 고역이었다. 그래서 이메일 보안 아키텍처는 역사적으로 두 파벌로 나뉘어 싸웠다.

암시적 TLS (Implicit TLS) - 구형 방식: "아예 포트를 2개 파자!" 일반 110번 포트로 오면 평문 통신, 995번(POP3S) 전용 포트로 접속하는 놈은 묻지도 따지지도 않고 무조건 처음부터 SSL 터널을 열어주는 억지 강제 방식이다. 포트 낭비가 심하다.
명시적 TLS (Explicit TLS / STARTTLS) - 모던 방식: "포트는 옛날 포트(25, 110, 143) 그대로 딱 1개만 쓰자!" 일단 평문으로 인사(Hello)를 나눈 뒤, 클라이언트가 STARTTLS 라는 명령어를 서버에 쏘면, 그 순간 평문 통신이 암호화 채널(TLS)로 스위칭(Upgrade)된다. 하나의 포트로 평문 고객과 암호화 고객을 유연하게 다 받을 수 있는 현대 통신 최적화의 꽃이다.
📢 섹션 요약 비유: 암시적 TLS는 입구가 2개인 식당입니다. VIP(암호화) 손님은 아예 옆에 있는 빨간 문(포트 995)으로 들어오라고 하는 거죠. 명시적 TLS(STARTTLS)는 식당 문(포트 110)이 하나뿐인데, 평범하게 들어온 손님이 "저 VIP입니다(STARTTLS)"라고 여권(인증서)을 보여주면 그 자리에서 즉시 VIP 커튼(암호화 터널)을 쳐주는 유연한 방식입니다.

Ⅲ. 융합 비교 및 다각도 분석

딜레마: 서버-서버 간 중계(SMTP Relay)에서의 암호화 취약성

내 스마트폰 ➔ 네이버 서버 (보안 구간) ➔ 구글 서버 (보안 구간?) ➔ 친구 폰 (보안 구간)

이메일은 발신자에서 수신자 폰으로 다이렉트로 날아가지 않는다. 네이버 메일 서버(MTA)가 구글 메일 서버(MTA)로 편지를 중계(Relay, 25번 포트)할 때, 양쪽 서버 중 하나라도 STARTTLS를 지원하지 않으면 둘은 암호화 터널을 포기하고 평문(Plain text)으로 데이터를 쏘고 받는다(Fallback/Downgrade). 즉, 내 폰에서 아무리 SMTPS 465번으로 안전하게 쐈어도, 바다 건너 인터넷망을 지날 땐 벌거벗은 채로 날아가는 반쪽짜리 보안의 굴레다. 이를 막기 위해 MTA 간 무조건 TLS 통신을 강제하는 MTA-STS (Strict Transport Security) 표준이 최근 융합되어 도입되고 있다.

과목 융합 관점

보안 (PGP/S-MIME vs TLS Tunneling): 이메일 보안의 양대 산맥이다. SMTPS/IMAPS(TLS 터널링)는 '길(도로)'을 지키는 보안이다. 길이 안전해도 메일이 구글 서버(MTA) 하드디스크에 도착해 저장될 때는 평문 파일로 툭 떨어진다. 만약 구글 직원이 맘만 먹으면 서버를 뒤져서 내 메일을 읽어볼 수 있다. 반면 PGP나 S-MIME (End-to-End Encryption, 종단간 암호화)는 편지 내용 자체를 외계어로 써서 봉투에 넣는 것이다. 서버 관리자조차 내용을 읽을 수 없는 궁극의 기밀성이지만 설정이 너무 어려워 일반인은 쓰지 못한다.
인프라/인증서 (PKI 아키텍처): SMTPS와 IMAPS가 작동하려면 메일 서버에 Verisign이나 Let's Encrypt 같은 신뢰할 수 있는 기관(CA)이 발급한 X.509 SSL 인증서가 꽂혀 있어야 한다. 만약 회사 관리자가 돈 아끼려고 사설 인증서(Self-Signed)를 대충 만들어 꽂으면, 아웃룩(Outlook)이나 아이폰 앱을 켤 때마다 "이 서버의 보안 인증서를 신뢰할 수 없습니다. 계속하시겠습니까?"라는 뻘건색 무서운 팝업이 떠서 전 직원들의 항의 전화가 빗발치는 운영(Ops)의 헬게이트가 열린다.
📢 섹션 요약 비유: TLS 터널링(SMTPS)은 현금 수송차(터널)에 돈을 싣고 가는 겁니다. 길도둑은 막을 수 있지만, 은행 금고(서버)에 돈을 부려놓고 나면 은행원들은 그 돈을 볼 수 있죠. 반면 PGP(종단간 암호화)는 돈 자체를 아무도 못 여는 투명 금고에 한 번 더 넣는 겁니다. 길도둑은 물론이고 은행원조차 내가 얼마를 입금했는지 절대 들여다볼 수 없습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 구형 사내 메일 서버의 평문 스니핑 사고: 중소기업 영업팀장이 카페 와이파이로 회사 메일(포트 143 IMAP)을 확인했다. 같은 카페에 있던 경쟁사 직원이 스니핑 툴로 아이디/비번을 1초 만에 탈취했고, 밤에 그 계정으로 회사에 접속해 단가표 기밀을 싹 다 퍼갔다.
- 판단: 최악의 인프라 태만이다. 실무 아키텍트는 아무리 폐쇄된 사내망 메일 서버(Postfix, Exchange)라 할지라도, 외부망(스마트폰)에서 붙을 수 있는 구조라면 방화벽에서 110(POP3), 143(IMAP), 25(SMTP) 평문 포트를 모조리 Block(차단) 해야 한다. 오직 993(IMAPS)과 995(POP3S), 465(SMTPS) 만 열어두고, 클라이언트 앱에서 "SSL 필요" 체크박스를 강제하는 제로 트러스트(Zero Trust) 아키텍처로 뜯어고쳐야 생존할 수 있다.
시나리오 — STARTTLS 지원 버그와 다운그레이드 공격(Downgrade Attack): 이메일 서버에 STARTTLS(명시적 암호화)를 세팅했다. 그런데 악질 해커가 네트워크 중간에 서서 서버가 보내는 "나 STARTTLS 지원해!"라는 패킷을 가로채서 몰래 지워버렸다(Man-in-the-Middle Attack). 클라이언트(Outlook)는 "아, 이 서버는 암호화 지원 안 하는 구형이구나" 하고 속아 넘어가서, 평문으로 아이디와 비밀번호를 쏘아버렸다.
- 판단: STARTTLS의 치명적인 취약점인 '다운그레이드 공격(STRIP-TLS)'이다. 포트 하나(110, 143)로 평문과 암호화를 동시에 받으려다 터진 맹점이다. 이를 막으려면 메일 클라이언트 설정에서 "암호화 연결(TLS)이 실패하면 평문으로 재시도" 옵션을 해제하고, **"반드시 암호화 연결만 사용"**으로 박아두어, 만약 해커가 암호화 협상을 훼방 놓으면 접속 자체가 에러를 내며 튕기도록(Fail-Safe) 강제해야 한다.

  ┌─────────────────────────────────────────────────────────────┐
  │         실무 아키텍처: STARTTLS (명시적 암호화) 업그레이드 트랜잭션        │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [ 포트 143 (IMAP) 접속 시 내부 통신 흐름 ]                        │
  │                                                             │
  │ 💻 (아웃룩)                                       🏢 (IMAP 서버) │
  │    │                                                   │      │
  │    │ 1. 안녕! (평문)                                     │      │
  │    │──────────────────────────────────────────────────▶│      │
  │    │ 2. 나 이런 거 할 줄 알아. STARTTLS도 지원해 (평문)         │      │
  │    │◀──────────────────────────────────────────────────│      │
  │    │                                                   │      │
  │    │ 3. 그래? 그럼 우리 지금부터 암호화 터널로 업그레이드하자!         │      │
  │    │    "STARTTLS" 명령어 전송 (평문)                       │      │
  │    │──────────────────────────────────────────────────▶│      │
  │    │ 4. OK! 지금부터 TLS 핸드셰이크 시작한다.                 │      │
  │    │◀──────────────────────────────────────────────────│      │
  │    │                                                   │      │
  │  ==================== [ 🌟 터널링 스위치 ON! ] ================= │
  │    │                                                   │      │
  │    │ 5. (인증서 교환 및 암호화 키 생성 완료)                   │      │
  │    │ 6. "LOGIN alice 1234" (🔥 100% 암호화된 쓰레기 텍스트로 날아감) │
  │    │◀══════════════════════════════════════════════════▶│      │
  │                                                             │
  │ 🌟 결론: 옛날 143번 포트를 그대로 쓰면서도, 방화벽을 새로 안 뚫고도 통신의   │
  │ 중간부터 암호화 모드로 둔갑(Upgrade)하는 가장 유연하고 똑똑한 아키텍처다.    │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] HTTP는 80번(평문)과 443번(HTTPS)이 완벽히 두 개의 포트로 나뉘어 작동하지만, 이메일 통신은 방화벽 관리의 편의를 위해 하나의 포트 안에서 평문 ➔ 암호화로 스위칭(Switching)하는 STARTTLS라는 독특한 진화 트리를 탔다. 3번 과정 전까지는 와이파이 해커가 글씨를 볼 수 있지만, 가장 중요한 6번 아이디/비번 전송 직전에 완벽히 까만 커튼(터널)을 쳐버리기 때문에 해커는 닭 쫓던 개가 된다. 현재 전 세계 이메일 생태계의 90% 이상이 이 STARTTLS 방식을 기본 탑재하고 있다.

도입 체크리스트

기술적: SSL v3.0, TLS 1.0/1.1 같은 10년 된 구형 암호화 알고리즘은 이미 POODLE, BEAST 같은 해킹 기법에 완전히 박살 나 뚫려있다. 메일 서버 데몬(Nginx/HAProxy/Postfix) 설정 파일에서 오래된 Ciphers(암호화 알고리즘)를 싹 다 비활성화시키고, 오직 무결점이 검증된 TLS 1.2 및 TLS 1.3 규격만으로 터널을 맺도록 강제(Hardening)하고 있는가?
운영·보안적: 사설망(인트라넷) 내부에서 도는 스캐너나 프린터 복합기가 scan@company.com으로 스캔본을 쏴줄 때(SMTP Relay), 복합기 펌웨어가 너무 낡아서 STARTTLS 465번을 지원 못 하고 에러를 뿜는 경우가 있다. 이때 보안 정책을 깰 수 없으므로, 내부 망망 전용으로 IP를 묶은(ACL) 별도의 포트 25 릴레이 우회망(Stunnel/Proxy) 아키텍처 구멍을 안전하게 하나 파두었는가?

안티패턴

포트 465와 587의 혼동: 이메일 세팅을 할 때 SMTP 보안 포트로 465와 587을 헷갈려 쓰는 끔찍한 삽질. **포트 465(SMTPS)**는 태어날 때부터 묻지도 따지지도 않고 암호화 터널을 무조건 열어버리는(Implicit) 무식한 전용 포트다. 반면 **포트 587(MSA - Mail Submission Agent)**은 클라이언트(내 폰)가 서버에 메일을 발송하러 갈 때 쓰는 최신 표준 포트로, 일단 평문으로 붙은 뒤 STARTTLS로 우아하게 암호화를 시작(Explicit)하는 포트다. 이 둘의 통신 사상(아키텍처)을 모르고 방화벽 포트 맵핑을 꼬아버리면 메일 발송 무한 로딩 지옥에 빠지게 된다.
📢 섹션 요약 비유: 포트 465(Implicit)는 비밀 요원만 타는 **'방탄 전용 엘리베이터'**입니다. 타자마자 문이 철컹 닫히고 암호화되죠. 반면 포트 587(Explicit STARTTLS)은 동네 꼬마도 타고 요원도 타는 **'일반 엘리베이터'**인데, 요원이 타서 "코드 블루(STARTTLS)!"라고 소리치면 그 순간 엘리베이터 벽이 촹촹촹 닫히며 방탄 모드로 변신하는 최첨단 엘리베이터입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	일반 이메일 프로토콜 (SMTP, POP3)	보안 캡슐화 프로토콜 (S 시리즈, STARTTLS)	개선 효과
정량	공용망 접속 시 계정 정보 100% 노출	TLS 터널 캡슐화로 스니핑 공격 차단	이메일 패스워드 탈취(Credential Theft) 사고 0건(Zero) 보장
정량	악성코드에 의한 중간자 패킷 변조	해시(MAC) 기반 무결성 검증 추가	전송 중 첨부파일(PDF, 엑셀)의 Man-in-the-Middle 악성 변조 차단
정성	"누가 내 메일 읽는 거 아냐?" 불안감	"자물쇠 자물쇠 아이콘" 든든한 신뢰감	글로벌 비즈니스 이메일(B2B) 컴플라이언스(보안 규제) 완벽 통과

미래 전망

MTA-STS (Strict Transport Security) 강제화: 구글과 마이크로소프트는 메일 서버(MTA) 간에 평문(Downgrade)으로 통신하는 꼴을 더 이상 봐주지 않기로 했다. 서버 DNS에 "우리 회사는 무조건 TLS 암호화로만 통신해. 평문으로 찌르면 메일 수신 자체를 튕겨낼 거야!"라고 MTA-STS 정책을 박아 넣는 것이 글로벌 대기업들의 필수 셋업 가이드로 자리 잡았다. 10년 뒤면 포트 25 평문 중계는 지구상에서 완전히 격리 멸종될 것이다.
양자 내성 암호(PQC)로의 교체: 현재 이메일의 SSL/TLS 터널은 RSA 비대칭 키 교환 알고리즘으로 자물쇠를 짠다. 5년 뒤 큐빗 수천 개짜리 진짜 양자 컴퓨터(Quantum Computer)가 나오면 이 자물쇠는 1분 만에 톱으로 썰려 박살 난다. 해커들은 지금 빼낸 암호화 이메일 패킷(쓰레기 텍스트)을 버리지 않고 하드디스크에 쌓아두고 있다(Store Now, Decrypt Later). 이를 방어하기 위해 TLS 1.3 터널의 내부 핸드셰이크 공식을 통째로 갈아엎는 포스트 양자 암호(Post-Quantum Cryptography) 터널링 규격(NIST)의 대대적인 펌웨어 이식 공사가 전 세계 메일 서버에서 벌어질 것이다.

참고 표준

RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. (이메일 평문 통신은 쓰레기이며, 무조건 TLS(포트 465, 993, 995) 캡슐화를 써야 한다는 IETF의 강력한 선언문)
RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security (STARTTLS 명령어의 규격화)

"편지의 내용은 숨길 수 없어도, 편지가 다니는 도로는 숨길 수 있다." SMTPS와 IMAPS는 이메일이라는, 태생부터 철저히 텍스트와 오픈(Open) 마인드로 짜인 80년대 프로토콜이 2020년대의 사이버 전쟁터에서 살아남기 위해 선택한 가장 현실적인 타협안이자 생존 장갑(Armor)이다. 응용(L7) 명령어는 한 줄도 건드리지 않고, 그 아래의 전송망(L4)만 슬쩍 암호화 터널로 교체해 낸 이 유연한 캡슐화 아키텍처 덕분에 인류는 낡은 이메일 서버를 다 때려 부수지 않고도 안전하게 수백조 원의 글로벌 비즈니스 계약서를 스마트폰으로 주고받을 수 있게 되었다.

📢 섹션 요약 비유: 이메일 보안 프로토콜 3대장(SMTPS, POP3S, IMAPS)은 낡고 비가 새는 종이 상자(평문 통신)에 비싼 택배를 넣고 그 겉면에 칭칭 감아버린 무적의 **'뽁뽁이 뽁뽁이 방수 테이프(SSL/TLS)'**입니다. 종이 상자 자체는 약하지만, 우주 최강의 테이프가 길바닥의 모든 도둑과 비바람으로부터 상자 안의 물건을 100% 안전하게 고객의 문 앞까지 수송해 줍니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
SSL / TLS 터널링	SMTPS 등 보안 이메일의 핵심 뼈대 엔진. 클라이언트와 서버가 RSA/ECDHE로 암호키를 교환해, 중간의 해커를 까막눈으로 만들어버리는 전송 계층의 절대 방패다.
STARTTLS (명시적 암호화)	구형 25번이나 143번 평문 포트에 접속했다가, 명령어를 한 대 때리면 즉시 무적의 TLS 터널로 스위칭(Upgrade)하는 가장 유연한 모던 암호화 융합 기술이다.
PGP (Pretty Good Privacy)	통신 터널(도로)만 지키는 SMTPS의 약점(서버엔 평문으로 저장됨)을 조롱하며, 아예 편지 내용물 자체를 암호화해서 서버 관리자도 못 읽게 만드는 종단간(E2E) 암호화다.
MTA-STS (메일 보안 전송 강제)	내 서버와 구글 서버(MTA ↔ MTA)끼리 릴레이로 메일을 넘길 때, 구형 서버 핑계를 대고 평문으로 다운그레이드 통신을 하려는 꼼수를 원천 차단하고 TLS를 강제하는 최신 표준이다.
인증서 (X.509 Certificate)	해커가 와이파이 공유기 앞에서 가짜 네이버 메일 서버로 둔갑(MITM 공격)하는 것을 막기 위해, 메일 서버가 터널을 뚫을 때 클라이언트 앱에 내밀어야 하는 신분증이다.

👶 어린이를 위한 3줄 비유 설명

일반 이메일(POP3, IMAP)은 투명한 유리 파이프를 통해 편지를 보내는 거예요. 그래서 나쁜 해커가 파이프 옆에 서서 내 비밀번호를 다 읽을 수 있어요!
이 위험을 막기 위해 파이프 겉면에 **'절대 속이 안 보이는 까만색 튼튼한 테이프(SSL/TLS)'**를 칭칭 감아버린 것이 바로 POP3S, IMAPS 같은 보안 이메일이에요.
이제 해커가 파이프를 아무리 쳐다봐도 까만 테이프 때문에 내 비밀번호는 1도 보이지 않아서, 안심하고 밖에서 이메일을 열어볼 수 있게 된 거랍니다!