HTTP 박살내기 프로젝트 - 7 | 게이트웨이, 터널

* 본 게시글은 <HTTP 완벽 가이드> 서적을 읽고 정리한 글입니다.

 

----

 

웹은 이제 단순히 정적인 HTML 파일을 보여주기만 하는 시대는 지났다. 사람들은 더 복잡한 리소스(동적인 HTML 등)를 사용하기를 원한다. 그런데 이 복잡한 리소스를 한개의 애플리케이션으로 처리하기는 이제 불가능해졌다. 이제 HTTP 외에 다른 프로토콜을 사용하는 애플리케이션과도 같이 연결해서 사용하고 싶다.

(대표적으로 FTP 서버)

 

이때 사용되는 기술(?)이 대표적으로 [게이트웨이 & 터널] 이다.

 

게이트웨이: 서로 다른 프로토콜과 애플리케이션 간의 HTTP 인터페이스.

터널: HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송하는데 사용한다.

 

# 게이트웨이

- 게이트는 리소스와 애플리케이션을 연결하는 역할을 한다.

- 애플리케이션은 게이트웨이에게 요청을 보내고, 게이트웨이는 그에 맞는 응답을 처리해준다.

- HTTP 트래픽을 다른 프로토콜으로 자동 변환하여 HTTP 클라이언트가 다른 프로토콜을 알 필요 없이도 서버에 접속할 수 있게 해준다.

 

<클라이언트 프로토콜>/<서버 프로토콜> 으로 표현한다

 

HTTP/FTP: 클라이언트(HTTP) -> 게이트웨이(HTTP/FTP) -> FTP 서버(FTP)

 

HTTP/HTTPS: 클라이언트(HTTP) -> 게이트웨이(HTTP/HTTPS) -> 보안 웹 서버(HTTPS)

- 클라이언트의 모든 웹 요청을 암호화, 개인정보 보호 및 보안을 제공한다

- 클라이언트는 HTTP를 사용하는 것 같지만 게이트웨이가 자동으로 HTTPS로 세션을 암호화시켜 전송한다.

 

HTTPS/HTTP: 클라이언트(HTTPS) -> 게이트웨이(HTTPS/HTTP) -> 웹 서버(HTTP)

- HTTPS로 암호화 되있는 세션을 벗겨서 HTTP로 빠르게 전송한다 (보안 가속기)

- 원 서버가 보안 세션을 복호화하는 부담을 줄여주나, 게이트웨이와 서버간 암호화되지 않은 트래픽을 전송하기 때문에 안전한 경로인 경우에만 사용해야한다.

 

# 터널

터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다.

-> HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고 다른 프로토콜을 HTTP 위에 올릴 수 있다.

<책 내용 요약>

1. 터널을 통해 전달되는 데이터는 게이트웨이에서 볼 수 없다.

2. 웹 터널은 원래 방화벽을 넘어서 암호화된 SSL 트래픽을 전달하려고 개발되었다

(회사 외부에서 회사 내부망에 접근하기 위해..)

- HTTP 트래픽 이외는 모두 차단하는 방화벽이 있다고 하자.

- 터널을 이용해서 SSL 트래픽을 HTTP 메시지로 감싸주면(캡슐화) SSL 트래픽이 방화벽을 통과할 수 있다.

- 매우 유용하지만, 악의적인 용도로 사용될 수 있다는 점을 항상 유의해야한다. ("백도어"와는 다르다!!)

3. 터널링이 보안에 좋은 이유

# HTTP/HTTPS 게이트웨이를 이용하는 경우

(클라(HTTP) <-> 게이트웨이(HTTP/HTTPS) <-> 프록시(HTTPS) <-> 원 서버)

-> 클라이언트와 게이트웨이 사이는 보안이 적용되지 않은 HTTP 커넥션이 연결된다.

* 그런데, 대부분의 경우 HTTP/HTTPS 게이트웨이를 굳이 사용할 필요 없이

                      클라이언트 단에서 곧바로 HTTPS를 사용해서 보내기 때문에 일반적으로 이런 일은 일어나지 않는다 *

(뇌피셜임)

 

# 터널링을 사용하는 경우

- 클라이언트와 목적지 웹 서버간 터널을 뚫어버림으로 중간에 보안이 적용되지 않는 구간이 없도록 함. 

 

+ VPN에 사용되는 기술이 터널, 터널링이다

 

 

[잠깐 딴길로 새는... HTTP와 HTTPS의 차이]

https://www.youtube.com/watch?v=H6lpFRpyl14&t=2s 

 

 

(쿠키를 여기 같이 쓰려다가 분량이 길어져서 다음으로 넘김)