Konfiguracja zabezpieczeń sieci

Funkcja Ustawienia bezpieczeństwa sieci umożliwia dostosowywanie ustawień bezpieczeństwa sieci aplikacji w bezpiecznym, deklaratywnym pliku konfiguracyjnym bez modyfikowania kodu aplikacji. Te ustawienia można skonfigurować dla konkretnych domen i konkretnej aplikacji. Najważniejsze funkcje tej funkcji to:

  • Niestandardowe kotwice zaufania: dostosuj, które urzędy certyfikacji są zaufane w przypadku bezpiecznych połączeń aplikacji. Możesz na przykład zaufać konkretnym certyfikatom podpisanym samodzielnie lub ograniczyć zestaw publicznych urzędów certyfikacji, którym ufa aplikacja.
  • Zastąpienia tylko na potrzeby debugowania: bezpieczne debugowanie zabezpieczonych połączeń w aplikacji bez dodatkowego ryzyka dla zainstalowanej bazy.
  • Rezygnacja z nieszyfrowanego ruchu: chroń aplikacje przed przypadkowym użyciem nieszyfrowanego ruchu.
  • Przejrzystość certyfikatów: ogranicz bezpieczne połączenia aplikacji do certyfikatów, które zostały udokumentowane w logach.
  • Przypinanie certyfikatów: ograniczanie bezpiecznego połączenia aplikacji do określonych certyfikatów.

Dodawanie pliku konfiguracji zabezpieczeń sieci

Funkcja konfiguracji bezpieczeństwa sieci korzysta z pliku XML, w którym określasz ustawienia aplikacji. Musisz dodać wpis w pliku manifestu aplikacji, aby wskazać ten plik. Poniższy fragment kodu z pliku manifestu pokazuje, jak utworzyć ten wpis: 

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

Dostosowywanie zaufanych urzędów certyfikacji

Może się zdarzyć, że aplikacja ma ufać niestandardowemu zestawowi urzędów certyfikacji zamiast domyślnemu zestawowi platformy. Najczęstsze przyczyny to:

  • Łączenie się z hostem z niestandardowym urzędem certyfikacji, np. urzędem certyfikacji z podpisem własnym lub wydanym wewnętrznie w firmie.
  • Ograniczenie zestawu urzędów certyfikacji tylko do tych, którym ufasz, zamiast do wszystkich preinstalowanych urzędów certyfikacji.
  • ufać dodatkowym urzędom certyfikacji, które nie są uwzględnione w systemie;

Domyślnie bezpieczne połączenia (przy użyciu protokołów takich jak TLS i HTTPS) ze wszystkich aplikacji ufają preinstalowanym certyfikatom CA systemu, a aplikacje kierowane na Androida 6.0 (poziom API 23) i starsze wersje domyślnie ufają też dodanemu przez użytkownika magazynowi certyfikatów CA. Połączenia aplikacji możesz dostosować za pomocą base-config (dla dostosowywania w całej aplikacji) lub domain-config (dla dostosowywania w poszczególnych domenach).

Konfigurowanie niestandardowego urzędu certyfikacji

Uwaga: weryfikacja przejrzystości certyfikatów nie jest przeprowadzana w przypadku połączeń, które korzystają z niestandardowych punktów zaufania.

Możesz chcieć połączyć się z hostem, który używa podpisanego samodzielnie certyfikatu SSL, lub z hostem, którego certyfikat SSL został wydany przez niepubliczny urząd certyfikacji, któremu ufasz, np. wewnętrzny urząd certyfikacji Twojej firmy. Poniższy fragment kodu pokazuje, jak skonfigurować aplikację pod kątem niestandardowego urzędu certyfikacji w res/xml/network_security_config.xml: 

<?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>

Dodaj certyfikat CA podpisany samodzielnie lub niepubliczny w formacie PEM lub DER do res/raw/my_ca.

Ograniczanie zestawu zaufanych urzędów certyfikacji

