Let's Encrypt, IP adresi sertifikaları vermeye hazırlanıyor

• Let's Encrypt yakında IP adresi SAN içeren sertifikaların verilmesini destekleyecek; başlangıçta bu destek yalnızca 6 günlük geçerlilik süresine sahip kısa ömürlü (short-lived) profil ile sunulacak ve bir süre izin listesi yöntemiyle sınırlı olarak işletilecek
• Resmî duyuru öncesinde belirli bir takvim ya da başvuru bilgisi olmadan iç testler ve hazırlıklar sürüyor
• Staging ortamında IPv6 adresi içeren örnek sertifika ve bunun uygulandığı site yayımlandı; topluluktan anormallikler veya geri bildirimlerini paylaşmaları istendi
• Firefox'ta IP SAN gösterimiyle ilgili bir hata (BZ #1973855) bulundu ve testler sürüyor
• DNS SAN ile IP SAN'ın karışık kullanıldığı durumlarda kafa karışıklığı olabileceği gerçek test örneğiyle doğrulandı; TLD ile IPv6 adresi gösterimlerinin benzer olabileceği gösterildi

---

Let's Encrypt, IP address certificates vermeye hazırlanıyor

IP adresi SAN desteği için hazırlık durumu

• Let's Encrypt yakında üretim ortamında IP adresi SAN içeren sertifikaların verilmesini desteklemeyi planlıyor
• Bu sertifikalar yalnızca 6 günlük geçerlilik süresine sahip short-lived profil kapsamında verilecek ve bir süre izin listesi (allowlist) yöntemiyle sınırlı olarak işletilecek
• Henüz resmî çıkış takvimi ve izin listesine başvuru yöntemi netleşmedi; ek iç hazırlıklar gerekiyor

Testler ve örnek sertifikalar

• Staging ortamında IP SAN içeren örnek sertifika ve bunun gerçek uygulama sitesi (IPv6 adresi) örnekleri yayımlandı
• Topluluk kullanıcılarından anormallik, ilginç nokta veya sorun tespit ederlerse paylaşmaları istendi

IP SAN ve DNS SAN'ın birlikte kullanıldığı örnekler

• Test sürecinde DNS SAN ve IP SAN'ın aynı anda yer aldığı sertifikaların verilebilmesi ve gösterim karışıklığı örnekleri sergilendi
• .cafe gibi belirli TLD'ler ile IPv6 adresi gösterimleri benzer olabildiğinden karışıklık ihtimali bulunuyor
• Firefox'ta IP adresi SAN gösterimiyle ilgili hata (BZ #1973855) da doğrulandı

Özet

• Let's Encrypt'in IP adresi sertifikası desteği önce izin listesi ve kısa süreli sertifikalarla sınırlı biçimde uygulanacak
• Gerçek hizmette kullanıma geçmeden önce çeşitli senaryoların test edilmesi ve topluluk geri bildirimiyle kararlılık ve uyumluluk gözden geçirilecek
• DNS adları ile IP adreslerinin SAN içinde birlikte kullanılmasıyla ilgili tarayıcı gösterim sorunları da tartışılıyor

[GN⁺]

Hacker News görüşleri

