본문 바로가기
Today I learned

SNI 개념과 차단 우회방법

by soheemon 2019. 8. 4.

SNI란

서버 네임 인디케이션(Server Name Indication, SNI)은 컴퓨터 네트워크 프로토콜인 TLS의 확장으로, 핸드셰이킹 과정 초기에 클라이언트가 어느 호스트명에 접속하려는지 서버에 알리는 역할을 한다. 이를 이용하면 같은 IP 주소와 TCP 포트 번호를 가진 서버로 여러 개의 인증서를 사용할 수 있게 되고, 따라서 모든 사이트가 같은 인증서를 사용하지 않아도 동일한 아이피로 여러 HTTPS 웹사이트(또는 TLS 상에서 돌아가는 다른 서비스)를 운영할 수 있게 된다.

 

배경

클라이언트에서 TLS 연결을 생성하려면 먼저 웹 서버로 디지털 인증서를 요청하게 된다. 서버가 인증서를 보내면 클라이언트는 이를 읽고 연결하려던 호스트명과 인증서에 적힌 이름이 일치하는지 확인한다. 일치하는 경우 정상적으로 연결 절차가 진행되나, 일치하지 않는 경우 누군가 중간자 공격을 시도하고 있다는 조짐이므로 경고문이 나타나거나 또는 연결이 중단된다.

 

SNI를 이용한 해결책

SNI를 이용하면 TLS 핸드셰이크 과정에서 현재 접속하려는 가상 도메인의 호스트명을 서버로 전송해 이 문제를 해결할 수 있다. 이렇게 하면 서버에서 가상 도메인 호스트명을 먼저 알 수 있게 되므로 해당 호스트명에 맞는 인증서를 선택해 전송할 수 있게 된다. 

 

보안측면

접속하려는 호스트명 정보가 암호화되지 않기 때문에 사용자가 어떤 사이트에 접속하는지 타인이 엿볼 수 있으며, 이를 이용해 보안 회사에서 필터링 기술을 개발하거나 한국 등의 정부에서 통신 검열에 활용하기도 한다.

 

SNI차단 관련해서 급 궁금해져서 찾아봤다.

SNI 차단의 큰 틀은... HTTPS패킷이라 할지라도 ClientHello패킷에 기록된 도메인이름은 암호화 되지 않기때문에, DPI장비가 중간에서 Client가 보낸 사이트 접속 패킷을 까서 '요망한 사이트에 접속하는구나.' 라고 판단을 하는것부터 시작한다.

여기서 DPI장비에 따라 Passive DPI와 Active DIP로 나뉘는데

PassiveDPI는 가운데서 복사된 패킷을 받기때문에 DPI장비는 Server가 Client에게 보낸 패킷을 막을 방법이 없다. 그래서 Server보다 먼저 RST패킷을 Client에 보내버린다. Server는 Client에 데이터를 보내지만.. 이미 DPI장비가 보낸 RST패킷에 의해 연결이 끊어진 Client로써는 받을 방법이 없다.


=> DPI장비가 보내는 패킷을 드랍시킴으로써 Server가 보내는 정상 응답을 Client가 전달받게끔 우회 가능.

ActiveDPI는 일반적인 네트워크 장비처럼 Client와 Server가운데에 위치한다. 따라서 패킷을 차단하는것이 가능

=>Client에서 DPI장비는 탐지하지 못하지만, 웹서버는 해석 가능한 형태의 패킷을 전송함으로써 우회한다. 예를들어, soheemon.tistory.com 이라는 사이트를 요청했을때 ClientHello 패킷에서 soheemon. 과 tistory.com
를 나누어서 전송하면 DPI장비는 탐지하지 못한다고한다. 아직까지는? 
[그외에도.. 여러가지 교묘한방법(?)이 있지만.. 패치가 되지않을까 하는 방법들이다..]

그리고 우회툴 구현에 대해서도 궁금해서 찾아봄...

 

-GoodbyeDPI
가장 유명하지 않을까 하는... 
패킷을 먼저 받아서 필터링하는 개념인것 같다.
아니 응용프로그램주제에 어떻게 패킷후킹을 하는거야?! 했는데.. 윈도우드라이버 개념인것 같다 머쓱...[WinDivert 라는 드라이버를 쓴다고 하는데 라이브러리인듯하다.]
위에서 작성한 DPI방법을 모두 지원한다고 함.

https://github.com/ValdikSS/GoodbyeDPI/tree/master/src
http://blog.naver.com/PostView.nhn

 

- MTU를 작은사이즈로 수정한다.
우회없이 OS레벨에서 MTU를 작은 사이즈로 지정한다. 
모든 패킷이 쪼매난 사이즈로 잘려서 전달되기 때문에 우회프로그램 없이도 soheemon.tistory.com 이 soheemon. tistory.com으로 전달되어 우회 가능!

하지만... HTTPS패킷뿐만아니라 모든패킷이 쥐똥만한 사이즈로 나뉘어서 가기때문에 많은 부하가 일어난다.

윈도우에서는 mtu를 400으로 맞추면 우회가 가능하다고 하는데.. IP TCP헤더 다 떼면.. Clienthello패킷이 360이 훨씬 넘는다는건가.. 이건 잘 모르겠다

댓글