HTTP vs HTTPS: 개념 및 차이점 완벽 정리

1. 기본 개념: 엽서와 금고

HTTP (HyperText Transfer Protocol)

• 정의: 인터넷에서 웹 브라우저와 웹 서버가 데이터를 주고받기 위한 규약입니다.
• 특징: 데이터를 평문(Clear Text)으로 전송합니다.
• 보안성: 매우 취약합니다.
• 비유: 내용이 훤히 보이는 투명 엽서를 보내는 것과 같습니다. 우체부(네트워크 관리자)나 중간 배달원(해커)이 내용을 모두 볼 수 있습니다.

HTTPS (HyperText Transfer Protocol Secure)

• 정의: HTTP에 보안(Secure) 계층(SSL/TLS)을 추가한 것입니다.
• 특징: 데이터를 암호화(Encryption)하여 전송합니다.
• 보안성: 강력합니다.
• 비유: 튼튼한 금고에 편지를 넣고 잠가서 보내는 것과 같습니다. 열쇠를 가진 수신자(서버)만 열어볼 수 있습니다.

2. 주요 차이점 비교

3. 인증서는 어떻게 확인하나요? (Chain of Trust)

브라우저는 서버가 제시한 인증서를 3단계로 엄격하게 검증합니다.

1단계: 신뢰할 수 있는 기관인가? (Root CA)

여러분의 PC(윈도우)와 브라우저에는 이미 "세계적으로 신뢰할 수 있는 인증기관(Root CA)" 목록이 내장되어 있습니다.

• 검증 방법: 서버가 보낸 인증서에 찍힌 도장이, 내 PC에 저장된 '진짜 기관의 도장'과 일치하는지 확인합니다.
• 직접 확인: 윈도우에서 실행(Win+R) → certmgr.msc → 신뢰할 수 있는 루트 인증 기관에서 목록을 볼 수 있습니다.

2단계: 유효기간과 폐기 여부

• 인증서가 만료되지 않았는지, 혹은 도난당해 폐기된 인증서인지 확인합니다.

3단계: 도메인 일치 여부 (Domain Verification)

• 가장 중요: 인증서가 아무리 진짜라도, 주인이 맞는지 확인해야 합니다.
• 상황: 해커가 자신의 사이트(hacker.com)에 대한 진짜 인증서를 발급받아서, bank.com인 척 사용하려고 합니다.
• 검증: 브라우저는 주소창의 URL(bank.com)과 인증서에 적힌 발급 대상(Issued to: hacker.com)을 비교합니다.
• 결과: 다르면 즉시 차단합니다. ("이 인증서는 유효하지만, bank.com의 것이 아닙니다!")

4. 내가 만든 인증서 vs 신뢰기관 인증서 (CA)

내가 만든 인증서 (Self-Signed)

• 가능 여부: 누구나 무료로 1분 만에 만들 수 있습니다.
• 문제점: "나를 믿어라"라고 스스로 주장하는 신분증입니다.
• 결과: 브라우저는 "알 수 없는 발급자"라며 빨간 경고창을 띄우고 접속을 차단하려 합니다.
• Any 대상 불가: 내 컴퓨터에만 강제로 등록할 순 있어도, 불특정 다수(Any)의 방문자에게 신뢰를 줄 순 없습니다.

신뢰기관 인증서 (Trusted CA)

• 비용 지불: Symantec, DigiCert, Let's Encrypt(무료) 등 공인된 기관에 비용을 내거나 심사를 받습니다.
• 엄격한 심사: 해당 도메인의 진짜 주인인지, 실존하는 회사인지 확인합니다.
• 보증 및 책임: 만약 인증서 내용이 틀렸거나(해킹 등), 잘못 발급되었다면 즉시 폐기(Revocation) 목록에 올려 전 세계 브라우저가 더 이상 믿지 않게 합니다.
• 결과: 브라우저 주소창에 "자물쇠" 아이콘이 당당하게 뜹니다.

5. 공개키(Public Key)와 비밀키(Private Key)

HTTPS가 안전한 이유는 두 가지 열쇠를 사용하기 때문입니다.

• 공개키 (Public Key):
  • 특징: 누구나 가질 수 있습니다. 인증서 안에 포함되어 브라우저에게 전달됩니다.
  • 역할: 데이터를 암호화(잠그기) 할 때 사용합니다. "이 상자를 잠가주세요!"