• IP adresleri için sertifikaların da faydalı olacağını düşünüyorum
  Ama Let’s Encrypt S/MIME sertifikalarını desteklese çok daha büyük etki yaratabilir diye düşünüyorum
  E-posta şifreleme konusunda yıllardır biraz absürt bir durum yaşanıyor
  Artık çoğu büyük e-posta istemcisi S/MIME şifrelemeyi doğrudan destekliyor ama web’de olduğu gibi sorunsuz bir kullanıcı deneyimi için bir CA’dan sertifika almak gerekiyor
  Güvenilir, ücretsiz ve 1 yıldan uzun geçerli S/MIME sertifikası veren CA’ların artık hepsi ortadan kalktı
  Sonuç olarak bireysel kullanıcılar e-posta şifrelemeyi neredeyse hiç kullanmıyor
  PGP fazla kullanışsız olduğu için teknik meraklılar dışında pek kullanan yok
  Bence artık e-postamızı da şifrelememiz gerekiyor
  Bu arada, eğer CA gizli anahtarı sizin yerinize oluşturuyorsa o sertifikaya güvenilmez diye düşünüyorum
  Ayrıca S/MIME’da eski postaları çözmek için eski sertifikaları saklamaya devam etmek gerektiğinden, sık değişen sertifikalar pratik değil

  • S/MIME’da eski e-postaları çözmek için eski sertifikanın gerektiği yorumuna karşılık, çözme anahtarının kendisi yeni sertifikada da mevcut anahtar tekrar kullanılarak üretilebilir (ör. certbot’un --reuse-key seçeneği) diye düşünüyorum; yani mutlaka sık değiştirmek gerekmeyebilir
    Tabii bunun iyi bir yöntem olup olmadığı ayrı mesele
    Asıl gerekenin ACME tarzı otomatik sertifika alma otomasyonu olduğunu düşünüyorum
    Şu an yenileme süreci zahmetli olduğu için neredeyse hiç kullanılmıyor

  • PGP için artık WKD (Web Key Directory) bağlantı diye bir yöntem var; bu sayede e-postaya TLS’in güven ağı uygulanabiliyor
    TLS sertifikalarını almak, S/MIME sertifikalarından çok daha kolay
    Kimlik yönetiminin üçüncü tarafça yapılması faydalı olabilir ama çoğu insan, bu tür kimlik yönetiminin pek uymadığı şirketlerde çalışıyor
    Şirket ortamında ise kimlik yönetiminin kurum içinde yapılması daha uygun diye düşünüyorum
    Yakındaki Signalgate 1.0 olayı bağlantı, uçtan uca şifrelemede kimlik yönetimi başarısızlığı açısından gerçekten öğreticiydi
    Bu yüzden S/MIME sertifikaları ya da WKD gerçekten kullanılabilir sistemler olarak hayata geçerse devlet tarafında da faydalı olabilir diye düşünüyorum

  • Kişisel olarak S/MIME tabanlı e-posta şifrelemesinin geleceğine olumlu bakıyorum ama uygulanabilirliği düşük geliyor
    Genel kullanıcılar çoğu zaman özel anahtar yönetimini bile zor buluyor; e-posta parolalarını bile düzgün yönetmekte zorlanıyorlar
    Sonuçta ya her alan adı için merkezi sertifika dağıtımı gerekecek ya da kullanıcılar sertifika alamazken siber suçlular S/MIME imzalı e-postalar göndermeye başlayacak
    Passkey kullanımı yaygınlaşıp nesil değişimi yaşandığında, insanların anahtar çiftlerini doğrudan yönetmesini istemek daha mantıklı olabilir

  • E-posta şifrelemesinin tamamen ortadan kalkması gerektiğini düşünenler de var
    Bkz: Stop using encrypted email

  • S/MIME şifreleme konusunda çok bilgili değilim, bu yüzden merak ettiğim bir nokta var
    Neden eski e-postaları aynı protokolle çözmek gerekiyor?
    Ben sertifikaları daha çok aktarım (transport) için düşünüyordum; kalıcı saklama için sunucu ya da host tarafında ayrı bir depolama şifrelemesi olur sanıyordum. Bu yüzden aktarım için kısa ömürlü sertifikalar, depolama içinse istenen başka bir şifreleme yöntemi kullanmak mantıklı geliyor; bir şeyi mi kaçırıyorum diye merak ediyorum

