HTTP란

Hyper Text Transfer Protocol
www상에서 정보를 주고받는 프로토콜

 

클라이언트인 웹 브라우저가 서버에 HTTP를 통해 웹페이지나 이미지 정보를 요청하면, 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.

HTTP는 웹 브라우저Client와 서버Server간의 웹페이지 같은 자원을 주고 받을 때 쓰는 통신 규약이다.

HTTP는 텍스트 교환이라 (html페이지도 텍스트!) 누군가 네트워크에서 신호를 가로채 본다면 내용이 노출될 것이다.

이와같은 보안상의 문제를 해결해주는 프로토콜이 HTTPS이다.

 

 

 

" HTTP의 문제점 "

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

* 위와 같은 문제점은 암호화하지 않은 다른 프로토콜에도 공통되는 문제점이다.

 

 

1. TCP/IP 는 도청 가능한 네트워크...

 TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것 만으로도 도청할 수 있다. 따라서 암호화하여 통신해야한다.

보안 방법

1. 통신 자체를 암호화
SSL 또는 TLS라는 다른 프로토콜을 조합함으로써  HTTP의 통신 내용을 암호화할 수 있다.  SSL을 조합한 HTTP를 바로 HTTPS(HTTP over SSL)라고 부른다.

2. 콘텐츠를 암호화
말 그대로 HTTP를 사용해서 운반하는 내용인 HTTP 메세지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.  

 

 

 

2. 통신 상대를 확인하지 않기 때문에 위장이 가능...

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

 

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. —> DoS 공격을 방지할 수 없다.

 

보완 방법

윗 상자에서 말한 SSL 로 상대를 확인할 수 있다. 
SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누성 등의 위험성이 줄어들게 된다.
한 가지 이점을 더 꼽자면, 클라이언트는 이증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

 

 

 

3. 완전성을 증명할 수 없기 때문에 변조가 가능하다

여기서 완전성이란 정보의 정확성 을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

 

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

 


HTTPS

HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS

HTTPS는 SSL 의 껍질을 덮어쓴 HTTP 라고 할 수 있다. 즉, HTTPS 는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신 하게 된다. SSL 을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

 

HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

 

 

모든 웹 페이지에서 HTTPS를 사용해도 될까?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

 


Reference.

'🔥 > Network' 카테고리의 다른 글

[네트워크] OSI 7계층  (0) 2021.09.09
[네트워크] 웹 통신의 큰 흐름  (0) 2021.08.31
[네트워크] DNS round robin 방식  (0) 2021.08.25
[네트워크] TCP와 UDP 차이점  (0) 2021.08.10
[네트워크] GET, POST 방식의 차이점  (0) 2021.08.01

+ Recent posts