הגדרה של אבטחת רשת

התכונה 'תצורה של אבטחת הרשת' מאפשרת להתאים אישית את הגדרות אבטחת הרשת של האפליקציה בקובץ הגדרות בטוח ודקלרטיבי, בלי לשנות את קוד האפליקציה. אפשר להגדיר את ההגדרות האלה לדומיינים ספציפיים ולאפליקציה ספציפית. היכולות העיקריות של התכונה הזו הן:

• עוגני אמון בהתאמה אישית: אפשר להתאים אישית את רשויות האישורים (CA) שמהימנות לחיבורים מאובטחים של אפליקציה. לדוגמה, אפשר להגדיר אמון באישורים מסוימים עם חתימה עצמית או להגביל את קבוצת ה-CA הציבוריים שהאפליקציה נותנת בהם אמון.
• ביטולים רק לצורך ניפוי באגים: ניפוי באגים בחיבורים מאובטחים באפליקציה באופן בטוח, בלי להוסיף סיכון לבסיס המשתמשים המותקן.
• ביטול הסכמה לתעבורת טקסט גלוי: הגנה על אפליקציות מפני שימוש לא מכוון בתעבורת טקסט גלוי (לא מוצפנת).
• שקיפות אישורים: הגבלת החיבורים המאובטחים של אפליקציה לשימוש באישור שנרשם ביומן וניתן להוכחה.
• הצמדת אישורים: הגבלת החיבור המאובטח של אפליקציה לאישורים מסוימים.

הוספת קובץ תצורה של אבטחת רשת

התכונה 'הגדרות אבטחה לרשת' משתמשת בקובץ XML שבו מציינים את ההגדרות של האפליקציה. צריך לכלול רשומה במניפסט של האפליקציה כדי להפנות לקובץ הזה. קטע הקוד הבא מתוך קובץ מניפסט מדגים איך ליצור את הרשומה הזו:

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

התאמה אישית של רשויות אישורים מהימנות

יכול להיות שתרצו שהאפליקציה שלכם תסמוך על קבוצה מותאמת אישית של רשויות אישורים במקום על ברירת המחדל של הפלטפורמה. הסיבות הנפוצות ביותר לכך הן:

• התחברות למארח עם רשות אישורים מותאמת אישית, כמו רשות אישורים בחתימה עצמית או רשות אישורים שהונפקה באופן פנימי בחברה.
• הגבלת קבוצת ה-CA רק ל-CA שאתם סומכים עליהם, במקום לכל CA שמותקן מראש.
• הוספת מהימנות ל-CA נוספים שלא נכללים במערכת.

כברירת מחדל, חיבורים מאובטחים (באמצעות פרוטוקולים כמו TLS ו-HTTPS) מכל האפליקציות נסמכים על אישורי CA של המערכת שהותקנו מראש, ואפליקציות שמטרגטות ל-Android 6.0 (רמת API‏ 23) ומטה נסמכות גם על מאגר אישורי ה-CA שנוספו על ידי המשתמש כברירת מחדל. אפשר להתאים אישית את החיבורים של האפליקציה באמצעות base-config (להתאמה אישית של האפליקציה כולה) או domain-config (להתאמה אישית לכל דומיין).

הגדרה של רשות אישורים (CA) בהתאמה אישית

יכול להיות שתרצו להתחבר למארח שמשתמש באישור SSL בחתימה עצמית, או למארח שאישור ה-SSL שלו הונפק על ידי רשות אישורים לא ציבורית שאתם סומכים עליה, כמו רשות אישורים פנימית של החברה שלכם. בקטע הקוד הבא אפשר לראות איך מגדירים באפליקציה CA מותאם אישית ב-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>

מוסיפים את האישור בחתימה עצמית או את אישור ה-CA הלא ציבורי בפורמט PEM או DER אל res/raw/my_ca.

הגבלת קבוצת אישורי ה-CA המהימנים

אם אתם לא רוצים שהאפליקציה שלכם תיתן אמון בכל רשויות האישורים שהמערכת נותנת בהן אמון, אתם יכולים במקום זאת לציין קבוצה מצומצמת של רשויות אישורים שאתם רוצים לתת בהן אמון. כך האפליקציה מוגנת מפני אישורים שמקורם בתרמית שהונפקו על ידי כל אחת מהרשויות שמנפיקות את האישורים האחרות.