• Tüm adres tahsis kurumlarının da (ör. ISP’ler, bulut sağlayıcıları) bu akıma katılıp katılmayacağını merak ediyorum
  Bunlar bazen IP’leri çok hızlı döndürüyor; 6 günden kısa sürede bile değişebiliyor
  Bulut sağlayıcılarının IP üzerinde analiz öncesi bir bekleme süresi uygulaması ya da o IP ile ilgili sertifikaları sorgulayıp iptal etmesi mantıklı olurdu; aksi halde kullanıcıların host header doğrulaması yapması, istenmeyen IP tabanlı bağlantıları reddetmesi ya da eski sertifikalar tamamen ortadan kalkana kadar beklemesi gibi bir karmaşıklık doğuyor
  Ayrıca bulut sağlayıcıları bazında IP sertifikalarının ne kadar ve hangi fiyata alınabileceğini de merak ediyorum

  • Aslında bunun, bulut sağlayıcılarının özel/vanity domain sunmasından çok da farklı olmadığını düşünüyorum
    Mesela Azure’da myapp.westus.cloudapp.azure.com gibi bir DNS adı bir VM’e bağlanabiliyor ve CA’lar o alan adı için isteyen herkese sertifika verebiliyor bkz.
    Bu durumda da ayrı bir bekleme süresi olmadan, VM silinince başka biri hemen aynı alan adını alabiliyor

  • HTTPS sertifikaları, alan adı süresi bitmeden bir gün önce bile 90 günlük olarak yenilenebiliyor ve CA’ların sizin kredi kartı limitinizi bilmesi de mümkün değil
    IP sertifikası kullanacak kişiler genelde IP’yi hemen bırakıp giden kullanıcılardan farklı olacaktır
    En faydalı kullanım alanları, çok özel eski yazılımlar ya da Cloudflare gibi paylaşımlı IP kullanmadan ECH (Encrypted Client Hello) veya ESNI (Encrypted SNI) desteği gerektiren durumlar olabilir
    İlk durumda (legacy) IP kolay kolay bırakılmaz; ikinci durumda (ECH/ESNI) ise gerçek alan adına bağlantı kurulmasının zaten zor olacağını düşünüyorum

  • ISP’lerin buna katılması gerekir mi sorusuna benim cevabım tam tersi olur
    ISP’lerin görevi TLS standartlarına uygun biçimde IP tahsis etmek değil; TLS sertifikası sağlayıcılarının, ekosistemde kimliklerin (alan adı, IP vb.) nasıl bağlandığına göre “kimlik doğrulama” rolünü üstlenmesi gerekir diye düşünüyorum
    Bu kez nasıl yaklaşacakları tam açıklanmadı ama içgüdüm, LetsEncrypt’in ASN’ler (otonom sistem numaraları) temelinde uzun süreli IP devrinin yapıldığı bir liste oluşturacağı yönünde; tıpkı Mozilla Public Suffix List gibi ortak yürütülen açık bir veritabanı gibi
    Ve yalnızca bu listedeki IP’lere sertifika verip başka bir ASN’ye taşınırsa sertifika geçersiz kılma süreçlerini yöneteceklerini tahmin ediyorum
    Bunu diğer ACME sağlayıcılarıyla da paylaşmalarını umuyorum

  • Farklı bulutlarda IP sertifikalarını kaça ve kaç tane alabileceğimizi merak ediyorsak, ileride wildcard sertifika desteği gelip gelmeyeceğini de merak etmek gerekir

  • Benim kullanım durumumda yalnızca bir günlüğüne bile IP sertifikası almak, https URL’lerini test edebilmek için çok faydalı olurdu; o yüzden bunu memnuniyetle karşılıyorum

