Ağ güvenliği yapılandırması

Ağ Güvenliği Yapılandırması özelliği, uygulama kodunu değiştirmeden uygulamanızın ağ güvenliği ayarlarını güvenli ve bildirimsel bir yapılandırma dosyasında özelleştirmenize olanak tanır. Bu ayarlar belirli alanlar ve belirli bir uygulama için yapılandırılabilir. Bu özelliğin temel işlevleri şunlardır:

  • Özel güven çapaları: Bir uygulamanın güvenli bağlantıları için hangi sertifika yetkililerinin (CA) güvenilir olduğunu özelleştirin. Örneğin, belirli kendi kendine imzalanmış sertifikalara güvenme veya uygulamanın güvendiği genel CA'ların kümesini kısıtlama.
  • Yalnızca hata ayıklama geçersiz kılmaları: Uygulamalardaki güvenli bağlantılarda, yüklü tabana ek risk getirmeden güvenli bir şekilde hata ayıklayın.
  • Şifresiz metin trafiğini devre dışı bırakma: Uygulamaları, şifresiz metin (şifrelenmemiş) trafiğin yanlışlıkla kullanılmasından koruyun.
  • Sertifika şeffaflığı: Bir uygulamanın güvenli bağlantılarını, kanıtlanabilir şekilde kaydedilmiş sertifikaları kullanacak şekilde kısıtlayın.
  • Sertifika sabitleme: Bir uygulamanın güvenli bağlantısını belirli sertifikalarla kısıtlayın.

Ağ Güvenliği Yapılandırma dosyası ekleme

Ağ Güvenlik Yapılandırması özelliği, uygulamanızın ayarlarını belirttiğiniz bir XML dosyası kullanır. Uygulamanızın manifestinde bu dosyayı işaret eden bir giriş eklemeniz gerekir. Aşağıdaki manifest kod alıntısı, bu girişi nasıl oluşturacağınızı gösterir: 

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

Güvenilen CA'ları özelleştirme

Uygulamanızın, platform varsayılanı yerine özel bir CA kümesine güvenmesini isteyebilirsiniz. Bunun en yaygın nedenleri şunlardır:

  • Kendi kendine imzalanmış veya şirket içinde verilmiş bir sertifika yetkilisi (CA) gibi özel bir sertifika yetkilisine (CA) sahip bir ana makineye bağlanma.
  • CA kümesini, önceden yüklenmiş her CA yerine yalnızca güvendiğiniz CA'larla sınırlayın.
  • Sisteme dahil olmayan ek CA'lara güvenme

Varsayılan olarak, tüm uygulamalardan gelen güvenli bağlantılar (TLS ve HTTPS gibi protokoller kullanılarak) önceden yüklenmiş sistem CA'larına güvenir. Android 6.0'ı (API düzeyi 23) ve daha düşük sürümleri hedefleyen uygulamalar da varsayılan olarak kullanıcı tarafından eklenen CA deposuna güvenir. Uygulamanızın bağlantılarını base-config (uygulama genelinde özelleştirme için) veya domain-config (alan başına özelleştirme için) kullanarak özelleştirebilirsiniz.

Özel CA yapılandırma

Kendinden imzalı bir SSL sertifikası kullanan veya SSL sertifikası, şirketinizin dahili CA'sı gibi güvenilir ancak herkese açık olmayan bir CA tarafından verilmiş bir ana makineye bağlanmak isteyebilirsiniz. Aşağıdaki kod alıntısında, uygulamanızı res/xml/network_security_config.xml içinde özel bir CA için nasıl yapılandıracağınız gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

PEM veya DER biçimindeki kendinden imzalı ya da genel olmayan CA sertifikasını res/raw/my_ca konumuna ekleyin.

Güvenilen CA'ların kümesini sınırlama

Uygulamanızın sistem tarafından güvenilen tüm CA'lara güvenmesini istemiyorsanız bunun yerine güvenilecek CA'ların azaltılmış bir kümesini belirtebilirsiniz. Bu, uygulamayı diğer CA'lar tarafından verilen sahte sertifikalara karşı korur.

Güvenilen CA'ların kümesini sınırlama yapılandırması, kaynakta birden fazla CA sağlanması dışında belirli bir alan için özel bir CA'ya güvenmeye benzer. Aşağıdaki kod alıntısında, res/xml/network_security_config.xml içinde uygulamanızın güvenilir CA'lar kümesinin nasıl sınırlandırılacağı gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <domain includeSubdomains="true">cdn.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/trusted_roots"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