Jeśli nie chcesz, aby Twoja aplikacja ufała wszystkim urzędom certyfikacji, którym ufa system, możesz zamiast tego określić mniejszy zestaw zaufanych urzędów certyfikacji. Dzięki temu aplikacja jest chroniona przed fałszywymi certyfikatami wydanymi przez dowolny z pozostałych urzędów certyfikacji.

Konfiguracja ograniczająca zestaw zaufanych urzędów certyfikacji jest podobna do zaufania niestandardowemu urzędowi certyfikacji w przypadku konkretnej domeny, z tym wyjątkiem, że w zasobie podanych jest wiele urzędów certyfikacji. Poniższy fragment kodu pokazuje, jak ograniczyć zestaw zaufanych urzędów certyfikacji aplikacji w res/xml/network_security_config.xml: 

<?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>

Dodaj zaufane urzędy certyfikacji w formacie PEM lub DER do res/raw/trusted_roots. Pamiętaj, że jeśli używasz formatu PEM, plik musi zawierać tylko dane w tym formacie i żaden dodatkowy tekst. Możesz też podać kilka elementów <certificates> zamiast jednego.

Ufanie dodatkowym urzędom certyfikacji

Możesz chcieć, aby Twoja aplikacja ufała dodatkowym urzędom certyfikacji, które nie są zaufane przez system, np. jeśli system nie zawiera jeszcze danego urzędu certyfikacji lub nie spełnia on wymagań dotyczących uwzględnienia w systemie Android. W konfiguracji możesz określić wiele źródeł certyfikatów w res/xml/network_security_config.xml, używając kodu podobnego do tego fragmentu. 

<?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>

Konfigurowanie urzędów certyfikacji na potrzeby debugowania

Podczas debugowania aplikacji, która łączy się przez HTTPS, możesz chcieć połączyć się z lokalnym serwerem deweloperskim, który nie ma certyfikatu SSL serwera produkcyjnego. Aby to umożliwić bez modyfikowania kodu aplikacji, możesz określić certyfikaty CA tylko do debugowania, które są zaufane tylko wtedy, gdy android:debuggable ma wartość true, używając debug-overrides. Zwykle środowiska IDE i narzędzia do kompilacji automatycznie ustawiają tę flagę w przypadku kompilacji innych niż wersje.

Jest to bezpieczniejsze niż zwykły kod warunkowy, ponieważ ze względów bezpieczeństwa sklepy z aplikacjami nie akceptują aplikacji, które są oznaczone jako z możliwością debugowania.

Fragment poniżej pokazuje, jak określić urzędy certyfikacji tylko do debugowania w res/xml/network_security_config.xml: 

<?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>

Przejrzystość certyfikatu

Uwaga: obsługa przejrzystości certyfikatów jest dostępna tylko w przypadku Androida 16 (poziom API 36).

Certificate Transparency (CT, RFC 6962) to standard internetowy zaprojektowany w celu zwiększenia bezpieczeństwa certyfikatów cyfrowych. Wymaga on od urzędów certyfikacji przesyłania wszystkich wystawionych certyfikatów do publicznego dziennika, który je rejestruje, co zwiększa przejrzystość i odpowiedzialność w procesie wydawania certyfikatów.

Dzięki prowadzeniu weryfikowalnej ewidencji wszystkich certyfikatów CT znacznie utrudnia złośliwym podmiotom fałszowanie certyfikatów, a urzędom certyfikacji – ich przypadkowe wydawanie. Pomaga to chronić użytkowników przed atakami typu „man-in-the-middle” i innymi zagrożeniami związanymi z bezpieczeństwem. Więcej informacji znajdziesz na stronie transparency.dev. Więcej informacji o zgodności z CT na Androidzie znajdziesz w zasadach CT na Androidzie.

Domyślne działanie przejrzystości certyfikatów zależy od poziomu interfejsu API:

Rezygnacja z przejrzystości certyfikatów

Uwaga: w przypadku Androida 16 (poziom interfejsu API 36) włącz przejrzystość certyfikatów, ustawiając wartość <certificateTransparency enabled="true"/> (domyślnie jest wyłączona).

