[네트워크] HTTP와 HTTPS의 차이점

 

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면

HTTPS는 안전하게 데이터를 주고 받을 수 있습니다.

 

다만, HTTPS는 암호화/복호화 과정이 필요하기 때문에 요즘은 거의 큰 차이를 못느끼지만

HTTP보다 속도가 느리고 인증서를 발급하고 유지하기 위한 추가비용이 발생할 수 있습니다.

 

HTTP (Hyper Text Transfer Protocol)

인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다.

즉, 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.

• 서로 다른 시스템들 사이에 통신을 주고 받게 해주는 가장 기본적인 프로토콜이다.
• 인터넷에서 하이퍼텍스트를 교환하기위한 통신규약이다.
• 요청(Request)과 응답(Response)으로 구성되어 있으며, 일반적으로 80번 포트를 사용한다.
  • HTTP 서버가 80번 포트에서 요청을 기다리고 있으며,
  • 클라이언트는 80번 포트로 요청을 보내게 된다.

• HTTP는 텍스트 교환이므로 암호화가 되지 않은 평문 데이터를 전송한다. (보안 문제)

 

프로토콜 이란 ?
컴퓨터 내부에서 또는 컴퓨터 사이에 데이터 교환 방식을 정의하는 규칙 세계이다.
기기 간 통신은 교환되는 데이터의 형식에 대해 상호 합의를 요구하며 이런 형식을 정의하는 규칙의 집합이다.

 

HTTP의 구조

• HTTP의 구조는 TCP 기반으로 요청과 응답으로 구성되어있다.
• 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.
• Method, Path, Version, Headers, Body 등으로 구성된다.

HTTP의 특징

• 비연결성(Connectionless): 클라이언트의 요청이 올 때만 TCP 커넥션을 맺고 통신이 완료되면 끊는다.
• 무상태(Stateless): 서버는 클라이언트의 상태 정보를 저장하지 않는다. (쿠키 사용)

 

HTTP의 단점

HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기 때문에,

비밀번호나 주민등록번호 등 개인정보를 주고받으면 제3자가 정보를 조회할 수 있다는 보안부분의 취약점이 발생할 수 있다.

 

누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 문제가 생긴다.

• HTTP는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

 

어플리케이션 계층에 HTTP 메세지가 들어왔을 때 TCP 소켓을 통해서 링크 계층으로 내려가게 되면 IP 패킷은 도청 당할 위험이 있다. 평문이기 때문에 메시지의 의미를 파악할 수 있기 때문이다.

 

이러한 보안 문제를 해결하기 위해 HTTPS가 등장하게 되었다.

 

 

HTTPS (HyperText Transfer Protocol Secure)

인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약이다.

 

• HTTP에 데이터 암호화가 추가된 프로토콜이다. (보안 강화)
  • 네트워크 상에서 제 3자가 정보를 볼 수 없도록 암호화하여 전송한다.

 

• HTTPS 프로토콜은 SSL(보안 소켓 계층)을 이용해서 HTTP의 보안상 문제를 해결했다. (보안 취약점을 개선)
  
  • 소켓 통신에서 일반 텍스트를 이용하는 대신
  • 웹 상에서 정보를 암호화하는 TLS이나 SSL 프로토콜을 사용하여 데이터를 암호화한다.
  • HTTP는 원래 TCP와 직접 통신했지만,
  • HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신함으로써 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

 

• TCP/IP 포트인 443포트를 사용한다.
• 기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 사용한 인증을 제공하는 방식이다.
• 보호의 수준은 웹 브라우저의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 따라 달라진다.

 

SSL (Secure Socket Layer) - 보안 소켓 계층 이란?
서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고 서버 브라우저가 민감한 정보를 주고 받을 때도 도난당하는 것을 막아준다.

 

HTTPS가 필요한 이유?

• 클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공한다.
• 웹 페이지(HTML)는 텍스트이고, HTTP를 통해 이런 텍스트 정보를 교환하는 것이다.
• 이때 주고 받는 정보들은 네트워크를 통해 공유되고, 이런 정보들 중 개인정보 또는 보안상 민감한 정보인 경우, 보안상 큰 문제가 된다.
• 즉, 중간에 중요한 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것이다.

 

HTTPS의 원리

• 공개키 암호화 방식으로 텍스트를 암호화한다.
• 암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법이다.
  • 공개키 : 모두에게 공개, 공개키 저장소에 등록
  • 개인키(비공개키) : 개인에게만 공개, 클라이언트-서버 구조에서는 서버가 가지고 있는 키가 비공개키

 

• 클라이언트 → 서버
  • 사용자의 데이터를 공개키로 암호화한다.(공개키를 얻은 인증된 사용자)
  • 서버로 전송(데이터를 가로채도 개인키가 없으므로 복호화를 할 수 없다.)
  • 서버의 개인키를 통해 복호화하여 요청을 처리한다.

 

HTTPS의 장점

• 네트워크 상에서 열람, 수정이 불가능하므로 안전하다.

 

HTTPS의 단점

• HTTPS는 설치 및 인증서를 유지하는 데 추가 비용이 발생한다.
• 암호화하는 과정이 웹 서버에 부하를 준다.
• HTTP에 비해 속도가 느리다.
• 인터넷의 연결이 끊긴 경우 재인증 시간이 소요된다.
  • HTTP는 비연결형으로 웹페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있다.
  • HTTPS는 소켓(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷의 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 재인증이 필요하다.

 

HTTPS 통신 흐름 (HTTPS의 발급)

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.

 

2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.

 

CA 란?
Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업

 

3. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.

 

4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.

 

5. 클라이언트가 `main.html` 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.

 

CA 기업의 공개키는 브라우저가 이미 알고있다.
(세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)

 

6. 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다.

 

7. 클라이언트가 A서버와 HandShaking 과정에서 주고받은 난수를 조합하여 pre-master-key(대칭키) 를 생성한 뒤, A서버의 공개키로 해당 대칭키를 암호화하여 서버로 보냅니다.

 

8. A서버는 암호화된 대칭키를 자신의 개인키로 복호화 하여 클라이언트와 동일한 대칭키를 획득합니다.

 

9. 이후 클라이언트-서버사이의 통신을 할 때 주고받는 메세지는 이 pre-master-key(대칭키)를 이용하여 암호화, 복호화를 진행합니다.

 

HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우 등)

이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.

---

참고 자료

https://inuplace.tistory.com/1086

https://mangkyu.tistory.com/98

https://gyoogle.dev/blog/computer-science/network/HTTP%20&%20HTTPS.html

https://velog.io/@inyong_pang/HTTP-HTTPS

https://developer-ellen.tistory.com/189