Güvenilen CA'ları PEM veya DER biçiminde res/raw/trusted_roots dosyasına ekleyin. PEM biçimini kullanıyorsanız dosyanın yalnızca PEM verilerini ve ek metin içermemesi gerektiğini unutmayın. Ayrıca, tek bir <certificates> öğesi yerine birden fazla öğe de sağlayabilirsiniz.

Ek CA'lara güvenme

Sistem tarafından henüz dahil edilmemiş veya Android sistemine dahil edilme şartlarını karşılamayan CA'lar gibi, sistemin güvenmediği ek CA'lara uygulamanızın güvenmesini isteyebilirsiniz. res/xml/network_security_config.xml bölümünde bir yapılandırma için aşağıdaki alıntıdaki gibi bir kod kullanarak birden çok sertifika kaynağı belirtebilirsiniz. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="@raw/extracas"/>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

Hata ayıklama için CA'ları yapılandırma

HTTPS üzerinden bağlanan bir uygulamada hata ayıklarken, üretim sunucunuz için SSL sertifikası olmayan yerel bir geliştirme sunucusuna bağlanmak isteyebilirsiniz. Uygulamanızın kodunda herhangi bir değişiklik yapmadan bunu desteklemek için debug-overrides kullanarak yalnızca hata ayıklama için olan CA'ları belirtebilirsiniz. Bu CA'lar yalnızca android:debuggable true olduğunda güvenilir olur. Normalde, IDE'ler ve derleme araçları bu işareti yayınlanmayan derlemeler için otomatik olarak ayarlar.

Bu, normal koşullu koddan daha güvenlidir. Çünkü uygulama mağazaları, güvenlik önlemi olarak hata ayıklanabilir olarak işaretlenen uygulamaları kabul etmez.

Aşağıdaki alıntıda, res/xml/network_security_config.xml içinde yalnızca hata ayıklama için kullanılan CA'ların nasıl belirtileceği gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

Sertifika şeffaflığı

Not: Sertifika şeffaflığı desteği yalnızca Android 16 (API düzeyi 36) ve sonraki sürümlerde kullanılabilir.

Sertifika Şeffaflığı (CT, RFC 6962), dijital sertifikaların güvenliğini artırmak için tasarlanmış bir internet standardıdır. CA'ların, verilen tüm sertifikaları kaydeden herkese açık bir günlüğe göndermesini zorunlu kılarak sertifika verme sürecinde şeffaflığı ve hesap verebilirliği artırır.

CT, tüm sertifikaların doğrulanabilir bir kaydını tutarak kötü niyetli kişilerin sertifika oluşturmasını veya CA'ların yanlışlıkla sertifika vermesini önemli ölçüde zorlaştırır. Bu sayede kullanıcılar, ortadaki adam saldırılarına ve diğer güvenlik tehditlerine karşı korunur. Daha fazla bilgi için transparency.dev adresindeki açıklamaya bakın. Android'de CT uyumluluğu hakkında daha fazla bilgi için Android'in CT politikası başlıklı makaleyi inceleyin.

Sertifika şeffaflığının varsayılan davranışı API düzeyine bağlıdır:

  • Android 17 (API düzeyi 37) sürümünden itibaren sertifika şeffaflığı varsayılan olarak etkindir. Uygulamalar, özelliği devre dışı bırakabilir. Bu işlem global olarak veya alan başına yapılabilir.
  • Android 16'da (API düzeyi 36) sertifika şeffaflığı varsayılan olarak devre dışıdır. Uygulamalar, özelliği etkinleştirebilir. Bu işlem genel olarak veya alan bazında yapılabilir.
  • Android 15 (API düzeyi 35) ve daha eski sürümlerde sertifika şeffaflığı kullanılamaz.

Sertifika şeffaflığını devre dışı bırakma

Not: Android 16 (API düzeyi 36) için <certificateTransparency enabled="true"/> ayarını yaparak sertifika şeffaflığını etkinleştirin (varsayılan olarak devre dışıdır).

Uygulamanızın, sertifikalarının sertifika şeffaflığı günlüklerine kaydedilmesini gerektirmeden hedeflere bağlanmasını istiyorsanız sertifika şeffaflığını devre dışı bırakabilirsiniz.