ההגדרה להגבלת קבוצת רשויות ה-CA המהימנות דומה להגדרת רשות CA מותאמת אישית כמהימנה עבור דומיין ספציפי, אלא שבמקרה הזה מסופקות כמה רשויות CA במשאב. קטע הקוד הבא מראה איך להגביל את קבוצת רשויות האישורים המהימנות של האפליקציה ב-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>

מוסיפים את רשויות האישורים המהימנות בפורמט PEM או DER אל res/raw/trusted_roots. שימו לב: אם אתם משתמשים בפורמט PEM, הקובץ צריך להכיל רק נתוני PEM, ולא טקסט נוסף. אפשר גם לספק כמה רכיבי <certificates> במקום אחד.

הוספת רשויות אישורים מהימנות

יכול להיות שתרצו שהאפליקציה שלכם תסמוך על רשויות אישורים נוספות שהמערכת לא סומכת עליהן, למשל אם המערכת עדיין לא כוללת את רשות האישורים או אם רשות האישורים לא עומדת בדרישות להכללה במערכת Android. אפשר לציין כמה מקורות אישורים להגדרה ב-res/xml/network_security_config.xml באמצעות קוד כמו בדוגמה הבאה.

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

הגדרת רשויות אישורים לניפוי באגים

כשמבצעים ניפוי באגים באפליקציה שמתחברת באמצעות HTTPS, יכול להיות שתרצו להתחבר לשרת פיתוח מקומי שאין לו אישור SSL לשרת הייצור שלכם. כדי לתמוך בזה בלי לבצע שינויים בקוד של האפליקציה, אפשר לציין רשויות אישורים (CA) לניפוי באגים בלבד, שהן מהימנות רק כש-android:debuggable הוא true, באמצעות debug-overrides. בדרך כלל, סביבות פיתוח משולבות (IDE) וכלי בנייה מגדירים את הדגל הזה באופן אוטומטי לגרסאות שאינן גרסאות הפצה.

השיטה הזו בטוחה יותר מקוד רגיל עם תנאים, כי מטעמי אבטחה, חנויות אפליקציות לא מקבלות אפליקציות שמסומנות כאפליקציות שאפשר לבצע בהן ניפוי באגים.

הקטע הבא מראה איך מציינים רשויות אישורים לניפוי באגים בלבד ב-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>

שקיפות אישורים

הערה: התמיכה בשקיפות של אישורים זמינה רק מ-Android 16 (רמת API‏ 36).

שקיפות אישורים (CT, ‏ RFC 6962) היא תקן אינטרנט שמטרתו לשפר את האבטחה של אישורים דיגיטליים. היא מחייבת את רשויות האישורים לשלוח את כל האישורים שהן מנפיקות ליומן ציבורי שמתעד אותם, וכך מגדילה את השקיפות והאחריות בתהליך הנפקת האישורים.

על ידי שמירה של תיעוד שניתן לאימות של כל האישורים, CT מקשה מאוד על גורמים זדוניים לזייף אישורים או על רשויות אישורים להנפיק אותם בטעות. כך אפשר להגן על המשתמשים מפני מתקפות מסוג "אדם בתווך" ומפני איומי אבטחה אחרים. מידע נוסף זמין בהסבר בנושא transparency.dev. מידע נוסף על תאימות ל-CT ב-Android זמין במדיניות ה-CT של Android.

התנהגות ברירת המחדל של שקיפות האישורים תלויה ברמת ה-API:

• החל מ-Android 17 (רמת API‏ 37), שקיפות האישורים מופעלת כברירת מחדל. אפליקציות יכולות להפסיק להשתמש בתכונה באופן גלובלי או לכל דומיין בנפרד.
• ב-Android 16 (רמת API‏ 36), שקיפות האישורים מושבתת כברירת מחדל. אפליקציות יכולות להצטרף לתכונה באופן גלובלי או לכל דומיין בנפרד.
• ב-Android 15 (רמת API 35) ובגרסאות קודמות, שקיפות האישורים לא זמינה.

ביטול ההסכמה לשקיפות האישורים

הערה: ב-Android 16 (רמת API‏ 36), כדי להביע הסכמה לשקיפות האישורים, צריך להגדיר את הערך <certificateTransparency enabled="true"/> (ההגדרה מושבתת כברירת מחדל).

