[네트워크] HTTP와 HTTPS 프로토콜

HTTP (Hyper Text Transfer Protocol)

• 웹 상에서 클라이언트와 서버 간에 요청(request)과 응답(response)으로 정보를 주고 받을 수 있는 프로토콜
• TCP와 UDP 사용, 80번 포트 사용
• 비연결(Connectionless)
  • 클라이언트가 서버에게 요청을 보내고 서버가 적절한 응답을 클라이언트에게 보내면 연결이 바로 끊김
  • 간단하기 때문에 자원이 적게 든다는 장점
  • 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결과 해제의 과정을 거쳐야해 오버헤드가 발생한다는 단점
• 무상태(Stateless)
  • 연결을 끊는 순간 클라이언트와 서버의 통신은 끊기며 상태 정보를 유지하지 않음
  • 서버는 클라이언트를 식별할 수 없어 매번 인증 과정 필요
• 단방향성
  • 클라이언트의 요청 한 개에 대해 한 개의 응답을 보내는 방식이기 때문에 서버가 먼저 응답하지 않음

 

HTTP의 문제점

1. 암호화되지 않은 평문 통신이기 때문에 도청 가능
2. 통신 상대를 확인하지 않기 때문에 위장 가능
3. 데이터 무결성(완전성)을 증명할 수 없기 때문에 변조 가능

 

 

HTTPS (Hyper Text Transfer Protocol Secure)

• HTTP에서 데이터 암호화, 인증, 무결성(완전성) 보호가 더해진 프로토콜
• 기본 TCP/IP 포트로 443번 포트 사용
• 소켓 통신에서 일반 텍스트를 이용하는 대신, 웹 상에서 정보를 암호화하는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화하여 사용
  • SSL(Secure Socket Layer)과 TLS(Transport Layer Security) 프로토콜의 주요 목표는 기밀성, 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것

 

HTTPS가 필요한 이유

  클라이언트인 웹 브라우저가 HTTP를 통해 서버에  웹 페이지 정보를 요청하면 서버는 해당 요청에 대한 응답으로 요구한 정보를 제공한다. 이때 웹 페이지(HTML)은 텍스트 정보가 되는데, 개인정보와 같이 민감한 정보가 포함된 텍스트 정보를 주고받을 때 제 3자가 네트워크 상에서 중간에 정보를 가로챈다면 보안상 큰 문제가 발생할 수 있다. 따라서, 중간에 정보가 가로채지더라도 해당 정보를 알아볼 수 없도록 암호화하는 방법인 HTTPS 프로토콜이 필요하다.

 

HTTPS의 원리 (SSL 통신 과정)

대칭키(세션키) 암호화와 비대칭키(공개키) 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 갖고 있다.
공개키만 사용할 경우 보안성은 좋지만 높은 CPU 사용량으로 인해 비용이 많이 든다. 따라서, 대칭키를 사용하여 메시지를 암호화하되 키를 공유할 때 유출 위험을 줄이기 위해 해당 대칭키를 공개키를 활용해 암호화한 뒤 공유하는 방식을 채택한다.

1. 클라이언트가 서버로 최초 연결 시도
2. 서버는 공개키(인증서)를 클라이언트로 전송
3. 클라이언트는 인증서의 유효성을 검사하고 세션키를 발급
4. 클라이언트는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터 전달 시 세션키로 암복호화 진행

 

 

HTTP와 HTTPS

  HTTP는 암호화 과정 없이 데이터를 전달하기 때문에 보안에 취약한 반면, HTTPS는 암호화로 네트워크 상에서 열람 및 수정이 불가능해 안전하다. 하지만 HTTPS는 암호화하는 과정이 웹 서버에 부하를 주고, 설치 및 인증서를 유지하는데 추가 비용이 발생하며, HTTP에 비해 느리다는 단점이 있다. 또한, HTTPS의 경우에는 소켓 자체에서 인증 과정이 있기 때문에 인터넷 연결이 끊기면 소켓도 끊어져 재인증하는 시간이 소요된다. 

결론적으로는 개인정보와 같이 민감한 데이터를 주고 받을 경우에는 HTTPS를 반드시 이용해야하고, 노출되어도 상관없는 단순한 정보 조회만을 처리한다면 HTTP를 이용해도 된다.