Let’s Encrypt güven zincirini kısaltıyor

 (letsencrypt.org)
2 puan yazan GN⁺ 2023-07-11 | 1 yorum | WhatsApp'ta paylaş
  • Let’s Encrypt, 30 Eylül 2024'te süresi dolacak çapraz imzayı (cross-sign) uzatmayarak, ISRG Root X1 ile sona eren daha kısa bir sertifika zincirine geçiyor
  • İlk çıkış döneminde kendi kök sertifikası yeterince güvenilmiyordu ve bu yüzden IdenTrust’un DST Root CA X3 köküne bağımlıydı; ancak artık ISRG Root X1’in güven kapsamı büyük ölçüde genişledi
  • 2021'de eski Android uyumluluğu için eklenen kök çapraz imzası geçici bir önlemdi ve bu sayede eski Android cihazlar Let’s Encrypt sertifikalarına 3 yıl daha güvenebildi
  • Son 3 yılda ISRG Root X1'e güvenen Android cihazların oranı %66'dan %93,9'a yükseldi ve çapraz imza kaldırıldığında TLS el sıkışmasındaki sertifika baytları da %40'tan fazla azalıyor
  • Android 7.0 ve altı kullanıcılarına Firefox Mobile öneriliyor; site yöneticileri ile ACME istemcisi geliştiricilerinin de 2024 geçiş takvimine göre zincir işleme süreçlerini kontrol etmesi gerekiyor

Çapraz imzanın sona ermesinin arka planı

  • Let’s Encrypt, ilk çıkış döneminde sertifikalarının yaygın olarak güvenilmesi için ara sertifikasını IdenTrust’un DST Root CA X3 köküyle çapraz imzaladı
    • Bu yöntem, kendi kökü olan ISRG Root X1 henüz yaygın şekilde güvenilmese bile, söz konusu ara sertifikanın verdiği sertifikalara güvenilmesini sağlıyordu
  • Zamanla ISRG Root X1 kendi başına yaygın güven kazanmış oldu
  • 2021 sonuna gelindiğinde, çapraz imzalı ara sertifikanın ve DST Root CA X3’ün kendisinin süresi dolacaktı
    • O dönemde güncel tarayıcılar Let’s Encrypt köküne güveniyordu, ancak Android cihazların üçte birinden fazlası hâlâ eski OS sürümlerini kullanıyordu
    • Bu cihazlar, Let’s Encrypt sertifikalarını kullanan web sitelerine bir anda güvenemez hale gelebilirdi
  • Let’s Encrypt, 2021’de ara sertifikaya değil, doğrudan köke çapraz imza uygulayarak DST Root CA X3’ten daha uzun süre geçerli olacak geçici bir çözüm hazırladı
    • Bu sayede eski Android cihazlar Let’s Encrypt sertifikalarına 3 yıl daha güvenebildi
  • Söz konusu çapraz imzanın süresi 30 Eylül 2024 tarihinde doluyor

Neden daha kısa zincire geçiliyor?

  • Let’s Encrypt, artık uyumluluğu uzatmak için yeni bir çapraz imza almıyor
    • Son 3 yılda ISRG Root X1’e güvenen Android cihazların oranı %66'dan %93,9'a çıktı
    • Android 14, tam OS güncellemesi olmadan güven deposunu güncelleyebildiği için bu oran daha da artabilir
    • Çapraz imzanın kaldırılması, TLS el sıkışmasında taşınan sertifika baytı miktarını %40'tan fazla azaltıyor
    • İşletme maliyetleri de önemli ölçüde düşüyor; böylece Let’s Encrypt fonlarını gizlilik ve güvenlik iyileştirmelerine daha fazla odaklayabiliyor

2024 geçiş takvimi

  • 8 Şubat 2024 Perşembe: /acme/certificate API uç noktasına yapılan isteklerde varsayılan çapraz imza sunulması durduruldu
    • Abonelerin çoğu için bu, ACME istemcisinin ISRG Root X1 ile sona eren zinciri yapılandırması ve web sunucusunun TLS el sıkışmasında daha kısa zinciri sunması anlamına geliyordu
    • Yakında süresi dolacak çapraz imza ile sona eren daha uzun zincir ise alternatif zincir olarak istenebiliyordu
  • 6 Haziran 2024 Perşembe: daha uzun çapraz imzalı zincirin sunulması tamamen durduruldu
    • Bu tarih, çapraz imzanın sona ermesinden 90 günden biraz daha erken ve yaklaşık bir sertifika ömrü kadar öncesine denk geliyor
    • Amaç, abonelere çapraz imzalı zincirden çıkmaları için en az bir tam yenileme/düzenleme döngüsü sağlamaktı
  • 30 Eylül 2024 Pazartesi: çapraz imzalı sertifikanın süresi doluyor
    • Kullanıcıların çoğu için bunun ayrı bir olay olmaması gerekiyor; istemci tarafı arızaların önceki 6 ay içinde zaten ortaya çıkmış olması bekleniyor