Jeśli chcesz, aby Twoja aplikacja łączyła się z miejscami docelowymi bez konieczności rejestrowania ich certyfikatów w dziennikach przejrzystości certyfikatów, możesz zrezygnować z tej funkcji.

Możesz na przykład zezwolić aplikacji na nawiązywanie połączeń z domeną secure.example.com bez wymagania przejrzystości certyfikatów. 

<?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>

Zaszyfrowany komunikat ClientHello

Uwaga: obsługa funkcji Encrypted Client Hello jest dostępna tylko na urządzeniach z Androidem 17 (poziom API 37) i wymaga, aby biblioteka sieciowa aplikacji obsługiwała ECH. Skonfigurowane tutaj ustawienia będą miały zastosowanie tylko wtedy, gdy biblioteka sieciowa będzie obsługiwać ECH.

Encrypted Client Hello (ECH, RFC 9849) to rozszerzenie protokołu TLS, które zwiększa prywatność bezpiecznych połączeń. Działa ona poprzez szyfrowanie wrażliwych części początkowego uzgadniania połączenia TLS, w szczególności pola wskazującego nazwę serwera (SNI).

Szyfrując SNI, ECH uniemożliwia pośrednikom sieciowym obserwowanie konkretnej nazwy domeny, z którą klient próbuje się połączyć. Pomaga to zapobiegać identyfikowaniu i monitorowaniu użytkowników na podstawie odwiedzanych przez nich domen, co ogranicza wyciek informacji o prywatności, który występuje w standardowym uzgadnianiu połączenia TLS.

Domyślne działanie szyfrowanego powitania klienta zależy od poziomu interfejsu API:

Rezygnacja z funkcji Encrypted Client Hello

Aby zrezygnować z tej funkcji, wyłącz ją. Jeśli na przykład chcesz wyłączyć ECH tylko w przypadku połączeń z domeną disable-ech.example.com, ale zachować włączoną ECH w przypadku wszystkich innych domen, możesz użyć tej konfiguracji: 

<?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>

Ruch w formie tekstu nieszyfrowanego

Deweloperzy mogą włączać lub wyłączać ruch w formie tekstu nieszyfrowanego (zamiast protokołu HTTPS używając nieszyfrowanego protokołu HTTP) w swoich aplikacjach. Więcej informacji znajdziesz w sekcji NetworkSecurityPolicy.isCleartextTrafficPermitted().

Domyślne zachowanie ruchu w postaci tekstu nieszyfrowanego zależy od poziomu interfejsu API:

Rezygnacja z ruchu w formie zwykłego tekstu

Uwaga: wskazówki w tej sekcji dotyczą tylko aplikacji kierowanych na Androida 8.1 (interfejs API na poziomie 27) lub starszego.

Jeśli chcesz, aby Twoja aplikacja łączyła się z miejscami docelowymi tylko za pomocą bezpiecznych połączeń, możesz zrezygnować z obsługi ruchu nieszyfrowanego do tych miejsc docelowych. Ta opcja pomaga zapobiegać przypadkowym regresjom w aplikacjach spowodowanym zmianami adresów URL dostarczanych przez zewnętrzne źródła, takie jak serwery backendu.

Możesz na przykład chcieć, aby aplikacja zapewniała, że połączenia z secure.example.com są zawsze nawiązywane przez HTTPS, aby chronić wrażliwe dane przed wrogimi sieciami. 

<?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>

Włączanie ruchu w formie zwykłego tekstu

Uwaga: wskazówki w tej sekcji dotyczą tylko aplikacji przeznaczonych na Androida 9 (API na poziomie 28) lub nowszego.

Jeśli Twoja aplikacja musi łączyć się z miejscami docelowymi za pomocą ruchu w postaci tekstu nieszyfrowanego (HTTP), możesz włączyć obsługę tekstu nieszyfrowanego w przypadku tych miejsc docelowych.

Możesz na przykład zezwolić aplikacji na nawiązywanie niezabezpieczonych połączeń z insecure.example.com. 