Örneğin, uygulamanızın secure.example.com ile bağlantı kurmasına izin vermek isteyebilirsiniz. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <certificateTransparency enabled="false"/>
    </domain-config>
</network-security-config>

Encrypted Client Hello

Not: Encrypted Client Hello desteği yalnızca Android 17 (API düzeyi 37) ve sonraki sürümlerde kullanılabilir. Ayrıca, uygulamanın ağ kitaplığının ECH'yi desteklemesi gerekir. Burada belirtilen yapılandırma yalnızca ağ kitaplığı ECH'yi kullanıyorsa geçerli olur.

Encrypted Client Hello (ECH, RFC 9849), güvenli bağlantıların gizliliğini artırmak için tasarlanmış bir TLS protokolü uzantısıdır. Bu özellik, ilk TLS el sıkışmasının hassas kısımlarını (en önemlisi Sunucu Adı Göstergesi (SNI) alanı) şifreleyerek çalışır.

ECH, SNI'yı şifreleyerek ağ aracıların istemcinin bağlanmaya çalıştığı belirli alan adını gözlemlemesini engeller. Bu sayede, kullanıcıların ziyaret ettikleri alan adlarına göre parmak izlerinin alınması veya izlenmesi önlenir. Böylece, standart TLS el sıkışmalarında bulunan önemli bir gizlilik açığı azaltılır.

Şifrelenmiş İstemci Merhaba'nın varsayılan davranışı API düzeyine bağlıdır:

Encrypted Client Hello'yu devre dışı bırakma

Bu özelliği devre dışı bırakarak kullanmayı durdurabilirsiniz. Örneğin, yalnızca disable-ech.example.com ile bağlantı oluştururken ECH'yi devre dışı bırakmak, ancak diğer tüm alanlar için ECH'yi etkin tutmak istiyorsanız aşağıdaki yapılandırmayı kullanabilirsiniz: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <domainEncryption mode="enabled"/>
    </base-config>
    <domain-config>
        <domain includeSubdomains="true">disable-ech.example.com</domain>
        <domainEncryption mode="disabled"/>
    </domain-config>
</network-security-config>

Şifresiz metin trafiği

Geliştiriciler, uygulamaları için düz metin trafiğini (HTTPS yerine şifrelenmemiş HTTP protokolünü kullanarak) etkinleştirebilir veya devre dışı bırakabilir. Daha fazla bilgi için NetworkSecurityPolicy.isCleartextTrafficPermitted() sayfasına bakın.

Düz metin trafiğinin varsayılan davranışı API düzeyine bağlıdır:

Şifresiz metin trafiğini devre dışı bırakma

Not: Bu bölümdeki yönergeler yalnızca Android 8.1 (API düzeyi 27) veya önceki sürümleri hedefleyen uygulamalar için geçerlidir.

Uygulamanızın yalnızca güvenli bağlantılar kullanarak hedeflere bağlanmasını istiyorsanız bu hedeflere şifresiz metin trafiği desteğini devre dışı bırakabilirsiniz. Bu seçenek, arka uç sunucular gibi harici kaynaklar tarafından sağlanan URL'lerdeki değişiklikler nedeniyle uygulamalarda yanlışlıkla gerileme olmasını önlemeye yardımcı olur.

Örneğin, uygulamanızın hassas trafiği saldırgan ağlardan korumak için secure.example.com bağlantılarının her zaman HTTPS üzerinden yapılmasını sağlamasını isteyebilirsiniz. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">secure.example.com</domain>
    </domain-config>
</network-security-config>

Şifresiz metin trafiğini etkinleştirme

Not: Bu bölümdeki yönergeler yalnızca Android 9 (API düzeyi 28) veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir.

Uygulamanızın şifresiz metin trafiği (HTTP) kullanarak hedeflere bağlanması gerekiyorsa bu hedeflerde şifresiz metin trafiğini desteklemeyi etkinleştirebilirsiniz.

Örneğin, uygulamanızın insecure.example.com ile güvenli olmayan bağlantılar kurmasına izin vermek isteyebilirsiniz. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
    </domain-config>
</network-security-config>

