Android 14, ngay cả quyền root cũng chặn việc sửa chứng chỉ hệ thống?
(httptoolkit.com)- Android 14 (API v34) đổi cách đọc chứng chỉ CA hệ thống: không còn từ
/systemmà từ mô-đuncom.android.conscryptdựa trên APEX, làm hỏng luồng debug trước đây vốn chèn chứng chỉ bằng quyền root - Từ Android 7 Nougat, kho tin cậy mặc định của ứng dụng đã tách thành CA hệ thống và CA người dùng, nên các công cụ phát triển, kiểm thử và reverse engineering lâu nay phụ thuộc vào cách sửa trực tiếp thư mục CA hệ thống
- Cấu trúc mới cho phép cập nhật chứng chỉ CA qua Google Play System Update, giúp gỡ bỏ CA có vấn đề và phát hành CA mới nhanh hơn, nhưng làm giảm quyền kiểm soát của chủ sở hữu thiết bị
- Trên trình giả lập beta Android 14, ngay cả khi ghi đè bằng tmpfs hoặc xóa
/system/etc/security/cacerts,/system/etc/security/cacerts_google,/apex/com.android.conscrypt/cacertsv.v., Settings và ứng dụng vẫn tiếp tục nhìn thấy danh sách CA của Google - Tại thời điểm bài viết được đăng, các lựa chọn thực tế là tiếp tục dùng Android 13 hoặc OS tùy biến không dùng APEX; về sau, tác giả cho biết đã xuất hiện nhiều cách vượt qua để chèn chứng chỉ trên Android 14
Diễn tiến thay đổi trong quản lý CA trên Android
- Khi Open Handset Alliance công bố Android vào năm 2007, nền tảng này nhấn mạnh tính mở bằng các cụm như “open platform”, “complete access to handset capabilities and tools”
- Theo thời gian, phạm vi mà người dùng, nhà phát triển và nhà nghiên cứu có thể kiểm soát thiết bị của mình ngày càng bị thu hẹp
-
Bước chuyển ở Android 7 Nougat
- Danh sách CA mà chủ sở hữu thiết bị có thể sửa được bị tách thành CA hệ thống và CA người dùng
- Danh sách CA hệ thống cố định do nhà cung cấp OS đưa ra trở thành mặc định cho mọi ứng dụng
- Danh sách CA mà người dùng có thể sửa chỉ được dùng khi ứng dụng chủ động opt-in
- Kết quả là gần như mọi ứng dụng đều không còn mặc định tin CA người dùng
Vì sao chứng chỉ CA quan trọng
- Các CA được thiết bị tin cậy là danh sách tổ chức bảo đảm an toàn cho lưu lượng mạng được mã hóa
- CA có thể phát hành chứng chỉ cho bất kỳ tên miền nào để dùng trong kết nối TLS như HTTPS, và thiết bị tin CA đó sẽ xem chứng chỉ ấy là bằng chứng của kết nối hợp lệ
- Nếu người dùng làm cho thiết bị tin một CA do chính mình tạo, họ có thể chặn và xem lưu lượng HTTPS hoặc TLS của mình
- Có thể kiểm tra dữ liệu điện thoại gửi và nhận
- Nếu cần, cũng có thể sửa đổi hoặc chặn dữ liệu đó
- Kiểu kiểm soát này quan trọng với nghiên cứu bảo mật và quyền riêng tư, reverse engineering, debug và kiểm thử ứng dụng, cấu hình mạng nội bộ doanh nghiệp, cũng như với người dùng không muốn tin các CA mặc định
- Việc khiến người dùng không chuyên khó vô tình thay đổi CA hoặc ngăn CA bị thay đổi mà họ không biết là hợp lý, nhưng nếu hạn chế luôn cả quyền kiểm soát của người dùng nâng cao thì nhiều trường hợp sử dụng sẽ trở nên khó khăn
Cách vượt qua bằng root sau Android 7
- Ngay cả sau Android 7, trên thiết bị đã có quyền root vẫn có thể thao tác trực tiếp kho CA hệ thống
- Cách tiêu biểu là đặt chứng chỉ cần tin cậy vào
/system/etc/security/cacerts/ /systemthường là chỉ đọc ngay cả trên thiết bị root, nên có hai cách thường dùng- Remount thư mục
/systemthành ghi được, khởi động lại rồi sửa trực tiếp thư mục chứng chỉ hệ thống thật - Mount một filesystem đọc/ghi tạm thời lên trên thư mục chỉ đọc, sao chép các CA hiện có rồi thêm chứng chỉ mới
- Remount thư mục
- Để chứng chỉ được hệ thống chấp nhận, còn phải khớp các điều kiện như tên tệp, quyền và nhãn SELinux
- HTTP Toolkit đã tự động hóa quy trình dựa trên mount tạm thời này để cung cấp thiết lập chặn bắt một cú nhấp trên thiết bị Android root hoặc trình giả lập
- Cách tiếp cận này hoạt động trên hầu hết thiết bị root tùy biến, bản phân phối Android đặc biệt và image trình giả lập chính thức của Google
- Ngoại lệ là các image full “Google Play” bị khóa như thiết bị OEM thông thường
- Tài liệu cấu hình mitmproxy, nhiều bài blog, câu trả lời trên StackOverflow, bài viết diễn đàn, gói Magisk và hướng dẫn của cacert.org cũng dùng cách tương tự
Cấu trúc cập nhật CA mới của Android 14
- Tại thời điểm bài viết, Android 14 đang ở giai đoạn beta cuối và dự kiến phát hành trong vài tuần
- Một trong các tính năng bảo mật chính là chứng chỉ CA có thể cập nhật từ xa
- Quản lý chứng chỉ CA được tách khỏi image OS cốt lõi và chuyển sang một thành phần riêng được phân phối, cập nhật qua Google Play
- Với cấu trúc này, Google có thể thu hồi niềm tin với CA có vấn đề nhanh hơn
- Không còn phải chờ từng hãng điện thoại phát hành bản cập nhật OTA cho toàn bộ OS
- Chỉ với Google Play System Update cũng có thể thay đổi danh sách CA trên thiết bị Android 14+
- Các CA tin cậy mặc định có quyền lực rất lớn nên cần giám sát và chế tài, và quyền của CA thất bại phải bị gỡ bỏ nhanh chóng
- Ví dụ, vào tháng 1/2023, TrustCor đã mất niềm tin CA từ Google và các bên lớn khác sau khi bị phát hiện có liên hệ chặt chẽ với tổ chức phát tán mã độc và các nhà thầu quốc phòng, tình báo Mỹ
- Ở chiều ngược lại, chậm phát hành CA mới cũng gây vấn đề
- Let’s Encrypt đã nhiều lần phải trì hoãn việc triển khai cải thiện chuỗi ký vì các thiết bị Android cũ không có CA gốc mới nhất
- Bản thân cấu trúc giúp tăng tốc phản ứng cập nhật CA là có giá trị, nhưng cách triển khai trên Android 14 khiến việc sửa CA hệ thống gần như không còn khả thi
Vị trí tệp thực tế và cách APEX hoạt động
- Thay đổi cốt lõi trên Android 14 là nếu có
/apex/com.android.conscrypt/cacertsthì chứng chỉ sẽ được đọc từ đó thay vì/system/etc/security/cacertsnhư trước /apexlà đường dẫn nơi các container APEX được mount; APEX là viết tắt của Android Pony EXpress- Mô-đun APEX là các thành phần hệ thống có thể cập nhật độc lập và được phát hành dưới dạng container bất biến có chữ ký
- Trên Android 14, chứng chỉ CA trở thành một phần của mô-đun
com.android.conscrypt, tức thư viện TLS/SSL cốt lõi của Android - Cách APEX hoạt động ở mức thấp chưa được tài liệu hóa đầy đủ, và một số liên kết chi tiết cốt lõi được cho là chỉ có trên trang nội bộ của Google
- Theo thử nghiệm, nội dung mô-đun APEX được lộ ra trực tiếp cho từng tiến trình, nên dù sửa tệp ở chỗ khác thì nội dung mà ứng dụng nhìn thấy cũng không thay đổi
Hiện tượng quan sát được trên trình giả lập Android 14
- Image AOSP và “Play Services” của trình giả lập chính thức Android 14 beta cho phép truy cập root
- Image “Google Play” thì bị khóa như thiết bị OEM thông thường
- Có thể tạo trình giả lập bằng image API 34 “Google APIs” và mở root shell
- Nhưng ngay cả khi ghi đè bằng tmpfs theo cách cũ lên các đường dẫn sau, hiệu ứng mong đợi vẫn không xảy ra
/system/etc/security/cacerts/system/etc/security/cacerts_google/apex/com.android.conscrypt/cacerts/apex/com.android.conscrypt@340818022/cacerts
- Trong Settings → Security & Privacy → More → Encryption → Trusted Credentials, tab “System” vẫn hiện nguyên các chứng chỉ tưởng như đã bị ẩn
- Ví dụ, nếu tìm tệp chứng chỉ “ACCV”
3c9a4d3b.0trên toàn filesystem thì trong lúc bị mount che đi, tệp đó không còn thấy nữa, nhưng Settings vẫn tiếp tục hiển thị - Khi làm cùng quy trình trên image Android 13, danh sách chứng chỉ trong Settings trống rỗng, tức cách cũ hoạt động đúng như dự kiến
Ngay cả sửa trực tiếp system image cũng thất bại
- Có thể khởi động trình giả lập Android 14 với
-writable-system, rồi chạyadb root,adb remount,avbctl disable-verification, khởi động lại v.v. để biến hệ thống thành ghi được - Sau đó có thể xóa chứng chỉ trong
/system/etc/security/cacerts/*và/system/etc/security/cacerts_google/* - Nhưng không thể xóa chứng chỉ trong
/apex- Ngay cả sau remount, nó vẫn ở chế độ chỉ đọc
- Lệnh
mount -o remount,rw ...cũng thất bại
- Thao tác gần nhất có thể làm là
umountđường dẫn chứng chỉ đó để nó biến mất khỏi đầu ra củamount - Dù vậy, danh sách “Trusted” trong Settings vẫn tiếp tục nạp các chứng chỉ CA
- Đây không phải vấn đề cache của ứng dụng Settings; xét từ góc nhìn kho chứng chỉ mà ứng dụng nhìn thấy thì hiện tượng cũng giống hệt
- Dù sửa filesystem thế nào, ứng dụng vẫn tiếp tục nhìn thấy danh sách CA của Google
Tác động và giới hạn
- Trên Android 14, luồng cũ cài chứng chỉ CA hệ thống để phục vụ debug, reverse engineering, kiểm thử và nghiên cứu đã bị phá vỡ
- Tại thời điểm đó, các lựa chọn thay thế là giữ Android 13 hoặc dùng bản phát hành OS tùy biến không dùng mô-đun APEX cho quản lý chứng chỉ CA
- Nhưng theo thời gian, những lựa chọn này có thể ngày càng kém thực tế vì phải tách khỏi thành phần nội bộ cốt lõi của Android mainline hoặc tiếp tục dùng phần mềm cũ
- Nếu nội dung trong mô-đun APEX không thể bị sửa ngay cả với quyền root, thì mỗi thành phần hệ thống được chuyển sang APEX trong tương lai có thể lại làm giảm thêm quyền kiểm soát của người dùng
- Điều này cũng có thể gây vấn đề cho các nhánh Android như GrapheneOS, LineageOS, cũng như Magisk và nhiều mô-đun khác
- Tuy nhiên, như cập nhật ở đầu bài cho biết, về sau thông qua thảo luận và nghiên cứu vượt qua, đã xuất hiện nhiều giải pháp cho phép chèn chứng chỉ trên Android 14
- Nếu muốn debug lưu lượng HTTPS trên Android 14, sẽ khó có thể tiếp tục giả định rằng chỉ cần chèn CA hệ thống dựa trên root là đủ
1 bình luận
Các ý kiến trên Hacker News
Từ góc nhìn của người từng làm với các công cụ root Android cũ, các ROM tùy biến phổ thông hiện đại và nhiều công việc liên quan đến Android OS, tôi cho rằng tiêu đề này sai cả hiện tại lẫn về sau
Khi nói root trên Android thì đúng nghĩa là quyền root, và có thể làm bất cứ điều gì mình muốn [1]
Công cụ root Android hiện nay là Magisk có cả khả năng “sửa” mã Java, nên dù có bị giấu sâu đến đâu thì vẫn phải có cách truy cập
Việc tác giả không làm được không có nghĩa là bất khả thi; có thể vấn đề là zygote cache CA nên cần khởi động lại bằng
stop;start, hoặc phải chuyển sang đúng mount namespace trước khi chạy lệnhGrapheneOS và LineageOS có quyền truy cập toàn bộ mã nguồn nên có thể sửa theo ý muốn; hạn chế chỉ là việc phải theo kịp những thứ Google phá vỡ với tốc độ chóng mặt khá phiền phức
Khi Android ngày càng trở nên đối địch với người dùng, đặc biệt là power user, tôi hy vọng nhiều người hơn sẽ chuyển sang ROM tùy biến
Trong mơ, tôi tạo một bản fork Android kiểu “OwnerDroid” mà dòng đầu tiên của mô hình bảo mật không phải là “người dùng là kẻ thù”, nhưng tôi mới chỉ xây được vài viên gạch nhỏ; cả dự án sẽ cần khối lượng công việc khổng lồ
[1] Ngoại trừ một số cơ chế bảo vệ ở cấp kernel, nhưng GKI giúp giảm rủi ro đó
Giờ thì không thể làm như vậy nữa
Tất nhiên, nếu có toàn bộ mã nguồn thì cái gì cũng làm được; cũng có thể build từ đầu một image hệ thống Android đã vô hiệu hóa module này, và GrapheneOS/LineageOS cũng có thể ứng phó
Nhưng sẽ phát sinh nhiều việc mới, và nếu các thành phần cốt lõi tách khỏi cách triển khai của Android thì về sau có thể cần bảo trì nhiều hơn nữa
Với đại đa số người dùng bị ảnh hưởng, việc “trước tiên hãy tự build image hệ thống” vượt xa vùng thoải mái và mức đầu tư thời gian của họ
Cuối cùng chắc sẽ có giải pháp khác, nhưng có thể sẽ là đào sâu vào namespace để sửa riêng mount của tiến trình đích, hoặc build/cài đặt module APEX riêng theo cách Android tin cậy để thay thế module hệ thống, hoặc hook từng ứng dụng bằng Frida
Dù vậy, đây vẫn là vấn đề lớn vì khiến người dùng khó kiểm soát hoàn toàn thiết bị của mình hơn
Những phần quan trọng như kiểm tra root của ứng dụng ngân hàng bắt buộc hay các tính năng liên quan đến Google đều không được tài liệu hóa, và gần như không thể tìm được thông tin rằng tổ hợp “mẫu điện thoại + ứng dụng ngân hàng địa phương + ROM tùy biến” đã được kiểm thử và hoạt động tốt
Tôi ủng hộ tự do và lựa chọn, nhưng trừ khi người dùng điện thoại trung bình sẵn sàng bỏ ra vài chiếc điện thoại cùng vài ngày làm việc, hoặc ngay từ đầu đã là chuyên gia, thì đây khó có thể xem là cách hành động thực tế
Trên máy tính tôi là power user, nhưng với điện thoại thì tôi nghĩ nó có ngu ngơ hơn cũng không sao
Tuy nhiên điều đó sẽ khó xảy ra nếu điện thoại ngày càng phải được dùng như thiết bị xác thực đa yếu tố, hoặc bị trói buộc vào sự thất thường của các công ty có đòn bẩy mạnh hơn như ngân hàng
Tôi không định đổi tài khoản ngân hàng ba lần chỉ để tìm ứng dụng chạy được trên điện thoại đã root
Nếu bạn hỏi “fork Android thì là đối thủ kiểu gì?”, điều đó có nghĩa là chiến lược này đang hiệu quả
Nếu cơ chế mới đọc chứng chỉ từ
/apex/com.android.conscrypt/cacertskhi thư mục đó tồn tại, thì có lẽ có thể chỉ ẩn/apex/com.android.conscrypt/cacertskhỏi các tiến trình cần thiết, giống như bypass SafetyNet, ẩn root hay ẩn Magisk hiện nay, để buộc nó fallback về cách cũĐó là lãnh địa của hacker, và ngay cả trong nhóm đó cũng chỉ một phần rất nhỏ sử dụng
Ở đây có nhiều bình luận hay, nhưng tôi cứ nghĩ mãi rằng thật may vì PC không hoạt động như smartphone
Android đã tự hủy hoại mình kỹ đến mức tôi thấy lạ khi chính mình lại biết ơn Microsoft vì họ không vận hành thế giới PC như cách Google vận hành thế giới smartphone
Bản thân Windows, so với Android, gần như là thành trì của sự ổn định và lẽ thường; tôi cũng không cần bị ép nâng cấp cho đến khi phần cứng thực sự hỏng vì quá cũ
Giống Google, Microsoft không kiểm soát toàn bộ pipeline phần cứng-phần mềm, nhưng họ đã có sức mạnh để dùng Store áp đặt chuẩn mực hoặc hạn chế việc thay đổi môi trường bằng cách kiểu SafetyNet, khiến quyền sở hữu PC trở nên cực kỳ khó chịu
Tôi nhớ không rõ trước đây Microsoft từng bị kiện chống độc quyền vì chuyện kiểu này chưa, và tự hỏi bao giờ điều tương tự sẽ đến với Google
Microsoft cũng đã thêm vô số DRM vào Windows, rồi sau đó cũng phá vỡ chúng; chứng thực từ xa cũng được tích hợp vào OS
Google đã thay đổi chi tiết triển khai nội bộ của Android vốn dĩ không nên bị phụ thuộc vào, làm các nhà phát triển khó chịu; Microsoft cũng luôn làm những việc như vậy
Nhiều khả năng chỉ cần chờ vài tuần để có module Magisk được cập nhật, và thành thật mà nói thì cũng không tệ đến thế
Với 5–6 thiết bị sẽ nhận Android 14, chỉ cần đừng bấm nút cập nhật cho đến lúc đó là được
Windows 11 yêu cầu TPM và Secure Boot
Tôi từng nghe nói một số nước đang phát triển yêu cầu cài CA quốc gia để tấn công trung gian tất cả kết nối; nếu khiến việc này cực kỳ khó thì trên thực tế cũng khó khiến người dùng tự tắt quyền riêng tư của mình hơn
Đang dùng PinePhone Pro làm máy chính hằng ngày
Chase.com thực sự cố chấp chặn các trình duyệt không chuẩn như Librewolf và trình duyệt trên điện thoại/máy tính bảng, đồng thời cố ép dùng ứng dụng di động
Ít nhất cho đến trước khi WEI trở thành bắt buộc, những biện pháp ngu ngốc này dễ bị vượt qua nên chưa phải vấn đề nghiêm trọng, nhưng vì Chase là ngân hàng nên tôi tò mò liệu có cơ sở nào để tranh chấp pháp lý hay không
Phỏng đoán đầu tiên là theo hướng tuân thủ ADA, nhưng tôi không chắc
Giờ thì tôi mệt mỏi đến mức cũng không biết nói muốn kiện vì chuyện này có còn là nói suông nữa không
Dù hơi lạc nhánh, chuyện này vẫn liên quan vì nó cho thấy thêm một khía cạnh rằng gần như không thể thoát khỏi thế độc quyền nhóm của các hệ điều hành di động
Ngay cả nếu ngách điện thoại Linux có kỳ tích tăng lên vài phần trăm, Android nhiều khả năng vẫn sẽ tiếp tục tệ đi, và cần có thứ gì đó
Có lẽ kỷ nguyên nông nô số sẽ tới
Bạn sẽ dùng một thiết bị do một công ty “nhân từ” nào đó cung cấp, công ty đó sở hữu mọi khía cạnh của thiết bị, và bạn chỉ có thể dùng nó như lái xe khi trả tiền
Phần lớn các con đường khác sẽ bị khóa, điện toán đa dụng chỉ còn dành cho “doanh nghiệp”, và “web tự do” thì vẫn tồn tại nhưng sẽ khá kỹ thuật và thù địch với người dùng
Phần lớn thị trường, đặc biệt là mọi nơi liên quan đến tiền, sẽ tránh nó như tránh dịch
Tôi cho rằng Google đã giết chết web mở bằng thứ này
Dù sao nó cũng đang hơi nhàm chán rồi, nhưng thật khó chịu khi giờ đây việc sống mà không có điện thoại hoặc trình duyệt “được phê duyệt” trở nên khó hơn nhiều
Việc người dùng thành thạo biết cài thêm phần mềm để tự khắc phục vấn đề là tốt, nhưng sẽ tốt hơn nếu Chase sửa trang web mặc định để cả những người dùng mới có nhu cầu tương tự cũng được giúp đỡ
Ở điểm này tôi cho rằng Android đã và vẫn đang cưỡng ép hơn Apple
Ngay cả khi còn có thể cài đặt và tin cậy CA gốc mới, một số ứng dụng vẫn có thể phớt lờ điều đó, và thực tế đã phớt lờ
Cả iOS lẫn Android đều cho phép ứng dụng dùng ghim chứng chỉ, nhưng trên Android 7+ thì từ năm 2016, mặc định ứng dụng bỏ qua CA do người dùng thêm vào[1]
Trên iOS, quá trình tin cậy CA gốc khá phiền phức, phải cài hồ sơ và đi qua các cảnh báo đáng sợ; bản thân điều đó là hợp lý, nhưng theo kinh nghiệm của tôi, đa số ứng dụng sẽ tin cậy nó miễn là không dùng ghim chứng chỉ
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
Android, vốn gần với máy tính phổ thông hơn iOS rất nhiều, có vấn đề stalkerware cực kỳ lớn
Stalkerware không bị chặn bằng hộp thoại nhắc, vũ khí hóa khả năng tương thích ngược, và bao gồm đủ loại lạm dụng
Trên iOS, việc cho ai đó mượn điện thoại 5 phút rồi bị đảo lộn quyền riêng tư HTTPS trong nhiều năm là điều dễ đến đáng ngạc nhiên
Tôi muốn có tùy chọn thực sự tin cậy chứng chỉ CA đã cài, nhưng thật bực khi ngay cả Firefox, một trình duyệt web, cũng không dùng chứng chỉ người dùng nếu không có tổ hợp tab và thiết lập ẩn
Dù vậy, xét đến rủi ro đối với người dùng Android trên toàn thế giới, khó có thể nói tính năng này quan trọng tương xứng với vài chục người kỹ thuật dùng hằng ngày
Tôi nghĩ vụ này giống tác dụng phụ của các cải tiến sandbox tốt của Google và cơ chế cập nhật kho CA bị trì hoãn quá lâu hơn là một âm mưu độc ác của Google nhằm phá kế hoạch của phòng IT địa phương
Một module Magisk chắc sẽ sớm xuất hiện như cách vượt qua, còn các module hiện có sẽ hỏng một thời gian, nhưng đó là chuyện thường gặp sau các bản cập nhật Android lớn
Nếu cần thì cũng có thể tự viết module
Tôi nghĩ đây chỉ là cách mount hoạt động thôi
Nếu có thứ gì đó được mount tại
/apex/whatevervà mỗi ứng dụng có không gian tên mount riêng, thì dù mount lại đè lên/apex/whatevertrong không gian tên của mình, các không gian tên khác cũng không thay đổi gìPhải sửa trực tiếp hệ thống tệp, hoặc đi vào không gian tên mount của ứng dụng khác rồi mount tmpfs ở đó nữa
Mount dùng chung có thể giúp ích, nhưng tôi không chắc, và cần xem chi tiết hơn thực tế đang xảy ra điều gì
Tôi cho rằng kết quả này nhiều khả năng là sản phẩm phụ của công việc namespace/container hóa của Google, hơn là một nỗ lực có chủ đích nhằm ngăn người dùng thay đổi CA gốc ngay cả khi có quyền root
Nhưng kết quả cuối cùng vẫn là một vấn đề lớn
Điểm đáng ngạc nhiên ở đây là “không gian tên mount riêng”
Trước đây, chỉ cần mở shell rồi mount vào hệ thống tệp hoặc sửa trực tiếp, các ứng dụng sẽ đọc tệp từ mount đó bình thường
Giờ thì với các tệp cacert này không còn như vậy, và theo cách mới cũng không thể sửa trực tiếp
Trước thay đổi này tôi thậm chí còn không biết ứng dụng Android dùng không gian tên mount riêng
Hầu như không có tài liệu về cách nó hoạt động chính xác, và tôi cũng không rõ trước đây đã có trường hợp nào bộc lộ rõ ràng như vậy chưa
Cứ nhìn manifest v3 là thấy
Tôi đã trả lời tác giả trên Twitter, nhưng có thể họ không thấy nên tôi cũng để lại ở đây
Tôi là người đã viết bài blog về các chứng chỉ có thể cập nhật trong Android 14, và bài đó được liên kết trong bài viết này
Thực ra có một thuộc tính hệ thống có thể được thiết lập để bỏ qua việc đọc từ thư mục chứng chỉ APEX
system.certs.enabled=trueNguồn: https://android-review.googlesource.com/c/platform/framework...
Đó là thuộc tính OS
android.os.SystemProperties, tức không phải giá trị có thể đặt trên toàn thiết bị bằngadb, mà là thuộc tínhjava.lang.System, nói cách khác là giá trị cấu hình được đặt trong một JVM/ứng dụngTheo tôi, để đặt lại cái trước thì phải sửa chính ứng dụng
Nó hữu ích cho kiểm thử tự động hoặc để bật/tắt cấu hình giữa bản build debug/prod, nhưng không giúp ích nhiều khi muốn khiến toàn bộ thiết bị tin cậy chứng chỉ CA
Tất nhiên, nếu bạn biết cách đặt thuộc tính đó từ bên ngoài để áp dụng cho mọi ứng dụng thì chắc chắn sẽ hoạt động rất tốt, tôi rất muốn nghe
Nhân tiện, tôi là tác giả, và trên Twitter tôi không thấy câu trả lời như vậy
Đúng là Twitter của năm 2023
Có vẻ tốt cho bảo mật và như địa ngục với một số nhà phát triển, nhưng tôi tự hỏi chuyện gì sẽ xảy ra khi phiên bản Android này bị bỏ rơi sau 2–3 năm nữa
Có phải chỉ biết cầu cho các chứng chỉ hard-code trụ thêm vài năm không
Android 14 cho phép cập nhật chứng chỉ gốc qua Google Play, không cần cập nhật OTA để thêm hoặc xóa chứng chỉ gốc như trước
Hôm nay tôi cũng biết một cách обход [0]
Nếu dùng Android 7.0 trở xuống, bạn có thể cần hành động để tiếp tục truy cập các website được bảo vệ bằng chứng chỉ Let’s Encrypt, và họ khuyến nghị cài đặt, sử dụng Firefox Mobile, vốn dùng kho tin cậy riêng thay vì kho tin cậy của Android OS
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
Vì bản cập nhật của Google thiếu chứng chỉ trung gian mà Let’s Encrypt sử dụng
Đây không phải là một vấn đề giả định trong tương lai, mà là vấn đề đang tồn tại ngay lúc này
Tại sao Google phải là người phán quyết cuối cùng về việc tôi tin cậy ai
Google rõ ràng cũng có lỗ hổng
Và ngay cả trong số các nhà cung cấp chứng chỉ đã được phê duyệt, cũng có những nơi từng cấp chứng chỉ cho những cá nhân và tổ chức không nên có chúng, nên thực tế không nên tin cậy họ
Các ứng dụng thường không chấp nhận chứng chỉ người dùng, và khi Google Cloud hay thứ gì đó liên quan chuyển sang chứng chỉ mới hơn, một số ứng dụng bắt đầu ngừng hoạt động
Tức là chúng được cập nhật ngoài băng thông qua Play Services và không cần cập nhật OS từ OEM
Mỗi khi có bản phát hành Android mới, tôi lại thấy một thứ gì đó bị gỡ bỏ, còn những thứ chẳng mấy ý nghĩa được thêm vào
iOS có vẻ đang đi theo hướng ngược lại, nên có vẻ hai bên sẽ dần gặp nhau ở giữa, rồi sau này iOS có thể vượt Android về mọi mặt
Tôi muốn nghe ý kiến thật lòng từ những người dùng Apple
Gần đây tôi đang dùng macOS, và tôi ghét nó vì nó thất bại ở những trải nghiệm người dùng rất cơ bản mà Windows/Linux đã xem là hiển nhiên từ hàng chục năm trước
Những thứ như Finder thật sự quá tệ
Nếu thế hệ sau tôi mua iPhone thay vì Android, liệu tôi có phản ứng tiêu cực tương tự với iOS không
Trong các trường hợp sử dụng smartphone, có thể xem iOS là trải nghiệm người dùng hoàn thiện và hữu ích hơn macOS không
Tôi cũng muốn chuyển, nhưng không muốn lãng phí thời gian và tiền bạc
Android ngày xưa không chỉ là iOS có
.apk, nên thật sự đáng tiếcVới các mục đích đó thì ổn
Nhưng người dùng bị hạn chế quá nhiều, nên có thể tôi sẽ tìm hiểu jailbreak, dù tôi đang cố tối thiểu hóa việc dùng điện thoại và làm gần như mọi thứ trên desktop
Nhân tiện, tôi cũng đang trong quá trình bỏ macOS để chuyển sang Linux
Tôi đang dùng PKI cá nhân để truy cập phần mềm tự host
Những thứ như máy chủ email, nhà cung cấp lịch, máy chủ ghi chú, công cụ đồng bộ ảnh
Tôi cần có thể thêm chứng chỉ gốc của mình vào danh sách cơ quan chứng thực
Tôi không muốn thay đổi danh sách do hệ thống cung cấp, chỉ muốn thêm chứng chỉ của mình thôi
Vì đây là thiết bị của tôi, tôi nghĩ mình phải có thể thay đổi bất cứ thứ gì nếu muốn
Nhiều khả năng các ứng dụng email và lịch cũng nằm trong số đó
Trường hợp có khả năng không được là cài CA tự tạo để chặn bắt lưu lượng giữa ứng dụng và máy chủ của nhà phát triển ứng dụng
Thật tiếc vì bạn nên có thể kiểm tra thiết bị của mình đang làm gì, nhưng use case dùng PKI cá nhân cho phần mềm tự host thì rõ ràng vẫn được hỗ trợ
Chắc phải có cách nào đó
getlocalcert đang làm công cụ cho việc này [1]
Vì có thể tránh phải thêm root tin cậy, cách tiếp cận “chứng chỉ công khai trên mạng riêng” nhìn chung có lợi cho một số mạng
Thành thật mà nói, tôi không ngờ Android sẽ chặn CA riêng, nhưng cuối cùng chuyện đã thành ra như vậy
[1] https://www.getlocalcert.net/
Hiện tôi không dùng điện thoại Android, nhưng trước đây tôi nhớ là có thể thêm chứng chỉ CA tự tạo vào điện thoại Android chỉ bằng tùy chọn trong phần cài đặt, không cần quyền root, và ít nhất các ứng dụng như trình duyệt web đã tin cậy nó
Cũng không phải chuyện quá xa xưa
Vì vậy tôi không hiểu vì sao việc cài chứng chỉ tùy chỉnh lại cần root thiết bị, hay đó là cho mục đích khác
HTTP Toolkit đã rất hữu ích để moi API ẩn từ một ứng dụng sạc xe điện tệ hại ở Thổ Nhĩ Kỳ
Tôi cũng dùng Frida cùng lúc để vượt qua SSL pinning và phát hiện root
Rồi tôi nhận ra có lẽ lý do họ muốn giấu API là vì các API đó là một thứ quái vật /s