<?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>

Jeśli Twoja aplikacja musi zezwalać na ruch nieszyfrowany w dowolnej domenie, ustaw cleartextTrafficPermitted="true" w base-config. Pamiętaj, że tej niebezpiecznej konfiguracji należy unikać, gdy tylko jest to możliwe.

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

Przypinanie certyfikatów

Zazwyczaj aplikacja ufa wszystkim wstępnie zainstalowanym urzędom certyfikacji. Jeśli któryś z tych urzędów certyfikacji wydałby fałszywy certyfikat, aplikacja byłaby narażona na atak typu „man-in-the-middle”. Niektóre aplikacje ograniczają zestaw akceptowanych certyfikatów, zawężając zestaw zaufanych urzędów certyfikacji lub stosując przypinanie certyfikatów.

Przypinanie certyfikatów odbywa się przez podanie zestawu certyfikatów według skrótu klucza publicznego (SubjectPublicKeyInfo certyfikatu X.509). Łańcuch certyfikatów jest wtedy ważny tylko wtedy, gdy zawiera co najmniej 1 przypięty klucz publiczny.

Pamiętaj, że podczas korzystania z przypinania certyfikatów zawsze należy uwzględniać klucz zapasowy. Dzięki temu, jeśli będziesz zmuszony(-a) do przejścia na nowe klucze lub zmiany urzędów certyfikacji (w przypadku przypinania do certyfikatu CA lub pośredniego urzędu certyfikacji), nie wpłynie to na łączność aplikacji. W przeciwnym razie musisz wdrożyć aktualizację aplikacji, aby przywrócić łączność.

Można też ustawić czas wygaśnięcia przypięć, po którym przypinanie nie będzie już możliwe. Pomaga to zapobiegać problemom z łącznością w aplikacjach, które nie zostały zaktualizowane. Ustawienie czasu wygaśnięcia przypiętych certyfikatów może jednak umożliwić atakującym obejście przypiętych certyfikatów.

Poniższy fragment pokazuje, jak przypiąć certyfikaty w res/xml/network_security_config.xml: 

<?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>

Dziedziczenie konfiguracji

Wartości, które nie zostały ustawione w określonej konfiguracji, są dziedziczone. Takie działanie umożliwia bardziej złożone konfiguracje przy zachowaniu czytelności pliku konfiguracyjnego.

Na przykład wartości nieustawione w domain-config są pobierane z elementu nadrzędnego domain-config, jeśli jest zagnieżdżony, lub z base-config, jeśli nie jest. Wartości nie ustawione w base-config używają domyślnych wartości platformy.

Rozważmy na przykład sytuację, w której wszystkie połączenia z subdomenami domeny example.com muszą korzystać z niestandardowego zestawu urzędów certyfikacji. Dodatkowo ruch nieszyfrowany do tych domen jest dozwolony z wyjątkiem połączeń z secure.example.com. Zagnieżdżając konfigurację secure.example.com w konfiguracji example.com, nie trzeba duplikować trust-anchors.

Poniższy fragment pokazuje, jak wyglądałoby to zagnieżdżenie w res/xml/network_security_config.xml: 

<?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>

Konfiguracja hosta lokalnego

Wymuszanie funkcji zabezpieczeń sieci w przypadku połączeń z localhostem jest zwykle niepotrzebne. Na przykład przejrzystość certyfikatów jest rzadko potrzebna w przypadku połączeń z localhostem.

W przypadku Androida 17 (poziom API 37) i nowszych wersji, jeśli nie zdefiniowano konfiguracji dla hosta lokalnego, uwzględniana jest konfiguracja domyślna. Domyślnie ta konfiguracja wykonuje te czynności:

  • Zezwala na ruch nieszyfrowany.
  • Nie wymusza protokołu Certificate Transparency (CT).
  • Nie wymusza przypinania certyfikatu.
  • Przekazuje kotwice zaufania do <base-config>.

