[네트워크] HTTP와 HTTPS

HTTP와 HTTPS

HTTP (HyperText Transfer Protocol)

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

이는 텍스트 교환이기 때문에 누군가가 네트워크에서 신호를 가로채면 내용이 노출된다는 보안적인 문제가 존재한다.

비연결성 프로토콜이며 REQUEST에 대한 RESPONSE만 전달되며 연결을 유지하지 않는다.(Hyper Text를 주고 받기 위해 만들어져서 따로 연결을 할 필요가 없음)

HTTPS (HyperText Transfer Protocol Secure)

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

HTTPS는 텍스트를 암호화한다. (공개키 암호키 방식을 사용)

 

HTTP의 문제점

- HTTP는 평문 통신이기 때문에 도청이 가능하다.

- 통신 상대를 확인하지 않아 위장이 가능하다.

- 완전성을 증명할 수 없어서 변조가 가능하다.

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

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

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있으며 패킷을 수집하는 것만으로도 도청이 가능하다.

따라서 평문으로 통신하는 경우 메시지의 의미를 파악할 수 있기 대문에 암호화해 통신해야 한다.

보안 방법

- 통신 자체를 암호화 : SSL(Source Socket Layer)이나 TLS(Transport Layer Security) 라는 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 하는 것.

- 콘텐츠를 암호화 : HTTP를 사용해 운반하는 내용인 HTTP 메시지에 포함되는 콘텐츠를 함호화 하는 것. 암호화해서 전송하면 수신측에서 그를 해독하는 처리가 필요하다.

통신 상대를 확인하지 않아 위장이 가능

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

이러한 특징은 여러 문제점을 유발한다.

- 리퀘스트를 보낸 곳의 웹서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 확인 불가

- 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 확인 불가

- 통신하는 상대가 접근이 허가된 상대인지 확인 불가

- 어디에서 누가 리퀘스트한지 확인 불가

- 의미없는 리퀘스트도 수신

보안 방법

SSL로 상대를 확인할 수 있다, 이는 상대 확인의 수단으로 증명서를 제공하고 있는데 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이를 이용해 통신상대가 내가 통신하고자하는 서버 임을 나타내고 이용자는 개인정보유출 등의 위험성이 줄어든다.

완전성을 증명할 수 없어 변조가 가능

완전성 = 정보의 정확성. 서버나 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수 없는 것이다.

따라서 요청이나 응답이 발신 된 후 상대가 수신하기 까지의 사이에 누군가가 그를 변조하더라도 이를 알 수 없다. 이처럼 공격자가 도중에 요청이나 응답을 빼앗아 변조하는 공격을 중간자 공격 (Man-in-the-Middle)이라고 한다.

보안 방법

확실히 방지하기 위해서는 HTTPS를 사용해야한다, SSL에서 인증, 암호화 등의 기능을 제공하고 있기 때문이다.

 

HTTPS

이는 SSL을 덮어쓴 HTTP라고 할 수 있다. 즉 HTTP 통신하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체하는 것일 뿐이다.

HTTP는 TCP와 직접 통신하는 반면 HTTPS에서의 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. 이를 통해 암호화, 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다.

하이브리드 암호 시스템: 공통키를 공개키 암호화 방식으로 교환한 다음 그 뒤로의 통신은 공통키 암호를 사용하는 방식.

모든 웹페이지에서 HTTPS를 사용하진 않는 이유

암호화 통신은 평문통신에 비해 CPU나 메모리 등의 자원을 더 많이 요구함.

따라서 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 감소하게 됨.

그러나 최근엔 하드웨어가 발달하여 HTTPS를 사용해도 속도 저하가 거의 일어나지 않아 현재는 대부분의 웹 페이지에 HTTPS를 적용하고 있다.

 HTTPS 통신흐름

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

2. 신뢰할 수 있는 CA(Certificate Authority) 기업을 선택하고 그 기업에게 내 공개키 관리를 부탁하는 계약을 맺는다.

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

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

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

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

6. 브라우저는 해독한 뒤 서버(A)의 공개키를 얻게 된다. 이제 서버(A)에 이 공개키로 공통키를 암호화해서 보낸다.

7. 서버(A)는 이 암호화된 공통키를 자신의 개인키로 해독한다. 이제 둘은 이 공통키로 암호화하여 요청과 응답을 보내게 된다.

 

그러나 신뢰받는 CA기업이 아닌 자체 인증서를 발급한 경우 HTTPS도 무조건 안전하지는 않다. 이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.