Cách đây khoảng vài tháng, không hiểu vì lý do gì tôi không còn truy cập được trực tiếp dịch vụ Medium, hỏi han bạn bè thì mọi người cũng bị tình trạng tương tự. Cũng may tôi chưa xuống tiền mua gói membership không thì chắc khóc ròng mất mấy tháng. Sau khi thử một vài thủ thuật kinh điển như đổi DNS, sử dụng DoH,... nhưng đều không ăn thua. Điều này làm cho tôi chợt nhận ra hình như đã có sự tiến hóa nào đó về khả năng kiểm soát Internet của nhà mạng mà tôi đang sử dụng, thú thật đó là tín hiệu tốt.
Để tìm hiểu chuyện gì đang xảy ra với Medium, tôi muốn nói lại một chút về những phương pháp phổ biến mà các ISP thường sử dụng để blacklist một website. Cũng nói thêm thì đây là nghiệp vụ thường xuyên đối với một nhà mạng vì hàng ngày đều phát sinh các website vi phạm chính sách của nước sở tại hoặc vi phạm chính sách chung của nhà mạng. Tuy nhiên, việc chặn này làm sao cho triệt để thì thực sự là không dễ.
1. Chặn bằng DNS
Mô tả: Trước đây (thời kỳ đồ đá của Internet), khi chưa có 8.8.8.8, 1.1.1.1 hay Opendns, một người dùng Internet bình thường hầu như sẽ sử dụng máy chủ phân giải tên miền mặc định của nhà mạng ISP. Điều này là rất thuận tiện cho nhà mạng khi chỉ cần sửa phân giải của tên miền cần chặn về một IP không có thật là ok.
Nhược điểm: Nhược điểm thì quá rõ, người dùng chỉ cần sử dụng 1 DNS khác hoặc biết IP thì sửa trực tiếp file hosts là có thể bypass được cách chặn này.
Cách kiểm tra: Để kiểm tra Medium có bị chặn bằng cách này không, tôi đã đổi DNS server sang 8.8.8.8 và 1.1.1.1 nhưng không ăn thua. Điều này chứng tỏ Medium của tôi không bị chặn qua cách này.
2. Chặn bằng firewall, blackhole
Mô tả: Trong phương pháp này, ip và port của website sẽ bị chặn ngay ở ngõ ra của ISP khi đi ra ngoài. Cơ chế này tương tự như cách chặn lọc của firewall layer 3 nhưng về cơ bản mức ISP không có thiết bị firewall nào có thể chịu được mức tải này. Tôi không chuyên về network nên không thể mô tả cụ thể được nhưng có thể hiểu nôm na là ip sẽ được routing vào hư vô để gói tin không thể đến được đích là máy chủ cung cấp dịch vụ.
Nhược điểm: Ưu điểm thì rất rõ, sẽ rất triệt để đối với đối tượng muốn chặn. Tuy nhiên, điều này sẽ bị vướng rất lớn khi các website hầu như đều sử dụng chung IP theo dạng sharehosting hoặc cao cấp hơn thì đều sử dụng chung 1 hạ tầng Cloud IPS như Cloudflare. Vì vậy, phương pháp này không được sử dụng rộng rãi vì rất dễ dẫn tới chặn nhầm.
Cách kiểm tra: Để kiểm tra Medium có bị chặn không, tôi telnet trực tiếp đến server của Medium. Thật kỳ diệu, tôi thấy vẫn có kết nối. Đến đây thì thực sự kỳ lạ, có kết nối nhưng không trình duyệt thì báo lỗi :-S
3. Chặn bằng DPI
Mô tả: Thực ra nếu biết về DPI thì việc có kết nối nhưng không gửi được gói tin đến server thì cũng không quá khó hiểu. Chặn bằng DPI (Deep Packet Inspection) là phương pháp can thiệp inline quá trình kết nối giữa client và server. Thông thường với phương pháp này, DPI đứng giữa, bóc các gói tin, thường thì ở mức Layer 7 để xác định nội dung. Nếu xác định gói tin có chứa các nội dung cần chặn, module DPI sẽ gửi gói tin TCP Reset cho cả client và server để kết thúc quá trình kết nối. Với cách thức này, việc chặn sẽ hoàn toàn perfect khi không bị phụ thuộc vào IP mà chỉ cần đi sâu vào gói tin http để xác định các http header như host hoặc url.
Nhược điểm: Có 2 nhược điểm lớn trong phương pháp này. Một là hiệu năng, do DPI chạy inline trong luồng request của người dùng nên nếu hạ tầng không đủ lớn, module DPI hiệu năng kém sẽ ảnh hưởng rất lớn đến trải nghiệm của người dùng. Nhược điểm thứ 2 là DPI sẽ không thể phân tích được các gói tin SSL, vì vậy nếu đường truyền được mã hóa trong quá trình kết nối thì gần như phương pháp này sẽ hoàn toàn bị vô hiệu. Nhược điểm số 1 được giải rất đơn giản bằng cách bỏ nhiều tiền để đầu tư hạ tầng lớn. Nhược điểm số 2 là vấn đề lớn về kỹ thuật và là cuộc chiến không hồi kết giữa các chuyên gia mã hóa và các nhà mạng.
4. SNI, ESNI, ECH
Mô tả: Sở dĩ mục mở đầu tôi có dùng từ tiến hóa là vì theo tôi quan sát thì các nhà mạng bị tắc ở cách thức chặn các website https từ rất lâu rồi mà không có cách thức hiệu quả. Medium dùng https và dùng cloudflare hẳn hoi nhưng vẫn bị DPI chặn.
SNI (Server Name Indication) là chìa khóa cho việc chặn này. Nói về SNI thì đây chính là điểm bất lợi cho phương pháp chặn bằng IP nhưng trong phương pháp này thì lại key point. Sở dĩ nói như vậy vì SNI có tác dụng tương tự như trường host trong http header, mục đích là để web server dùng chung phân biệt được request đến các website khác nhau để có các xử lý tương ứng. SNI là 1 trường extend trong gói tin client hello của giao thức SSL. Server dùng chung (ví dụ cloudflare) sẽ dựa vào trường này để tiến hành quá trình key exchange tương ứng với certificate được chỉ định trong trường SNI này. Và điều quan trọng là các trường thông tin ở bước client hello này hoàn toàn không được mã hóa. Đương nhiên DPI sẽ đọc được thông tin này và tiến hành drop.
Nhược điểm: Như đã nói ở trên, đây là cuộc chiến không hồi kết giữa bên bảo vệ privacy là các chuyên gia mã hóa và bên chặn là các nhà mạng. Người đi tiên phong trong chuyện bảo vệ internet privacy là Cloudflare và Firefox. Cloudflare và Firefox đã đề xuất 2 khái niệm là ESNI (Encrypt Server Name Indication ) và mới hơn là ECH (Encrypted Client Hello ). 2 phương pháp này đều hướng tới việc implement cách thức mã hóa trường SNI, key point trong việc mã hóa này là public key sử dụng cho mã hóa được delivery thông qua trường TXT trong giao thức DNS-over-HTTPS. Tuy nhiên hiện tại 2 phương thức này đang ở dạng lý thuyết, quá trình imlement mới ở dạng thử nghiệm ở 1 vài phiên bản Firefox và chưa có sự ổn định. Nhìn dài hơn về tương lai thì các phương thức này hoàn toàn có thể đi vào thực tế và khi đó việc chặn bằng SNI sẽ trở nên khó khăn hơn rất nhiều.
Ảnh: ESNI (https://blog.cloudflare.com/encrypted-client-hello/)
Bonus
Nói là Bonus vì nó không phải là vấn đề chung của các phương pháp chặn truy cập, chỉ là 1 số phát hiện trong việc implement cơ chế DPI của nhà mạng mà tôi đang sử dụng.
HTTP v3 (QUIC)
Cách đây khoảng 1 tháng, tôi phát hiện ra dường như module DPI của nhà mạng tôi đang sử dụng dường như chưa phân tích được các gói tin http v3. Tôi đã có thử nghiệm sử dụng Chrome truy cập website qua giao thức QUIC thì Medium đã không bị chặn, mặc dù trong gói tin bắt tay SSL của QUIC cũng có trường SNI. Tuy nhiên, có vẻ điều này không khó để cải tiến, thời điểm tôi viết bài thì QUIC cũng đã được phân tích và chặn qua trường SNI.
chrome --enable-quic --origin-to-force-quic-on=medium.com:443 --host-resolver-rules='MAP medium.com:443 medium.com:443' https:
Lệnh khởi động Chrome ở chế độ chạy giao thức HTTPS v3 (QUIC)
Theo Google thì QUIC cũng có SNI
Vì thế sớm muộn nó cũng bị DPI chặn cũng không có gì lạ
SNI Wildcard
Có lẽ vì lý do hiệu năng mà DPI không thể chặn theo wildcard. Theo thử nghiệm của tôi thì https://medium.com bị chặn nhưng những domain dạng *.medium.com như https://abcdef.medium.com thì không. Điều này gợi ý cho cách bypass rất đơn giản là trong gói tin client hello, trường SNI sử dụng abcdef.medium.com nhưng trong http header thì sử dụng là medium.com. Tất cả đều rất phù hợp: DPI cho qua, Cloudflare nhận ra https wildcard nên vẫn SSL bắt tay được với server của Medium, server của Medium thì dựa vào trường host để xử lý dữ liệu tương ứng.
Phía trình duyệt thì có thể lợi dụng cơ chế cache certificate, trong lần request đầu, truy cập trang https://abcdef.medium.com để trình duyệt cache Cert wildcard của Medium, ngay sau đó chuyển sang truy cập vào https://medium.com là ok.
Bằng cách này bạn đã có thể "lừa" được DPI
Kết
Nhắc lại một chút, trên phương diện kỹ thuật thì tôi hoàn toàn ủng hộ các cách thức áp dụng để có thể chặn được các website vi phạm chính sách, nó hoàn toàn rất văn minh. Còn tất nhiên, việc này chỉ chặn được người dùng phổ biến, còn đã muốn truy cập thì có rất nhiều cách, sử dụng VPN thì không có cách nào để chặn cả.
Nói về Medium thì đây quả là đáng buồn cho người dùng tại Việt Nam. Đó cũng là 1 trong các lý do mà tôi đã không viết blog trên Medium mà viết trên Hashnode.