Uygulamanızın herhangi bir alan adında şifresiz metin trafiğini etkinleştirmesi gerekiyorsa base-config içinde cleartextTrafficPermitted="true" değerini ayarlayın. Bu güvenli olmayan yapılandırmadan mümkün olduğunca kaçınılması gerektiğini unutmayın. 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
    </base-config>
</network-security-config>

Sertifikaları sabitleme

Normalde bir uygulama, önceden yüklenmiş tüm CA'lara güvenir. Bu CA'lardan herhangi biri sahte bir sertifika yayınlarsa uygulama, yol üzerindeki saldırganlardan risk altında olur. Bazı uygulamalar, güvendikleri CA'ların kümesini sınırlayarak veya sertifika sabitleme yoluyla kabul ettikleri sertifika kümesini sınırlandırmayı tercih eder.

Sertifika sabitleme, ortak anahtarın karma değeri (X.509 sertifikasının SubjectPublicKeyInfo) ile bir dizi sertifika sağlanarak yapılır. Sertifika zinciri, yalnızca sabitlenmiş ortak anahtarlardan en az birini içeriyorsa geçerli olur.

Sertifika sabitleme kullanırken, yeni anahtarlara geçmek veya CA'ları değiştirmek zorunda kalırsanız (CA sertifikasına ya da bu CA'nın ara sertifikasına sabitleme yaparken) uygulamanızın bağlantısının etkilenmemesi için her zaman bir yedek anahtar eklemeniz gerektiğini unutmayın. Aksi takdirde, bağlantıyı geri yüklemek için uygulamaya güncelleme göndermeniz gerekir.

Ayrıca, sabitleme işleminin yapılmayacağı bir son kullanma tarihi de ayarlayabilirsiniz. Bu sayede, güncellenmemiş uygulamalarda bağlantı sorunları önlenir. Ancak, sabitlenmiş sertifikalarda geçerlilik süresi belirlemek saldırganların sabitlenmiş sertifikalarınızı atlamasına olanak tanıyabilir.

Aşağıdaki alıntıda, res/xml/network_security_config.xml'da sertifikaların nasıl sabitleneceği gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Yapılandırma devralma davranışı

Belirli bir yapılandırmada ayarlanmayan değerler devralınır. Bu davranış, yapılandırma dosyasının okunabilirliğini korurken daha karmaşık yapılandırmalara olanak tanır.

Örneğin, bir domain-config içinde ayarlanmayan değerler, iç içe yerleştirilmişse üst domain-config öğesinden, yerleştirilmemişse base-config öğesinden alınır. base-config içinde ayarlanmamış değerler, platformun varsayılan değerlerini kullanır.

Örneğin, example.com alt alan adlarına yapılan tüm bağlantıların özel bir CA kümesi kullanması gereken bir durumu ele alalım. Ayrıca, secure.example.com'a bağlanırken hariç olmak üzere bu alanlara şifresiz metin trafiğine izin verilir. secure.example.com yapılandırmasını example.com yapılandırmasının içine yerleştirerek trust-anchors'nin yinelenmesi gerekmez.

Aşağıdaki alıntıda bu iç içe yerleştirme işleminin res/xml/network_security_config.xml içinde nasıl görüneceği gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <domain-config cleartextTrafficPermitted="false">
            <domain includeSubdomains="true">secure.example.com</domain>
        </domain-config>
    </domain-config>
</network-security-config>

Localhost yapılandırması

Genellikle localhost bağlantıları için ağ güvenliği özelliklerinin uygulanması gerekmez. Örneğin, localhost bağlantıları için sertifika şeffaflığına nadiren ihtiyaç duyulur.

Android 17 (API düzeyi 37) ve sonraki sürümlerde, localhost için yapılandırma tanımlanmamışsa örtülü bir yapılandırma eklenir. Varsayılan olarak bu yapılandırma şunları yapar:

  • Şifresiz metin trafiğine izin verir.
  • Sertifika şeffaflığını (CT) zorunlu kılmaz.
  • Sertifika sabitlemeyi zorunlu kılmaz.
  • Güven bağlantıları için <base-config>'ya yetki verir.

Aşağıdaki durumlarda yapılandırmanın localhost'u hedeflediği kabul edilir:

  • localhost
  • ip6-localhost veya
  • sayısal bir IP adresi ve InetAddress.isLoopback(), true (örneğin, 127.0.0.1 veya [::1])

Yapılandırma dosyası biçimi