אם אתם רוצים שהאפליקציה שלכם תתחבר ליעדים בלי שהאישורים שלהם יתועדו ביומני שקיפות האישורים, אתם יכולים לבטל את ההסכמה לשקיפות האישורים.

לדוגמה, יכול להיות שתרצו לאפשר לאפליקציה ליצור חיבורים אל secure.example.com בלי לדרוש שקיפות של אישורים.

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

Client Hello מוצפן

הערה: התמיכה ב-Client Hello מוצפן זמינה רק מגרסה Android 17 (רמת API‏ 37) ונדרשת ספריית הרשת של האפליקציה כדי לתמוך ב-ECH. ההגדרה שצוינה כאן תיכנס לתוקף רק אם ספריית הרשת תאמץ את ECH.

פרוטוקול הצפנת Client Hello‏ (ECH, ‏ RFC 9849) הוא תוסף לפרוטוקול TLS שמיועד לשפר את הפרטיות של חיבורים מאובטחים. ההצפנה מתבצעת על החלקים הרגישים של לחיצת היד הראשונית ב-TLS, בעיקר על השדה Server Name Indication (SNI).

הצפנה של SNI באמצעות ECH מונעת מתווכים ברשת לצפות בשם הדומיין הספציפי שהלקוח מנסה להתחבר אליו. השיטה הזו עוזרת למנוע את זיהוי המשתמשים או המעקב אחריהם על סמך הדומיינים שהם מבקרים בהם, ומצמצמת דליפת מידע משמעותית שקיימת בלחיצות יד רגילות של TLS.

ההתנהגות שמוגדרת כברירת מחדל של Encrypted Client Hello תלויה ברמת ה-API:

• החל מ-Android 17 (רמת API‏ 37), ‏ ECH מופעל כברירת מחדל במצב 'אופורטוניסטי'. אפליקציות יכולות להשבית את התכונה או לשנות את ההתנהגות שלה באופן גלובלי או לכל דומיין בנפרד.
• ב-Android 16 (רמת API 36) ובגרסאות קודמות, ECH לא זמין.

ביטול ההסכמה לשימוש ב-ClientHello מוצפן

כדי להפסיק להשתמש בתכונה הזו, אפשר להשבית אותה. לדוגמה, אם רוצים להשבית את ECH כשמתחברים רק ל-disable-ech.example.com, אבל להשאיר את ECH מופעל לכל שאר הדומיינים, אפשר להשתמש בהגדרה הבאה:

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

תעבורת נתונים בטקסט לא מוצפן

מפתחים יכולים להביע הסכמה או להשבית תנועה בטקסט לא מוצפן (באמצעות פרוטוקול HTTP לא מוצפן במקום HTTPS) באפליקציות שלהם. פרטים נוספים מופיעים במאמר NetworkSecurityPolicy.isCleartextTrafficPermitted().

התנהגות ברירת המחדל של תנועה בטקסט גלוי תלויה ברמת ה-API:

• עד Android 8.1 (רמת API‏ 27), התמיכה בטקסט גלוי מופעלת כברירת מחדל. אפליקציות יכולות לבטל הסכמה לתעבורת טקסט לא מוצפן כדי להגביר את האבטחה.
• החל מ-Android 9 (רמת API‏ 28), התמיכה בטקסט גלוי מושבתת כברירת מחדל. אפליקציות שנדרשת בהן תנועה לא מוצפנת יכולות להצטרף לתנועה לא מוצפנת.

ביטול ההסכמה לשימוש בתנועה בטקסט גלוי

הערה: ההנחיות שבקטע הזה רלוונטיות רק לאפליקציות שמטרגטות Android 8.1 (רמת API‏ 27) או גרסאות נמוכות יותר.

אם אתם רוצים שהאפליקציה שלכם תתחבר ליעדים רק באמצעות חיבורים מאובטחים, אתם יכולים לבטל את ההסכמה לתמיכה בתעבורת נתונים לא מוצפנת ליעדים האלה. האפשרות הזו עוזרת למנוע רגרסיות מקריות באפליקציות בגלל שינויים בכתובות URL שמסופקות על ידי מקורות חיצוניים, כמו שרתי קצה עורפי.

לדוגמה, יכול להיות שתרצו שהאפליקציה שלכם תוודא שהחיבורים אל secure.example.com תמיד מתבצעים באמצעות HTTPS כדי להגן על תעבורת נתונים רגישה מפני רשתות עוינות.

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

הצטרפות לאפשרות של תעבורת נתונים בטקסט גלוי