Konfiguracja jest uznawana za kierowaną na host lokalny, jeśli domena:

  • localhost
  • ip6-localhost lub
  • InetAddress.isLoopback() to adres IP w formacie numerycznym, a true to 127.0.0.1 (np. 127.0.0.1 lub [::1]).

Format pliku konfiguracji

Funkcja konfiguracji bezpieczeństwa sieci korzysta z formatu pliku XML. Ogólną strukturę pliku przedstawia ten przykładowy kod: 

<?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>

W sekcjach poniżej znajdziesz opis składni i inne szczegóły dotyczące formatu pliku.

<network-security-config>

Może zawierać:
0 lub 1 wartość <base-config>
Dowolna liczba wartości <domain-config>
0 lub 1 wartość <debug-overrides>

<base-config>

składnia:
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
Może zawierać:
<trust-anchors> <certificateTransparency> <domainEncryption>
description:
Domyślna konfiguracja używana przez wszystkie połączenia, których miejsce docelowe nie jest objęte domain-config.

Wszystkie wartości, które nie są ustawione, używają wartości domyślnych platformy.

Domyślna konfiguracja aplikacji kierowanych na Androida 9 (API na poziomie 28) lub nowszego jest następująca: 

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

Domyślna konfiguracja aplikacji kierowanych na Androida 7.0 (poziom interfejsu API 24) do Androida 8.1 (poziom interfejsu API 27) jest następująca: 

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

Domyślna konfiguracja aplikacji kierowanych na Androida 6.0 (poziom interfejsu API 23) i starszego jest taka: 

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

<domain-config>

składnia:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
Może zawierać:
Co najmniej 1 <domain>
0 lub 1 <certificateTransparency>
0 lub 1 <trust-anchors>
0 lub 1 <pin-set>
0 lub 1 <domainEncryption>
Dowolna liczba zagnieżdżonych <domain-config>
description:
Konfiguracja używana w przypadku połączeń z określonymi miejscami docelowymi zdefiniowanymi przez elementy domain.

Pamiętaj, że jeśli wiele elementów domain-config obejmuje miejsce docelowe, używana jest konfiguracja z najbardziej szczegółową (najdłuższą) pasującą regułą domeny.

<domena>

składnia:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
atrybuty:
includeSubdomains
Jeśli "true", ta reguła domeny pasuje do domeny i wszystkich subdomen, w tym subdomen subdomen. W przeciwnym razie reguła będzie stosowana tylko do dopasowań ścisłych.

<certificateTransparency>

składnia:
<certificateTransparency enabled=["true" | "false"]/>
description:
Jeśli true, aplikacja będzie używać dzienników Certificate Transparency do weryfikowania certyfikatów. Gdy aplikacja używa własnego certyfikatu (lub magazynu użytkownika), prawdopodobnie certyfikat nie jest publiczny, a tym samym nie można go zweryfikować za pomocą przejrzystości certyfikatów. Domyślnie weryfikacja jest w tych przypadkach wyłączona. Wymuszenie weryfikacji jest nadal możliwe za pomocą <certificateTransparency enabled="true"/> w konfiguracji domeny. W przypadku każdego <domain-config> ocena jest przeprowadzana w tej kolejności:
  1. Jeśli certificateTransparency jest włączona, włącz weryfikację.
  2. Jeśli którykolwiek z tych elementów <trust-anchors> jest "user" lub wstawiony w tekście (np. "@raw/cert.pem"), wyłącz weryfikację.
  3. W przeciwnym razie użyj odziedziczonej konfiguracji.

<domainEncryption>

składnia:
<domainEncryption mode=["enabled" | "disabled"]/>
description:
Określa zachowanie zaszyfrowanego powitania klienta (ECH) w przypadku połączeń z określonymi domenami.

Uwaga: element domainEncryption zależy od tego, czy biblioteka sieciowa aplikacji obsługuje ECH. Określone działanie jest stosowane tylko wtedy, gdy biblioteka sieciowa obsługuje ECH. Aplikacje nie powinny samodzielnie obsługiwać konfiguracji ECH, ale zamiast tego powinny polegać na bibliotekach sieciowych podczas nawiązywania połączenia TLS.

