HTTPS 트래픽 감지에 대한 Wehe의 단점 이해

~에 의해 Net Neutrality: Unbiased Internet Access for All! 7m2024/04/11

너무 오래; 읽다

이 연구에서는 특히 HTTPS 트래픽에서 트래픽 차별화를 감지할 때 Wehe 앱이 직면한 과제를 조사합니다. 네트워크 응답, 트래픽 속도, 포트 사용, 네트워크 부하 효과 및 NAT 장치 처리 제약 조건과 관련된 문제를 논의하고 다양한 시나리오에서 TD를 감지하는 Wehe의 한계를 조명합니다.

featured image - HTTPS 트래픽 감지에 대한 Wehe의 단점 이해

저자:

(1) Vinod S. Khandkar 및 Manjesh K. Hanawal, 산업 공학 및 운영 연구 인도 기술 연구소 봄베이(인도 뭄바이) 및 {vinod.khandkar, mhanawal}@iitb.ac.in.

링크 표

개요 및 소개

V. HTTPS 트래픽에 대한 WEHE의 단점

우리의 연구는 다양한 네트워크 구성에서 재생된 트래픽 스트림, TD 감지 및 운영 타당성에 대한 네트워크 응답을 검증하는 데 중점을 둡니다. 운영 타당성은 Google Playstore에서 공개적으로 사용 가능한 "Wehe" Android 앱을 사용하여 검증되는 반면, TD 탐지 시나리오는 이론적 인수를 사용하여 검증됩니다. 네트워크 응답을 검증하려면 수신된 트래픽 스트림의 대역폭 분석이 필요합니다. 이 분석에는 검증 시나리오에 따라 수행된 특정 재생에 대한 네트워크 로그가 필요합니다. 장치 및 기타 여러 스트리밍에서 수행된 재생

그림 6. 재생된 YouTube 트래픽의 트래픽 분류

병렬로 실행되는 서비스는 그러한 시나리오 중 하나입니다. Wehe 앱은 테스트 완료 후 재생을 위한 네트워크 로그를 즉시 제공하지 않습니다. 그래서 우리는 Wehe 도구의 동작을 모방하는 사용자 클라이언트와 서버를 구현했습니다.

우리는 Wehe를 검증하기 위해 그림 3에 표시된 설정과 유사한 클라이언트-서버 설정을 사용합니다. 현재 설정에서는 원래 서비스의 서버를 재생 서버로 교체했습니다. 사용자 클라이언트와 재생 서버는 상용 트래픽 셰이퍼를 통해 연결됩니다. 게다가 우리의 설정에는 여러 재생을 병렬로 수행할 수 있는 조항이 있습니다. 우리의 검증 설정에는 부채널과 같은 관리 채널과 오버헤드가 필요하지 않습니다. 우리 서버는 항상 단일 사용자 클라이언트를 지원해야 합니다. 여러 클라이언트를 사용한 시나리오 검증에는 관련 트래픽 분석이 필요하지 않기 때문에 Wehe 앱을 직접 사용합니다.

이 섹션의 알림은 검증 결과를 설명합니다.

A. 기존 서비스의 트래픽 에뮬레이션

네트워크 응답은 Sec.III-A에 언급된 대로 네트워크 미들박스에 의한 올바른 검색 트래픽 분류를 기반으로 하는 네트워크 정책 적용에 따라 달라집니다. 우리는 상업용 트래픽 셰이퍼를 사용하여 Wehe의 에뮬레이트된 트래픽 분류를 검증했습니다. 에뮬레이트된 트래픽의 분류는 상업용 트래픽 셰이퍼의 사용자 인터페이스를 사용하여 관찰됩니다.

실험을 수행하기 위해 YouTube 애플리케이션 데이터는 상용 트래픽 셰이퍼를 통해 재생 서버에서 사용자 클라이언트로 재생됩니다. 데이터 전송 중에 상업용 트래픽 셰이퍼의 사용자 인터페이스 창에서 YouTube 트래픽이 있는지 관찰합니다. 또한 인터넷 브라우저를 사용하여 YouTube 트래픽에 액세스하고 트래픽 분류 관찰의 기준을 설정하기 위해 트래픽 셰이퍼의 분류 결과를 관찰했습니다.

그림 6은 유튜브 서버에서 인터넷 브라우저를 통해 직접 접속한 트래픽에 대한 상용 트래픽 셰이퍼의 사용자 인터페이스 창을 통해 트래픽 분류 결과를 보여준다. 왼쪽 창에는 인터넷 활동이 표시되고 오른쪽 창에는 해당 트래픽의 분류가 표시됩니다.

