Rút ngắn chuỗi tin cậy của Let’s Encrypt

 (letsencrypt.org)
2 điểm bởi GN⁺ 2023-07-11 | 1 bình luận | Chia sẻ qua WhatsApp
  • Let’s Encrypt sẽ không gia hạn chữ ký chéo (cross-sign) hết hạn vào ngày 30 tháng 9 năm 2024, và sẽ chuyển sang chuỗi chứng chỉ ngắn kết thúc ở ISRG Root X1
  • Khi mới ra mắt, do root riêng chưa được tin cậy đủ rộng, dịch vụ này phụ thuộc vào DST Root CA X3 của IdenTrust, nhưng hiện nay phạm vi tin cậy của ISRG Root X1 đã mở rộng đáng kể
  • Chữ ký chéo root được bổ sung vào năm 2021 để tương thích với Android cũ chỉ là biện pháp tạm thời, và nhờ đó các thiết bị Android đời cũ có thể tiếp tục tin cậy chứng chỉ Let’s Encrypt thêm 3 năm
  • Trong 3 năm gần đây, tỷ lệ thiết bị Android tin cậy ISRG Root X1 đã tăng từ 66% lên 93.9%, và khi bỏ chữ ký chéo thì số byte chứng chỉ trong bắt tay TLS cũng giảm hơn 40%
  • Người dùng Android 7.0 trở xuống được khuyến nghị dùng Firefox Mobile, còn nhà vận hành website và tác giả ACME client cần kiểm tra việc xử lý chuỗi theo lịch chuyển đổi năm 2024

Bối cảnh kết thúc chữ ký chéo

  • Khi mới ra mắt, để chứng chỉ được tin cậy rộng rãi, Let’s Encrypt đã ký chéo chứng chỉ trung gian bằng DST Root CA X3 của IdenTrust
    • Đây là cách để các chứng chỉ do chứng chỉ trung gian đó phát hành vẫn được tin cậy, ngay cả khi root riêng ISRG Root X1 chưa được tin cậy rộng rãi
  • Theo thời gian, ISRG Root X1 đã trở nên được tin cậy rộng rãi nhờ chính nó
  • Cuối năm 2021, chứng chỉ trung gian được ký chéo và bản thân DST Root CA X3 đều sắp hết hạn
    • Khi đó các trình duyệt hiện đại đã tin cậy root của Let’s Encrypt, nhưng hơn một phần ba thiết bị Android vẫn đang dùng các phiên bản OS cũ
    • Những thiết bị này có thể đột ngột không còn tin cậy các website dùng chứng chỉ Let’s Encrypt
  • Năm 2021, Let’s Encrypt đã áp dụng ký chéo trực tiếp lên root thay vì chứng chỉ trung gian, tạo ra một biện pháp tạm thời kéo dài lâu hơn DST Root CA X3
    • Nhờ biện pháp này, các thiết bị Android cũ có thể tiếp tục tin cậy chứng chỉ Let’s Encrypt thêm 3 năm
  • Chữ ký chéo đó sẽ hết hạn vào ngày 30 tháng 9 năm 2024

Vì sao chuyển sang chuỗi ngắn

  • Let’s Encrypt sẽ không nhận chữ ký chéo mới để kéo dài khả năng tương thích nữa
    • Trong 3 năm gần đây, tỷ lệ thiết bị Android tin cậy ISRG Root X1 đã tăng từ 66% lên 93.9%
    • Android 14 có thể cập nhật trust store mà không cần cập nhật toàn bộ OS, nên tỷ lệ này có thể còn tăng thêm
    • Việc bỏ chữ ký chéo giúp giảm hơn 40% số byte chứng chỉ được truyền trong bắt tay TLS
    • Chi phí vận hành cũng giảm đáng kể, giúp Let’s Encrypt tập trung nguồn lực vào quyền riêng tư và cải thiện bảo mật