הערה: ההנחיות שבקטע הזה רלוונטיות רק לאפליקציות שמטרגטות את Android 9 (רמת API 28) ומעלה.

אם האפליקציה שלכם צריכה להתחבר ליעדים באמצעות תעבורת נתונים בטקסט לא מוצפן (HTTP), אתם יכולים להביע הסכמה לתמיכה בטקסט לא מוצפן ליעדים האלה.

לדוגמה, יכול להיות שתרצו לאפשר לאפליקציה ליצור חיבורים לא מאובטחים אל 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>

אם האפליקציה צריכה להצטרף לתעבורת נתונים לא מוצפנת לכל דומיין, צריך להגדיר את cleartextTrafficPermitted="true" ב-base-config. הערה: מומלץ להימנע מהגדרה לא מאובטחת כזו ככל האפשר.

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

הצמדת אישורים

בדרך כלל, אפליקציה נותנת אמון לכל רשויות האישורים שמותקנות מראש. אם אחד ממרכזי האישורים האלה ינפיק אישור שמקורו בתרמית, האפליקציה תהיה בסיכון לתקיפה בנתיב. חלק מהאפליקציות מגבילות את קבוצת האישורים שהן מקבלות על ידי הגבלת קבוצת רשויות האישורים שהן בוטחות בהן או על ידי הצמדת אישורים.

כדי להצמיד אישורים, צריך לספק קבוצה של אישורים לפי הגיבוב של המפתח הציבורי (SubjectPublicKeyInfo של אישור X.509). שרשרת אישורים תקפה רק אם היא מכילה לפחות אחד מהמפתחות הציבוריים המוצמדים.

הערה: כשמשתמשים בקיבוע אישורים, תמיד צריך לכלול מפתח גיבוי, כדי שאם תהיו חייבים לעבור למפתחות חדשים או לשנות רשויות אישורים (כשמבצעים קיבוע לאישור CA או לאישור ביניים של רשות האישורים הזו), הקישוריות של האפליקציה לא תיפגע. אחרת, תצטרכו לדחוף עדכון לאפליקציה כדי לשחזר את הקישוריות.

בנוסף, אפשר להגדיר זמן תפוגה לסיכות, שאחריו לא מתבצעת הצמדה. כך אפשר למנוע בעיות בקישוריות באפליקציות שלא עודכנו. עם זאת, הגדרת זמן תפוגה לסיכות עשויה לאפשר לתוקפים לעקוף את האישורים המוצמדים.

בדוגמה הבאה אפשר לראות איך מצמידים אישורים ב-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>

התנהגות של ירושת הגדרות

ערכים שלא מוגדרים בהגדרה ספציפית עוברים בירושה. ההתנהגות הזו מאפשרת הגדרות מורכבות יותר, תוך שמירה על קובץ ההגדרות קריא.

לדוגמה, ערכים שלא מוגדרים ב-domain-config נלקחים מההורה domain-config, אם הוא מוטמע, או מ-base-config, אם לא. הערכים לא מוגדרים ב-base-config, המערכת משתמשת בערכי ברירת המחדל של הפלטפורמה.

לדוגמה, נניח שכל החיבורים לתת-דומיינים של example.com חייבים להשתמש בקבוצה מותאמת אישית של רשויות אישורים. בנוסף, תעבורת נתונים שאינה מוצפנת לדומיינים האלה מותרת אלא אם מתחברים אל secure.example.com. אם משבצים את ההגדרה של secure.example.com בתוך ההגדרה של example.com, אין צורך לשכפל את trust-anchors.

בקטע הפיד הבא אפשר לראות איך הקינון הזה ייראה ב-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>

הגדרת localhost

בדרך כלל אין צורך לאכוף את תכונות האבטחה של הרשת עבור חיבורים ל-localhost. לדוגמה, שקיפות אישורים נדרשת לעיתים רחוקות לחיבורים למארח המקומי.

מגרסה Android 17 (רמת API‏ 37) ואילך, אם לא הוגדרה תצורה עבור localhost, נכללת תצורה משתמעת. כברירת מחדל, ההגדרה הזו מבצעת את הפעולות הבאות:

• מאפשר תנועה שאינה מוצפנת.
• לא אוכפת שקיפות אישורים (CT).
• לא אוכף הצמדת אישורים.
• ההרשאות מוקצות ל-<base-config> עבור נקודות מהימנות.

