본 글은 'HTTPS/DNS 차단 쉽게 이해하기' (https://www.clien.net/service/board/park/13152618)CLIEN 에서 이어지는 글로, 비유를 제거하고 기술적인 부분만을 다룹니다.
현행 HTTPS/DNS 차단 방식이 어떠한 방식으로 이뤄지고 있는지에 대해 설명하기 위한 글이며, 따라서 구체적인 네트워크의 작동 방식과 암호화 방식에 대한 내용은 생략하고 필요한 부분만을 다룹니다.
비전공자 분들의 이해를 돕기 위해 비유로만 설명을 했더니, 원치 않던 왜곡이 생겨 이를 바로잡고 더 자세한 이해를 원하시는 분들을 위한 글입니다.
이해를 돕기 위한 스크린샷들은 네트워크 패킷 캡쳐 및 분석 프로그램인 Wireshark 실행 화면에 대한 캡쳐로, https://www.wireshark.org/ 에서 직접 다운받으셔서 실제 오가는 패킷을 열어보실 수 있습니다. 제 MAC 주소, IP 주소 등은 모자이크 처리하였습니다.
먼저 HTTP 통신부터 보도록 하죠.
잘못된 형식의 이미지 링크입니다.
위의 패킷은 HTTP 요청 패킷입니다. 가장 먼저 보셔야 할 것은 Internet Protocol Version 4 레이어로, 송신 IP와 수신 IP 주소를 담고 있죠. ISP는 해당 정보를 통해 들어온 패킷이 어느 목적지로 가야하는지 파악하고, 해당 목적지로 패킷을 보내주게 됩니다.
아래의 Hypertext Transfer Protocol은 HTTP 패킷의 내용입니다. 보시다시피 HTTP는 암호화가 되지 않는 평문 통신이며, 제3자가 통신 내용을 전부 볼 수 있습니다.
따라서 기존에 시행되어왔던 HTTP 차단 방식은 HTTP 패킷을 열어, Host 헤더의 정보를 보고 해당 도메인이 차단 목록에 있다면 warning.or.kr로 보내버리는 방식으로 작동합니다.
여기서 중요한 것은 통신사가 원하는 목적지로 패킷을 보내기 위해서는 원래 IP 레이어만 보면 된다는 사실입니다. 즉, 차단을 위해 열어볼 필요가 없는 HTTP 패킷까지 열어보고 있다는거죠.
이전 글에서 HTTP 통신을 봉투에 들어간 편지에 비유한 이유도 이와 같습니다. 편지 봉투 = 암호화가 아닙니다. 이전 글의 비유에서 편지지 = HTTP 패킷이며, 봉투 = IP 패킷인거죠. 구조상으로도 HTTP 패킷이 IP 패킷으로 둘러싸인 구조니까요. (엄밀히 TCP 패킷으로 한번 더 둘러싸이긴 합니다만)
잘못된 형식의 이미지 링크입니다.
위의 스크린샷은 HTTP 응답 패킷으로, 앞서 말했듯 HTTP 통신은 평문 통신이기 때문에, 제3자가 내용도 전부 열람이 가능합니다. 물론 '열람할 수 있다'이지 '열람하고 있다'는 아닙니다. HTTP 차단을 위해서는 일단 HTTP 요청 패킷의 Host 헤더만 열어보고 있다니까요. 어쨌든 HTTP 패킷을 열어보고 있다는 사실은 동일합니다만.
HTTP 통신을 열어볼 수 있는건 통신사 뿐만 아닌, 통신 과정 중간에 있는 모든 제3자이며 따라서 보안에 매우 취약하기 때문에, 이를 보완하기 위해 HTTPS가 도입되었습니다. (공용 와이파이 쓰지 말라는 큰 이유 중 하나가 이겁니다)
잘못된 형식의 이미지 링크입니다.
위 스크린샷은 TLS 패킷의 일부입니다. 왜 HTTPS 패킷이 아니고 TLS 패킷이냐 하면, HTTPS 패킷은 HTTP + TLS 패킷이기 때문입니다. HTTP 패킷을 TLS 패킷으로 감싸서 암호화해서 보내는게 HTTPS거든요.
보시다시피 HTTP와 비슷하게 TLS 레이어가 TCP로 한겹, IP로 한겹 둘러싸인 형태입니다. IP 패킷으로 둘러싸였다는건 똑같죠? 그러니까 HTTPS면 IP도 암호화된다는건 개소리라는겁니다. IP 패킷을 암호화하면 통신사가 어디로 보내야할지 모르는데 어떻게 보내요...
아무튼, 더 엄밀하게 말하자면 위의 패킷은 HTTPS 연결을 시작하기 전 암호화 정보를 서로 교환하는 TLS Handshake 패킷입니다. 서로가 지원하는 암호화 방식, 암호화에 사용하는 난수, 공개키 등등을 교환하죠.
잘못된 형식의 이미지 링크입니다.
자... 여기 우리의 문제가 있습니다.
어찌된건지 TLS 표준을 정한 사람들은 설마 그거까지 까볼거란 생각은 못했는지, 까봐야 어디다 써먹겠냐는 생각이었지 모르겠지만 이 Handshake 과정에서 서버의 이름, 즉 SNI 필드를 암호화 하지 않고 평문으로 보내기로 결정합니다.
위의 예시처럼요. 해당 TLS 패킷이 www.clien.net으로 가고 있다는걸 SNI 필드는 평문으로 노출하게 됩니다.
그래서 현행 SNI 필드를 이용한 HTTPS 차단 방식은 모든 TLS Handshake 패킷을 까본 뒤, SNI 필드의 도메인 값이 차단 대상이면 차단시켜버리는 방식으로 작동합니다.
잘못된 형식의 이미지 링크입니다.
여기까지 읽었으면 TLS 패킷은 평문으로 전송되는 SNI 필드 등 일부 설정 정보를 제외하면 암호화된다는 사실은 매우 당연한데, 많은 분들이 HTTPS 패킷의 내용까지 까본다는 의미로 오해하시더군요.
SNI 필드 등 평문으로 전송되는 일부 메타데이터를 제외하면, HTTPS(TLS)의 내용은 위 스크린샷처럼 암호화되며 제3자가 복호화 할 수 없습니다.
뭐 NSA 쯤 되면 TLS를 실시간으로 풀어내는 미친짓을 성공했을지도 모르겠습니다만... 현재 이게 복호화가 가능하다면 심각한 보안 취약점입니다. 인증서 바꿔치기를 통한 중간자 공격 (MITM) 등을 이용하면 불가능하진 않지만, 그럼 바로 보안 경고가 뜨게 되어있죠.
잘못된 형식의 이미지 링크입니다.
Firefox에서 지원하는 ESNI를 쓰면, 위 스크린샷처럼 SNI 필드까지 암호화되어 전송되기 때문에 근본적으로 위의 문제를 막을 수 있습니다. (Wireshark에서 ESNI 필드를 아직 미지원해서 Unknown type으로 나오는데, Type 0xFFCE가 encrypted_server_name = ESNI 필드입니다. https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-5 참고하세요)
현재 Firefox 및 Cloudflare에 적용되었고, TLS 1.3 표준에 등재되기 위한 논의가 활발히 이뤄지고 있습니다. 즉, ESNI가 보급되면 현행 차단 방식은 무용지물이 된다는 소리죠.
Bonus) 갑자기 급부상한 GoodbyeDPI류의 우회 프로그램은 정보를 추가적으로 암호화 하는 것이 아닌, 패킷을 약간 변조하여 필터링 장비가 탐지하지 못하게 하는 방식으로 작동합니다. 예를 들어, 위의 SNI 필드를 여러개의 TCP 패킷으로 쪼개서 보내더라도 서버가 받아서 해석하는데는 표준상 문제가 없습니다만, 필터링 장비는 아직 쪼개진 패킷을 다시 합쳐서 보지 못하므로 탐지하지 못합니다.
이번에는 DNS에 대해서도 알아볼까요?
잘못된 형식의 이미지 링크입니다.
위 스크린샷은 KT DNS 서버인 168.126.63.1로 www.clien.net 도메인의 IP 주소를 요청하는 DNS 쿼리 패킷입니다.
보시다시피 DNS 또한 암호화되지 않은 평문 통신이며, 따라서 열어보거나 변조가 가능합니다.
현행 DNS 차단 방식은 크게 DNS 오염과 DNS 변조, 총 2가지 방식이 있습니다.
DNS 오염은 통신사 DNS 서버를 사용할 때만 적용 가능하며, 통신사 DNS로 들어오는 쿼리 요청 중 차단 도메인이 있다면 원래 사이트 IP 대신 warning.or.kr의 IP 주소를 대신 보내는 방식으로 작동합니다. 작동 원리 상 망에서 모든 DNS 쿼리를 열어볼 필요도 없고 통신사 DNS 서버만 바꾸면 되지만, 통신사 DNS 대신 구글 DNS 등 다른 DNS 서버를 이용하는 것으로 간단히 우회되죠.
그래서 작년 도입된 DNS 변조 방식은, 모든 DNS 패킷을 열어본 뒤 DNS 패킷의 내용에 차단 대상 도메인이 있다면 차단해버리는 방식으로 작동합니다.
잘못된 형식의 이미지 링크입니다.
이 역시 DNS 통신을 암호화 하는 것으로 해결 되겠죠? 위 스크린샷은 Cloudflare DNS 서버인 1.1.1.1에 www.clien.net의 IP 주소를 쿼리하는 DNS-over-HTTPS 패킷으로, 보시다시피 TLS로 암호화되며 내용을 확인할 수 없습니다.
여기까지 현행 HTTPS/DNS 차단 방식을 패킷 구조를 통해 알아봤습니다.
이것이 과연 '감청'이냐 문제는 법리적인 해석이 필요한 부분이겠습니다만, 제 생각은 통신사에서 라우팅에 필요하지 않은 정보까지 차단을 위해 열어보는 것은 엄연한 감청이며 프라이버시 침해라는 것입니다. 많은 분들이 비판하시는 부분도 마찬가지고요.
오늘 올라온 정부의 정책 브리핑에서는 '감청'을 ‘암호화’되어 송수신되는 전기통신 내용을 ‘열람 가능한 상태로 전환’하여 내용을 파악하는 행위로 정의하였습니다만 (https://m.news.naver.com/read.nhn?mode=LSD&mid=sec&sid1=123&oid=298&aid=0000268618), 감청의 개념을 암호화 통신에만 적용한다면 앞서 말한 HTTP 통신을 포함한 Telnet, FTP, DNS, SMTP 등 암호화되지 않고 평문으로 이뤄지는 수많은 프로토콜의 내용을 제3자가 엿보는 행동 또한 감청이 아니게 되겠죠.
일부 전문가 분들은 TLS Handshake 과정의 정보는 내용이 암호화되어 포함되기 전의 정보이므로 개인정보가 아니니 패킷 감청이라고 보기 어렵다고 보시는 분들도 있습니다만, 글쎄요. 과연 개인이 접속하는 사이트 도메인 주소가 개인정보가 아니라고 할 수 있을지 의문입니다.
http://www1.president.go.kr/petitions/522031
이번 HTTPS 차단 정책 반대 청원 링크로 글을 맺습니다. 틀린 부분에 대한 지적 환영합니다.
공대생들에게 존경을...
HTTP는 발송지, 목적지, 내용이 다 보이고, HTTPS는 발송지, 목적지를 볼 수 있지만, 내용은 볼 수 없는...
TLS 핸드쉐이크 과정에서 교환하는 키, 암호화 방식 등의 정보를 통신사에서 가로채 가지고 있다고 교환되는 패킷을 감청할 수는 없는건가요?
통신사가 아닌 중간 라우터에서도 가능한지도 궁금하구요.
SNI도 들여본다는 것은 결국 패킷을 열어서 내용을 보는건데 더 한일도 가능할 것 같아서요.
즉, TLS Handshake 과정을 가로채더라도, 복호화에 사용되는 키가 포함되어있지 않으므로 복호화는 불가능합니다.
본문에도 나와있지만, 유일하게 가능한 방법은 중간자 공격 (MITM) 방식으로, 중간에 들어가서 속이는거죠. 브라우저에는 내 공개키를 보내줘서 내가 서버인것처럼, 서버에는 내가 브라우저인 것처럼요.
물론 개발자들도 바보가 아니기때문에 위의 공격을 막기 위해 루트 인증서라는 개념을 도입합니다. 즉, 데이터를 주고받기전 양쪽의 신원을 먼저 확실히 확인하는거죠. 이를 위해서는 사전에 루트 인증서 발급 기관으로부터 내가 서버가 맞다는걸 검증받아야하며, 해당 신뢰가 이뤄지지 않는다면 보안 경고가 뜨게 됩니다.
좋은 답변에도 납득이 되지 않는 부분이 있어서 검색해보니 TLS에서는 디피-헬먼 키교환 방식을 쓰고
사전에 교환한 임시키가 충분히 크면 중간에 가로채도 임시키로 서로 만들어 내는 개인키를 현재 컴퓨팅 파워로는 계산하기 힘든 방식이었군요.
암호화는 RSA만 얼추 알고 있었는데 덕분에 좀 더 잘 알게 되었네요.
감사합니다.
dns사이의 암호화 되지않는 통신이든
암호화 되지 않은 sni든 간에
그걸로 접속 차단 하라고 그게 있는게 아닙니다.
그걸로 송수신자가 인터넷 통신 하라고 있는겁니다.
그걸 보고 통신을 방해한건 통비법상 감청에 해당되구요.
가끔 찬성한다는 사람들이 들고나온는,
그걸 기계가 하니까 감청이 아니다
라는건 심각한 말장난입니다.
사람이 의도를 가지고 명령어랑 차단 DB 짜 넣은 기계가
접속차단을 하면, 기계가 차단한 겁니까 사람이 차단한 겁니까?
사람이 프로그래밍해서 만든 자율주행 차가 사람을 치어 죽이면
차가 살인한 겁니까, 자율주행차 만든 사람이 살인한 겁니까?
패킷의 헤더를 열어보는 건 헤더를 열어볼 권한이 있는 자(서버를 포함합니다)만이 할 수 있는 것입니다. 열어볼 권한이 있는지 없는지는 패킷을 만들어 발송하는 자가 결정하는 것이고요. 그 권한이 없는 자가 열어보고 패킷을 자기 마음대로 처리하면 그건 감청-검열입니다.
이 문제는 암호화되어있는지 여부와는 아무 상관 없어요. 편지봉투를 제대로 봉하지 않았다고 해서 아무나 편지봉투를 열어볼 수는 없는 것이니까요.
그래서 따지고 들면 기존의 http 검열도 감청-검열입니다. 그때도 아는 사람들은 감청-검열이라고 생각했지만 시비를 안 건 거죠. 그럼 왜 지금와서 시비를 거는 것일까요? 감청-검열이 강화되기 시작했기 때문입니다. 기존에 그랬던 것에서 나아가 더 강화되기 시작했고, 점점 더 강화될 것이 분명하기 때문이에요. 이걸 “지금까지 그랬으니 문제삼을 이유가 없다”고 하는 건 말도 안 되는 겁니다. 기존의 감청-검열까지 같이 문제를 삼는 것이 맞는 거죠.
http던 https던 개인 패킷의 내용을 보고 필터링하는 것 자체가 감청(위/변조 및 차단)이라고 아무리 얘길해도 전화통화는 어떻게 하냐는 사람들이 있는데 저도 패킷따서 보여줄껄 그랬나봅니다.
개인정보 해당 여부 판단 기준
가. 개인정보 보호법 등 관련 법률에서 규정하고 있는 개인정보의 개념은 다음과 같으며, 이에 해당하지 않는 경우에는 개인정보가 아님
나. 개인정보는 ⅰ)살아 있는 ⅱ)개인에 관한 ⅲ)정보로서 ⅳ)개인을 알아볼 수 있는 정보이며, 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 ⅴ)다른 정보와 쉽게 결합하여 알아볼 수 있는 정보를 포함
ⅰ) (살아있는) 자에 관한 정보이어야 하므로 사망한 자, 자연인이 아닌 법인, 단체 또는 사물 등에 관한 정보는 개인정보에 해당하지 않음
ⅱ) (개인에 관한) 정보이어야 하므로 여럿이 모여서 이룬 집단의 통계값 등은 개인정보에 해당하지 않음
ⅲ) (정보) 의 종류, 형태, 성격, 형식 등에 관하여는 특별한 제한이 없음
ⅳ) (개인을 알아볼 수 있는 정보) 이므로 특정 개인을 알아보기 어려운 정보는 개인정보가 아님
여기서 ‘알아볼 수 있는’의 주체는 해당 정보를 처리하는 자(정보의 제공 관계에 있어서는 제공받은 자를 포함)이며, 정보를 처리하는 자의 입장에서 개인을 알아볼 수 없다면 그 정보는 개인정보에 해당하지 않음
ⅴ) (다른 정보와 쉽게 결합하여) 란 결합 대상이 될 다른 정보의 입수 가능성이 있어야 하고, 또 다른 정보와의 결합 가능성이 높아야 함을 의미
접속하고자 하는 서버 주소만으로는 누구인지는 알수 없음으로 개인정보라고는 말할 수 없겠네요.
‘너무나 당연해서 간략화 혹은 설명 생략한’ 부분
꼬투리 잡는겁니다.
누군지 알 수 없으면 어케 워닝이나 접속불가를 되돌려줍니까?
ㅋㅋㅋ
2. 그렇지만 검열이나 감청에서 문제되는 정보는 개인정보보호법상 개인정보만이 아닙니다. 국가가 사인에게 동의를 받지 않고 대화하는 것을 엿들으면 모두 감청입니다. 통신비밀보호법도 같은 취지입니다.
3. 개인정보보호법을 퍼오신 이유가 무엇인지 잘 모르겠습니다만, “개인정보보호법에 따른 개인정보”만이 감청의 대상이라고 주장하시는 거라면, 심지어 현행법과도 맞지 않는 주장입니다.
서버만 알수 있는거 아닌가요?
어찌된건지 TLS 표준을 정한 사람들은 설마 그거까지 까볼거란 생각은 못했는지, 까봐야 어디다 써먹겠냐는 생각이었지 모르겠지만 이 Handshake 과정에서 서버의 이름, 즉 SNI 필드를 암호화 하지 않고 평문으로 보내기로 결정합니다.
위의 예시처럼요. 해당 TLS 패킷이 www.clien.net으로 가고 있다는걸 SNI 필드는 평문으로 노출하게 됩니다.
그래서 현행 SNI 필드를 이용한 HTTPS 차단 방식은 모든 TLS Handshake 패킷을 까본 뒤, SNI 필드의 도메인 값이 차단 대상이면 차단시켜버리는 방식으로 작동합니다.
모든 TCP/IP 패킷은 IP base로 움직이며 주소 또한 확인 할 수 있습니다만
차단과정에서 보는건 SNI 필드를 보고 서버 주소를 보고.. 불법 서버 주소이면 주소 삭제를 하는 방식이라고 하는데
그럼 송신자를 몰라도 되는 거 아닌가요??
제말이 틀렸는지요??
(지금까지 관련 글들 중에 가장 설명이 잘 되어 있는 것 같습니다 )
그럼 이제 구리선 까서 이어놓고 전화 들어도 되나?
라는 말이 있었죠
재밌게 읽었습니다 ㅎㅎ
통신사가
각 개인별 통화한 정보 .. 송신자 수신자 통화시간 등을 저장 관리하는 것은 어떤지요?
누군지 알아야 통화정보를 저장 관리 할 수 있잖아요
통화정보 관리할때 송신자 번호 수신자 번호만 알면 되듯이, 라우팅도 송신자 IP 수신자 IP만 알면 됩니다. 그거 본다고 뭐라고 하는게 아니에요. 아 당연히 그 정보도 수사기관이 열람하려면 영장 필요한 자료죠.
해당 통신사업을 법적으로 보장받는 통신업자가
송 수신자간 통신을 위해 하는 모든 행위는 감청이 아닙니다.
그걸로 딴짓하라고 통신사업권이 있는게 아니라
송수신자간 통신을 중개하라고 그 사업권이 있는겁니다.
그 정보를 영장없이 제 3자가 보거나,
영장없이 제3자의 의도대로 송수신자간 통신을 방해하거나
하는게 감청이지요.
혹시 IP로 차단하는 방식은 쓸 수 없나요?
보통 대형 사이트들의 IP는 고정되어있는걸로 아는데
통신사에서 특정 사이트의 IP를 추적해서 차단하는 방식은 가능하지 않나요?
오히려 더 쉬울 것 같은데 이렇게 안하는 이유가 있나요?
IP 차단을 못하는 가장 큰 이유는 한 IP에 여러개의 도메인이 연결되는 경우가 매우 많아서 입니다. 웹호스팅이 싹 다 이 구조거든요. IP로 사이트 차단하면, 해당 IP를 공유하고 있는 멀쩡한 다른 사이트들까지 죄다 차단됩니다.
아 물론 중국은 그런거 신경 안쓰고 아이피 차단합니다. 텔레그램 막는다고 AWS 아이피 대역을 전부 차단하는 미친짓도 감행했었죠.
IP 하나에 수많은 사이트가 가능해진 이후부턴
IP차단방식은 쓰지 않습니다.
하나 막다가 수많은 멀쩡한 곳 다 차단되서요...
(우리나라에서 북한으로의 접속은 IP차단 아직 씁니다)
통신사에서 내가 누군가에게 걸었던 전화를 동의 없이 마음대로 차단한다거나 다른곳으로 돌렸다고 생각하시면 쉬울 것 같은데요.
8/28/12-22:14:21.101619 - Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0 HTTP/1.1 GET us.cnn.com /video/data/3.0/video/world/2012/08/28/hancocks-korea-typhoon-bolavan.cnn/index.xml 200 16856 192.168.1.91:45111 -> 157.166.255.18:80tls의 경우엔
12/03/16-19:20:14.85859 10.10.10.4:58274 -> 192.0.78.24:443 VERSION='TLS 1.2' suricata-ids.org NOTBEFORE='2016-10-27T20:36:00' NOTAFTER='2017-01-25T20:36:00'
대충 이렇게 나옵니다... 수리카타의 경우...
법 기술(description)이 네트웍7layer나 tcp/ip, http/https를 일일이 구별하지 않고 일일이 구별할 필요도 없으며 일일이 구별할 이유도 없습니다. 그랬다가는 기술 변화마다 국회에서 매번 법을 개정해야 하는 문제가 있고 여러 개의 기술이 공존하는 경우 하나하나 다 다루어야 하는 문제도 있습니다. 본문에 쓰신 내용들을 몇 줄짜리 조문 몇 개에 말로 풀어내 다 담을 수 없습니다. 법 기술(descripton)이 기술(technics)을 다 담을 수 없어요.
사람 또한 마찬가지입니다.
본문의 http/https를 이해하고 구별할만큼 네트웍을 공부 내지 전공하고 법이나 행정까지 공부 또는 전공해서 법 다루고 행정하라고까지 모든 공무원들에게 요구할 수 없습니다. 되지도 않아요.
법 기술에서는 한 꺼풀 벗기느냐 두 꺼풀 벗기느냐의 차이에 주목하지 않습니다. 현행법제는 http와 https의 차이에 대해 주목하지 않습니다. 현행법상 http와 https의 차이에 큰 의미가 없습니다. 단지 법이 기술하는 바를, 법이 규정하는 바를 http에서 또는 https에서 어떻게 집행할 것인가에 주목할 뿐입니다.
법이 기술을 전부 이해하고 기술의 변화에 대응할 필요는 없으며 애초에 불가능한 일입니다만, 그래도 기본적인 기반은 공유해야하며 그 기반이 완전히 변화했을때는 법도 따라가야겠죠.
결론적으로 현행 차단 방식은 현재 대한민국 법의 몇 줄짜리 조문에도 위배된다고 생각합니다. 본문을 요약하면 통신사에서 볼 필요가 없는 정보까지 차단을 위해 열어보고 있다는 의미니까요. 볼 필요가 있는 정보 / 없는 정보의 구분은 기술의 영역이지만, 통신사에서 볼 필요가 없는 정보를 열어보는 행위는 법에서 금지하고 있지 않습니까.
공통분모가 있어야 한다는 말씀 지당합니다.
하여 법령에 따른 시규나 지침이 따로 있을테고 거기서 구체적으로 규정하는 바도 어느 정도 있겠지만 그 내용을 알 수 없으니 제쳐두고 말씀드리면, 암호문은 정의 규정의 "부호"에 해당한다고 생각합니다. 암호에 국한하는 브리핑 내용에는 저도 동의하지 않습니다.
하지만 말씀하신 정부 브리핑과 관계 없이, 제3자인 통신사업자가 sni를 대조하는데에 그치며 수집활동이 없기 때문에 통비법 정의 규정의 지득 또는 채록이 아니어서 통비법상 감청에 해당하지 않는다고 생각합니다. 불법으로 규정된 사이트에의 접속차단을 방해행위라고 할 것도 아니구요.(정부의 수집활동이 없다는 점에 대해서는 클리앙 어느분께서 정부가 이미 밝혔다는 내용이 담긴 캡쳐로 올리셨더라구요. 출처라 할 수 없는 줄 알지만 그래도 이 부분 양해부탁드립니다. 정부의 수집활동이 없다는 점이 부정되면 저도 더 이상 불법이 아니라 할 생각은 없습니다)
불법사이트에의 접속 차단이라 "방해 "가 성립하지 않는다고 보았습니다.
종래의 http차단과 같이 보아 당연히 제한 근거가 있을거라 생각했는데요
살펴보니 말씀대로 마땅한 근거 법령이 보이지 않네요.
제 생각이 짧았습니다. 말씀 감사합니다.