Ağ Güvenliği Yapılandırması özelliği, XML dosya biçimini kullanır. Dosyanın genel yapısı aşağıdaki kod örneğinde gösterilmektedir: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </base-config>

    <domain-config>
        <domain>android.com</domain>
        ...
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
        <pin-set>
            <pin digest="...">...</pin>
            ...
        </pin-set>
    </domain-config>
    ...
    <debug-overrides>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </debug-overrides>
</network-security-config>

Aşağıdaki bölümlerde, dosya biçiminin söz dizimi ve diğer ayrıntıları açıklanmaktadır.

<network-security-config>

Şunları içerebilir:
<base-config>
öğesinden 0 veya 1 <domain-config>
öğesinden herhangi bir sayı <debug-overrides> öğesinden 0 veya 1

<base-config>

söz dizimi:
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
Şunları içerebilir:
<trust-anchors> <certificateTransparency> <domainEncryption>
description:
Hedefi bir domain-config kapsamında olmayan tüm bağlantılar tarafından kullanılan varsayılan yapılandırma.

Ayarlanmayan tüm değerler, platformun varsayılan değerlerini kullanır.

Android 9'u (API düzeyi 28) ve sonraki sürümleri hedefleyen uygulamaların varsayılan yapılandırması aşağıdaki gibidir: 

<base-config cleartextTrafficPermitted="false">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

Android 7.0 (API düzeyi 24) ile Android 8.1 (API düzeyi 27) arasındaki sürümleri hedefleyen uygulamaların varsayılan yapılandırması aşağıdaki gibidir: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

Android 6.0 (API düzeyi 23) ve önceki sürümleri hedefleyen uygulamaların varsayılan yapılandırması aşağıdaki gibidir: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

<domain-config>

söz dizimi:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
Şunları içerebilir:
1 veya daha fazla <domain>
0 veya 1 <certificateTransparency>
0 veya 1 <trust-anchors>
0 veya 1 <pin-set>
0 veya 1 <domainEncryption>
Herhangi bir sayıda iç içe yerleştirilmiş <domain-config>
description:
domain öğeleriyle tanımlandığı şekilde belirli hedeflere yapılan bağlantılar için kullanılan yapılandırma.

Birden fazla domain-config öğesi bir hedefi kapsıyorsa en ayrıntılı (en uzun) eşleşen alan adı kuralına sahip yapılandırmanın kullanıldığını unutmayın.

<alanadı>

söz dizimi:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
özellikleri:
includeSubdomains
"true" ise bu alan adı kuralı, alan adıyla ve tüm alt alan adlarıyla (alt alan adlarının alt alan adları dahil) eşleşir. Aksi takdirde kural yalnızca tam eşlemeler için geçerli olur.

<certificateTransparency>

söz dizimi:
<certificateTransparency enabled=["true" | "false"]/>
description:
true ise uygulama, sertifikaları doğrulamak için Sertifika Şeffaflığı günlüklerini kullanır. Bir uygulama kendi sertifikasını (veya kullanıcı deposunu) kullandığında, sertifikanın herkese açık olmaması ve bu nedenle sertifika şeffaflığı kullanılarak doğrulanamaması olasıdır. Doğrulama, varsayılan olarak bu durumlarda devre dışıdır. Alan yapılandırmasında <certificateTransparency enabled="true"/> kullanarak doğrulamayı zorlamak mümkündür. Her bir <domain-config> için değerlendirme şu sırayla yapılır:
  1. certificateTransparency etkinse doğrulamayı etkinleştirin.
  2. <trust-anchors> "user" veya satır içi (ör. "@raw/cert.pem") doğrulamayı devre dışı bırakın.
  3. Aksi takdirde, devralınan yapılandırmayı kullanın.

<domainEncryption>

söz dizimi:
<domainEncryption mode=["enabled" | "opportunistic" | "disabled"]/>
description:
Belirtilen alanlara yapılan bağlantılar için Encrypted Client Hello (ECH) davranışını kontrol eder.

Not: domainEncryption öğesi, uygulamanın ağ kitaplığının ECH'yi desteklemesine bağlıdır. Belirtilen davranış yalnızca ağ kitaplığı ECH'yi kullanıyorsa geçerli olur. Uygulamaların ECH yapılandırmalarını kendilerinin işlemesi beklenmez. Bunun yerine, TLS el sıkışması oluşturulurken bu yapılandırmaları işlemek için ağ iletişimi kitaplıklarını kullanmaları gerekir.

