질문과 답변
Q. server certificate은 어떻게 얻는 것일까?
server setup
web server가 https connection을 허용하게 준비하려면, 관리자는 public key certficate를 만들어야 한다.
이 public key certificate은 certificate authority(CA)에 의해 서명이 되어야 한다. 그래야 웹 브라우저가 워닝 없이 허용할 수 있다.
authority는 certificate holder가 web server의 관리자임을 증명한다.
web browser는 signing certificates of major certificate authorities의 리스트를 갖고 있으므로 certificate을 확인할 수 있다.
acquiring certificates
상업적인 CA들이 존재하는데, 이들은 extended validation certificates를 비롯한 다양한 SSL/TLS certificate을 유료로 제공한다.
Let's Encrypt는 기본적인 SSL/TLS certificates를 웹사이트에 제공한다.
Use as access control
certificate는 유저를 인증하기 위한 access control로도 사용될 수 있다.
사이트 관리자는 각 유저마다 certificate을 만드는데, 여기에는 이메일, 이름 등이 들어있다.
서버는 이 certificate을 자동으로 체크하며, 비밀번호를 입력하지 않아도 인증이 되는 등의 기능을 제공한다.
in case of compromised secret key
이 과정에서 중요한 것은 PFS(perfect forward secrecy)이다.
https session을 만들기 위한 장기 비대칭키는, 대화를 복호화하기 위해 필요한 단기 session key를 해석하는데 도움을 주어선 안된다.
ref
Q. proxy와 gateway의 차이는?
주로 proxy server 는 wall 같이 커넥션을 필터링하고, gateway는 어떤 필터링도 하지 않는다.
Gateway는 어떤 것이 internal network고 어떤 것이 external network인지를 결정한다.
Gateway가 없이는, 컴퓨터는 외부망으로 연결되지 못할 것이다.
Proxy server는 외부로부터의 네트워크를 대표한다. 바깥으로 나가기 전에 네트워크를 숨기는 역할을 하는 것이다. 따라서 외부에서는 내부 컴퓨터가 익명으로 보이게 된다.
Functional difference - proxy server가 gateway보다 강력하다. Gateway처럼 필터링을 하지 않고 요청을 pass하면서, 보안을 제공하기 때문이다.
Gateway는 웹사이트를 막지 못하나, proxy server는 redirect로 막을 수 있다.
Proxy server는 website cache를 제공한다.
ref
https://www.techwalla.com/articles/difference-between-a-proxy-server-a-gateway
Q. 애초에 http client에서 https로 보내는 게 아니라면, gateway전에는 안전하지 않은 건가?
http로 보낼때 https로 변경하면서 위험할 수도 있다.
http에서 inbound security gateway까지 갈때, MITM 공격에 취약할 수 있다.
사실 클라이언트와의 통신상 보안의 목적보다는, 서버 네트워크 내부의 보안을 지키기 위함이 큰 듯 하다.
반대로 client side security accelerator gateway는 http를 지원하지 않는 서버를 대신해서 https로 클라이언트와 통신하여 MITM으로부터 보호하는 역할을 하지 않을까.
물론 서버의 부하를 줄여주는 등의 역할도 할 수 있다.
ref
https://www.ibm.com/cloud/blog/secure-gateway-everything-ever-wanted-know
Q. fig 8-13의 인증과정을 자세히 이해해보자. - proxy authenticate, proxy authorization은 어떻게 쓰이는걸까.
proxy-authenticate - 프록시에 인증이 되어, 그 뒤의 리소스에 접근하기 위해 사용된다. 만일 이게 없다면 407 proxy authentication이 떨어진다.
407 proxy authentication required와 함께 proxy-authenticate 헤더가 떨어지면, 브라우저는 proxy-authorization에 인증 정보를 넘기게 된다.
ref
* 표시는 정확하지 않음을 의미
Q. 통합점이라고 명명한 이유는 무엇일까? 심오한 의미가 있을까?
Q. HTTP/HTTPS 게이트웨이 : 서버측 보안용도 : 서버측 게이트웨이에 들어가기 전 까지는 보안이 안 되는 것은 아닐까? : 어떤 보안에 힘을 쓰려는걸까?
내부망을 HTTPS로 강제하는 것은 도대체 무슨 의미가 있는 걸까? 아무리 찾아도 이해가 안된다.
책 후반부에 보면 SSL 터널링에 대해 나오는데 이 경우 비슷한 용도인 것 같다. HTTP 위에 HTTPS 메시지를 올려 통신하지만 HTTP/HTTPS 게이트웨이에 비해 클라이언트와 원서버가 직접 SSL 커넥션을 이룰 수 있어 좋다는 내용.
그렇다면 HTTP/HTTPS 게이트웨이의 경우에도 80번 포트만 허용하는 리버스프록시(게이트웨이) 에 통신하되 내부적으로는 SSL 처리를 하는 것일까?
Q. 리소스 게이트웨이, CGI, WAS, 웹서버 등 용어가 혼동되는 것 같다. 헷갈린다.
웹서버
nginx 등 정적으로 정해진 프로그램을 직접 실행한다.
WAS
tomcat 등 동적으로 프로그램을 찾아 실행한다. 웹 서버에 어플리케이션(동적으로 돌아가게)이 같이 돌아가는 형태.
CGI
동적인 웹 서비스를 위한 표준. 이를 구현한 것이 WAS. 고로, CGI + 웹서버 = WAS
리소스 게이트웨이
http 요청을 받으면 특정 어플리케이션, 프로토콜을 통해 리소스를 받아오는 게이트웨이 고로, WAS, 웹서버 모두 리소스 게이트웨이에 해당한다.
Q. 데몬 프로세스가 뭘까? 안쓰면 CGI가 느려지는 이유?
데몬 프로세스
쉽게 말해 백그라운드 프로세스의 일종.
CGI 프로세스
CGI가 작동하는 프로세스는 다음과 같다.
request를 받으면
CGI 프로세스가 생성되고
메모리를 로딩하고
로직을 처리하고
종료한다.
Fast CGI
CGI의 경우 요청이 정해져있는 경우가 많아 비슷하게 쓰이는 자원이 많다. 하나의 요청에 대해 생성과 종료가 이루어지는 것은 불필요한 낭비. 하나의 프로세스가 여러 요청을 여러 쓰레드에 담당시켜 처리할 수 있도록 한다. 메모리를 공유하게 되므로 명령이 절약되어 처리속도가 빨라진다.
Last updated