Pemendekan rantai kepercayaan Let’s Encrypt

 (letsencrypt.org)
2 poin oleh GN⁺ 2023-07-11 | 1 komentar | Bagikan ke WhatsApp
  • Let’s Encrypt beralih ke rantai sertifikat yang lebih pendek yang berakhir di ISRG Root X1, tanpa memperpanjang cross-sign yang akan kedaluwarsa pada 30 September 2024
  • Pada awal peluncurannya, karena root miliknya sendiri belum cukup dipercaya, Let’s Encrypt bergantung pada DST Root CA X3 milik IdenTrust, tetapi kini cakupan kepercayaan untuk ISRG Root X1 telah meluas secara signifikan
  • Cross-sign root yang ditambahkan pada 2021 untuk kompatibilitas Android lama adalah langkah sementara, dan berkat itu perangkat Android lama dapat terus mempercayai sertifikat Let’s Encrypt selama 3 tahun tambahan
  • Dalam 3 tahun terakhir, persentase perangkat Android yang mempercayai ISRG Root X1 naik dari 66% menjadi 93.9%, dan penghapusan cross-sign juga mengurangi byte sertifikat dalam TLS handshake lebih dari 40%
  • Pengguna Android 7.0 ke bawah disarankan menggunakan Firefox Mobile, dan operator situs serta penulis klien ACME perlu memeriksa penanganan rantai sertifikat agar sesuai dengan jadwal transisi 2024

Latar belakang berakhirnya cross-sign

  • Pada awal peluncurannya, Let’s Encrypt melakukan cross-sign sertifikat perantara dengan DST Root CA X3 milik IdenTrust agar sertifikatnya dipercaya secara luas
    • Ini adalah cara agar sertifikat yang diterbitkan oleh sertifikat perantara tersebut tetap dipercaya meskipun root miliknya sendiri, ISRG Root X1, belum dipercaya secara luas
  • Seiring waktu, ISRG Root X1 kemudian menjadi dipercaya secara luas dengan sendirinya
  • Pada akhir 2021, sertifikat perantara yang di-cross-sign dan DST Root CA X3 sendiri dijadwalkan akan kedaluwarsa
    • Pada saat itu browser modern sudah mempercayai root Let’s Encrypt, tetapi lebih dari sepertiga perangkat Android masih menjalankan versi OS lama
    • Perangkat-perangkat ini bisa saja tiba-tiba tidak lagi mempercayai situs web yang menggunakan sertifikat Let’s Encrypt
  • Pada 2021, Let’s Encrypt menerapkan cross-sign langsung ke root, bukan ke sertifikat perantara, sebagai langkah sementara yang bertahan lebih lama daripada DST Root CA X3
    • Dengan langkah ini, perangkat Android lama dapat terus mempercayai sertifikat Let’s Encrypt selama 3 tahun tambahan
  • Cross-sign tersebut akan kedaluwarsa pada 30 September 2024

Alasan beralih ke rantai yang lebih pendek

  • Let’s Encrypt tidak lagi memperoleh cross-sign baru untuk memperpanjang kompatibilitas
    • Dalam 3 tahun terakhir, persentase perangkat Android yang mempercayai ISRG Root X1 meningkat dari 66% menjadi 93.9%
    • Android 14 dapat memperbarui trust store tanpa pembaruan OS penuh, sehingga persentase ini bisa meningkat lebih lanjut
    • Penghapusan cross-sign mengurangi jumlah byte sertifikat yang dikirim dalam TLS handshake hingga lebih dari 40%
    • Biaya operasional juga turun secara signifikan, sehingga Let’s Encrypt dapat memfokuskan pendanaan pada peningkatan privasi dan keamanan

Jadwal transisi 2024

  • Kamis, 8 Februari 2024: berhenti menyediakan cross-sign default untuk permintaan ke endpoint API /acme/certificate
    • Bagi sebagian besar pelanggan, klien ACME akan mengatur rantai yang berakhir di ISRG Root X1, dan web server akan menyajikan rantai yang lebih pendek dalam TLS handshake
    • Rantai yang lebih panjang yang berakhir pada cross-sign yang akan segera kedaluwarsa masih dapat diminta sebagai rantai alternatif
  • Kamis, 6 Juni 2024: sepenuhnya menghentikan penyediaan rantai cross-sign yang lebih panjang
    • Titik ini sedikit lebih dari 90 hari sebelum cross-sign kedaluwarsa, setara dengan masa berlaku 1 sertifikat
    • Jadwal ini dimaksudkan untuk memastikan pelanggan memiliki setidaknya satu siklus penerbitan penuh agar dapat lepas dari rantai cross-sign
  • Senin, 30 September 2024: sertifikat cross-sign kedaluwarsa
    • Bagi sebagian besar pengguna, ini seharusnya bukan peristiwa tersendiri, dan kegagalan klien semestinya sudah terjadi selama 6 bulan sebelumnya