הגדרה נחשבת כמטרגטת את localhost אם הדומיין הוא:

• localhost
• ip6-localhost או
• כתובת IP מספרית ו-InetAddress.isLoopback() היא true (לדוגמה, 127.0.0.1 או [::1])

פורמט של קובץ תצורה

התכונה 'הגדרת אבטחת רשת' משתמשת בפורמט קובץ XML. המבנה הכללי של הקובץ מוצג בדוגמת הקוד הבאה:

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

בקטעים הבאים מוסבר על התחביר ועל פרטים נוספים של פורמט הקובץ.

<network-security-config>

יכול להכיל:

‫0 או 1 מתוך <base-config>
כל מספר של <domain-config>
‫0 או 1 מתוך <debug-overrides>

<base-config>

תחביר:

<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>

יכול להכיל:

<trust-anchors> <certificateTransparency> <domainEncryption>

תיאור:

ההגדרה שמוגדרת כברירת מחדל לכל החיבורים שהיעד שלהם לא נכלל ב-domain-config.

אם לא תגדירו ערכים, המערכת תשתמש בערכי ברירת המחדל של הפלטפורמה.

הגדרת ברירת המחדל לאפליקציות שמטרגטות ל-Android 9 (רמת API‏ 28) ומעלה היא כדלקמן:

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

הגדרת ברירת המחדל לאפליקציות שמטרגטות Android 7.0 (רמת API‏ 24) עד Android 8.1 (רמת API‏ 27) היא כדלקמן:

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

הגדרת ברירת המחדל לאפליקציות שמטרגטות ל-Android 6.0 (רמת API‏ 23) ולגרסאות קודמות היא:

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

<domain-config>

תחביר:

<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>

יכול להכיל:

‫1 או יותר <domain>
0 או 1 <certificateTransparency>
0 או 1 <trust-anchors>
0 או 1 <pin-set>
0 או 1 <domainEncryption>
כל מספר של תגיות מקוננות <domain-config>

תיאור:

ההגדרה שמשמשת לחיבורים ליעדים ספציפיים, כפי שמוגדרים ברכיבי domain.

שימו לב: אם כמה רכיבי domain-config חלים על יעד מסוים, המערכת משתמשת בהגדרה עם כלל הדומיין הספציפי ביותר (הארוך ביותר) שתואם ליעד.

<domain>

תחביר:

<domain includeSubdomains=["true" | "false"]>example.com</domain>

מאפיינים:

includeSubdomains

אם "true", כלומר אם הדומיין הוא example.com, כלל הדומיין הזה תואם לדומיין ולכל תתי-הדומיינים, כולל תתי-הדומיינים של תתי-הדומיינים. אחרת, הכלל חל רק על התאמות מדויקות.

<certificateTransparency>

תחביר:

<certificateTransparency enabled=["true" | "false"]/>

תיאור:

אם true, האפליקציה תשתמש ביומני שקיפות האישורים כדי לאמת את האישורים. כשמשתמשים באפליקציה באישור משלה (או בחנות המשתמש), סביר להניח שהאישור לא ציבורי ולכן לא ניתן לאמת אותו באמצעות שקיפות האישורים. כברירת מחדל, האימות מושבת במקרים האלה. עדיין אפשר לכפות את האימות באמצעות <certificateTransparency enabled="true"/> בהגדרות הדומיין. לכל <domain-config>, ההערכה מתבצעת לפי הסדר הבא:

1. אם certificateTransparency מופעל, מפעילים את האימות.
2. אם יש <trust-anchors> שהוא "user" או מוטבע (כלומר, "@raw/cert.pem"), משביתים את האימות.
3. אחרת, מסתמכים על ההגדרה שעברה בירושה.

<domainEncryption>

תחביר:

<domainEncryption mode=["enabled" | "opportunistic" | "disabled"]/>

תיאור:

ההגדרה קובעת את ההתנהגות של הצפנת Client Hello (ECH) בחיבורים לדומיינים שצוינו.

הערה: האלמנט domainEncryption תלוי בספריית הרשת של האפליקציה שתומכת ב-ECH. ההתנהגות שצוינה מתרחשת רק אם ספריית הרשתות תומכת ב-ECH. אפליקציות לא אמורות לטפל בהגדרות ECH בעצמן, אלא להסתמך על ספריות הרשת שלהן כדי לעשות זאת בזמן יצירת לחיצת היד של TLS.