• Teknik olarak nasıl çalıştığını anlıyorum ama asıl hedeflenen kullanım alanının ne olduğunu merak ediyorum

  • Sadece ECH (Encrypted Client Hello) ya da ESNI (Encrypted SNI) desteği bile çok büyük anlam taşır diye düşünüyorum
    ESNI’nin ilk dönemlerinde bunu ancak Cloudflare gibi büyük https proxy’leri uygulayabiliyordu; bu yüzden IP sertifikaları biraz hayal gibi duruyordu, ama artık her sunucu ESNI/ECH’ye katılabilir
    İstemciler tüm sunucularda IP sertifikası olduğunu varsayıp ESNI denemeye başlarsa, bunun internet genelinde gizliliği ciddi biçimde iyileştireceğini düşünüyorum

  • Çeşitli yanıtlarda iyi örnekler verilmiş ama NTS’ten (Network Time Security) de bahsetmek gerek
    IP sertifikası olmadan NTS için de DNS gerekir; bu da DNS çökerse doğrulanmış zaman senkronizasyonunun tamamen imkânsız hale gelmesi demek
    DNSSEC doğru zaman olmadan doğrulanamaz; DNS+NTS bağımlılığında ise toparlanmak mümkün olmaz
    IP içeren sertifikalarla DNS olmadan doğrulanmış zaman dağıtımı yapılabilse bu sorun çözülebilir

  • DNS’te büyük değişiklikler yaşanırken geçerli sertifikayı korumak gerekiyorsa, örneğin dashboard erişimini ayakta tutmak ya da eski otomasyonların DNS hatası yüzünden durmamasını sağlamak için kullanılabilir
    Bir başka kullanım alanı da DNS gerekmeksizin daha basit şekilde test ortamı kurmak ya da Cockpit gibi araçları hızla dışarı açmak olabilir
    Kısacası hayal gücünün izin verdiği pek çok kullanım doğabilir

  • authdns (yetkili DNS sunucuları) için fırsatçı (opportunistic) DoTLS (TLS üzerinden DNS sorguları) kullanımında da ilginç olabilir
    Genel IP’yi SAN (Subject Alternative Name) olarak içeren bir sertifikayla yetkili DNS sunucusu DoTLS portunda hizmet verebilir
    Bugün bunu host adıyla yapmak mümkün ama tek bir genel IP üzerinde pek çok farklı isim olabildiğinden, IP tabanlı SAN bunu daha net bağlar

  • Alan adı yerine projeye doğrudan IP bağlamak isteyen, hobi amaçlı ya da tek seferlik kullanım senaryoları için uygun olduğunu düşünüyorum

• Neden internet bölgesel kayıt kuruluşları (RIR) ya da yerel kayıt kuruluşları (LIR) sertifika vermiyor diye merak ediyorum
  Neden üçüncü bir tarafın RIR/LIR kayıt sahiplerini doğrulaması gerekiyor? Alan adı kayıt şirketlerinin işi zaten fazla diye mi böyle yapılıyor?
  Aynı gerekçenin burada da geçerli olup olmadığını merak ediyorum

• Sanki TLS’in kötüye kullanılabileceği yeni bir alan daha açılmış gibi geliyor
  Daha önce sahip olunmayan alan adları için sertifika verilmesi sorunu vardı; şimdi sahip olunmayan IP’ler için de sertifika alınabilir gibi duruyor
  Black hat’ler Telegram’da kutlama yapıyordur herhalde

  • Aslında IP sertifikaları uzun zamandır vardı; değişen tek şey, artık bunları Let’s Encrypt’in de verecek olması

• Bunun yerel router’ların (ör. 192.168.0.1) yönetim arayüzlerine self-signed hatası olmadan https ile bağlanmayı mümkün kılıp kılmayacağını merak ediyorum

  • Hayır, ama belki mümkün hale gelebilir
    Yerel adresler evrensel olarak tahsis edilmediği ve küresel olarak yönlendirilmediği için doğaları gereği doğrulanmaları mümkün değil
    Ama router üreticisi isterse, CG-NAT arkasında olmayan ve genel IPv4 adresi atanmış cihazlarda, genel adres için sertifika istemek mümkün olabilir
    IPv6 çoğu zaman küresel olarak yönlendirilebilir olduğu için daha da kolay olur

  • Hayır, olmamalı da
    Aslında proxy, gerçek alan adı ve geçerli sertifikayla, buna ek olarak DNS rewrite kullanarak bunu rahatça yapabilirsiniz
    Örneğin nginx manager arayüzü ve DNS olarak adguard kullanabilirsiniz
    Router’ın DNS’ini adguard ile sınırlandırıp kendi alan adınızı proxy’ye rewrite edersiniz
    Alan adını kaydedip gerçek sertifikayı alınca sorun çözülür
    Ben de tüm yerel servislerimi https ile kullanıyorum

  • Özel IP’ler için sertifika verilmez
    Aynı özel IP, başka ağlarda tamamen farklı cihazlara tekrar tekrar atanabilir; yani münhasır sahiplik garanti edilemez

  • Tam tersi
    Genel IP’niz yoksa geçerli sertifika da alamazsınız
    Zaten alan adı sertifikası alıp o alan adını 192.168.0.1 adresine yönlendirme yöntemi mevcut

  • Sertifika alabilmek için o IP’nin (genel IP’nin) gerçekten size ait olması gerekir