그림 6(a)는 인터넷 브라우저를 통해 접속한 트래픽이 YouTube로 올바르게 분류되었음을 보여준다. 이는 상업용 트래픽 셰이퍼의 의도된 동작과 일치합니다.

그림 6(b)는 사용자-클라이언트를 이용하여 접속한 트래픽에 대한 트래픽 분류 결과를 보여준다. 이는 통신 링크를 통해 YouTube 트래픽이 전송되지 않았다는 증거를 보여줍니다. 또한 동일한 트래픽을 HTTPS 트래픽으로 분류합니다. 이 실험의 결과는 모든 네트워크 미들박스가 Wehe의 재생 트래픽을 올바르게 분류할 수 있는 것은 아니라는 것을 보여줍니다.

B. 재생 스크립트의 데이터 속도 효과

프로빙 트래픽 생성은 TD 감지 알고리즘이 예상하는 대로 네트워크 응답에 영향을 미칩니다. Wehe는 원래 서비스의 트래픽 추적을 사용하여 애플리케이션 데이터와 타이밍 관계를 보존하는 재생 스크립트를 생성합니다. 이 재생 스크립트는 원래 네트워크와 지리적 위치가 다른 네트워크에서도 사용됩니다. 트래픽 조절 속도는 동일한 서비스에 대해 네트워크마다 다르기 때문에([32]에서 언급한 바와 같이) 재생 스크립트에 보존된 트래픽 속도는 현재 고려되는 네트워크의 트래픽 조절 속도와 다를 수 있습니다. 재생 트래픽 비율은 트래픽 형성 비율보다 낮을 수 있습니다.

Wehe 방법론은 재생 스크립트의 트래픽 속도가 네트워크의 형성 속도보다 낮은 경우 트래픽 스트림에 영향을 주지 않으므로 트래픽 차별화를 감지하지 않습니다. 이러한 재생 스크립트는 해당 네트워크에서 트래픽 형성을 감지할 수 없습니다. 따라서 Wehe 도구의 TD 감지 기능은 재생 스크립트의 탐색 트래픽 속도에 의해 제한됩니다.

다. 포트번호 80번의 사용법

네트워크 응답은 프로빙 트래픽에 대한 네트워크 미들박스 인식에 따라 결정됩니다(섹션 III-A 참조). 재생 스크립트는 애플리케이션의 원래 네트워크 추적에 있는 데이터를 보존합니다. 원래 애플리케이션 서버는 일반 텍스트 데이터에 포트 80을 사용하고 암호화된 데이터 전송에 포트 443을 사용합니다. Wehe 재생 스크립트는 애플리케이션 네트워크 추적의 암호화된 데이터를 직접 사용하여 포트 80에서 전송합니다. 이 경우 Wehe는 암호화된 애플리케이션 데이터를 사용하여 네트워크 장치에서 원래 재생 트래픽 스트림이 올바르게 분류될 것으로 기대합니다. 암호화된 트래픽 데이터는 네트워크 장치에 ID를 노출할 수 없기 때문에 포트 80의 데이터는 불가능합니다. 따라서 Wehe 도구는 재생 실행을 위한 포트 80의 기본 사용으로 인해 포트 번호 443에서 실행되는 서비스에 필요한 트래픽 스트림을 생성할 수 없습니다.

D. 트래픽 부하에 따른 네트워크 동작

리소스가 부족하면 네트워크는 특히 QoS 기반 트래픽 관리(섹션 III-A 참조)와 같이 네트워크의 모든 활성 서비스에 유용한 특정 네트워크 트래픽 관리(특히 과도한 네트워크 로드 시나리오)를 적용해야 합니다. 이러한 트래픽 관리의 효과를 검증했습니다.

그림 7. 네트워크 부하가 Wehe의 트래픽 스트림 성능에 미치는 영향

컨트롤과 오리지널 리플레이의 성능에 관한 것입니다. 검증에서는 검증을 위해 다음 세 가지 시나리오를 사용합니다.

• 네트워크에 부하 없이 Wehe의 두 가지 트래픽 스트림만 재생 (그림 7(a))

• 병렬로 실행되는 하나의 추가 스트리밍 서비스로 Wehe의 세 가지 트래픽 스트림을 재생합니다(그림 7(b)).

• 병렬로 실행되는 2개의 추가 스트리밍 서비스를 사용하여 Wehe의 3개 트래픽 스트림을 재생합니다(그림 7(c)).