Hal yang perlu diperiksa oleh pengguna dan operator

  • Pengguna Android 7.0 ke bawah mungkin perlu mengambil tindakan agar tetap dapat mengakses situs web yang dilindungi sertifikat Let’s Encrypt
    • Let’s Encrypt merekomendasikan memasang dan menggunakan Firefox Mobile, yang memakai trust store sendiri alih-alih trust store OS Android
  • Operator situs perlu memeriksa statistik penggunaan situs web dan string user-agent aktif pada kuartal 2 dan 3 tahun 2024
    • Jika kunjungan Android tiba-tiba menurun, kemungkinan ada cukup banyak pengguna Android 7.0 ke bawah
    • Disarankan memberi panduan kepada pengguna tersebut untuk memakai Firefox Mobile
  • Penulis klien ACME harus mengunduh dan memasang rantai sertifikat yang disediakan API dengan benar setiap kali sertifikat diterbitkan atau diperbarui
    • Jenis gangguan yang pernah terjadi antara lain tidak mengunduh rantai sama sekali dan hanya menyajikan sertifikat end-entity
    • Ada juga kasus menyajikan rantai yang di-hardcode tanpa mengunduh rantainya
    • Ada pula kasus hanya mengunduh rantai saat penerbitan awal dan tidak mengunduh ulang saat pembaruan
  • Pertanyaan terkait transisi dapat diajukan di community forum Let’s Encrypt

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-11
Opini Hacker News

  • Saya ingat Let's Encrypt pernah mengumumkan pada musim panas 2019 bahwa mereka akan melakukan transisi ini, lalu menundanya setelah mendengar masukan komunitas
    Saat itu saya termasuk salah satu orang yang sangat meminta mereka mempertimbangkannya ulang, tetapi saya tidak menyangka dalam hal ini mereka akan jauh melampaui ekspektasi dan menundanya sampai 4,5 tahun. Terima kasih karena menangani ekosistem TLS dengan begitu hati-hati

    • Bisa jelaskan? Saya memakainya, tetapi sering lupa seberapa penting Let's Encrypt bagi situs web saya

  • Untuk mencakup 95% perangkat Android, perlu mendukung hingga Android 7.0 Nougat dari Agustus 2016
    https://en.wikipedia.org/wiki/Android_Nougat
    Untuk mencakup 95% perangkat iOS, iOS 14 dari September 2020 sudah cukup; bahkan jika hanya melihat 90%, Android adalah 8.1 (2017), sementara iOS adalah 15 (2021)
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    Apple tampaknya lebih baik dalam meyakinkan atau memungkinkan orang berpindah ke sistem operasi yang lebih baru

    • Apple tidak menjual ponsel seharga 10 dolar di negara berkembang. Jika membandingkan perangkat dari produsen atau operator besar di rentang harga yang sama, perbedaannya mungkin tidak akan seekstrem itu
    • Lebih sederhana lagi. Apple tidak mengizinkan pihak ketiga membuat iPhone, sedangkan Google mengizinkan pihak ketiga membuat ponsel Android
      Alasan perangkat tidak diperbarui adalah karena produsen berhenti menyediakan pembaruan
    • Upgrade sistem operasi memang ditangani dengan buruk oleh Google dan produsen perangkat bersama-sama, tetapi tidak ada alasan CA bundle harus terikat pada versi sistem operasi
      Menurut halaman CA bundle milik curl, bundle Mozilla sekitar 200KB setelah diekstrak, dan di Android saya aplikasi Chrome berukuran 25MB, jadi menjaga agar tetap terbaru dengan menambah ukuran aplikasi 1% tampaknya masuk akal
      Tentu aplikasi lain juga mungkin menginginkan CA terbaru, tetapi patut dipertimbangkan juga apakah semuanya membutuhkan semua CA, atau cukup CA yang kemungkinan benar-benar akan dipakai
    • Jika mengendalikan seluruh stack hardware dan software, jauh lebih mudah menjaga perangkat lama pelanggan tetap mutakhir
      Google tidak bisa berbuat banyak jika produsen murah tertentu memutuskan tidak akan memperbarui pelanggannya. Mereka bisa mensyaratkan pembaruan selama periode tertentu untuk mendapatkan atau mempertahankan sertifikasi Android, tetapi pada titik tertentu produsen itu juga bisa saja meninggalkan Android itu sendiri
      Selain itu Qualcomm juga, seiring waktu, tidak menyediakan kernel dan blob yang diperbarui untuk chipset lama. Google memang bernegosiasi agar periodenya diperpanjang dibanding 18 bulan lama yang menyedihkan itu, tetapi Qualcomm tidak berkewajiban untuk lebih kooperatif. Setelah Google mulai membuat chipset sendiri, perhatian terhadap masalah ini juga sedikit berkurang
      Bukan berarti ini bagus, tetapi dengan model Android, sebagian besar memang hampir tak terhindarkan, dan model Apple memungkinkan mereka mengendalikan hal-hal seperti ini dengan lebih baik
    • Dalam kasus saya, alasannya adalah kamera yang lebih baik

  • Cara mereka membuat cross-sign lama tetap berfungsi cukup menarik
    Cross-sign baru itu agak tidak biasa karena berlanjut hingga setelah DST Root CA X3 kedaluwarsa. Solusi ini dimungkinkan karena Android sengaja tidak memaksakan tanggal kedaluwarsa sertifikat yang digunakan sebagai trust anchor
    Memang, trust anchor berperilaku cukup berbeda dari sertifikat lain, dan itu bisa mengejutkan
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • Solusi ini tidak sempurna. Sebagian besar masalah diselesaikan cukup cepat, tetapi itu memicu salah satu thread terpanjang yang pernah saya lihat di forum LE: https://community.letsencrypt.org/t/help-thread-for-dst-root...
      Seingat saya, salah satu masalah besar adalah OpenSSL lama memeriksa kedaluwarsa root anchor. Itu pun bukan semuanya; di perusahaan saat itu, Ubuntu harus mem-patch sesuatu untuk menangani situasi ini, dan patch baru keluar beberapa hari sebelum kedaluwarsa sehingga sebagian sistem sempat mengalami gangguan singkat. Kami harus membangun ulang banyak image Docker untuk memperbaiki masalahnya
      Saya rasa workaround ini dipakai karena sangat ekstrem dan belum ada presedennya, sehingga selisihnya sangat besar dibanding biaya mendapatkan cross-sign dari root yang belum kedaluwarsa dan kompatibel luas. Pengujiannya juga pasti luar biasa banyak. Walau tidak sempurna, cukup mengesankan bahwa semuanya secara umum berjalan mulus
    • Saya agak terkejut bahwa cara Android bukanlah cara yang umum juga di tempat lain. Saya kira validasi waktu untuk chain sertifikat TLS C0 -> C1 -> C2 ... -> Cn bekerja kira-kira seperti pseudocode ini
      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
      Namun setelah mencari, ternyata dalam praktiknya ia berjalan dengan baris 5 dihilangkan, sehingga semua pemeriksaan waktu dilakukan berdasarkan waktu saat ini. Semua sertifikat dalam chain harus valid sekarang
      Sertifikat code signing bekerja seperti cara yang saya kira juga berlaku untuk TLS. Kode yang diberi timestamp tetap valid meskipun sertifikat root sudah kedaluwarsa, asalkan root tersebut valid pada saat timestamp dibuat

  • Semoga kedaluwarsanya sertifikat tanda tangan silang tidak berdampak apa pun bagi kebanyakan orang, tetapi kedaluwarsanya tanda tangan silang DST dulu tidak demikian
    Seingat saya, GnuTLS tidak bisa menyusun jalur dengan benar setelah kedaluwarsa. Tampaknya ia hanya membuat jalur menuju sertifikat yang sudah kedaluwarsa, melaporkannya sebagai kedaluwarsa, lalu berhenti sambil mengabaikan jalur lain yang mungkin
    Yang lebih buruk, GnuTLS adalah pustaka TLS yang digunakan apt saat memakai HTTPS. HTTPS memang bukan default, tetapi tim keamanan kami ingin semua paket disediakan dengan aman melalui vendor, dan itu sendiri masuk akal, tetapi biayanya adalah gangguan layanan. Sepertinya sudah diperbaiki di Bullseye, dan murni karena beruntung, hanya sekitar seminggu sebelum kedaluwarsa. Azure juga mengalami beberapa gangguan terkait kedaluwarsa itu

    • Bukankah semua operator mirror apt memperbarui sertifikat LE mereka kira-kira sebulan sekali dengan certbot? Kalau begitu, setelah 6 Juni 2024 mereka seharusnya menerima sertifikat yang ditandatangani oleh root LE baru yang tidak kedaluwarsa dan bukan hasil tanda tangan silang, atau ada yang saya lewatkan?

  • Selain memakai HTTP yang tidak terenkripsi, adakah solusi yang diusulkan agar TLS tidak lagi menjadi komponen paling rapuh di web?
    Perubahan terus-menerus seperti penghentian protokol, kedaluwarsa sertifikat, dan penggantian tampaknya seperti memperbesar planned obsolescence secara berlebihan

    • Saya tidak melihat TLS sebagai komponen paling rapuh di web. Gelar itu mungkin jatuh ke DNS, BGP, atau us-east-1, tergantung kriterianya
    • Masalahnya bukan karena TLS terus berubah. Ia memang harus berubah demi keamanan
      Bagian buruk yang mengarah ke planned obsolescence adalah perangkat terlalu cepat tidak lagi menerima pembaruan dari produsen, dan pihak ketiga juga tidak bisa memperbaruinya
      Solusi yang saya sukai adalah undang-undang yang mewajibkan produsen, jika harus atau ingin berhenti membuat pembaruan keamanan sebelum 10 tahun sejak akhir penjualan, untuk membuka semuanya sebagai open source atau memungkinkan semua pembeli mendapat pengembalian dana penuh
    • Sebagian besar ketidaknyamanan pada TLS tampaknya berasal dari keharusan terus mengikuti penerbitan ulang sertifikat
      Alasan hal itu perlu dilakukan adalah karena pencabutan terdistribusi dalam skala global adalah masalah yang luar biasa sulit. Untuk mengurangi dampak fakta bahwa sebagian kombinasi pengguna dan sertifikat pada dasarnya tidak bisa dicabut, masa berlaku sertifikat dipersingkat agar lingkup kerusakan tetap kecil
      Tentu itu bukan penghiburan besar, tetapi dunia sertifikat berumur pendek setelah ACME memang memberikan pengalaman pengembang yang lebih baik daripada dunia mimpi buruk sertifikat Verisign jangka panjang. Patut diingat bahwa alternatif TLS pun pasti akan menghadapi masalah serupa
    • Pada dasarnya, menurut saya tidak ada entitas yang bisa dipercaya selamanya. Solusi terbaik adalah menyediakan pembaruan sertifikat terpisah dari jalur pembaruan biasa
      Format sertifikat x509 pada praktiknya sudah lama tidak berubah
      Perubahan protokol tampaknya akan mulai stabil sekarang. TLS 1.2 diperkenalkan pada 2008 dan masih dianggap baik, jadi sulit menyebutnya baru lagi. Karena sudah banyak orang menelaahnya dengan cermat, kita berharap sebagian besar masalah sudah terungkap
    • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      Menurut saya, apa yang dilakukan Let's Encrypt pada dasarnya bisa dianggap DANE, jadi kalau begitu kenapa tidak mendukungnya saja. Tentu mungkin ada use case yang tidak cocok untuk DANE
      Kesempurnaan rasanya tidak perlu menghalangi sesuatu yang sudah cukup baik, dan biarkan orang yang menginginkannya memakai DANE

  • Apakah pernyataan “dapat sangat mengurangi biaya operasional sehingga dana bisa difokuskan pada peningkatan privasi dan keamanan” berarti mereka membayar jumlah seperti jutaan dolar untuk tanda tangan silang?

    • Berdasarkan Form 990 tahun 2021, mereka membayar 434.000 dolar kepada Identrust dengan keterangan “Internet Services”. Saya tidak tahu apakah mereka menerima hal lain dari Identrust selain tanda tangan silang, tetapi tampaknya ada kemungkinan jumlah ini adalah biaya tanda tangan silang
      Total biaya pada tahun yang sama adalah 5,1 juta dolar, jadi pengeluaran ini hampir 10% dari anggaran
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • Ada yang tahu cerita di balik bagaimana perusahaan sertifikat akhirnya mau memberikan tanda tangan silang? Bukankah Let’s Encrypt sepenuhnya menghancurkan model bisnis mereka?

    • Yang dihancurkan Let's Encrypt adalah model bisnis penjualan sertifikat validasi domain seharga 10 dolar per tahun. Kalau ingin wildcard, harganya jauh lebih mahal
      Perusahaan seperti RapidSSL atau GoDaddy tidak akan memberikan tanda tangan silang kepada Let’s Encrypt kecuali ditawari uang setingkat “beli seluruh bisnis CA kami”
      Namun penjualan sertifikat DV bukan model bisnis IdenTrust, jadi seperti perkiraan di tempat lain, mereka mungkin bersedia menyediakan tanda tangan silang dengan jumlah di bawah enam digit. Karena cara kerja sertifikat root TLS, tanda tangan silang dari IdenTrust sama bergunanya bagi LE seperti tanda tangan silang dari CA yang sangat menguntungkan
    • Jika saya perusahaan sertifikat yang target pasarnya adalah perusahaan besar yang kecil kemungkinannya memakai Let’s Encrypt, saya akan memberikan tanda tangan silang kepada Let’s Encrypt untuk melemahkan pesaing yang lebih bergantung pada usaha kecil atau proyek lain yang tertarik pada Let’s Encrypt
    • Mungkin mereka dibujuk dengan uang. Kalau tidak, orang lain pasti akan melakukannya
      Sepertinya IdenTrust juga tidak bangkrut
      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
    • Sama sekali tidak. Semua otoritas sertifikat utama menjual kepada pelanggan korporat, dan akan terus begitu. Sebagian besar pengguna Letsencrypt lebih dekat ke individu atau ranah hobi

  • Ketika sertifikat perantara yang ditandatangani silang dan DST Root CA X3 itu sendiri kedaluwarsa pada akhir 2021, semua browser modern sudah memercayai root LE, tetapi lebih dari sepertiga perangkat Android masih menjalankan sistem operasi lama, sehingga situs web yang menggunakan sertifikat LE bisa tiba-tiba tidak dipercaya
    Saya baru mengetahuinya beberapa minggu lalu, dan tampaknya pengguna Ubiquiti juga terdampak

  • Baru-baru ini saat memindahkan backend dari AWS ke server lokal, saya harus beralih ke ZeroSSL alih-alih Letsencrypt yang biasa saya gunakan
    Alasannya, perangkat IoT keluaran 2016 yang masih didukung tidak memiliki sertifikat root yang diperlukan untuk memverifikasi sertifikat LE. Mungkin ini terkait dengan kedaluwarsanya sertifikat root R3 yang digunakan LE pada 2021
    Cukup mengejutkan bahwa kedaluwarsanya satu sertifikat bisa membuat seluruh produk yang sudah terjual menjadi brick. Dalam kasus ini, tidak terlalu bermasalah karena ada sertifikat root yang valid dari penyedia lain

    • Saat SHA-1 mulai dipensiunkan secara bertahap, banyak CA yang banyak mengeluh di mozilla.dev.security.policy karena mereka telah memasukkan sertifikat SHA-1 ke perangkat medis dan sistem POS, dengan nyaris tidak ada cara untuk memperbaruinya
      Mereka bahkan terus menerbitkannya setelah tanggal yang ditetapkan CA/Browser Forum lewat. Saat itu saya kira semua orang sudah sadar bahwa memakai Web PKI tanpa cara untuk mendorong pembaruan itu tidak kompatibel, tetapi sepertinya tidak begitu

  • Sejak tak lama setelah penandatanganan silang diperkenalkan, kami telah menghapus sertifikat penandatanganan silang dari situs yang ditujukan untuk desktop
    Itu menimbulkan masalah kompatibilitas yang sebelumnya tidak ada, dan sebagian validator sertifikat tersandung pada sertifikat root yang sudah kedaluwarsa. Para pengguna yang terdampak bukan orang teknis, jadi penyebab dasarnya pada akhirnya tidak pernah kami ketahui