mode özelliği aşağıdakilerden biri olabilir:

  • enabled: TLS el sıkışması oluşturulurken ECH yapılandırması sağlandığında bağlantıda ECH'yi zorunlu kılın, aksi takdirde ECH GREASE'i etkinleştirin.
  • opportunistic: TLS el sıkışması oluşturulurken ECH yapılandırması sağlandığında bağlantıda ECH'yi kullanın. Bağlantı başarısız olursa veya yapılandırma sağlanmazsa standart şifrelenmemiş TLS ClientHello'ya geri dönülür. Bu modda ECH GREASE etkinleştirilmez.
  • disabled: ECH veya ECH GREASE'i hiçbir bağlantıda kullanmaya çalışmayın.

Belirtilmezse varsayılan mode değeri "opportunistic" olur.

<debug-overrides>

söz dizimi:
<debug-overrides>
    ...
</debug-overrides>
Şunları içerebilir:
0 veya 1 <trust-anchors>
description:
android:debuggable "true" olduğunda uygulanacak geçersiz kılmalar. Bu durum, genellikle IDE'ler ve derleme araçları tarafından oluşturulan, yayınlanmayan derlemeler için geçerlidir. debug-overrides içinde belirtilen güven bağlantıları diğer tüm yapılandırmalara eklenir ve sunucunun sertifika zinciri bu yalnızca hata ayıklama amaçlı güven bağlantılarından birini kullandığında sertifika sabitleme işlemi gerçekleştirilmez. android:debuggable değeri "false" ise bu bölüm tamamen yoksayılır.

<trust-anchors>

söz dizimi:
<trust-anchors>
...
</trust-anchors>
Şunları içerebilir:
<certificates> öğesinden herhangi bir sayıda
description:
Güvenli bağlantılar için güven bağlantıları kümesi.

<certificates>

söz dizimi:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
description:
trust-anchors öğeleri için X.509 sertifikaları kümesi.
özellikleri:
src
CA sertifikalarının kaynağı. Her sertifika aşağıdakilerden biri olabilir:
  • X.509 sertifikaları içeren bir dosyaya işaret eden ham kaynak kimliği. Sertifikalar DER veya PEM biçiminde kodlanmalıdır. PEM sertifikaları söz konusu olduğunda dosya, yorum gibi PEM olmayan ek veriler içermemelidir.
  • Önceden yüklenmiş sistem CA sertifikaları için "system"
  • Kullanıcı tarafından eklenen CA sertifikaları için "user"
overridePins

Bu kaynaktaki CA'ların sertifika sabitlemeyi atlayıp atlamayacağını belirtir. If "true", then pinning is not performed on certificate chains which are signed by one of the CAs from this source. Bu, CA'larda hata ayıklamak veya uygulamanızın güvenli trafiğine yönelik ortadaki adam saldırılarını test etmek için yararlı olabilir.

Bir debug-overrides öğesinde belirtilmediği sürece varsayılan değer "false" olur. Bu durumda varsayılan değer "true" olur.

<pin-set>

söz dizimi:
<pin-set expiration="date">
...
</pin-set>
Şunları içerebilir:
<pin> öğesinden herhangi bir sayıda
description:
Bir dizi ortak anahtar sabitleme. Güvenli bir bağlantının güvenilir olması için güven zincirindeki ortak anahtarlardan birinin sabitlenmiş anahtarlar arasında olması gerekir. Sabitlenmiş öğelerin biçimi için <pin> sayfasına bakın.
özellikleri:
expiration
Pinlerin geçerliliğinin sona ereceği ve sabitleme özelliğinin devre dışı bırakılacağı yyyy-MM-dd biçimindeki tarih. Özellik ayarlanmamışsa PIN'lerin süresi dolmaz.

Geçerlilik süresi, kullanıcının uygulama güncellemelerini devre dışı bırakması gibi durumlarda, PIN kümesi güncellenmeyen uygulamalarda bağlantı sorunlarının önlenmesine yardımcı olur.

<pin>

söz dizimi:
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
özellikleri:
digest
PIN'i oluşturmak için kullanılan özet algoritması. Şu anda yalnızca "SHA-256" desteklenmektedir.