• İç ağ IPv4 adresleri (192.168.x.x, 172.16.x.x, 10.x.x.x) için sertifika mümkün olur mu, yoksa tarayıcıların bu adresleri yok sayması mı gerekir? Ya da değilse iç ağ için wildcard sertifika alınabilir mi diye merak ediyorum

  • Genel (public) CA’ların verdiği sertifikalar bağlamında bu soru çok anlamlı değil diye düşünüyorum
    Alan adlarından farklı olarak 10.10.10.10 gibi özel IP’ler aynı anda çok sayıda kişi tarafından “sahiplenilmiş” olabilir
    İç geliştirme için mkcert gibi araçlar var; şirket içi paylaşımlı kaynaklar içinse alan adı tabanlı TLS sertifikaları daha pratik

  • Eğer cihazın özel anahtarının asla sızdırılmayacağını kanıtlayabiliyorsanız, mevcut CA’larla da denemek mümkün olabilir
    Ama iç adres sertifikalarında biri cihazı satın alıp özel anahtarı çıkarırsa, sertifika anahtarının iptali hemen sorun haline gelir
    Bu yüzden güvenilir cihazlarda sertifikayı elle içe aktarıp hata olmadan bağlanmak ya da çok sayıda cihaz varsa kendi CA’nızı kurup sertifika dağıtmak daha gerçekçi
    Açık kaynak ACME sunucularıyla Let’s Encrypt’e benzer otomatik dağıtım iç ağda da yapılabilir

  • DNS’i önce genel sunucuya yönlendirip sertifikayı alırsınız; sonra DNS’i içteki 192.168... adresine döndürüp sertifikayı ve anahtarı kopyalarsınız
    Dikkat edilmesi gereken nokta şu: bazı router’lar iç adreslere yönlenen DNS yanıtlarını kara deliğe düşürebilir, o yüzden önceden test etmek gerekir

  • Tarayıcıların özel ağları yok saymaması gerektiğini düşünüyorum
    Benim için özel ağ yerel router’ımdan ibaret olabilir ama başkası için tüm dünyaya yayılmış bir ağ anlamına gelebilir

• Örnek sertifikada subject alanının olmaması ilginç
  Acaba IP ile istenip SAN’da DNS yazdığı için mi böyle?

  • Let’s Encrypt ekibine göre, ileride subject common name yerine yalnızca subject alternative names kullanılacak
    Bu, 6 günlük kısa ömürlü sertifika profilinde zaten uygulanmış durumda; “klasik” 90 günlük profilde ise henüz değil

• CVE-2010-3170 açığının yeniden gündeme geleceği yönünde şakalı bir yorum

  • X.509 doğrulama mantığını kendiniz yazıyorsanız böyle açıklar kalmış olabilir ama pratikte bunu suistimal etmek için hatalı çalışan bir CA’nın o sertifikayı vermesi gerekir; bu yüzden olasılığı düşük görüyorum

• Ne yazık ki IP adresi sertifikaları DNS challenge yöntemiyle alınamıyor
  Ama neden böyle olduğunu anlayabiliyorum