자신의 서버 IP를 숨기기 위해 Cloudflare같은 CDN을 이용하는 경우가 종종있다.. 이러한 CDN(일종의 Proxy 시스템)을 이용하면 DNS 조회를 했을 때 실제 서버의 주소 대신 해당 CDN의 노드 IP주소가 표시된다. 서버의 실제 IP가 노출됨을 막음으로서 DDos공격이나 기본적인 해킹 시도를 줄이거나 어렵게 만들수 있다.

CDN이나 표면 서버를 앞에 두면 실제 핵심(코어) 서버의 주소를 가릴수 있다. 그렇지만 서버 프로그램에 설정을 잘 못하면 모두 헛수고가 될 수도 있다. 주의를 가져야 하는 부분은 SSL 인증서의 DNS 필드이다. SSL 인증서에는 발급대상 정보와 “도메인 주소” 주소가 담겨있다. SSL 인증서만 받아낼 수 있으면 해당 서버가 어디에 소속된 서버인지 쉽게 판단할 수 있다는 말이다.

서버의 SSL 인증서는 어떻게 받아낼수 있을까? 몇년 전 까지만 해도 HTTP로 도메인 없이 서버의 IP에 직접 접속하면 운영중인 웹사이트가 그대로 나왔었다. 이것으로 “이 서버는 ~~ 사이트를 운영하는 곳이다”를 알아낼 수 있었다. 요즘은 서버 IP로 직접 접속 시도를 하면 운영중인 웹 사이트 대신 안내 페이지나 오류페이지 따위가 나오도록 조치한 서버가 많아졌다.

그와 비슷하게 SSL도 일종의 기본 인증서 같은게 있다. SSL을 사용하는 서버에 SSL Handshake를 요청하면 알맞는 SSL 인증서를 클라이언트에게 알려준다. 별도의 설정이 없으면 접속정보가 없거나 틀리더라도 임의로 프로그램에 붙어있는 인증서가 전송된다. 이 인증서를 통하여 서버가 어디에 속해 있는지 알 수 있다. 이것은 HTTPS 에서만 발생하는 문제가 아니다. SSL을 지원하는 서버면 모두 다 해당되는 이야기이다.

서버 IP로 SSL Handshake만 하면 기본 인증서를 얻어낼 수 있는 이유는 SNI를 살펴보면 알 수 있다. 본래 SSL 서버는 1개의 인증서만을 가질수 있었다. 다른 인증서를 가지고 운영하려면 별도의 포트나 IP에 새로운 서버 프로그램을 실행했어야 했다. 이런식으로 여러개의 인증서로 운영하려면 새 IP나 다른 Port를 써야하는게 불편하여 만든게 SNI이다. SNI는 클라이언트(주로 브라우저)가 서버에 접속할 때 “~~~~이런 사이트에 접속을 원합니다” 라고 알려주고 서버가 적절한 인증서를 고를 수 있게 해 준다.

SNI는 SSL의 확장형으로 나왔기에 SNI정보가 없어도 올바른 SSL 요청이다. 물론 대부분의 클라이언트측에서 SNI를 사용하긴 하지만, SNI없이 그냥 접속하는 것도 문제가 없다. 그렇기에 SNI가 안들어왔을때도 처리를 해 줘야하지 않는가? 이런 경우에 서버는 위의 문단에서 적은것 처럼 규칙에 따라 가장 우선도가 높은 인증서를 전달해 준다.

SNI없이 어떻게 클라이언트가 SSL 요청을 하냐고? SNI 필드는 그저 서버측에 내가 접속하고픈 도메인은 ~~.com 이야 라고 알려주기 위한 것일 뿐이다. 그냥 “어느 서버로 접속하고 싶은지”에 대한 정보를 알려주지 않으면 된다. 그러면 SSL 서버는 가장 기본이 되는 인증서로 SSL 연결(Handshake)을 시도하며, 기본 인증서를 던져준다. 가장 손 쉬운 방법은 https://127.0.0.1 처럼 직접 IP로 접속시도를 하는 것이다.

이런식이면 서버를 모든 IP 주소에 SSL Handshake를 해봐야 실제 서버를 찾을수 있는것 아닌가? 생각이 들 것이다. 맞다. 모든 IP주소에 SSL Handshake 요청을 해서 인증서를 읽어 봐야한다. 그러나 그걸 우리가 직접 할 필요는 없다. 이 지겨운 일을 해서 DB화 한 사이트가 있다. 의외로 꽤 있다. 찾아보면 꽤 나온다. 표적 서버를 몇가지 추린다면 본인이 직접 스캔을 돌려볼 수도 있다.

서버 관리자들은 이런 기법이 있는지를 알고 SNI가 이상하거나 누락되어 있을때 적절히 서버가 응답할 수 있도록 설정해야 한다. 특히 DDos나 공격에 대비해서 CDN을 이용하는 경우엔 절대 놓치면 안 될 부분이다. CDN을 사용한다면 해당 CDN에서만 어플리케이션에 접근할 수 있도록 방화벽을 설정하는것도 좋은 방법일 것이다.