הערך של מאפיין mode יכול להיות אחד מהערכים הבאים:

• ‫enabled: אוכף ECH בחיבור כשמסופקת הגדרת ECH בזמן יצירת לחיצת היד של TLS, ומפעיל ECH GREASE אחרת.
• ‫opportunistic: שימוש ב-ECH בחיבור כשמסופקת הגדרת ECH בזמן יצירת לחיצת היד של TLS. אם החיבור נכשל או שההגדרה לא סופקה, המערכת תחזור ל-ClientHello רגיל ב-TLS לא מוצפן. במצב הזה לא מופעלת תכונת ה-GREASE של ECH.
• ‫disabled: אל תנסו להשתמש ב-ECH או ב-ECH GREASE בחיבורים כלשהם.

אם לא מציינים ערך, ברירת המחדל mode היא "opportunistic".

<debug-overrides>

תחביר:

<debug-overrides>
    ...
</debug-overrides>

יכול להכיל:

0 או 1 <trust-anchors>

תיאור:

ההגדרות לשינוי שיוחלו כשהערך של android:debuggable הוא "true", שזה בדרך כלל המצב בגרסאות build שאינן גרסאות הפצה שנוצרות על ידי סביבות פיתוח משולבות (IDE) וכלים לבניית אפליקציות. ישויות עוגן אמינות שמצוינות ב-debug-overrides מתווספות לכל שאר ההגדרות, וקיבוע אישורים לא מתבצע כששרשרת האישורים של השרת משתמשת באחת מישויות העוגן האמינות האלה לניפוי באגים בלבד. אם הערך של android:debuggable הוא "false", המערכת מתעלמת לחלוטין מהקטע הזה.

<trust-anchors>

תחביר:

<trust-anchors>
...
</trust-anchors>

יכול להכיל:

Any number of <certificates>

תיאור:

קבוצה של נקודות מהימנות לחיבורים מאובטחים.

<certificates>

תחביר:

<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />

תיאור:

קבוצה של אישורי X.509 לרכיבי trust-anchors.

מאפיינים:

src

המקור של אישורי CA. כל אישור יכול להיות אחד מהסוגים הבאים:

• מזהה משאב גולמי שמפנה לקובץ שמכיל אישורי X.509. האישורים צריכים להיות מקודדים בפורמט DER או PEM. במקרה של אישורי PEM, הקובץ לא יכול להכיל נתונים נוספים שאינם PEM, כמו הערות.
• ‫"system" לאישורי CA של המערכת שמותקנים מראש
• ‫"user" לאישורי CA שנוספו על ידי משתמשים

overridePins

המדיניות הזו קובעת אם רשויות האישורים מהמקור הזה יעקפו את הצמדת האישורים. אם "true", אז הצמדה לא מתבצעת בשרשראות אישורים שנחתמו על ידי אחת מרשויות האישורים ממקור זה. האפשרות הזו יכולה להיות שימושית לניפוי באגים של רשויות אישורים או לבדיקת התקפות אדם בתווך על תנועת הגולשים המאובטחת של האפליקציה.

ערך ברירת המחדל הוא "false", אלא אם מציינים ערך אחר ברכיב debug-overrides, ובמקרה כזה ערך ברירת המחדל הוא "true".

<pin-set>

תחביר:

<pin-set expiration="date">
...
</pin-set>

יכול להכיל:

Any number of <pin>

תיאור:

קבוצה של הצמדות של מפתחות ציבוריים. כדי שחיבור מאובטח ייחשב למהימן, אחד מהמפתחות הציבוריים בשרשרת האמון צריך להיות בקבוצת הפינים. בכתובת <pin> מפורט הפורמט של הפינים.

מאפיינים:

expiration

התאריך, בפורמט yyyy-MM-dd, שבו תוקף הסיכות יפוג, וכך יושבת ההצמדה. אם המאפיין לא מוגדר, התוקף של קודי האימות לא יפוג.

תפוגה עוזרת למנוע בעיות בקישוריות באפליקציות שלא מקבלות עדכונים לסט הפינים שלהן, למשל כשהמשתמש משבית את העדכונים של האפליקציה.

<pin>

תחביר:

<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>

מאפיינים:

digest

אלגוריתם הגיבוב ששימש ליצירת ה-pin. בשלב הזה יש תמיכה רק ב-"SHA-256".