Lịch chuyển đổi năm 2024

  • Thứ Năm, ngày 8 tháng 2 năm 2024: ngừng cung cấp chữ ký chéo mặc định trong các yêu cầu tới endpoint API /acme/certificate
    • Với hầu hết thuê bao, ACME client sẽ cấu hình chuỗi kết thúc ở ISRG Root X1 và web server sẽ cung cấp chuỗi ngắn hơn trong bắt tay TLS
    • Chuỗi dài hơn kết thúc ở chữ ký chéo sắp hết hạn vẫn có thể được yêu cầu như chuỗi thay thế
  • Thứ Năm, ngày 6 tháng 6 năm 2024: ngừng hoàn toàn việc cung cấp chuỗi ký chéo dài hơn
    • Thời điểm này sớm hơn ngày hết hạn chữ ký chéo hơn 90 ngày một chút, tương ứng với tuổi thọ của 1 chứng chỉ
    • Đây là lịch nhằm bảo đảm thuê bao có ít nhất một chu kỳ cấp phát đầy đủ để rời khỏi chuỗi ký chéo
  • Thứ Hai, ngày 30 tháng 9 năm 2024: chứng chỉ ký chéo hết hạn
    • Với phần lớn người dùng, đây không nên là một sự kiện riêng biệt, và mọi sự cố phía client lẽ ra đã xảy ra trong 6 tháng trước đó

