XXX XXXXX대학 정보보안학과 교수는 충분히 우려가 가능한 부분이라고 지적했다. 현재 정부가 유해사이트와 저작권침해사이트 확인을 위해 인터넷사업자 또는 정보통신사에게 문의해 HTTPS의 중계역할(프록시)을 하게되면 모두 풀어 볼 수 있는데, 이는 정부가 지침만 내리면 인터넷사업자 등이 HTTPS를 풀어 볼 수 있다로 해석될 수 있기 때문이다. 


해당 교수는 SNI checking과 SSL inspection(SSL sniffing, SSL split)을 혼동하고 있는 것으로 보이네요. 이 둘은 다른 개념입니다. SNI checking은 SSL 통신 과정의 Client Hello Message안에 있는 특정 필드값(암호화되지 않은)을 보는 기법이고, SSL inspection은 중간에 Proxy를 두어 SSL(혹은 TLS)레벨에서 송수신되는(원래는 암호화되는) Application Data를 확인하는 기법입니다. SSL inspection이 제대로 작동하려면 다음과 같은 제약 사항이 존재합니다.


1. RootCA의 도움을 받아야 합니다.

SSL inspection을 작동시키려면 네트워크 장비에 현재 RootCA에서 관리하는 private key를 받아서 세팅해 줘야 합니다. 그런데 이는 기존의 시만텍이나 GPKI 사건과는 비교할 수 없을 정도로 큰 스캔들이기 때문에 만약 이러한 짓을 하고 있음이 만천하에 공개된다면 엄청난 큰 파장을 가져올 수 밖에 없습니다. private key 파일을 제공하는 RootCA는 RootCA 리스트에서 즉각적인 퇴출이 이루어 질 것이고, 국가적인 신뢰도에도 적지 않은 타격을 줄 수 있습니다.


2. SSL pinning을 하는 Application에는 무용지물입니다.

Windows Update를 비롯한 각종 OS Update, Kakaotalk이나 Line 같은 유명한 Messenger들은 대부분 SSL pinning을 하기 때문에 이러한 통신은 SSL inspection을 할 수가 없고, Application에서는 통신이 끊겨 버리기 때문에 SSL inspection을 돌리는 네트워크 환경에서는 사용자들의 불만이 터져 나올 수 밖에 없습니다(물론 예외 사항을 IP리스트로 관리하면 되지만 이게 참 골치 아픈 일임).


3. Proxy로 인해 속도가 저하됩니다.

뭐, 이것은 CPU 빵빵한 성능 좋은 proxy 사용하면 해결될 문제.


BurpSuite을 사용해 본 사람은 잘 알겠지만, 프로그램을 설치하면 자동으로 Fake RootCA 파일이 Local에 등록이 되고 Browser Proxy Setting까지 자동으로 변경되기 때문에 로컬 브라우저에서의 HTTPS 송수신 내용을 편리하게 볼 수가 있죠. 그래서 저는 SSL inspection 교육을 할 때 BurpSuite을 가급적 사용하지 않습니다. Step by Step 원리 이해에 별 도움이 되지 않거든요.


결론적으로 얘기하자면, SSL inspection은 금융권이나 공공기관과 같이 제한된 네트워크 환경에서만 운영이 가능하고 국가망에서 일반인들을 대상으로 SSL inspection을 운영한다라는 건 거의 힘들다고(불가능에 가깝다고) 보면 되겠습니다.
You would..