게이트웨이
HTTP 의 확장과 인터페이스는 사람들의 필요에 따라 발전해왔다.
통신에는 HTTP 말고도 다양한 프로토콜이 존재한다.
이 때 다른 프로토콜을 이용하는 애플리케이션이 존재 할 때
HTTP 를 사용하는 웹 서버와 다른 프로토콜을 이용하는 애플리케이션간의
통신을 가능하게 이어주는 중개자 역할이 게이트웨이다 .
게이트웨이는 서로 다른 프로토콜을 서로 잘 이해 할 수 있게, 수신자의 프로토콜에 맞춰 받은 발신자의 프로토콜을 해석하여 중개한다.
프록시에 대해 이야기 할 때 짧게 이야기하였지만 게이트웨이는 다른 프로토콜을 사용하는 2개 이상의 주체 를 중개 할 수 있다.
가장 우리에게 익숙한 게이트웨이 는 아마 데이터베이스 와 웹 서버를 연결하는 게이트웨이 일 것이다.
이 때 게이트웨이는 다른 프로토콜을 이용하는 2개의 주체를 이어주는 인터페이스 역할을 한다.
주로 데이터베이스 시스템은
HTTP통신보다는 주로TCP/IP통신을 사용한다고 한다.생각해보면
HTTP자체가HyperText Transport Protocol로 웹 문서와 같은 텍스트 기반을 위해 생긴 프로토콜이고데이터베이스는 주로 요청하는 정보인
Packet만 잘 전달하면 되니까 접속이 유지되고 단순하고 효율적인 저수준 프로토콜인TCP/IP를 사용하는 것이 당연 한 듯 싶다.
게이트웨이라는 인터페이스를 통해 웹서버는 HTTP 통신이 아닌 다른 프로토콜을 사용하는 애플리케이션 , 특히 데이터베이스등에 효과적으로 접근 할 수 있다.
프록시가 클라이언트 단에 가깝거나 서버단에 가깝게 위치 할 수 있었듯이
게이트웨이도 자유롭게 위치 할 수 있다.
물론 위치에 따라 목적이 다를 수 있지만 본질적인 것은 같다.
다른 프로토콜을 이용하는 주체를 이어주는 인터페이스 역할 말이다.
이중 이후 나올 내용들과 밀접한 관계가 있는 HTTP/HTTPS 보안 게이트웨이를 공부해보자
HTTP/HTTPS 게이트 웨이에 대해 공부하기 전 HTTPS 에 대해서 먼저 공부 할 필요가 있다.
해당 부분은 교재에 아직 나오지 않아서 유튜브를 참조했다.
HTTPS
HTTPS (Hyper Text Trasport Protocol Secure) 는 말 그대로 보다 안전한 프로토콜이다.
가장 먼저 HTTPS 가 안전한 이유를 먼저 겉핥기로 보게되면
- 호스트와 클라이언트가 주고 받는 정보를 암호화 하여 전송한다
호스트와 클라이언트가 주고 받는 요청/반응에는 다양한 개인정보들이 들어있을 수 있다.회원가입을 할 때 주민번호를 입력하거나 로그인을 위해 아이디와 비밀번호를 입력하는 것도 모두 네트워크를 타고 전송된다.
HTTPS는 기관으로부터 인증 받은 사이트만 사용 할 수 있기 때문에 사용자는 주소창을 통해HTTPS유무로 비교적 공신력 있는 사이트 라 추측 할 수 있다.
이 두가지 때문에 HTTPS 는 HTTP 에 비해 안전한 프로토콜이라고 할 수 있다.
어떻게 서버와 클라이언트가 주고 받는 정보를 암호화 할까 ?
HTTPS가 뭐고 왜 쓰나요? (Feat. 대칭키 vs. 비대칭키)
해당 영상을 보고 감을 잡았다. 정말 대단한 유튜버이다. 구우웃
어떤 정보를 남들이 알아 볼 수 없게 하는 것을 암호화 , 암호화 된 글을 알아 볼 수 있게 바꾸는 것을 복호화 라고 한다.
이 때 평문(plain text)을 암호화 하고 복호화 하도록 도와주는 것을 key 라고 한다.
암호화는 이 key 를 통해서 평문을 암호화하고 복호화 한다.
이 때 암호화 하고 복호화 하는 key 가 동일한 경우를 대칭키 라고 한다.
그러니 서버와 클라이언트가 동일한 key 하나 를 가지고 둘이 주고 받는 데이터를 암호화 하고 복호화 하는 것이다.
그럼 HTTPS 는 대칭키 를 이용할까 ?
놉
이용하지 않는다. 그 이유는 대칭키 를 효과적으로 이용하려면 클라이언트 한 명당 해당 클라이언트만을 위한 유일한 키를 만들어야 할 뿐인더러
해당 키가 다른 이에게 유출이 되게 되면 보안이 뚫리기 때문이다.
이것이 대칭키의 한계이다.
그래서 사용 하는 것이 바로 비대칭 키 다.
비대칭 키 는 키가 두 가지 존재하며, 한 키로 암호화 한 데이터는 다른 키 만으로 복호화 할 수 있다.
암호한 데이터는 암호화 시킨 키로 복호화 하는 것이 불가능하다.
그러면 비대칭 키 를 이용해서 서버와 호스트가 어떤 식으로 데이터를 암호화 하고 복호화 할지 예상해보자
어떻게 보안을 유지할까 ? 조금만 더 깊게 들어가보자
우선 https 를 사용하는 사이트들은 모두 기관에서 인증 받은 공신력 있는 사이트 이다.
해당 사이트들은 클라이언트와 TCP 커넥션 을 맺는 과정에서 두 가지 정보들을 주고 받는다.
- 서버는 클라이언트 측으로 서버에 대한 인증서를 암호화 하여 클라이언트에게 전송한다.
- 서버와 클라이언트는 서로 규칙 없이 임시로 만들어진 텍스트를 주고 받는다.
CA (Certificate Authority) 라고 암호화 된 인증서들을 검사하는 민간 기업이 존재한다. 우리의 브라우저들에 탑재 되어 있는 CA 는 서버로부터 받은 인증서를 검사한다.
검사한 인증서가 실제 https 페이지에서 보낸 암호화 된 인증서를 CA 만 가지고 있는 개인키를 이용하여 복호화 하고 실제 해당 페이지에서 보낸 인증서인지 확인한다.
CA가 가지고 있는 개인키는 현재 서버와 클라이언트의 비대칭 키와 전혀 상관 없다.
그저 암호화된 인증서를 복호화 하여 실제 서버인지 확인하기 위한CA만을 위한 키라고 우선은 생각하자
만약 실제 서버로부터 받은 인증서가 맞다면 해당 서버의 공개키 를 클라이언트에게 전달한다.
만약 실제 서버로부터 온 것이 아니라 https 인증서 목록에 없어 다른 브라우저 (사칭 브라우저와 같은) 에서 온 인증서로 판단된다면 안전하지 않은 페이지임을 주소창에 띄운다.
그럼 CA 로부터 공개키를 받았다고 해보자
현재 상황을 정리하면 서버와 클라이언트는 3-way-handshaking 과정에서 랜덤하게 생성된 임시 데이터를 주고 받았다.
그리고 클라이언트는 서버의 공개키 를 가지고 있고, 서버는 본인만 가지고 있는 개인키 를 가지고 있다.
그럼 클라이언트는 서버와 주고 받은 임시 더미 데이터 2개 (3-way-handshaking 시 주고 받은)를 조합하여 둘의 대칭키를 만들고 만들어진 대칭키를 공개키 로 암호화 하여 서버에 보낸다.
그러면 서버는 암호화 된 대칭키 를 서버의 개인키 로 해석하여 확인하고 만들어진 대칭키 를 서버와 클라이언트만 알고 있는 것으로 간주하고
해당 키를 이용해 암호화와 복호화를 한다.
그럼 두 가지 의문이 든다.
아~!니 ~! 왜 비대칭키 그렇게 설명해놓고 왜 대칭키를 이용해서 암호화 복호화 하셈?
다량의 데이터를 비대칭키를 이용해서 암호화 하고 복호화 하는 것 보다 하나의 대칭키를 이용해 암호화, 복호화 하는 것이 컴퓨터에 오버헤드를 덜 준다.
그래서 대칭키를 이용하는 거고, 남들에게 뺏기면 좋지 않은 대칭키를 비대칭키를 이용해서 숨기는 것 이다.
아~!니~! 그러면
3-way-handshaking할 때 주고 받은 임시 데이터 탈취 당하면 위험한거 아니셈?맞다. 그래서 임시 데이터가 탈취되지 않게 보안에 더 신경 쓰고 거기에 맞는 프로토콜들이 또 존재한다고 한다.
갸갸갹 이해가 될랑 말랑
정리해보자
정리
서버와 클라이언트는 결국 대칭키 를 이용해서 정보를 암호화 하고 복호화 한다. 그런데 그 대칭키 가 다른 곳들에 유출되지 않도록 암호화, 복호화에 쓰일 대칭키 를 서버와 클라이언트가 각각 가지고 있는 비대칭키 를 이용해 암호화 해서 서로 주고 받는다.
SSL / TLS
SSL / TLS 는 모두 위에서 설명한 단계들을 정의하는 인증서이다.
SSL 은 Secure Sockets Layer 로 초기 웹 보안 프로토콜이며 TLS (Transport Layer Security) 는 SSL 의 후속 버전으로 보안적인 측면에서 업그레이드 및 개선이 이뤄졌다.
SSL 은 보안 결함이 있어 현재는 사용되지 않는다고 한다.
교재에서는
SSL만 가지고 예시를 들었기에 이후 나올 설명들에선 교재에 충실하게SSL로 설명하려고 한다.
그럼 얘네들이 뭘까 ?
해당 인증서들의 구성 요소는 서버의 공개 키, 서버의 개인키, 인증서에 포함된 서버의 정보 등을 가지고 있다.
https 프로토콜을 사용하게 위해 페이지들은 해당 인증서들을 도메인에 맞게 구매해서 사용해야 하며 해당 인증서들은 위에서 설명한 CA 를 통해 관리된다.
그니까 SSL / TLS 는 https 를 구성하기 위한 요소로 서버의 신원을 확인 하고 데이터를 암호화 하는 목적을 위해 만들어진 인증서이다.
얘네들의 이름이 왜
SSL/TLS일까 ?암호화는 모두
HTTPS통신인 애플리케이션 레이어에서 이뤄지는데 왜Transport Layer Security인지 의문이 들었다.
그 이유는 데이터의 암호화와 복호화는 주로 전송 계층 (Transport layer) 에서 작동하기 때문이다.데이터란 것은 결국
TCP / IP Layer를 통과해서 전송되어야 하기 때문이다.
HTTP/HTTPS 보안 게이트웨이
/로 구분되는 것은 좌측은 클라이언트, 우측은 서버를 의미한다.
HTTP/HTTPS는 클라이언트가HTTP를 사용하고 서버가HTTPS를 사용 할 때를 의미한다.
HTTP/HTTPS 보안 게이트웨이 또한 HTTP 통신을 하는 클라이언트와 HTTPS 통신을 하는 서버 간의 통신을 가능하게 해준다.
이 때 HTTP 를 통해 오는 요청은 암호화 되어 있지 않지만 HTTPS 를 사용하는 웹 서버에 전달 될 때에는
암호화 된 채로 전달된다.
HTTPS/HTTP 보안 게이트 웨이
이는 HTTP/HTTPS 에 비해 속도가 더 빠르다.
그 이유는 게이트웨이가 가깝게 있기 때문에 캐싱 데이터등이 더 클라이언트와 가깝게 위치하기 때문이다.
리소스 게이트웨이
게이트웨이가 가장 많이 사용되는 리소스 게이트웨이 에 대해 알아보자
리소스 게이트웨이는 다른 프로토콜을 갖는 애플리케이션과의 통신을 이어주는 인터페이스이다.
데이터베이스와 웹 서버간의 연결을 이어주는 인터페이스로 생각하고 가자
초기에는 CGI (Common GateWay Interface) 가 가장 많이 사용되었다.
HTTP 프로토콜을 이용하는 웹 서버와 게이트 웨이의 프로토콜이 다르기 때문에
이를 연결 시켜주는 인터페이스인 CGI 는 애플리케이션에 탑재 되어 있는 것이 아니라
요청이 들어올 때 마다 활성화 되어 애플리케이션으로 요청이 전달되고 받아졌다.
그러니까 해당 인터페이스는 요청이 호출 될 때 마다 프로세스가 작동 되고 요청이 종료되면 같이 종료되는
단순한 프로세스였다.
Fast CGI
들어오는 요청에 따라 개별적으로 작성해서 프로세스에 올리는 CGI 는 외부 인터프리터가 쉽게 접속 할 수 있게 도와주지만
몇 가지 단점이 존재했다.
- 요청마다 새로운 프로세스를 만들어야 한다는 점
- 실행 될 때 마다 프로세스가
OS에 올라갔다가 사라진다는 점 - 서버에게 최적화 된 서비스가 힘들다는 점
이거를 해결해주는게 Fast CGI 이다. Fast CGI 는 서버를 제공하는 회사 단에서
각자 서버 형식에 특화 된 인터페이스 API 를 제공하고 각 서버는 해당 API 를 이용해 다른 애플리케이션과 소통한다.
이러한 기능은 서버 사용자 맞춤 인터페이스를 제공 해준다.
또한 Fast CGI 는 동작때마다 프로세스가 생성되어 실행되고 종료되는 것이 아닌, 항상 대기 하다가 요청이 들어오면 빠르게 실행되고 다시 대기하기에 오버헤드가 적다.
터널
웹터널 은 HTTP 통신을 지원하지 않는 애플리케이션에 HTTP 통신을 이용해 접근하는 방법을 제공한다.
아니 여태까지
HTTPS나 게이트웨이 잘 설명해놓고 왜 웹터널이 필요한데 ?필요하다. 인터넷은 다양한 프록시 서버를 통과하며 정보를 주고 받는데 프록시들이 다양한 통신 메소드들을 모두 해석하고 전달한다고 생각해보자
생각만 해도 너~무 느리다.
HTTPS 가 생기기 전 이미 네트워크에는 수 많은 방화벽과 프록시들이 쌓여있었다.
이런 구닥다리 방화벽, 프록시들은 HTTP 가 아닌 트래픽들은 처리하지 못하고 차단했다.
왜냐면 그 때는 HTTP 가 전부였고 HTTP 가 아닌 것들은 비정상 트래픽이기 때문이다.
그러면 , 이미 전 세계에 깔린 방화벽과 프록시들을 변경해야 할까 ?
놉
차라리 HTTP 가 아닌 애들도 HTTP 처럼 지나갈 수 있게 하자 , 그게 바로 웹 터널 이다.
웹 터널은 HTTP 통신이 아닌 정보들도 HTTP 통신처럼 지나가게 한다.
그건 바로 HTTP 통신이 아닌 데이터들을 HTTP 패킷에 캡슐화 하여 집어 넣어 HTTP 메시지처럼 보낸다.
그러면 프록시와 방화벽들은 안에 들은 내용물과 상관 없이 HTTP 인 줄 알고 보낸다.
그것이 바로 터널링이다.
이러한 방식으로 HTTP를 이용한 터널링은 HTTP의 유연성과 보편성을 활용하여, 다양한 프로토콜을 HTTP 패킷으로 캡슐화하고 중계 서버에서 원래의 프로토콜로 변환하여 목적지 서버에 전달한다.
이를 통해 네트워크의 다양한 제약을 우회하면서도 안전하고 효과적인 통신을 가능케한다.