Người dùng và nhà vận hành cần kiểm tra gì

  • Người dùng Android 7.0 trở xuống 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
    • Let’s Encrypt khuyến nghị cài đặt và sử dụng Firefox Mobile, ứng dụng dùng trust store riêng thay vì trust store của Android OS
  • Nhà vận hành website nên kiểm tra thống kê sử dụng website và các chuỗi user-agent đang hoạt động trong quý 2 và quý 3 năm 2024
    • Nếu lượng truy cập từ Android giảm đột ngột, có thể vẫn còn nhiều người dùng Android 7.0 trở xuống
    • Khuyến nghị cung cấp hướng dẫn cho nhóm người dùng này về việc dùng Firefox Mobile
  • Tác giả ACME client phải tải xuống và cài đặt đúng chuỗi chứng chỉ do API cung cấp ở mỗi lần cấp phát và gia hạn chứng chỉ
    • Một kiểu lỗi trước đây là hoàn toàn không tải chuỗi mà chỉ cung cấp chứng chỉ end-entity
    • Cũng có trường hợp không tải chuỗi mà lại cung cấp chuỗi được hardcode sẵn
    • Cũng có trường hợp chỉ tải chuỗi ở lần cấp đầu tiên và không tải lại khi gia hạn
  • Các câu hỏi liên quan đến quá trình chuyển đổi có thể được đặt trên community forum của Let’s Encrypt

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-07-11
Ý kiến trên Hacker News

  • Nhớ là Let's Encrypt đã thông báo sẽ thực hiện chuyển đổi này vào mùa hè năm 2019, rồi sau đó nghe phản hồi từ cộng đồng và hoãn lại
    Khi đó tôi là một trong những người yêu cầu họ cân nhắc lại thật kỹ, nhưng cũng không ngờ ở vấn đề này họ lại trì hoãn tới tận 4 năm rưỡi, vượt xa kỳ vọng của tôi. Cảm ơn vì đã xử lý hệ sinh thái TLS một cách thận trọng như vậy

    • Có thể giải thích thêm không? Tôi vẫn đang dùng nó, nhưng hay quên mất Let's Encrypt quan trọng với website của tôi đến mức nào

  • Để bao phủ 95% thiết bị Android thì vẫn phải hỗ trợ tới Android 7.0 Nougat từ tháng 8/2016
    https://en.wikipedia.org/wiki/Android_Nougat
    Còn để bao phủ 95% thiết bị iOS thì chỉ cần iOS 14 từ tháng 9/2020, và ngay cả khi chỉ xét 90% thì Android là 8.1 (2017), còn iOS là 15 (2021)
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    Có vẻ Apple làm tốt hơn trong việc thuyết phục hoặc cho phép người dùng chuyển sang hệ điều hành mới hơn

    • Apple không bán điện thoại 10 đô ở các nước đang phát triển. Nếu so các thiết bị cùng tầm giá từ những hãng lớn hoặc nhà mạng lớn thì khác biệt có lẽ không cực đoan đến vậy
    • Đơn giản hơn thế. Apple không cho bên thứ ba sản xuất iPhone, còn Google thì cho bên thứ ba sản xuất điện thoại Android
      Lý do thiết bị không được cập nhật là vì nhà sản xuất ngừng cung cấp cập nhật
    • Việc nâng cấp hệ điều hành đang bị Google và các nhà sản xuất thiết bị cùng nhau xử lý rất tệ, nhưng không có lý do gì để gói CA phải bị buộc chặt vào phiên bản hệ điều hành
      Theo trang về gói CA của curl, gói Mozilla khi giải nén chỉ khoảng 200KB, còn ứng dụng Chrome trên Android của tôi là 25MB, nên tăng kích thước ứng dụng thêm 1% để luôn cập nhật có vẻ khá hợp lý
      Tất nhiên các ứng dụng khác cũng có thể muốn CA mới nhất, nhưng cũng đáng xem liệu có thực sự cần tất cả CA hay chỉ cần những CA có khả năng được dùng đến
    • Khi kiểm soát toàn bộ stack phần cứng và phần mềm thì việc giữ cho thiết bị cũ của khách hàng luôn cập nhật sẽ dễ hơn rất nhiều
      Google không thể làm được nhiều nếu một nhà sản xuất giá rẻ nào đó quyết định không cập nhật cho khách hàng. Họ có thể yêu cầu phải cung cấp cập nhật trong một khoảng thời gian nhất định để được hoặc duy trì chứng nhận Android, nhưng đến một lúc nào đó nhà sản xuất đó cũng có thể bỏ luôn Android
      Ngoài ra Qualcomm cũng không cung cấp kernel và blob được cập nhật cho các chipset cũ sau một thời gian. Google đã đàm phán để kéo dài thời gian này hơn con số 18 tháng đáng thất vọng trước đây, nhưng Qualcomm không có nghĩa vụ phải hợp tác hơn nữa. Khi Google bắt đầu tự làm chipset, họ cũng bớt quan tâm đến vấn đề này phần nào
      Không phải là tốt đẹp gì, nhưng với mô hình của Android thì phần lớn khó tránh khỏi như vậy, còn mô hình của Apple cho phép họ kiểm soát mảng này tốt hơn
    • Với tôi thì đó là nhờ camera được cải thiện

  • Cách họ giữ cho chứng chỉ ký chéo cũ tiếp tục hoạt động khá thú vị
    Chứng chỉ ký chéo mới hơi khác thường ở chỗ nó kéo dài quá cả thời điểm DST Root CA X3 hết hạn. Đây là giải pháp khả thi vì Android cố ý không bắt buộc kiểm tra ngày hết hạn của chứng chỉ được dùng làm trust anchor
    Trên thực tế, trust anchor hoạt động khá khác so với các chứng chỉ khác, điều này có thể khiến nhiều người ngạc nhiên
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • Giải pháp này không hề hoàn hảo. Phần lớn vấn đề được xử lý khá nhanh, nhưng nó vẫn dẫn đến một trong những chuỗi thảo luận dài nhất mà tôi từng thấy trên diễn đàn LE: https://community.letsencrypt.org/t/help-thread-for-dst-root...
      Nếu nhớ không nhầm thì một trong những vấn đề lớn là OpenSSL cũ vẫn kiểm tra việc root anchor đã hết hạn hay chưa. Và đó chưa phải tất cả; ở công ty lúc đó, Ubuntu phải vá gì đó để xử lý tình huống này, và bản vá chỉ được phát hành vài ngày trước khi hết hạn nên một số hệ thống đã bị gián đoạn ngắn. Chúng tôi phải rebuild hàng loạt image Docker để khắc phục sự cố
      Tôi cho rằng người ta chỉ dùng cách lách này vì nó quá mạnh tay và chưa từng có tiền lệ, trong khi chi phí để xin ký chéo từ một root chưa hết hạn và tương thích rộng rãi thì chênh lệch là rất lớn. Chắc hẳn họ cũng phải kiểm thử rất nhiều. Nó không hoàn hảo, nhưng việc mọi thứ nhìn chung vẫn trôi qua khá êm là điều đáng ấn tượng
    • Tôi hơi ngạc nhiên khi cách của Android lại không phải là cách phổ biến ở nơi khác. Tôi từng nghĩ việc kiểm tra thời gian của chuỗi chứng chỉ TLS C0 -> C1 -> C2 ... -> Cn sẽ chạy theo đại loại đoạn mã giả này
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Nhưng tìm kiếm rồi mới thấy thực tế nó hoạt động như phiên bản bỏ dòng 5, tức là mọi lần kiểm tra thời gian đều dựa trên thời điểm hiện tại. Tất cả chứng chỉ trong chuỗi đều phải còn hiệu lực ngay lúc này
      Chứng chỉ ký mã thì lại hoạt động theo cách mà tôi từng tưởng TLS cũng làm vậy. Mã có đóng dấu thời gian vẫn hợp lệ nếu tại thời điểm được đóng dấu, chứng chỉ gốc còn hiệu lực, kể cả bây giờ chứng chỉ gốc đã hết hạn

  • Hy vọng việc chứng chỉ ký chéo hết hạn sẽ không gây ra vấn đề gì với đa số mọi người, nhưng lần DST cross-sign hết hạn trước đó thì không như vậy.
    Nếu nhớ không nhầm thì GnuTLS đã không dựng được đường dẫn đúng cách sau khi hết hạn. Có vẻ nó chỉ tạo đường dẫn đi tới chứng chỉ đã hết hạn, báo là đã hết hạn rồi dừng lại, bỏ qua các đường dẫn khả dĩ khác.
    Tệ hơn nữa là GnuTLS chính là thư viện TLS mà apt dùng khi sử dụng HTTPS. HTTPS không phải mặc định, nhưng nhóm bảo mật của chúng tôi muốn phân phối an toàn bằng cách vendor toàn bộ package, điều đó tự nó là hợp lý, nhưng cái giá phải trả là sự cố ngừng dịch vụ. Hình như việc này đã được sửa trong Bullseye, và hoàn toàn may mắn là chỉ khoảng một tuần trước khi chứng chỉ hết hạn. Azure cũng gặp nhiều sự cố liên quan đến lần hết hạn đó.

    • Chẳng phải mọi nhà vận hành apt mirror đều gia hạn chứng chỉ LE cỡ mỗi tháng một lần bằng certbot sao? Vậy thì sau ngày 2024-06-06 họ sẽ nhận được chứng chỉ do root LE mới ký, không hết hạn và cũng không còn là ký chéo nữa, đúng không? Hay là tôi đang bỏ sót điều gì?

  • Ngoài việc dùng HTTP không mã hóa ra, có giải pháp nào được đề xuất để khiến TLS không còn là thành phần mong manh nhất của web nữa không?
    Những thay đổi liên miên như loại bỏ giao thức, hết hạn chứng chỉ, thay thế chứng chỉ có vẻ đã đẩy planned obsolescence lên quá mức.

    • Tôi không nghĩ TLS là thành phần mong manh nhất của web. Danh hiệu đó có lẽ nên thuộc về DNS, BGP, hoặc tùy theo tiêu chí thì là us-east-1.
    • Vấn đề không phải là TLS cứ thay đổi liên tục. Nó phải thay đổi vì lý do bảo mật.
      Phần tệ dẫn đến planned obsolescence là thiết bị quá nhanh chóng không còn nhận được bản cập nhật từ nhà sản xuất, và bên thứ ba cũng không thể cập nhật được.
      Giải pháp tôi thích là luật buộc nhà sản xuất không được ngừng phát hành cập nhật bảo mật trước khi sản phẩm ngừng bán được 10 năm, hoặc nếu muốn/ngừng thì phải công khai toàn bộ dưới dạng mã nguồn mở, hoặc hoàn tiền đầy đủ cho toàn bộ người mua.
    • Phần lớn sự bất tiện của TLS dường như nằm ở chỗ phải liên tục theo kịp việc cấp lại chứng chỉ.
      Lý do phải làm vậy là vì việc thu hồi phân tán ở quy mô toàn cầu là một bài toán cực kỳ khó đến mức phi lý. Để giảm nhẹ việc người dùng và chứng chỉ bị gắn với nhau theo cách gần như không thể thu hồi, người ta rút ngắn thời hạn chứng chỉ để thu nhỏ phạm vi thiệt hại.
      Tất nhiên đây không phải an ủi lớn lao gì, nhưng thế giới chứng chỉ thời hạn ngắn sau ACME vẫn có trải nghiệm cho lập trình viên tốt hơn so với thế giới ác mộng của chứng chỉ Verisign dài hạn. Cũng đáng nhớ là bất kỳ giải pháp thay thế nào cho TLS cũng khó tránh khỏi các vấn đề tương tự.
    • Về cơ bản tôi không nghĩ có thực thể nào có thể được tin cậy mãi mãi. Giải pháp tốt nhất là cung cấp cập nhật chứng chỉ tách biệt khỏi luồng cập nhật thông thường.
      Định dạng chứng chỉ x509 thực ra hầu như không thay đổi trong thời gian rất dài.
      Thay đổi ở cấp giao thức có lẽ giờ đã ổn định lại. TLS 1.2 được đưa vào từ năm 2008 và đến giờ vẫn được xem là ổn, nên khó mà coi là mới nữa. Rất nhiều người đã soi xét kỹ, nên hy vọng phần lớn vấn đề đã được lộ ra.
    • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      Theo tôi thì những gì Let's Encrypt đang làm về cơ bản cũng có thể xem là DANE, vậy nên tôi tự hỏi sao không hỗ trợ luôn. Dĩ nhiên có thể có những trường hợp sử dụng mà DANE không phù hợp.
      Có vẻ không nên để cái hoàn hảo cản trở cái đủ tốt, và ai muốn thì cứ để họ dùng DANE.

  • Câu “có thể giảm đáng kể chi phí vận hành để dồn nguồn lực cho quyền riêng tư và cải thiện bảo mật” có nghĩa là họ đang trả cỡ hàng triệu đô cho việc ký chéo sao?

    • Theo Form 990 năm 2021, họ đã trả cho Identrust 434.000 USD dưới mục “Internet Services”. Tôi không biết họ có nhận gì khác từ Identrust ngoài ký chéo hay không, nhưng có vẻ số tiền này có khả năng là chi phí cho việc ký chéo.
      Tổng chi phí cùng năm là 5,1 triệu USD, nên khoản chi này chiếm gần 10% ngân sách.
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • Có ai biết câu chuyện hậu trường về việc làm thế nào họ thuyết phục được công ty chứng chỉ ký chéo không? Let’s Encrypt chẳng phải đang giết chết hoàn toàn mô hình kinh doanh của họ sao?

    • Điều Let's Encrypt giết chết là mô hình bán chứng chỉ xác thực tên miền giá 10 USD/năm. Nếu muốn wildcard thì trước đây còn đắt hơn nhiều.
      Những công ty như RapidSSL hay GoDaddy có lẽ đã không ký chéo cho Let’s Encrypt trừ khi được đề nghị một khoản tiền ở mức “mua luôn toàn bộ mảng kinh doanh CA của chúng tôi đi”.
      Nhưng bán chứng chỉ DV không phải mô hình kinh doanh của IdenTrust, nên như người khác đã suy đoán, họ có thể sẵn sàng cung cấp ký chéo với số tiền chưa tới 6 chữ số. Với cách hoạt động của chứng chỉ root TLS, việc ký chéo của IdenTrust cũng hữu ích với LE chẳng kém gì ký chéo từ các CA siêu lợi nhuận.
    • Nếu tôi là một công ty chứng chỉ có thị trường mục tiêu là doanh nghiệp lớn, nơi khả năng dùng Let’s Encrypt thấp, thì tôi cũng sẽ ký chéo cho Let’s Encrypt để làm suy yếu các đối thủ phụ thuộc nhiều hơn vào doanh nghiệp nhỏ hay các dự án khác bị hấp dẫn bởi Let’s Encrypt.
    • Chắc là họ trả tiền để thuyết phục thôi. Nếu họ không làm thì cũng sẽ có người khác làm.
      Có vẻ IdenTrust cũng đâu có phá sản.
      1 IdenTrust 48.5% 53.6%
      2 DigiCert Group 13.1% 14.5%
      3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
      4 GlobalSign 6.1% 6.7%
      5 Let's Encrypt 5.8% 6.4%
      6 GoDaddy Group 4.8% 5.3%
      https://en.wikipedia.org/wiki/Certificate_authority
    • Hoàn toàn không. Các tổ chức chứng thực lớn đều đang bán cho khách hàng doanh nghiệp, và sau này cũng vẫn vậy. Phần lớn người dùng Letsencrypt là cá nhân hoặc thuộc nhóm gần với sở thích/hobbyist.

  • Vào cuối năm 2021, khi chứng chỉ trung gian ký chéo và chính DST Root CA X3 hết hạn, tất cả trình duyệt hiện đại đều đã tin cậy root của LE, nhưng hơn một phần ba thiết bị Android vẫn chạy hệ điều hành cũ nên đã có nguy cơ đột nhiên không còn tin cậy các website dùng chứng chỉ LE nữa
    Chỉ vài tuần trước tôi mới biết, có vẻ người dùng ubiquiti cũng bị ảnh hưởng

  • Gần đây khi chuyển backend từ AWS về máy chủ cục bộ, tôi đã phải đổi từ Letsencrypt vốn vẫn dùng sang ZeroSSL
    Vì các thiết bị IoT đời 2016 mà tôi còn phải hỗ trợ không có chứng chỉ root cần thiết để xác minh chứng chỉ LE. Có lẽ việc này liên quan đến việc chứng chỉ root R3 mà LE dùng đã hết hạn vào năm 2021
    Việc chỉ một chứng chỉ hết hạn mà có thể khiến toàn bộ sản phẩm đã bán ra biến thành cục gạch thật sự khá sốc. Trong trường hợp này thì không thành vấn đề lớn vì vẫn có chứng chỉ root hợp lệ từ nhà cung cấp khác

    • Khi chứng chỉ SHA-1 bị loại bỏ dần, đã có khá nhiều CA than vãn trên mozilla.dev.security.policy vì họ đã đưa chứng chỉ SHA-1 vào các thiết bị y tế và hệ thống POS nhưng gần như không có cách nào cập nhật
      Họ thậm chí còn tiếp tục phát hành sau cả thời hạn do CA/Browser Forum quy định. Tôi đã nghĩ khi đó mọi người đều nhận ra rằng việc dùng Web PKI trong khi không có cách đẩy cập nhật là điều không thể dung hòa, nhưng có vẻ không phải vậy

  • Ngay từ sau khi ký chéo được đưa vào sử dụng, các website nhắm tới desktop đã dần loại bỏ chứng chỉ ký chéo
    Vì nó tạo ra những vấn đề tương thích trước đây chưa từng có, và một số bộ xác minh chứng chỉ bị vấp ở chứng chỉ root đã hết hạn. Những người dùng bị ảnh hưởng không rành kỹ thuật nên cuối cùng cũng không xác định được nguyên nhân gốc rễ