Atrybut mode może mieć jedną z tych wartości:

  • enabled: wymusza ECH w połączeniu, gdy konfiguracja ECH jest podana podczas nawiązywania uzgadniania TLS, a w innych przypadkach włącza ECH GREASE.
  • disabled: Nie próbuj używać ECH ani ECH GREASE w przypadku żadnych połączeń.

Jeśli nie określisz tu żadnej wartości, domyślnie mode będzie "enabled" w przypadku aplikacji kierowanych na interfejs API na poziomie 37 lub wyższym, a w pozostałych przypadkach – "disabled".

<debug-overrides>

składnia:
<debug-overrides>
    ...
</debug-overrides>
Może zawierać:
0 lub 1 <trust-anchors>
description:
Zastąpienia, które mają być stosowane, gdy android:debuggable ma wartość "true", co zwykle ma miejsce w przypadku wersji innych niż produkcyjne generowanych przez środowiska IDE i narzędzia do kompilacji. Kotwice zaufania określone w debug-overrides są dodawane do wszystkich innych konfiguracji, a przypinanie certyfikatów nie jest wykonywane, gdy łańcuch certyfikatów serwera używa jednej z tych kotwic zaufania przeznaczonych tylko do debugowania. Jeśli wartość atrybutu android:debuggable to "false", ta sekcja jest całkowicie ignorowana.

<trust-anchors>

składnia:
<trust-anchors>
...
</trust-anchors>
Może zawierać:
Dowolna liczba znaków <certificates>
description:
Zbiór kotwic zaufania do bezpiecznych połączeń.

<certificates>

składnia:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
description:
Zestaw certyfikatów X.509 dla elementów trust-anchors.
atrybuty:
src
Źródło certyfikatów CA. Każdy certyfikat może mieć jedną z tych wartości:
  • identyfikator zasobu niezdefiniowanego wskazujący plik zawierający certyfikaty X.509. Certyfikaty muszą być zakodowane w formacie DER lub PEM. W przypadku certyfikatów PEM plik nie może zawierać dodatkowych danych innych niż PEM, takich jak komentarze.
  • "system" w przypadku fabrycznie zainstalowanych systemowych certyfikatów CA;
  • "user" w przypadku certyfikatów CA dodanych przez użytkowników;
overridePins

Określa, czy urzędy certyfikacji z tego źródła pomijają przypinanie certyfikatów. Jeśli "true", przypinanie nie jest wykonywane w przypadku łańcuchów certyfikatów podpisanych przez jeden z urzędów certyfikacji z tego źródła. Może to być przydatne podczas debugowania urzędów certyfikacji lub testowania ataków typu „man-in-the-middle” na bezpieczny ruch aplikacji.

Wartość domyślna to "false", chyba że określono ją w elemencie debug-overrides. W takim przypadku wartość domyślna to "true".

<pin-set>

składnia:
<pin-set expiration="date">
...
</pin-set>
Może zawierać:
Dowolna liczba znaków <pin>
description:
Zbiór przypiętych kluczy publicznych. Aby bezpieczne połączenie było zaufane, jeden z kluczy publicznych w łańcuchu zaufania musi znajdować się w zestawie przypiętych certyfikatów. Informacje o formacie pinezek znajdziesz na stronie <pin>.
atrybuty:
expiration
Data wygaśnięcia przypięć w formacie yyyy-MM-dd, po której przypinanie zostanie wyłączone. Jeśli atrybut nie jest ustawiony, kody PIN nie wygasają.

Wygasanie pomaga zapobiegać problemom z łącznością w aplikacjach, które nie otrzymują aktualizacji zestawu przypiętych certyfikatów, np. gdy użytkownik wyłączy aktualizacje aplikacji.

<pin>

składnia:
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
atrybuty:
digest
Algorytm skrótu użyty do wygenerowania kodu PIN. Obecnie obsługiwana jest tylko forma "SHA-256".