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

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

• עוגני מהימנות בהתאמה אישית: אפשר להתאים אישית את רשויות האישורים (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) וכלי בנייה מגדירים את הדגל הזה באופן אוטומטי עבור גרסאות build שאינן גרסאות הפצה.

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

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

<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" | "disabled"]/>

תיאור:

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

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

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

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

אם לא מציינים ערך, ברירת המחדל mode היא "enabled" באפליקציות שמטרגטות לרמת API 37 ומעלה, ו-"disabled" בכל מקרה אחר.

<debug-overrides>

תחביר:

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

יכולים לכלול:

0 או 1 <trust-anchors>

תיאור:

ההגדרות לשינוי שיחולו כש-android:debuggable הוא "true", שזה בדרך כלל המצב בגרסאות שאינן גרסאות הפצה שנוצרות על ידי סביבות פיתוח משולבות (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"] />

תיאור:

‫

Set of X.509 certificates for trust-anchors elements.

מאפיינים:

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>

תיאור:

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

מאפיינים:

expiration

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

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

<pin>

תחביר:

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

מאפיינים:

digest

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