Kullanıcılar ve yöneticiler neyi kontrol etmeli?

  • Android 7.0 ve altı kullanıcılarının, Let’s Encrypt sertifikalarıyla korunan web sitelerine erişmeye devam etmek için ek adım atması gerekebilir
    • Let’s Encrypt, Android OS güven deposu yerine kendi güven deposunu kullanan Firefox Mobile uygulamasının kurulmasını ve kullanılmasını öneriyor
  • Site yöneticileri, 2024’ün 2. ve 3. çeyreğinde web sitesi kullanım istatistiklerini ve etkin user-agent dizelerini kontrol etmeli
    • Android ziyaretlerinde ani düşüş varsa, Android 7.0 ve altı kullanıcıların kayda değer bir paya sahip olması muhtemeldir
    • Bu kullanıcılara Firefox Mobile kullanmaları yönünde bilgilendirme yapılması öneriliyor
  • ACME istemcisi geliştiricileri, her sertifika düzenleme ve yenileme sırasında API’nin sunduğu sertifika zincirini doğru şekilde indirip kurmalı
    • Geçmişte görülen hata türlerinden biri, zincirin hiç indirilmemesi ve yalnızca end-entity sertifikasının sunulmasıydı
    • Bir diğer durum, zincir indirilmeden hard-code edilmiş bir zincirin sunulmasıydı
    • Bir başka durumda ise zincir yalnızca ilk düzenlemede indiriliyor, yenileme sırasında yeniden indirilmiyordu
  • Geçişle ilgili sorular Let’s Encrypt community forum üzerinden sorulabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-11
