- Let's Encrypt sắp hỗ trợ phát hành chứng chỉ có chứa IP address SAN, ban đầu chỉ cung cấp dưới dạng profile shortlived với thời hạn 6 ngày, và trong một thời gian sẽ được vận hành hạn chế theo cơ chế allowlist
- Trước khi công bố chính thức, vẫn chưa có lịch trình cụ thể hay hướng dẫn đăng ký, hiện đang tiếp tục thử nghiệm nội bộ và chuẩn bị
- Trong môi trường staging, chứng chỉ mẫu có chứa địa chỉ IPv6 cùng với website áp dụng chứng chỉ đó đã được công khai, đồng thời cộng đồng được mời chia sẻ các hiện tượng bất thường hoặc phản hồi
- Đã phát hiện lỗi trên Firefox liên quan đến việc hiển thị IP SAN (BZ #1973855) và việc thử nghiệm vẫn đang tiếp tục
- Qua ví dụ thử nghiệm thực tế, đã xác nhận khả năng gây nhầm lẫn khi trộn DNS SAN và IP SAN, cho thấy cách biểu thị TLD và địa chỉ IPv6 có thể trông tương tự nhau
Let's Encrypt, đang chuẩn bị phát hành chứng chỉ cho địa chỉ IP
Tình hình chuẩn bị hỗ trợ IP address SAN
- Let's Encrypt dự kiến sớm hỗ trợ phát hành chứng chỉ có chứa IP address SAN trong môi trường production
- Loại chứng chỉ này chỉ được phát hành trong profile shortlived có thời hạn 6 ngày và trong một khoảng thời gian sẽ được giới hạn theo cơ chế allowlist
- Hiện chưa chốt lịch phát hành chính thức cũng như cách đăng ký vào allowlist, vì vẫn cần thêm công tác chuẩn bị nội bộ
Thử nghiệm và chứng chỉ mẫu
- Trong môi trường staging, đã công bố chứng chỉ mẫu có chứa IP SAN và ví dụ website áp dụng thực tế (địa chỉ IPv6)
- Cộng đồng người dùng được đề nghị chia sẻ nếu phát hiện điều gì bất thường, thú vị hoặc có vấn đề
Trường hợp trộn IP SAN và DNS SAN
- Trong quá trình thử nghiệm, đã trình diễn khả năng phát hành chứng chỉ chứa đồng thời DNS SAN và IP SAN cùng các trường hợp dễ gây nhầm lẫn trong cách hiển thị
- Một số TLD như
.cafe có thể trông giống với cách biểu thị địa chỉ IPv6, nên có khả năng gây nhầm lẫn
- Trên Firefox cũng đã xác nhận lỗi liên quan đến hiển thị IP address SAN (BZ #1973855)
Tóm tắt
- Việc hỗ trợ chứng chỉ cho địa chỉ IP của Let's Encrypt trước mắt sẽ được áp dụng giới hạn với allowlist và chứng chỉ ngắn hạn
- Trước khi áp dụng vào dịch vụ thực tế, nhiều trường hợp khác nhau sẽ được kiểm thử và tiếp nhận phản hồi từ cộng đồng để đánh giá độ ổn định và khả năng tương thích
- Các vấn đề hiển thị trên trình duyệt khi trộn SAN của tên DNS và địa chỉ IP cũng đang được thảo luận cùng lúc
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ chứng chỉ cho địa chỉ IP cũng hữu ích.
Nhưng tôi nghĩ nếu Let’s Encrypt hỗ trợ chứng chỉ S/MIME thì tác động còn có thể lớn hơn nhiều.
Tình huống khá khôi hài quanh việc mã hóa email đã diễn ra nhiều năm nay.
Giờ đây hầu hết các ứng dụng email lớn đều hỗ trợ mã hóa S/MIME ngay sẵn có, nhưng cũng như web, để có trải nghiệm người dùng mượt mà thì phải lấy chứng chỉ từ CA.
Các CA cung cấp chứng chỉ S/MIME đáng tin cậy, miễn phí và có hiệu lực hơn 1 năm giờ đều đã biến mất.
Kết quả là người dùng cá nhân hầu như không dùng mã hóa email.
PGP quá bất tiện nên ngoài dân mê công nghệ thì gần như chẳng ai dùng.
Tôi nghĩ giờ email của chúng ta cũng nên được mã hóa.
Tham khảo thêm, nếu CA tạo hộ khóa bí mật thì tôi không xem chứng chỉ đó là đáng tin cậy.
Ngoài ra, S/MIME đòi hỏi phải giữ lại chứng chỉ cũ để giải mã email cũ, nên chứng chỉ thay đổi quá thường xuyên là không thực tế.
Về ý rằng cần chứng chỉ cũ để giải mã email cũ trong S/MIME, tôi nghĩ không nhất thiết phải thay quá thường xuyên vì chính khóa giải mã vẫn có thể được dùng lại khi tạo chứng chỉ mới (ví dụ: tùy chọn
--reuse-keycủa certbot).Dù vậy, việc đó có phải cách làm tốt hay không lại là chuyện khác.
Tôi nghĩ thứ thực sự cần là tự động hóa cấp chứng chỉ kiểu ACME.
Hiện tại quá trình gia hạn chứng chỉ quá bất tiện nên gần như không ai dùng.
PGP giờ đã có phương thức gọi là WKD(Web Key Directory) liên kết, cho phép áp dụng mạng lưới tin cậy của TLS vào email.
Chứng chỉ TLS hiện dễ lấy hơn nhiều so với chứng chỉ S/MIME.
Việc để bên thứ ba quản lý danh tính cũng có thể hữu ích, nhưng phần lớn mọi người lại làm việc ở những công ty không thật sự phù hợp với kiểu quản lý danh tính đó.
Nếu là môi trường công ty, tôi nghĩ quản lý danh tính nội bộ sẽ phù hợp hơn.
Vụ lùm xùm Signalgate 1.0 gần đây liên kết cho thấy rất nhiều điều đáng học về thất bại trong quản lý danh tính của mã hóa đầu-cuối.
Vì vậy tôi nghĩ nếu chứng chỉ S/MIME hoặc WKD được triển khai thành một hệ thống thực sự dùng được, thì nó cũng có thể hữu ích cho chính phủ.
Cá nhân tôi nhìn nhận tích cực về mã hóa email dựa trên S/MIME, nhưng cảm thấy khả năng hiện thực hóa khá thấp.
Người dùng phổ thông thường còn khó quản lý cả khóa riêng, và thực tế là ngay cả mật khẩu email họ cũng khó quản lý cho tốt.
Kết cục là hoặc phải có cơ chế cấp chứng chỉ tập trung theo từng domain, hoặc người dùng không lấy được chứng chỉ, trong khi tội phạm mạng lại gửi email có chữ ký S/MIME.
Tôi nghĩ khi việc dùng passkey trở nên phổ biến và có sự thay đổi thế hệ thì lúc đó mới phù hợp để yêu cầu người dùng tự xử lý cặp khóa.
Tôi cho rằng mã hóa email nên biến mất luôn.
Tham khảo: Stop using encrypted email
Tôi không rành về mã hóa S/MIME nên có điều thắc mắc.
Vì sao lại cần giải mã email cũ bằng cùng một giao thức?
Cá nhân tôi vẫn nghĩ chứng chỉ là để phục vụ lớp truyền tải, còn khi lưu trữ thực tế thì máy chủ hay máy chủ lưu trữ sẽ có cơ chế mã hóa at-rest riêng, nên việc tách ra thành chứng chỉ ngắn hạn cho truyền tải và kiểu mã hóa tùy ý cho lưu trữ có vẻ hợp lý; không rõ tôi có đang bỏ sót điều gì không.
Tôi tự hỏi liệu tất cả các cơ quan quản lý địa chỉ (ví dụ ISP, nhà cung cấp cloud) cũng có tham gia xu hướng này không.
Họ có trường hợp xoay vòng IP rất nhanh, thậm chí nhanh hơn 6 ngày.
Tôi có thể hiểu nếu nhà cung cấp cloud đặt thời gian cooldown trước khi phân tích IP hoặc truy vấn và thu hồi các chứng chỉ liên quan tới IP đó, nhưng nếu không thì sẽ phát sinh độ phức tạp khi người dùng phải tự chịu trách nhiệm xác minh host header, từ chối các kết nối dựa trên IP không mong muốn, hoặc chờ đến khi chứng chỉ cũ hoàn toàn biến mất.
Tôi cũng tò mò mỗi nhà cung cấp cloud sẽ cho lấy bao nhiêu chứng chỉ IP và tính phí thế nào.
Thực ra tôi nghĩ vấn đề này không khác mấy so với việc các nhà cung cấp cloud cung cấp custom/vanity domain.
Ví dụ trên Azure, có thể gắn DNS như
myapp.westus.cloudapp.azure.comvào VM, và bất kỳ ai cũng có thể xin CA cấp chứng chỉ cho domain đó tham khảo.Trong những trường hợp như vậy, nếu VM biến mất thì người khác cũng có thể lấy ngay domain đó mà không cần cooldown riêng.
Chứng chỉ HTTPS có thể được gia hạn 90 ngày ngay từ một ngày trước khi domain hết hạn, và CA cũng không thể biết hạn mức thẻ thanh toán.
Những người dùng chứng chỉ IP có lẽ sẽ khác với kiểu người dùng bỏ IP rất nhanh rồi rời đi.
Trường hợp hữu ích nhất là phần mềm legacy rất đặc thù, hoặc tình huống như Cloudflare cần hỗ trợ ECH(Encrypted Client Hello) hay ESNI(Encrypted SNI) mà không dùng IP dùng chung.
Với trường hợp đầu tiên (legacy), họ sẽ không dễ từ bỏ IP; còn trường hợp thứ hai (ECH/ESNI), tôi nghĩ việc truy cập thành công vào domain thực tế sẽ khó xảy ra.
Với câu hỏi liệu ISP có cần tham gia hay không, tôi lại nghĩ theo hướng ngược lại.
Vai trò của ISP không phải là cấp phát IP theo cách phù hợp với tiêu chuẩn TLS, mà là nhà cung cấp chứng thực TLS phải đảm nhiệm phần “xác minh danh tính” sao cho khớp với cách hệ sinh thái gắn danh tính (domain, IP, v.v.).
Lần này chưa thấy mô tả chi tiết họ sẽ tiếp cận thế nào, nhưng trực giác của tôi là LetsEncrypt sẽ lập một danh sách các IP được chuyển giao dài hạn theo ASN (số hệ tự trị), giống như cùng duy trì một cơ sở dữ liệu công khai kiểu Mozilla Public Suffix List, rồi chỉ cấp chứng chỉ cho các IP trong danh sách đó, đồng thời xử lý vô hiệu hóa chứng chỉ nếu IP chuyển sang ASN khác.
Tôi hy vọng họ cũng sẽ chia sẻ cách đó với các đơn vị cấp ACME khác.
Nếu tò mò mỗi cloud cho lấy bao nhiêu chứng chỉ IP và với giá bao nhiêu, thì tôi cũng muốn biết liệu sau này có hỗ trợ chứng chỉ wildcard hay không.
Với trường hợp của tôi, chỉ cần có chứng chỉ IP trong một ngày là đã có thể thử nghiệm URL https, nên tôi thấy đây là thay đổi rất đáng hoan nghênh.
Về mặt kỹ thuật tôi hiểu cơ chế hoạt động, nhưng vẫn tò mò mục đích sử dụng thực tế là gì.
Chỉ riêng việc hỗ trợ ECH(Encrypted Client Hello) hay ESNI(Encrypted SNI) thôi cũng đã rất có ý nghĩa.
Thời kỳ đầu của ESNI, chỉ các proxy https lớn như Cloudflare mới áp dụng được nên ý tưởng đưa chứng chỉ IP vào bị xem như điều xa vời, nhưng giờ mọi máy chủ đều có thể tham gia ESNI/ECH.
Nếu client bắt đầu giả định rằng mọi máy chủ đều có chứng chỉ IP và thử ESNI, thì tôi kỳ vọng điều đó sẽ giúp cải thiện quyền riêng tư trên toàn Internet rất nhiều.
Nhiều câu trả lời đã nêu các ví dụ hay, nhưng cũng đáng nhắc đến NTS(Network Time Security).
Nếu không lấy được chứng chỉ IP thì NTS cũng cần DNS, nghĩa là khi DNS chết thì đồng bộ thời gian có xác thực cũng hoàn toàn không thể thực hiện.
DNSSEC sẽ thất bại khi xác minh nếu không có thời gian đúng, mà nếu còn phụ thuộc DNS+NTS thì sẽ không thể khôi phục.
Nếu có thể phân phối thời gian đã xác thực bằng chứng chỉ chứa IP mà không cần DNS, thì vấn đề này có thể được giải quyết.
Có thể dùng trong các trường hợp cần duy trì chứng chỉ hợp lệ ngay cả khi DNS đang thay đổi mạnh, chẳng hạn để đảm bảo khả năng truy cập dashboard hoặc để tự động hóa cũ không bị dừng vì lỗi DNS.
Một trường hợp khác là dựng môi trường thử nghiệm đơn giản hơn mà không cần DNS, hoặc nhanh chóng mở Cockpit hay dịch vụ tương tự ra ngoài.
Về cơ bản sẽ xuất hiện đủ kiểu cách dùng mà trí tưởng tượng cho phép.
Đây cũng có thể là một cách thú vị khi làm DoTLS(truy vấn DNS qua TLS) theo kiểu “opportunistic” cho authdns(máy chủ DNS có thẩm quyền).
Máy chủ DNS có thẩm quyền có thể phục vụ trên cổng DoTLS bằng chứng chỉ có chứa IP công khai trong SAN(Subject Alternative Name).
Hiện giờ cũng làm được bằng hostname, nhưng vì một IP công khai có thể gắn với nhiều tên khác nhau nên SAN dựa trên IP sẽ ràng buộc rõ ràng hơn.
Tôi nghĩ nó phù hợp với những người muốn gắn IP trực tiếp vào dự án thay vì hostname, hoặc muốn dùng không cần domain cho các mục đích cá nhân hay dùng một lần.
Tôi thắc mắc vì sao các cơ quan đăng ký Internet khu vực(RIR) hay cơ quan đăng ký địa phương(LIR) không tự cấp chứng chỉ.
Vì sao phải để bên thứ ba xác minh người đăng ký RIR, LIR, có phải vì các đơn vị đăng ký domain đã quá nhiều việc rồi không?
Tôi tự hỏi lý do có giống hệt nhau không.
Tôi có cảm giác như vừa mở thêm một lỗ hổng mới để lạm dụng TLS.
Trước đây vấn đề là cấp chứng chỉ cho domain không thuộc quyền sở hữu, giờ có thể thành cấp chứng chỉ cho IP không thuộc quyền sở hữu.
Mấy tay black-hat chắc đang bàn tán sôi nổi trên Telegram.
Tôi tự hỏi liệu việc này có giúp truy cập trang quản trị router nội bộ (ví dụ
192.168.0.1) qua https mà không bị lỗi self-signed hay không.Không được, nhưng có thể rồi sẽ được.
Địa chỉ nội bộ không được cấp phát theo cách phổ quát và cũng không được định tuyến toàn cục, nên về bản chất không có cách xác minh.
Tuy nhiên, nếu nhà sản xuất router thực sự muốn làm, thì với thiết bị không nằm sau CG-NAT và được gán IPv4 công khai, việc yêu cầu chứng chỉ cho địa chỉ công khai là khả thi.
IPv6 thì thường được định tuyến toàn cục nên tôi nghĩ còn dễ hơn.
Không được, và cũng không nên như vậy.
Trên thực tế, chỉ cần kết hợp proxy, domain thật, chứng chỉ thật và tính năng rewrite DNS là đủ.
Ví dụ dùng giao diện quản lý nginx và adguard làm DNS.
Giới hạn DNS của router về adguard, rewrite domain của tôi sang proxy.
Đăng ký domain và xin chứng chỉ thật là xong.
Tôi cũng đang dùng https cho mọi dịch vụ cục bộ.
Không cấp chứng chỉ cho IP riêng.
Cùng một IP riêng có thể luôn được dùng cho những thiết bị hoàn toàn khác nhau trong các mạng khác nhau, nên không thể đảm bảo quyền sở hữu độc quyền.
Thực ra là ngược lại.
Nếu không phải IP công khai thì không thể cấp chứng chỉ hợp lệ.
Hiện đã có cách lấy chứng chỉ domain rồi chuyển tiếp domain đó tới
192.168.0.1.Muốn lấy chứng chỉ thì bạn phải thực sự sở hữu IP đó (IP công khai).
Tôi tự hỏi liệu có thể cấp chứng chỉ cho IPv4 nội bộ (
192.168.x.x,172.16.x.x,10.x.x.x) hay không, hay đúng hơn là trình duyệt nên bỏ qua các địa chỉ như vậy, và nếu không thì có thể cấp chứng chỉ wildcard cho mạng nội bộ hay không.Trong bối cảnh chứng chỉ do CA công khai cấp, tôi nghĩ câu hỏi đó không thật sự phù hợp.
Không như domain, một IP riêng như
10.10.10.10có thể đang được vô số người “sở hữu” cùng lúc.Nếu là cho phát triển nội bộ thì có các công cụ như mkcert, còn nếu là tài nguyên dùng chung trong công ty thì chứng chỉ TLS dựa trên domain sẽ đơn giản hơn.
Nếu có thể chứng minh khóa riêng của thiết bị tuyệt đối không bao giờ bị lộ, thì ngay cả CA hiện có cũng có thể thử được.
Nhưng với chứng chỉ cho địa chỉ nội bộ, nếu ai đó mua thiết bị rồi trích được khóa riêng thì việc thu hồi khóa chứng chỉ sẽ ngay lập tức thành vấn đề.
Vì vậy, với thiết bị đáng tin cậy thì cách thực tế là tự nhập chứng chỉ để truy cập không lỗi, hoặc nếu có nhiều thiết bị thì tự dựng CA riêng để phân phối chứng chỉ.
Với máy chủ ACME mã nguồn mở, cũng có thể tự động hóa cấp phát nội bộ theo đúng cách Let's Encrypt đang làm.
Cách làm là trỏ DNS ưu tiên sang máy chủ công khai để lấy chứng chỉ, rồi sau đó hạ DNS về địa chỉ nội bộ
192.168…và sao chép chứng chỉ cùng khóa sang.Điều cần lưu ý là một số router có thể blackhole các phản hồi DNS trỏ tới địa chỉ nội bộ, nên cần kiểm tra trước.
Tôi nghĩ trình duyệt không nên bỏ qua mạng riêng.
Với tôi, mạng riêng chỉ là router cục bộ, nhưng với người khác đó có thể là một mạng trải khắp toàn cầu.
Tôi thấy thú vị là chứng chỉ ví dụ không có trường subject.
Tôi tự hỏi có phải vì yêu cầu bằng IP và DNS được ghi trong SAN nên mới như vậy không.
Cách này đã được áp dụng trong profile chứng chỉ ngắn hạn 6 ngày, còn profile “cổ điển” 90 ngày thì vẫn chưa.
Có người đùa rằng đây có lẽ là lúc lỗ hổng CVE-2010-3170 lại được nhắc tới.
Đáng tiếc là chứng chỉ cho địa chỉ IP không thể được cấp bằng phương thức DNS challenge.
Nhưng tôi cũng hiểu vì sao lại như vậy.