Chặn văn bản rõ trong ứng dụng Android mà không dựa vào VPN

Hai thứ hoàn toàn khác nhau được gọi là chặn văn bản rõ trên Android. Một là chính sách bên trong ứng dụng yêu cầu ngăn xếp mạng của chính nó từ chối HTTP thường. Hai là cách bố trí ở cấp thiết bị nhằm bảo vệ mọi thứ trên điện thoại cùng lúc, thường bằng cách định tuyến lưu lượng qua VPN. Chúng giải quyết các vấn đề khác nhau, và cái thứ hai không thể sửa cái thứ nhất: đường hầm bảo vệ đoạn giữa điện thoại và lối ra, trong khi một ứng dụng nói HTTP vẫn nói HTTP với mọi thứ nằm ngoài lối ra đó.

Hai vấn đề dưới một cái tên

Vấn đề thứ nhất là phần tải: ứng dụng ghi thông tin đăng nhập hoặc token vào một yêu cầu không được mã hóa từ đầu đến cuối, nên mỗi chặng có thể nhìn thấy nó đều có thể đọc nó. Vấn đề thứ hai là đường đi: ứng dụng có thể hoàn toàn đúng đắn, và bạn vẫn muốn nhà mạng Wi-Fi địa phương không biết gì về nơi nó kết nối. VPN chỉ xử lý vấn đề thứ hai.

Sự phân biệt đó quyết định ai sở hữu việc sửa. Phần tải thuộc về người phát hành ứng dụng, vì chỉ đoạn mã đó quyết định URL nào được gọi và chứng chỉ có được xác thực hay không. Đường đi thuộc về thiết bị hoặc mạng, vì đó là chuyện gói tin đi đâu, không phải chúng chứa gì.

Đường thứ nhất: ứng dụng bạn kiểm soát

Nếu bạn phát hành ứng dụng, việc sửa là một quyết định về truyền tải cộng với chính sách thực thi nó. Trỏ mọi điểm cuối vào HTTPS, giữ nguyên việc xác thực tên máy chủ và chứng chỉ, và xóa đường lui về HTTP thường thay vì để nó cách một cờ cấu hình. Chuyển hướng không giúp gì ở đây: một yêu cầu HTTP nhận 301 đã gửi tiêu đề và nội dung của nó một cách công khai, nên thông tin đăng nhập không bao giờ được đi với giả định rằng chuyển hướng sẽ bảo vệ chúng.

Từ Android 7.0, Network Security Configuration diễn đạt chính sách. Tệp dưới đây là phiên bản hữu ích nhỏ nhất: nó từ chối văn bản rõ ở mọi nơi trừ khi một ngoại lệ riêng cho tên miền nói khác.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

Tham chiếu tài nguyên đó từ manifest, sau đó đọc các ngoại lệ đã có trước khi phát hành. Một tên miền gỡ lỗi cũ hoặc một mục SDK của nhà cung cấp thanh toán có thể âm thầm cho phép lại văn bản rõ cho máy chủ mà bạn đang cố bảo vệ.

Hai chi tiết phiên bản đáng biết. Ứng dụng nhắm tới API 28 trở lên đã mặc định từ chối văn bản rõ, nên một ứng dụng vẫn nói HTTP thường hoặc nhắm tới mức API cũ hơn hoặc có một ngoại lệ ở đâu đó. Và khi có cấu hình bảo mật mạng, thuộc tính manifest cũ hơn android:usesCleartextTraffic không còn quyết định câu hỏi đó nữa, đó là lý do đôi khi thay đổi cờ ấy có vẻ không làm gì cả.

Đường thứ hai: ứng dụng bạn không kiểm soát

