HTTP란?

HTTP(HyperText Transfer Protocol)는 클라이언트(사용자 웹 브라우저)와 서버 간 데이터를 주고받기 위한 프로토콜이다.
인터넷에서 HTML, 이미지, 동영상 등의 데이터를 전송하는 데 주로 사용된다.

주요 특징

• 클라이언트-서버 모델
  • 요청(Request)을 보내면 서버가 응답(Response)을 반환한다.
  • 요청과 응답은 독립적인 한 번의 연결로 이루어진다.
• 비연결 지향적(Connectionless)
  • 요청/응답이 끝난 후 연결이 끊어져 서버 리소스를 절약한다.
  • 단점: 상태를 기억하지 않기 때문에 추가 요청 시 다시 연결해야 한다.
• 보안성 부족
  • 데이터를 평문(Plain Text)으로 전송하므로 도청이나 변조에 취약하다.
  • 개인 정보 유출 가능성이 크다.
• 포트 번호
  • 기본적으로 80번 포트를 사용한다.

HTTPS란?

HTTPS(HyperText Transfer Protocol Secure)는 HTTP에 보안 계층(TLS/SSL)을 추가하여 데이터를 암호화하고 안전한 통신을 가능하게 한 프로토콜이다.
현대 웹 환경에서는 필수적인 표준이다.

주요 특징

• 데이터 암호화
  • TLS/SSL 프로토콜을 사용해 데이터를 암호화하여 전송한다.
  • 도청 및 데이터 변조를 방지한다.
• 인증
  • SSL 인증서를 통해 서버의 신원을 검증한다.
  • 클라이언트는 신뢰할 수 있는 서버와 통신 중임을 확인할 수 있다.
• 무결성
  • 데이터가 전송 중 변조되거나 손상되지 않았음을 보장한다.
• 포트 번호
  • 기본적으로 443번 포트를 사용한다.

HTTP와 HTTPS의 주요 차이

구분	HTTP	HTTPS
보안성	평문으로 데이터 전송	TLS/SSL 암호화를 통해 안전한 데이터 전송
URL형식	http://로시작	https://로시작
인증과정	없음	인증서를 통한 서버 신원 검증
속도	상대적으로 빠름	초기 암호화 과정으로 약간 느림
포트 번호	80번	443번
사용 사례	비보안 웹사이트 (테스트용 등)	금융, 쇼핑, 로그인 등 민감 정보
신뢰성	서버 신원 보장 없음	SSL 인증서로 서버 신원 보장
구현 비용	별도의 인증서가 필요 없음	SSL 인증서 필요

HTTPS가 중요한 이유

• 데이터 보호

  • HTTPS는 데이터를 암호화하여 도청 및 중간자 공격(Man-in-the-Middle Attack)으로부터 사용자를 보호한다.
  • 사용자 비밀번호, 결제 정보 등 민감한 데이터를 안전하게 전송할 수 있다.

• 신뢰성

  • HTTPS를 사용하는 웹사이트는 SSL 인증서를 통해 신원을 검증받아 사용자에게 신뢰를 준다.
  • 주소창의 자물쇠 아이콘은 보안 연결임을 나타낸다.
  • 브라우저는 HTTPS를 지원하지 않는 웹사이트에 대해 "보안되지 않음" 경고를 표시하기도 한다.

• SEO(검색 엔진 최적화) 우대

  • Google을 비롯한 주요 검색 엔진은 HTTPS를 사용하는 웹사이트를 더 선호하며, 검색 순위에서 가산점을 부여한다.

• 법적 요구사항 충족

  • 개인정보보호법이나 GDPR과 같은 법규는 HTTPS를 통해 데이터를 암호화하여 전송하도록 요구하는 경우가 많다.
    • GDPR : 유럽연합(EU)에서 제정한 개인정보 보호 규정

HTTPS 구현 과정

• SSL 인증서 구매 및 설치

  • 신뢰할 수 있는 인증 기관(CA, Certificate Authority)에서 SSL 인증서를 발급 받는다.
    • 대표적인 CA: DigiCert, Let's Encrypt(무료 제공), GlobalSign 등.
  • 발급받은 인증서를 웹 서버(Apache, Nginx 등)에 설치한다.

• 서버 설정

  • 서버 설정 파일을 수정하여 HTTPS를 활성화한다.
  • HTTP 요청을 HTTPS로 리다이렉트하는 규칙을 추가한다.
  • 예) http://example.com로 접속하면 자동으로 https://example.com으로 이동.