• 비밀키 (Private Key):
  • 특징: 서버만 몰래 가지고 있습니다. 절대 유출되면 안 됩니다.
  • 역할: 암호화된 데이터를 복호화(열기) 할 때 사용합니다. "서버만이 이 상자를 열 수 있습니다."

비유: 여러분(브라우저)은 서버가 준 열린 자물쇠(공개키)로 편지함을 잠가서 보냅니다. 이 자물쇠를 열 수 있는 열쇠(비밀키)는 서버만 가지고 있어서, 중간에 해커가 편지함을 가로채도 열어볼 수 없습니다.

Q. 공개키로도 암호를 풀 수 있나요? (전자 서명)

네, 가능합니다! 하지만 용도(방향)가 다릅니다.

• 비밀키로 잠그고 → 공개키로 열기: 이것은 "암호화"가 아니라 "전자 서명(Digital Signature)" 검증입니다.
• 원리: 비밀키는 서버만 가지고 있습니다. 만약 어떤 데이터가 "서버의 공개키로만 열린다"면, 그건 "서버가 비밀키로 잠갔다"는 확실한 증거가 됩니다.
• 사용처: 인증서 위조 방지. (브라우저는 인증기관(CA)의 공개키를 사용해, 인증서에 찍힌 CA의 도장(서명)을 확인합니다.)

Q. 누구나 인증서(공개키)를 가질 수 있는데, 해킹 위험은 없나요?

전혀 없습니다.

• 비대칭의 마법: 공개키는 "잠그는 기능"만 있습니다. (또는 서명 확인 기능)
• 비유: 서버가 길거리에 "열린 자물쇠(공개키)"를 뿌립니다. 해커가 이 자물쇠를 주워가도 아무 소용이 없습니다.
• 왜?: 이미 잠긴 상자(암호화된 데이터)를 "자물쇠 그 자체"로는 열 수 없기 때문입니다. 여는 건 오직 서버 금고에 있는 "열쇠(비밀키)"로만 가능합니다.
• 결론: 공개키는 신문 광고처럼 모두에게 공개되어야 합니다.

Q. 해커가 공개키를 훔쳐서 통신 내용을 엿볼 순 없나요?

안 됩니다. (이 부분이 가장 중요합니다!)

1. 방향성: 여러분(브라우저)이 데이터를 보낼 때는 공개키로 잠급니다(암호화).
2. 해커의 입장: 해커는 "잠긴 상자"와 "잠그는 자물쇠(공개키)"만 가지고 있습니다.
3. 불가능: 이미 잠긴 상자를 "잠그는 자물쇠"로 여는 것은 불가능합니다.
4. 유일한 열쇠: 이 상자를 열 수 있는 건, 서버 깊숙한 곳에 있는 비밀키뿐입니다.

요약: 공개키는 "넣을 수 있는 구멍(투입구)"일 뿐, "꺼낼 수 있는 문(출구)"이 아닙니다.

7. 세션키 (Session Key)는 뭔가요?

"그냥 공개키/비밀키로 계속 대화하면 안 되나요?"
안 됩니다. 너무 느리기 때문입니다.

• 공개키/비밀키 (비대칭키): 수학적으로 매우 복잡해서, 계산 속도가 느립니다. (트럭으로 금고 나르기)
• 세션키 (대칭키): 암호화/복호화 속도가 매우 빠릅니다. (오토바이 배달)

HTTPS의 현명한 전략 (하이브리드)

1. 만날 때만 (Handshake):
   • 느리지만 안전한 '공개키'를 사용해 '세션키'를 몰래 주고받습니다.
2. 대화할 때 (Data Transfer):
   • 이제 서로 공유한 빠른 '세션키'를 이용해 데이터를 순식간에 암호화해서 주고받습니다.
   • 매번 새로 생성: 이 세션키는 이번 연결(Session)에서만 쓰고 즉시 버립니다. 다음 접속 때는 또 새로운 키를 만듭니다. (그래서 해커가 과거의 키를 알아내도 미래의 대화는 안전합니다.)

8. API 호출도 HTTPS를 써야 하나요?

네, 무조건 써야 합니다.

• API란?: 앱이나 프로그램이 서버와 데이터를 주고받는 방식입니다.
• 착각: "화면이 안 보이니까 안전하겠지?"라고 생각하기 쉽습니다.
• 현실: API 데이터는 JSON 텍스트 파일로 전송됩니다. HTTP로 보내면 {"password": "123"} 같은 내용이 해커에게 그대로 노출됩니다.
• 결론: 모바일 앱, 백엔드 서버 통신 등 모든 데이터 전송에는 HTTPS가 필수입니다.