Với một ứng dụng của bên thứ ba đã cài đặt, bạn không thể viết lại cấu hình bảo mật của nó bằng một cài đặt người dùng. Các lựa chọn thực tế là các kiểm soát kết nối an toàn của chính sản phẩm, một giải pháp thay thế được duy trì đã dùng TLS, hoặc chính sách thiết bị được quản lý giới hạn những gì thiết bị được chạy. Đó là những cam kết khác nhau, và chỉ cái thứ ba mở rộng tới cả một đội thiết bị.

Các quy tắc mạng là những thứ thay thế yếu hơn vẻ ngoài của chúng. Chỉ cho phép cổng 443 không thực thi TLS có xác thực, vì nhiều giao thức văn bản rõ có thể được chuyển sang cổng đó, và chặn cổng 80 không bao phủ văn bản rõ trên các cổng khác. Chế độ chỉ-HTTPS của trình duyệt cũng chỉ giới hạn trong trình duyệt đó, không áp dụng cho ứng dụng thư hay trò chuyện riêng trên cùng điện thoại.

Cài một chứng chỉ chặn bắt để lưu lượng trông như được mã hóa là thay đổi niềm tin, không phải sửa chữa. Nó thay thế việc xác thực máy chủ của ứng dụng bằng của bạn, và một ứng dụng vốn không xác thực chứng chỉ thì không được sửa bằng cách đó; bạn chỉ chuyển ai có thể đọc luồng.

VPN giúp ở đâu và không giúp ở đâu

Đường hầm là công cụ đúng khi yêu cầu là mạng cục bộ không biết gì về kết nối, hoặc ứng dụng cần tới một dịch vụ riêng mà nếu không thì không tới được. Nó là công cụ sai để bắt một ứng dụng khách HTTP nói HTTPS, vì yêu cầu rời đường hầm đúng như khi vào.

Android thêm một ràng buộc thực tế: nền tảng chỉ chạy một dịch vụ VPN tại một thời điểm. Một ứng dụng lọc cục bộ chiếm chỗ đó sẽ cạnh tranh với đường hầm từ xa mà bạn thực sự cần, và chuyển đổi giữa hai thứ là thao tác ở cấp thiết bị chứ không phải cấp ứng dụng. Chỗ duy nhất đó là lý do tốt để giữ chính sách phần tải trong ứng dụng và dành đường hầm cho đường đi.

Trường hợp duy nhất hai thứ chồng lên nhau là một máy chủ riêng mà bạn cũng vận hành. Ở đó đường hầm có thể làm đường đi thành riêng tư dù giao thức vẫn là văn bản rõ, điều này giảm phơi nhiễm nhưng không thay đổi phần tải là gì. Hãy coi đó là giảm rủi ro, không phải mã hóa dữ liệu.

Cần kiểm tra gì trước khi gọi là đã chặn

Bắt đầu với mặc định khiến người ta ngạc nhiên: một ứng dụng nhắm tới API 28 trở lên lẽ ra đã từ chối văn bản rõ, nên hãy kiểm tra mức mục tiêu trước khi thêm cấu hình trùng lặp một mặc định. Sau đó cố ý kiểm tra trường hợp thất bại: một yêu cầu tới máy chủ HTTP thường phải thất bại chứ không được âm thầm thành công qua đường lui.

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

Với trường hợp thành công, xác nhận rằng lời gọi HTTPS xác thực một chuỗi chứng chỉ thật và một proxy có chứng chỉ không tin cậy bị từ chối chứ không được chấp nhận. Một lần bắt tay thành công với bất kỳ chứng chỉ nào chưa chứng minh được gì về an toàn truyền tải.

Với một ứng dụng của bên thứ ba, hãy ghi lại ranh giới mà bạn thực sự có thể thực thi, dù đó là chính sách thiết bị được quản lý, một quy tắc mạng hay không gì cả, và nói điều đó trong tiêu chí chấp nhận. hướng dẫn cấu hình bảo mật Android liệt kê các mặc định của nền tảng và những thành phần nào tuân thủ chính sách, và chính phần đó quyết định cấu hình của bạn có làm được gì hay không.