• 테스트

  • SSL 인증서가 올바르게 설치되었는지 확인한다.
  • HTTPS 연결이 정상적으로 작동하는지 브라우저와 네트워크 도구로 점검한다.
  • SSL/TLS 취약성 점검 도구를 사용해 보안 강화를 검토한다.

사용 사례 비교

• HTTP가 적합한 경우

  • 테스트 환경이나 내부 네트워크에서 보안이 불필요한 경우.
  • 간단한 웹 애플리케이션(단, 민감한 사용자 데이터를 입력받지 않아야 함).

• HTTPS가 필수인 경우

  • 로그인, 결제, 개인 정보 입력이 필요한 모든 웹사이트.
  • 금융, 쇼핑몰, 의료 데이터 등 민감한 정보를 처리하는 서비스.
  • SEO(검색 엔진 최적화)와 사용자 신뢰 확보가 중요한 경우.

HTTP/HTTPS가 동작하는 과정

HTTP 요청/응답 과정

HTTP는 데이터를 평문(Plain Text)으로 주고받는 간단한 통신 프로토콜로 보안이 적용되지 않는다.

1. 클라이언트가 HTTP 요청을 서버로 전송
   • 사용자가 브라우저에 URL(예: http://example.com)을 입력하면 브라우저가 서버로 HTTP 요청(Request)을 보낸다.
   • 요청에는 HTTP 메서드(GET, POST, PUT, DELETE 등)와 헤더(Header), 본문(Body)이 포함된다.
   • 예시)

   GET /index.html HTTP/1.1
   Host: example.com

2. 서버는 요청 데이터를 처리하고 응답 생성
   • 서버는 클라이언트의 요청을 받아 처리하며 요청 내용에 따라 HTML, 이미지, 동영상 등의 데이터를 생성하여 응답(Response)을 든다.
   • 응답은 HTTP 헤더(Header)와 본문(Body)으로 구성된다.
   • 본문(Body)에는 요청된 콘텐츠(예: HTML 페이지)가 포함된다.
   • 예시)

   HTTP/1.1 200 OK
   Content-Type: text/html
   Content-Length: 137

3. 연결 종료 및 데이터 전송
   • 요청/응답이 완료되면 클라이언트와 서버 간의 연결이 종료된다.
   • 데이터는 암호화되지 않은 평문(Plain Text)으로 전송되므로 제3자가 네트워크 트래픽을 가로채면 내용을 쉽게 확인하거나 변조할 수 있다.

HTTPS 요청/응답 과정

HTTPS는 HTTP에 TLS/SSL 보안 계층을 추가하여 데이터를 안전하게 암호화하고 인증 및 무결성을 보장한다. HTTPS는 초기 단계에서 보안 연결을 설정하기 위한 핸드셰이크(Handshake) 과정을 거친다.

