Giới thiệu
Các hệ thống lọc nội dung doanh nghiệp hiện đại của các nhà sản xuất nổi tiếng như Cisco, BlueCoat, FireEye có khá nhiều điểm chung với các đối tác mạnh mẽ hơn của họ - hệ thống DPI, đang được triển khai tích cực ở cấp quốc gia. Bản chất công việc của cả hai là kiểm tra lưu lượng truy cập Internet đến và đi và dựa trên danh sách đen/trắng để đưa ra quyết định cấm kết nối Internet. Và vì cả hai đều dựa trên những nguyên tắc tương tự trong công việc cơ bản của mình nên các phương pháp để vượt qua chúng cũng sẽ có nhiều điểm chung.
Một trong những công nghệ cho phép bạn vượt qua khá hiệu quả cả hệ thống của công ty và Sở KHĐT là công nghệ định tuyến miền. Bản chất của nó là chúng ta đi đến một tài nguyên bị chặn, ẩn sau một miền khác, miền công cộng có danh tiếng tốt, rõ ràng là sẽ không bị chặn bởi bất kỳ hệ thống nào, chẳng hạn như google.com.
Khá nhiều bài viết đã viết về công nghệ này và nhiều ví dụ đã được đưa ra. Tuy nhiên, các công nghệ DNS-over-HTTPS và SNI mã hóa phổ biến và được thảo luận gần đây, cũng như phiên bản mới của giao thức TLS 1.3, giúp có thể xem xét một tùy chọn khác cho tiền tuyến miền.
Hiểu biết về công nghệ
Đầu tiên, chúng ta hãy xác định một số khái niệm cơ bản để mọi người hiểu ai là ai và tại sao tất cả những điều này lại cần thiết. Chúng tôi đã đề cập đến cơ chế eSNI, hoạt động của cơ chế này sẽ được thảo luận thêm. Cơ chế eSNI (Chỉ báo tên máy chủ được mã hóa) là phiên bản bảo mật của SNI, chỉ khả dụng cho giao thức TLS 1.3. Ý tưởng chính là mã hóa, trong số những thứ khác, thông tin về miền mà yêu cầu được gửi đến.
Bây giờ hãy xem cơ chế eSNI hoạt động như thế nào trong thực tế.
Giả sử chúng ta có một tài nguyên Internet bị chặn bởi giải pháp DPI hiện đại (ví dụ: hãy lấy trình theo dõi torrent nổi tiếng rutracker.nl). Khi chúng tôi cố gắng truy cập trang web của trình theo dõi torrent, chúng tôi thấy sơ khai tiêu chuẩn của nhà cung cấp cho biết rằng tài nguyên đã bị chặn:
Trên trang web RKN, tên miền này thực sự được liệt kê trong danh sách dừng:
Khi truy vấn whois, bạn có thể thấy rằng chính miền đó đã bị “ẩn” đằng sau nhà cung cấp đám mây Cloudflare.
Nhưng không giống như các “chuyên gia” từ RKN, những nhân viên am hiểu kỹ thuật hơn từ Beeline (hoặc được dạy bởi kinh nghiệm cay đắng của cơ quan quản lý nổi tiếng của chúng tôi) đã không ngu ngốc cấm trang web theo địa chỉ IP mà thêm tên miền vào danh sách dừng. Bạn có thể dễ dàng xác minh điều này nếu bạn xem những tên miền khác bị ẩn sau cùng một địa chỉ IP, hãy truy cập một trong số chúng và thấy rằng quyền truy cập không bị chặn:
Làm thế nào điều này xảy ra? Làm cách nào để PP của nhà cung cấp biết trình duyệt của tôi nằm trên miền nào, vì tất cả các giao tiếp đều diễn ra thông qua giao thức https và chúng tôi vẫn chưa nhận thấy việc thay thế chứng chỉ https từ Beeline? Anh ta là người thấu thị hay tôi đang bị theo dõi?
Hãy thử trả lời câu hỏi này bằng cách xem xét lưu lượng truy cập qua wireshark
Ảnh chụp màn hình cho thấy rằng trước tiên trình duyệt lấy địa chỉ IP của máy chủ qua DNS, sau đó thực hiện bắt tay TCP tiêu chuẩn với máy chủ đích, sau đó trình duyệt cố gắng thiết lập kết nối SSL với máy chủ. Để thực hiện việc này, nó sẽ gửi gói SSL Client Hello, gói này chứa tên miền nguồn ở dạng văn bản rõ ràng. Trường này được yêu cầu bởi máy chủ giao diện cloudflare để định tuyến kết nối một cách chính xác. Đây là lúc nhà cung cấp dpi bắt chúng tôi, phá vỡ kết nối của chúng tôi. Đồng thời, chúng tôi không nhận được bất kỳ sơ khai nào từ nhà cung cấp và chúng tôi thấy lỗi trình duyệt tiêu chuẩn như thể trang web bị vô hiệu hóa hoặc đơn giản là không hoạt động:
Bây giờ hãy kích hoạt cơ chế eSNI trong trình duyệt, như được viết trong hướng dẫn dành cho :
Để làm điều này, chúng tôi mở trang cấu hình Firefox about: config và kích hoạt các cài đặt sau:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Sau này, chúng tôi sẽ kiểm tra xem các cài đặt có hoạt động chính xác trên trang web cloudflare hay không. và hãy thử lại thủ thuật với trình theo dõi torrent của chúng tôi.
Thì đấy. Trình theo dõi yêu thích của chúng tôi đã mở mà không cần bất kỳ máy chủ VPN hoặc proxy nào. Bây giờ chúng ta hãy xem kết xuất lưu lượng truy cập trong wireshark để xem điều gì đã xảy ra.
Lần này, gói ssl client hello không chứa miền đích một cách rõ ràng mà thay vào đó, một trường mới xuất hiện trong gói - mã hóa_server_name - đây là nơi chứa giá trị của rutracker.nl và chỉ máy chủ giao diện người dùng cloudflare mới có thể giải mã được điều này cánh đồng. Và nếu vậy thì nhà cung cấp dpi không còn lựa chọn nào khác ngoài việc rửa tay và cho phép lưu lượng truy cập như vậy. Không có lựa chọn nào khác với mã hóa.
Vì vậy, chúng tôi đã xem xét cách hoạt động của công nghệ này trong trình duyệt. Bây giờ chúng ta hãy thử áp dụng nó vào những điều cụ thể và thú vị hơn. Và trước tiên, chúng tôi sẽ hướng dẫn cách sử dụng eSNI tương tự để hoạt động với TLS 1.3, đồng thời chúng tôi sẽ xem cách hoạt động của giao diện miền dựa trên eSNI.
Giao diện miền với eSNI
Do Curl sử dụng thư viện openssl tiêu chuẩn để kết nối qua giao thức https, trước hết chúng tôi cần cung cấp hỗ trợ eSNI ở đó. Chưa có hỗ trợ eSNI trong các nhánh chính openssl, vì vậy chúng ta cần tải xuống một nhánh openssl đặc biệt, biên dịch và cài đặt nó.
Chúng tôi sao chép kho lưu trữ từ GitHub và biên dịch như bình thường:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Tiếp theo, chúng tôi sao chép kho lưu trữ bằng Curl và định cấu hình quá trình biên dịch của nó bằng thư viện openssl đã biên dịch của chúng tôi:
$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni
$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug
Ở đây, điều quan trọng là phải chỉ định chính xác tất cả các thư mục chứa openssl (trong trường hợp của chúng tôi là /opt/openssl/) và đảm bảo rằng quá trình cấu hình diễn ra không có lỗi.
Nếu cấu hình thành công chúng ta sẽ thấy dòng:
CẢNH BÁO: esni ESNI đã bật nhưng được đánh dấu THỬ NGHIỆM. Sử dụng cẩn thận!
$ makeSau khi xây dựng gói thành công, chúng tôi sẽ sử dụng tệp bash đặc biệt từ openssl để định cấu hình và chạy Curl. Hãy sao chép nó vào thư mục với cuộn tròn để thuận tiện:
cp /opt/openssl/esnistuff/curl-esni và thực hiện yêu cầu https thử nghiệm tới máy chủ cloudflare, đồng thời ghi lại các gói DNS và TLS trong Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Trong phản hồi của máy chủ, ngoài rất nhiều thông tin gỡ lỗi từ openssl và Curl, chúng ta sẽ nhận được phản hồi HTTP với mã 301 từ cloudflare.
HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/
cho biết rằng yêu cầu của chúng tôi đã được gửi thành công đến máy chủ đích, được nghe và xử lý.
Bây giờ chúng ta hãy xem kết xuất lưu lượng truy cập trong Wireshark, tức là. những gì nhà cung cấp đã thấy trong trường hợp này.
Có thể thấy, đầu tiên, Curl chuyển sang máy chủ DNS để lấy khóa eSNI công khai cho máy chủ cloudflare - yêu cầu DNS TXT tới _esni.cloudflare.com (gói số 13). Sau đó, bằng cách sử dụng thư viện openssl, Curl đã gửi yêu cầu TLS 1.3 đến máy chủ cloudflare trong đó trường SNI được mã hóa bằng khóa chung thu được ở bước trước (gói số 22). Tuy nhiên, ngoài trường eSNI, gói SSL-hello còn bao gồm một trường có SNI mở thông thường, mà chúng ta có thể chỉ định theo bất kỳ thứ tự nào (trong trường hợp này - ).
Trường SNI mở này không được tính đến dưới bất kỳ hình thức nào khi được xử lý bởi các máy chủ cloudflare và chỉ đóng vai trò làm mặt nạ cho nhà cung cấp dpi. Máy chủ cloudflare đã nhận được gói ssl-hello của chúng tôi, giải mã eSNI, trích xuất SNI gốc từ đó và xử lý nó như thể không có chuyện gì xảy ra (nó thực hiện mọi thứ chính xác như kế hoạch khi phát triển eSNI).
Điều duy nhất có thể nắm bắt được trong trường hợp này theo quan điểm của DPI là yêu cầu DNS chính tới _esni.cloudflare.com. Nhưng chúng tôi chỉ mở yêu cầu DNS để hiển thị cách hoạt động của cơ chế này từ bên trong.
Cuối cùng, để gỡ bỏ tấm thảm trong phạm vi dpi, chúng tôi sử dụng cơ chế DNS-over-HTTPS đã được đề cập. Giải thích một chút - DOH là giao thức cho phép bạn bảo vệ khỏi cuộc tấn công trung gian bằng cách gửi yêu cầu DNS qua HTTPS.
Hãy thực hiện lại yêu cầu, nhưng lần này chúng ta sẽ nhận được khóa eSNI công khai thông qua giao thức https chứ không phải DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Kết xuất lưu lượng truy cập yêu cầu được hiển thị trong ảnh chụp màn hình bên dưới:
Có thể thấy, trước tiên, Curl truy cập vào máy chủ mozilla.cloudflare-dns.com thông qua giao thức DoH (kết nối https tới máy chủ 104.16.249.249) để lấy từ chúng các giá trị của khóa chung để mã hóa SNI, sau đó đến đích máy chủ, ẩn đằng sau tên miền .
Ngoài trình phân giải DoH ở trên mozilla.cloudflare-dns.com, chúng ta có thể sử dụng các dịch vụ DoH phổ biến khác, chẳng hạn như từ tập đoàn tà ác nổi tiếng.
Hãy chạy truy vấn sau:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Và chúng ta nhận được câu trả lời:
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH
Trong trường hợp này, chúng tôi đã chuyển sang máy chủ rutracker.nl bị chặn, sử dụng trình phân giải DoH dns.google (không có lỗi đánh máy ở đây, hiện tại tập đoàn nổi tiếng đã có tên miền cấp một của riêng mình) và tự bảo vệ mình bằng một tên miền khác, điều này hoàn toàn phù hợp. bị cấm đối với tất cả các Sở Kế hoạch và Đầu tư để ngăn chặn nỗi đau của cái chết. Dựa trên phản hồi nhận được, bạn có thể hiểu rằng yêu cầu của chúng tôi đã được xử lý thành công.
Như một biện pháp kiểm tra bổ sung xem PPI của nhà cung cấp có phản hồi với SNI mở mà chúng tôi truyền tải dưới dạng vỏ bọc hay không, chúng tôi có thể gửi yêu cầu tới rutracker.nl dưới vỏ bọc của một số tài nguyên bị cấm khác, chẳng hạn như một trình theo dõi torrent “tốt” khác:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Chúng tôi sẽ không nhận được phản hồi từ máy chủ, vì... yêu cầu của chúng tôi sẽ bị hệ thống dpi chặn.
Một kết luận ngắn gọn cho phần đầu tiên
Vì vậy, chúng tôi đã có thể chứng minh chức năng của eSNI bằng cách sử dụng openssl và Curl, đồng thời kiểm tra hoạt động của miền tiền tuyến dựa trên eSNI. Theo cách tương tự, chúng ta có thể điều chỉnh các công cụ yêu thích sử dụng thư viện openssl để hoạt động “dưới vỏ bọc” của các miền khác. Thông tin chi tiết hơn về điều này trong các bài viết tiếp theo của chúng tôi.
Nguồn: www.habr.com