그림 7(a)의 성능은 Wehe 도구에 의해 생성된 트래픽 스트림의 성능이 추가 네트워크 부하 조건이 없는 경우에도 동일함을 보여줍니다. 네트워크 부하가 증가함에 따라 제어 재생의 성능은 원래 재생의 성능과 더 높은 수준에서 벗어납니다(그림 7(b)). 제어 재생의 성능은 아래쪽의 원래 재생에서 더 벗어나지만 두 개의 원래 재생은 그림 7(c)에 표시된 것처럼 여전히 유사한 성능을 보여줍니다. 이는 제어 재생이 차별화되지 않을 것이라는 Wehe 도구의 기대를 무효화합니다. 또한 총 대역폭으로 인해 TD를 감지하는 도구의 주장도 무효화됩니다.

E. Wehe는 동일한 서브넷 내의 여러 장치에서 테스트합니다.

여러 사용자 클라이언트를 동시에 지원하기 위해 Wehe 디자인에 사이드 채널이 도입되었습니다. 또한 사이드 채널은 사용자-클라이언트와 IP 주소 및 포트 조합 간의 매핑을 식별하는 데 도움을 줍니다. NAT를 사용하는 네트워크의 경우에 유용합니다[33]. 우리는 두 가지 다른 테스트를 사용하여 여러 클라이언트 및 NAT 지원 네트워크에 대한 Wehe의 지원을 검증했습니다. 먼저 동일한 서브넷 내에서 두 개의 사용자 클라이언트, 즉 동일한 공용 IP 주소를 공유하는 클라이언트를 연결했습니다. 한 테스트에서 Wehe 도구는 두 장치 모두에서 동일한 서비스를 테스트합니다. 예를 들어 두 장치의 Wehe 앱은 YouTube에 대해 테스트합니다. 결과에 따르면 Wehe 테스트는 한 기기에서만 완료되었지만 다른 기기에서는 Wehe 앱이 갑자기 종료된 것으로 나타났습니다. 동일한 시나리오를 반복했지만 이번에는 Wehe가 다양한 서비스를 테스트합니다. 예를 들어 Wehe는 한 장치에서 YouTube를 테스트하는 동안 다른 장치에서는 Netflix를 테스트합니다. 우리는 그림 9와 같이 한 장치의 Wehe 테스트가 제대로 완료되는 반면 다른 장치의 Wehe 테스트는 화면에 오류를 표시하여 다른 클라이언트가 이미 테스트를 수행하고 있음을 사용자에게 알리는 것을 발견했습니다. 이 테스트는 Wehe가 수행함을 보여줍니다. 동일한 IP 주소를 공유하는 경우 여러 장치를 지원하지 않습니다. 사이드 채널은 Wehe 재생 서버에 직접 연결된 사용자 클라이언트에서 각 재생을 식별하는 데 유용하지만 NAT 장치를 사용하는 네트워크에서는 유용하지 않습니다. NAT의 경우 여러 사용자가 동일한 IP 주소를 공유합니다. 이러한 경우 사이드 채널은 각 재생 실행을 클라이언트에 고유하게 매핑할 수 없습니다. Wehe의 사용은 재생 서버, ISP 및 애플리케이션당 하나의 활성 클라이언트로 제한됩니다. 이 제한 사항은 Wehe 개발자도 문서화했습니다.

F. TD 감지에 대한 장치 네트워크 부하의 영향

Wehe의 재생 서버는 원래 애플리케이션 트래픽과 동일한 애플리케이션 데이터 전송 타이밍을 사용합니다. 이러한 전송 전략은 사용 가능한 대역폭을 소진하지 않을 것으로 예상됩니다. 따라서 사용 가능한 대역폭을 초과하는 트래픽 속도의 오버슈팅으로 인한 소스 속도 변조의 효과는 거의 발생하지 않습니다. 네트워크 정책, 즉 TD에 의해 의도적으로 수정되지 않는 한 원본 및 제어 재생은 유사한 트래픽 성능을 보여줍니다.

그럼에도 불구하고 Wehe 테스트를 수행하는 동안 트래픽 데이터 속도가 사용자 장치의 네트워크 부하에 의해 변조되기 때문에 이러한 기대가 항상 충족되는 것은 아닙니다. 이러한 교란은 시간에 따라 변하는 현재 네트워크 로드가 프로빙 트래픽에 미치는 영향도 시간에 따라 변하고 항상 동일하지 않을 수 있으므로 불일치를 만듭니다. Wehe의 연속 재생 전략은 두 가지(원본 및 제어 재생) 탐색 트래픽 스트림이 현재 네트워크 로드에 따라 서로 다른 영향을 받도록 보장합니다. 장치 측의 이러한 네트워크 부하에서는 서비스가 사용 가능한 대역폭을 소진하지 않는다는 개념과 TD 감지에 대한 이점이 더 이상 존재하지 않습니다. TD를 검출하기 전에 이러한 교란 요인(Sec. III-B 참조)을 정규화하는 것이 필요합니다.