1. HTTPS 연결 초기화

   1-1. 클라이언트가 서버에 연결 요청

   • 사용자가 브라우저에 HTTPS URL(예: https://example.com)을 입력하면 브라우저는 서버의 443번 포트로 연결을 요청한다.

   1-2. 서버가 SSL 인증서 반환

   • 서버는 클라이언트 요청에 응답하여 SSL 인증서를 반환한다.
   • SSL 인증서에는 다음 정보가 포함된다.
     • 서버의 공개 키(Public Key)
     • 서버의 도메인 이름
     • 인증 기관(CA) 정보
     • 인증서 유효 기간 등

   1-3. 클라이언트가 인증서를 검증

   • 클라이언트는 서버가 보낸 인증서를 검증한다.
     • CA 신뢰성 확인: 인증서를 발급한 인증 기관(CA)이 신뢰할 수 있는지 확인한다.
     • 도메인 일치 여부: 인증서에 기록된 도메인이 사용자가 요청한 URL과 일치하는지 확인한다.
     • 유효 기간: 인증서가 만료되지 않았는지 확인한다.
   • 인증서가 유효하지 않으면 연결이 중단되고 보안 경고가 표시된다.

2. 세션 키 교환 (핸드셰이크 과정)

   2-1. 클라이언트가 암호화된 세션 키 생성

   • 클라이언트는 서버의 공개 키(Public Key)를 사용해 암호화된 세션 키(Session Key)를 생성한다.
   • 세션 키는 대칭 암호화(Symmetric Encryption)에 사용되며 클라이언트와 서버 간 데이터를 암호화/복호화하는 데 사용된다.

   2-2. 서버가 세션 키를 복호화

   • 서버는 자신의 개인 키(Private Key)를 사용해 클라이언트가 보낸 암호화된 세션 키를 복호화한다.
   • 클라이언트와 서버는 동일한 세션 키를 공유하게 된다.

3. 데이터 암호화 및 안전한 통신

   3-1. 암호화된 데이터 전송

   • 클라이언트와 서버는 공유된 세션 키를 사용하여 요청(Request) 및 응답(Response) 데이터를 암호화한다.
   • 데이터는 암호화된 채로 네트워크를 통해 전송되므로 제3자가 데이터를 가로채도 내용을 해독할 수 없다.

   3.2. 안전한 통신 채널 유지

   • 클라이언트와 서버 간의 데이터는 암호화된 채널을 통해 주고받으며, 제3자가 데이터를 가로채도 내용을 해독할 수 없다.

4. HTTPS 통신 후 연결 종료

   • HTTPS 통신이 완료되면 세션 키가 만료되거나 연결이 종료된다.
   • 클라이언트와 서버 간 새로운 요청이 발생하면 다시 핸드셰이크 과정을 수행하여 새로운 세션 키를 설정한다.

SSL/TLS에서 대칭키와 비대칭키의 역할

• 비대칭키 암호화 (Public Key / Private Key)
  • 사용 시점 : SSL/TLS 핸드셰이크 과정 (초기 연결 설정 단계).
  • 목적
    • 클라이언트와 서버 간에 대칭키(세션 키)를 안전하게 공유하기 위해 사용한다.
    • 클라이언트는 서버의 공개키(Public Key)를 사용해 대칭키(세션 키)를 암호화해 전송한다.
    • 서버는 자신의 개인키(Private Key)를 사용해 이 대칭키를 복호화한다.
  • 특징
    • 비대칭키는 암호화와 복호화에 서로 다른 키(공개키, 개인키)를 사용한다.
    • 암호화 속도가 느리지만, 보안성이 높다.
      
      
• 대칭키 암호화 (Session Key)
  • 사용 시점 : 핸드셰이크 완료 후 본격적인 데이터 통신 단계.
  • 목적
    • 클라이언트와 서버 간 데이터를 효율적으로 암호화 및 복호화.
    • 클라이언트와 서버가 공유한 대칭키를 사용해 데이터를 암호화/복호화한다.
  • 특징
    • 대칭키는 암호화와 복호화에 동일한 키를 사용한다.
    • 암호화 속도가 빠르며 실제 데이터 전송 단계에서 주로 사용된다.

SSL/TLS 암호화 과정 요약

1. 초기 핸드셰이크 단계 (비대칭키 사용)

   • 클라이언트는 서버의 공개키를 사용해 대칭키(세션 키)를 암호화해 전송한다.
   • 서버는 자신의 개인키로 암호화된 대칭키를 복호화하여 복원한다.
   • 클라이언트와 서버는 동일한 대칭키를 안전하게 공유한다.

2. 데이터 전송 단계 (대칭키 사용)

   • 클라이언트와 서버는 공유한 대칭키를 사용해 데이터를 암호화/복호화 한다.
   • 대칭 암호화를 통해 빠르고 효율적인 데이터 전송을 수행한다.

핸드셰이크 과정 요약 (TLS/SSL)

1. 인증서 교환 및 검증
   • 서버는 SSL 인증서를 제공하고 클라이언트는 이를 검증한다.
2. 세션 키 교환
   • 클라이언트는 공개 키 암호화를 통해 세션 키를 서버와 공유한다.
3. 데이터 암호화 통신 시작
   • 세션 키를 사용해 데이터를 암호화하여 안전한 통신을 수행한다.

결론

HTTP는 간단한 통신 프로토콜이지만 보안 취약점으로 인해 현대 웹 환경에서는 HTTPS로의 전환이 필수적이다.
HTTPS는 데이터를 안전하게 암호화하고 신뢰성과 무결성을 제공하며 사용자 데이터를 보호한다.
HTTPS로 전환하지 않으면 사용자 신뢰를 잃고 브라우저의 '보안되지 않음' 경고로 인해 서비스 품질에 영향을 미칠 수 있다.