Hacker News görüşleri

  • Let's Encrypt'in 2019 yazında bu geçişi yapacağını duyurup ardından topluluk geri bildirimini dinleyerek ertelediğini hatırlıyorum
    O dönemde yeniden değerlendirilmesini güçlü biçimde talep edenlerden biriydim ama bu konuda beklentilerin çok ötesine geçip tam 4,5 yıl gecikeceğini düşünmemiştim. TLS ekosistemini bu kadar dikkatli ele aldıkları için minnettarım

    • Açıklayabilir misin? Kullanıyorum ama Let's Encrypt'in web sitem için ne kadar önemli olduğunu sık sık unutuyorum

  • Android cihazların %95'ini kapsamak için Ağustos 2016'daki Android 7.0 Nougat sürümüne kadar destek vermek gerekiyor
    https://en.wikipedia.org/wiki/Android_Nougat
    iOS cihazlarda %95 kapsama için Eylül 2020'de çıkan iOS 14 yeterli oluyor; hatta yalnızca %90'a bakarsak Android'de 8.1 (2017), iOS'ta ise 15 (2021) gerekiyor
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    Apple, insanları daha yeni işletim sistemlerine geçmeye ikna etme ya da buna imkân tanıma konusunda daha başarılı görünüyor

    • Apple, gelişmekte olan ülkelerde 10 dolarlık telefonlar satmıyor. Aynı fiyat aralığındaki başlıca üretici veya operatör cihazları karşılaştırılırsa fark o kadar uç olmayabilir
    • Daha basit bir açıklaması var. Apple, üçüncü tarafların iPhone üretmesine izin vermezken Google, üçüncü tarafların Android telefon üretmesine izin veriyor
      Cihazların güncellenmemesinin nedeni, üreticinin güncelleme sunmayı bırakması
    • İşletim sistemi yükseltmeleri Google ile cihaz üreticileri tarafından birlikte kötü yönetiliyor ama CA paketinin işletim sistemi sürümüne bağlı olmak zorunda olması için bir neden yok
      curl'ün CA paketi sayfasına göre Mozilla paketi sıkıştırılmamış halde yaklaşık 200KB ve benim Android telefonumda Chrome uygulaması 25MB, dolayısıyla uygulama boyutunda %1 artışla bunu güncel tutmak makul görünüyor
      Elbette başka uygulamalar da güncel CA'lar isteyebilir ama gerçekten tüm CA'ların gerekip gerekmediği ya da yalnızca fiilen kullanılma ihtimali olanların yeterli olup olmadığı da tartışılabilir
    • Donanım ve yazılım yığınının tamamını kontrol ettiğinizde müşterilerin eski cihazlarını güncel tutmak çok daha kolay oluyor
      Google'ın, düşük maliyetli bir üretici müşterilere güncelleme vermemeye karar verirse yapabileceği fazla bir şey yok. Android sertifikası almak veya korumak için belli bir süre güncelleme sunmalarını şart koşabilir ama bir noktada o üretici Android'i tamamen bırakabilir
      Üstelik Qualcomm da zaman geçtikçe eski yonga setleri için güncellenmiş kernel ve blob'lar sağlamıyor. Google, eskiden gülünç derecede kısa olan 18 aylık süreyi uzatmaları için pazarlık yaptı ama Qualcomm'un daha fazlasını yapma zorunluluğu yok. Google kendi yonga setlerini üretmeye başlayınca bu soruna olan ilgisi de biraz azaldı
      Bunun iyi olduğunu söylemiyorum ama Android'in modeli gereği genelde sonuç böyle oluyor ve Apple'ın modeli bu alanlarda daha fazla kontrol sağlıyor
    • Benim için mesele geliştirilmiş kamera

  • Eski çapraz imzanın çalışmaya devam etmesini sağlama yöntemi oldukça ilginçti
    Yeni çapraz imza, DST Root CA X3'ün süresi dolduktan sonrasına kadar uzandığı için biraz sıra dışıydı. Bu, Android'in güven çıpası olarak kullanılan sertifikaların son kullanma tarihini bilerek zorunlu kılmaması sayesinde mümkün olan bir çözümdü
    Aslında güven çıpası, diğer sertifikalardan oldukça farklı çalıştığı için şaşırtıcı gelebilir
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • Bu çözüm kusursuz değildi. Çoğu sorun oldukça hızlı çözüldü ama Let's Encrypt forumunda gördüğüm en uzun başlıklardan birine yol açtı: https://community.letsencrypt.org/t/help-thread-for-dst-root...
      Hatırladığım kadarıyla büyük sorunlardan biri, eski OpenSSL sürümlerinin kök güven çıpasının süresinin dolup dolmadığını kontrol etmesiydi. Üstelik mesele bundan da ibaret değildi; o sırada çalıştığım şirkette Ubuntu'nun bu durumu ele alabilmek için bir şeyler yamaması gerekmişti ve yama ancak son kullanma tarihinden birkaç gün önce çıktı, bu yüzden bazı sistemler kısa süreli aksaklık yaşadı. Sorunu gidermek için çok sayıda Docker imajını yeniden derlemek zorunda kaldık
      Bu geçici çözüm o kadar radikal ve emsalsizdi ki, muhtemelen süresi dolmamış ve geniş uyumluluğa sahip bir kökten çapraz imza almanın maliyetine kıyasla fark çok büyük olduğu için tercih edildi. Muazzam miktarda test de gerekmiş olmalı. Kusursuz değildi ama genel olarak oldukça sorunsuz atlatılması etkileyiciydi
    • Android yaklaşımının başka yerlerde de yaygın yöntem olmaması beni biraz şaşırttı. TLS sertifika zinciri C0 -> C1 -> C2 ... -> Cn için zaman doğrulamasının kabaca şu sözde kod gibi çalıştığını sanıyordum
      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
      Ama araştırınca gerçekte 5. satırın olmadığı bir biçimde çalıştığını gördüm; yani tüm zaman kontrolleri mevcut zamana göre yapılıyor. Zincirdeki tüm sertifikaların şu anda geçerli olması gerekiyor
      Kod imzalama sertifikaları ise TLS'in de böyle çalıştığını düşündüğüm şekilde çalışıyor. Zaman damgalı bir kodun kök sertifikasının süresi dolmuş olsa bile, zaman damgası anında kök geçerliyse kod hâlâ geçerli sayılıyor

  • Çapraz imzalı sertifikanın süresinin dolmasının çoğu kişi için bir sorun yaratmamasını umuyorum, ancak önceki DST çapraz imza süresi dolumu öyle olmamıştı
    Hatırladığım kadarıyla GnuTLS, süre dolumundan sonra yol oluşturmayı düzgün yapamamıştı. Yalnızca süresi dolmuş sertifikaya giden yolu kuruyor, sonra da süresi dolduğunu görüp diğer olası yolları yok sayarak duruyormuş gibi görünüyordu
    Daha da kötüsü, GnuTLS apt'nin HTTPS kullanırken yararlandığı TLS kütüphanesiydi. HTTPS varsayılan değildi ama güvenlik ekibimiz tüm paketleri vendor olarak getirip güvenli şekilde sunmak istiyordu; bu başlı başına makul olsa da bedeli kesinti oldu. Sanırım Bullseye'da düzeltilmişti ve tamamen şans eseri, süre dolumundan yalnızca yaklaşık bir hafta önceydi. Azure da bu süre dolumuyla bağlantılı olarak çeşitli kesintiler yaşadı

    • Bütün apt mirror işletmecileri certbot ile ayda bir kadar LE sertifikalarını yenilemiyor mu? O zaman 6 Haziran 2024'ten sonra süresi dolmamış ve çapraz imzalı da olmayan, yeni LE root tarafından imzalanmış sertifikalar alacaklar gibi görünüyor; benim kaçırdığım bir şey mi var?

  • Şifrelenmemiş HTTP kullanmak dışında, TLS'nin artık web'in en kırılgan bileşeni olmamasını sağlayacak önerilmiş bir çözüm var mı?
    Protokolün kaldırılması, sertifika sürelerinin dolması, değiştirmeler gibi bitmeyen değişiklikler planlı eskitmeyi gereğinden fazla büyütmüş gibi görünüyor

    • TLS'nin web'in en kırılgan bileşeni olduğunu düşünmüyorum. Bu ödül muhtemelen DNS'e, BGP'ye veya kritere göre us-east-1'e gider
    • Sorun TLS'nin sürekli değişmesi değil. Güvenlik için değişmek zorunda
      Planlı eskitmeye yol açan kötü taraf, cihazların üretici güncellemelerini çok hızlı biçimde alamaz hale gelmesi ve üçüncü tarafların da güncelleme yapamaması
      Benim tercih ettiğim çözüm, üreticilerin satış sonundan itibaren 10 yıl dolmadan güvenlik güncellemesi üretmeyi durdurmasının yasak olması ya da durdurmak istiyorlarsa her şeyi açık kaynak yapmaları veya tüm alıcıların tam geri ödeme alabilmesi yönünde bir yasa olurdu
    • TLS'deki rahatsızlığın büyük kısmı, sertifika yeniden düzenleme sürecine sürekli ayak uydurmak zorunda olmanız gibi görünüyor
      Bunun gerekli olmasının sebebi, dünya çapında dağıtık iptalin son derece zor bir problem olması. Kullanıcı ile sertifikanın kısmen birbirine bağlanmış olmasının fiilen iptal edilemez hale gelmesini hafifletmek için sertifika ömürlerini kısaltıp etki alanını küçültüyoruz
      Elbette bu çok teselli etmiyor ama ACME sonrası kısa ömürlü sertifika dünyası, uzun süreli Verisign sertifikalarının kâbus gibi dünyasına kıyasla geliştirici deneyimi açısından daha iyi. TLS'ye alternatiflerin de benzer sorunlarla karşılaşacağını akılda tutmakta fayda var
    • Temelde hiçbir varlığa sonsuza kadar güvenilebileceğini sanmıyorum. En iyi çözüm, normal güncelleme yolundan ayrı olarak sertifika güncellemeleri sunmaktır
      x509 sertifika biçimi aslında uzun zamandır neredeyse hiç değişmedi
      Protokol değişiklikleri artık istikrar kazanıyor gibi görünüyor. TLS 1.2 2008'de tanıtıldı ve hâlâ yeterli kabul ediliyor, dolayısıyla artık yeni sayılmaz. Birçok kişi onu dikkatle incelediği için sorunların çoğunun ortaya çıkmış olmasını umuyoruz
    • DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      Bence Let's Encrypt'in yaptığı şey özünde DANE olarak görülebilir; öyleyse neden doğrudan desteklenmesin ki? Elbette DANE'in uygun olmadığı kullanım senaryoları olabilir
      Mükemmelin yeterince iyinin önüne geçmesi için bir sebep görmüyorum; isteyen DANE kullansın

  • “İşletme maliyetlerini büyük ölçüde azaltıp gizlilik ve güvenlik iyileştirmelerine kaynak ayırabiliriz” sözü, çapraz imza için milyonlarca dolar gibi tutarlar ödendiği anlamına mı geliyor?

    • 2021 Form 990'a göre, Identrust'a “Internet Services” kalemi altında 434.000 dolar ödendi. Identrust'tan çapraz imza dışında başka bir şey alınıp alınmadığını bilmiyorum ama bu tutarın çapraz imza maliyeti olması muhtemel görünüyor
      Aynı yıl toplam gider 5,1 milyon dolardı; yani bu harcama bütçenin neredeyse %10'una denk geliyor
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • Sertifika şirketinin nasıl çapraz imza vermeye ikna edildiğine dair perde arkası hikâyeyi bilen var mı? Let’s Encrypt onların iş modelini tamamen öldürmüyor mu?

    • Let's Encrypt'in öldürdüğü şey, yıllık 10 dolarlık alan adı doğrulamalı sertifika satış iş modeliydi. Wildcard istiyorsanız fiyat çok daha yüksekti
      RapidSSL veya GoDaddy gibi şirketler, “tüm CA işimizi satın alın” seviyesinde para teklif edilmedikçe Let’s Encrypt'e çapraz imza vermezdi
      Ama DV sertifika satışı IdenTrust'ın iş modeli değildi; bu yüzden başkalarının tahmin ettiği gibi 6 haneli rakamın altında bir bedelle çapraz imza sağlamaya istekli olmuş olabilir. TLS root sertifikalarının çalışma biçimi nedeniyle IdenTrust'ın çapraz imzası da, aşırı kârlı bir CA'nın çapraz imzası kadar LE için faydalıydı
    • Hedef pazarım Let’s Encrypt kullanma olasılığı düşük olan büyük şirketler olan bir sertifika şirketi olsaydı, Let’s Encrypt'e ilgi duyan küçük işletmelere veya başka projelere daha çok bağımlı rakipleri zayıflatmak için çapraz imza verirdim
    • Muhtemelen para vererek ikna ettiler. Onlar yapmasaydı başkası yapardı
      IdenTrust da batmış gibi görünmüyor
      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
    • Hiç de değil. Büyük sertifika otoritelerinin hepsi kurumsal müşterilere satış yapıyor ve yapmaya da devam edecek. Letsencrypt kullanıcılarının çoğu bireysel ya da hobi tarafına daha yakın

  • 2021 sonlarında çapraz imzalı ara sertifikanın ve DST Root CA X3’ün kendisi süresi dolduğunda, modern tarayıcıların hepsi LE köküne güveniyordu; ancak Android cihazların üçte birinden fazlası hâlâ eski işletim sistemleri çalıştırdığı için LE sertifikası kullanan web sitelerine bir anda güvenememe riski ortaya çıkmış
    Bunu ancak birkaç hafta önce öğrendim ama ubiquiti kullanıcıları da etkilenmiş gibi görünüyor

  • Kısa süre önce backend’i AWS’den yerel sunucuya taşırken, her zamanki Letsencrypt yerine ZeroSSL kullanmak zorunda kaldım
    Çünkü desteklediğim 2016 üretimi IoT cihazlarında LE sertifikasını doğrulamak için gereken kök sertifika yoktu. Muhtemelen bu, LE’nin kullandığı R3 kök sertifikasının 2021’de sona ermesiyle ilgiliydi
    Tek bir sertifikanın süresinin dolmasının, satılmış ürünlerin tamamını kullanılamaz hale getirebilmesi oldukça sarsıcıydı. Bu durumda başka bir sağlayıcının geçerli kök sertifikası olduğu için büyük bir sorun yaşanmadı

    • SHA-1 aşamalı olarak devreden çıkarılırken, tıbbi cihazlara ve POS sistemlerine SHA-1 sertifikaları koymuş ve bunları güncellemenin neredeyse hiçbir yolu olmayan CA’ler mozilla.dev.security.policy’de epey sızlanmıştı
      Hatta CA/Browser Forum’un belirlediği tarihten sonra bile bunları vermeye devam ettiler. O zaman herkesin Web PKI kullanmasının, ama güncelleme dağıtmanın bir yolu olmamasının birbiriyle bağdaşmadığını fark ettiğini sanmıştım; ama öyle değilmiş

  • Çapraz imzalama sunulduktan hemen sonra, masaüstünü hedefleyen sitelerde çapraz imzalı sertifikalar kaldırılmaya başlanmıştı
    Çünkü daha önce olmayan uyumluluk sorunları ortaya çıktı ve bazı sertifika doğrulayıcıları süresi dolmuş kök sertifikada takılıp kaldı. Etkilenen kullanıcılar teknik olmayan kişiler olduğundan, kök neden hiçbir zaman tam olarak anlaşılamadı