پیکربندی امنیت شبکه

ویژگی پیکربندی امنیت شبکه به شما امکان می‌دهد تنظیمات امنیت شبکه برنامه خود را در یک فایل پیکربندی امن و اعلانی، بدون تغییر کد برنامه، سفارشی کنید. این تنظیمات را می‌توان برای دامنه‌های خاص و برای یک برنامه خاص پیکربندی کرد. قابلیت‌های کلیدی این ویژگی عبارتند از:

  • لنگرهای اعتماد سفارشی: می‌توانید مشخص کنید که کدام مراجع صدور گواهی (CA) برای اتصالات امن یک برنامه مورد اعتماد هستند. به عنوان مثال، اعتماد به گواهی‌های خودامضای خاص یا محدود کردن مجموعه CAهای عمومی که برنامه به آنها اعتماد دارد.
  • لغو فقط اشکال‌زدایی: اتصالات امن را در یک برنامه بدون خطر اضافی برای پایگاه داده نصب شده، با خیال راحت اشکال‌زدایی کنید.
  • انصراف از ترافیک Cleartext: از برنامه‌ها در برابر استفاده تصادفی از ترافیک Cleartext (رمزگذاری نشده) محافظت کنید.
  • انتخاب شفافیت گواهی: اتصالات امن یک برنامه را محدود کنید تا از گواهی‌های ثبت‌شده‌ی قابل اثبات استفاده کند.
  • پین کردن گواهی: اتصال امن یک برنامه را به گواهی‌های خاص محدود کنید.

یک فایل پیکربندی امنیت شبکه اضافه کنید

ویژگی پیکربندی امنیت شبکه از یک فایل XML استفاده می‌کند که در آن تنظیمات برنامه خود را مشخص می‌کنید. برای اشاره به این فایل، باید یک ورودی در مانیفست برنامه خود وارد کنید. گزیده‌ای از کد زیر از یک مانیفست، نحوه ایجاد این ورودی را نشان می‌دهد:

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

سفارشی‌سازی CAهای مورد اعتماد

ممکن است بخواهید برنامه شما به جای پیش‌فرض پلتفرم، به مجموعه‌ای سفارشی از CAها اعتماد کند. رایج‌ترین دلایل این امر عبارتند از:

  • اتصال به یک میزبان با یک CA سفارشی، مانند CA که خود امضا شده است یا به صورت داخلی در یک شرکت صادر شده است.
  • محدود کردن مجموعه CAها فقط به CAهایی که به آنها اعتماد دارید به جای هر CA از پیش نصب شده.
  • اعتماد به CA های اضافی که در سیستم گنجانده نشده اند.

به طور پیش‌فرض، اتصالات امن (با استفاده از پروتکل‌هایی مانند TLS و HTTPS) از همه برنامه‌ها به CAهای از پیش نصب شده سیستم اعتماد می‌کنند و برنامه‌هایی که اندروید ۶.۰ (سطح API ۲۳) و پایین‌تر را هدف قرار می‌دهند نیز به طور پیش‌فرض به فروشگاه CA اضافه شده توسط کاربر اعتماد دارند. می‌توانید اتصالات برنامه خود را با استفاده از base-config (برای سفارشی‌سازی در کل برنامه) یا domain-config (برای سفارشی‌سازی به ازای هر دامنه) سفارشی کنید.

پیکربندی یک CA سفارشی

ممکن است بخواهید به میزبانی متصل شوید که از گواهی SSL خودامضا شده استفاده می‌کند یا به میزبانی که گواهی SSL آن توسط یک CA غیرعمومی مورد اعتماد شما، مانند CA داخلی شرکت شما، صادر شده است. گزیده کد زیر نحوه پیکربندی برنامه شما برای یک 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 های دیگر محافظت می‌کند.

پیکربندی برای محدود کردن مجموعه 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>

CA های مورد اعتماد را، با فرمت PEM یا DER، به res/raw/trusted_roots اضافه کنید. توجه داشته باشید که اگر از فرمت PEM استفاده می‌کنید، فایل باید فقط شامل داده‌های PEM باشد و هیچ متن اضافی نداشته باشد. همچنین می‌توانید به جای یک عنصر، چندین عنصر <certificates> ارائه دهید.

به CA های اضافی اعتماد کنید

ممکن است بخواهید برنامه شما به CA های اضافی که مورد اعتماد سیستم نیستند، اعتماد کند، مثلاً اگر سیستم هنوز CA را شامل نمی‌شود یا CA الزامات لازم برای گنجاندن در سیستم اندروید را ندارد. می‌توانید با استفاده از کدی مانند قطعه کد زیر، چندین منبع گواهی را برای یک پیکربندی در 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>

پیکربندی CAها برای اشکال‌زدایی

هنگام اشکال‌زدایی برنامه‌ای که از طریق HTTPS متصل می‌شود، ممکن است بخواهید به یک سرور توسعه محلی متصل شوید که گواهی SSL برای سرور تولید شما را ندارد. برای پشتیبانی از این امر بدون هیچ گونه تغییر در کد برنامه خود، می‌توانید CA های فقط اشکال‌زدایی را مشخص کنید که فقط در صورت true بودن android:debuggable با استفاده از debug-overrides قابل اعتماد هستند. معمولاً، IDEها و ابزارهای ساخت، این پرچم را به طور خودکار برای نسخه‌های غیر منتشر شده تنظیم می‌کنند.

این روش از کد شرطی معمول امن‌تر است، زیرا به عنوان یک اقدام امنیتی، فروشگاه‌های اپلیکیشن، اپلیکیشن‌هایی را که با برچسب اشکال‌زدایی (debuggable) مشخص شده‌اند، نمی‌پذیرند.

متن زیر نحوه تعیین CA های فقط اشکال زدایی (debug-only CA) را در 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>

شفافیت گواهی را انتخاب کنید

توجه: پشتیبانی از شفافیت گواهی فقط از اندروید ۱۶ (سطح API ۳۶) در دسترس است.

شفافیت گواهی (CT، RFC 6962 ) یک استاندارد اینترنتی است که برای افزایش امنیت گواهی‌های دیجیتال طراحی شده است. این استاندارد، مراکز صدور گواهی (CA) را ملزم می‌کند که تمام گواهی‌های صادر شده را به یک گزارش عمومی که آنها را ثبت می‌کند، ارسال کنند و شفافیت و پاسخگویی را در فرآیند صدور گواهی افزایش دهند.

با نگهداری یک سابقه قابل تأیید از تمام گواهینامه‌ها، CT جعل گواهینامه‌ها را برای عوامل مخرب یا صدور اشتباه آنها توسط CAها به طور قابل توجهی دشوارتر می‌کند. این امر به محافظت از کاربران در برابر حملات مرد میانی و سایر تهدیدات امنیتی کمک می‌کند. برای اطلاعات بیشتر، به توضیحات در transparency.dev مراجعه کنید. برای اطلاعات بیشتر در مورد انطباق با CT در اندروید، به سیاست CT اندروید مراجعه کنید.

به طور پیش‌فرض، گواهینامه‌ها صرف نظر از اینکه در یک گزارش CT ثبت شده‌اند یا خیر، پذیرفته می‌شوند. برای اطمینان از اینکه برنامه شما فقط به مقاصدی متصل می‌شود که گواهینامه‌های آنها در یک گزارش CT ثبت شده‌اند، می‌توانید این ویژگی را به صورت سراسری یا بر اساس هر دامنه فعال کنید .

ترافیک متن شفاف

توسعه‌دهندگان می‌توانند ترافیک متن شفاف (استفاده از پروتکل HTTP رمزگذاری نشده به جای HTTPS) را برای برنامه‌های خود فعال یا غیرفعال کنند. برای جزئیات بیشتر به NetworkSecurityPolicy.isCleartextTrafficPermitted() مراجعه کنید.

رفتار پیش‌فرض ترافیک cleartext به سطح API بستگی دارد:

از ترافیک متن ساده صرف نظر کنید

توجه: راهنمایی‌های این بخش فقط برای برنامه‌هایی اعمال می‌شود که اندروید ۸.۱ (سطح API ۲۷) یا پایین‌تر را هدف قرار می‌دهند.

اگر قصد دارید برنامه شما فقط با استفاده از اتصالات امن به مقاصد متصل شود، می‌توانید از پشتیبانی ترافیک متن ساده به آن مقاصد صرف نظر کنید. این گزینه به جلوگیری از رگرسیون‌های تصادفی در برنامه‌ها به دلیل تغییرات در URL های ارائه شده توسط منابع خارجی مانند سرورهای backend کمک می‌کند.

برای مثال، ممکن است بخواهید برنامه شما اطمینان حاصل کند که اتصالات به 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>

به ترافیک متن پاک‌شده بپیوندید

توجه: راهنمایی‌های این بخش فقط برای برنامه‌هایی اعمال می‌شود که اندروید ۹ (سطح 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>

اگر برنامه شما نیاز دارد که ترافیک cleartext را به هر دامنه‌ای بپذیرد، cleartextTrafficPermitted="true" را در base-config تنظیم کنید. توجه داشته باشید که تا حد امکان باید از این پیکربندی ناامن اجتناب شود.

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

گواهی‌های پین

معمولاً یک برنامه به تمام CA های از پیش نصب شده اعتماد می‌کند. اگر هر یک از این CA ها یک گواهی جعلی صادر کنند، برنامه در معرض خطر یک مهاجم در مسیر قرار می‌گیرد. برخی از برنامه‌ها تصمیم می‌گیرند مجموعه گواهی‌هایی را که می‌پذیرند، با محدود کردن مجموعه CA های مورد اعتماد یا با پین کردن گواهی، محدود کنند.

پین کردن گواهی با ارائه مجموعه‌ای از گواهی‌ها توسط هش کلید عمومی ( SubjectPublicKeyInfo گواهی X.509) انجام می‌شود. یک زنجیره گواهی تنها در صورتی معتبر است که زنجیره گواهی حداقل یکی از کلیدهای عمومی پین شده را داشته باشد.

توجه داشته باشید که هنگام استفاده از پین کردن گواهی، همیشه باید یک کلید پشتیبان داشته باشید تا اگر مجبور شدید به کلیدهای جدید تغییر دهید یا CAها را تغییر دهید (هنگام پین کردن به یک گواهی CA یا یک 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 باید از مجموعه‌ای سفارشی از CAها استفاده کنند. علاوه بر این، ترافیک cleartext به این دامنه‌ها مجاز است ، مگر هنگام اتصال به 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 مورد نیاز است.

از اندروید ۱۷ (سطح API ۳۷) و بالاتر، اگر هیچ پیکربندی برای 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>

بخش‌های بعدی، سینتکس و سایر جزئیات فرمت فایل را شرح می‌دهند.

<پیکربندی-امنیت-شبکه>

می‌تواند شامل موارد زیر باشد:
۰ یا ۱ از <base-config>
هر تعداد <domain-config>
۰ یا ۱ از <debug-overrides>

<پیکربندی پایه>

نحو:
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
می‌تواند شامل موارد زیر باشد:
<trust-anchors> <certificateTransparency>
شرح:
پیکربندی پیش‌فرض مورد استفاده توسط تمام اتصالاتی که مقصد آنها توسط domain-config پوشش داده نمی‌شود.

هر مقداری که تنظیم نشده باشد، از مقادیر پیش‌فرض پلتفرم استفاده می‌کند.

پیکربندی پیش‌فرض برای برنامه‌هایی که اندروید ۹ (سطح API 28) و بالاتر را هدف قرار می‌دهند به شرح زیر است:

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

پیکربندی پیش‌فرض برای برنامه‌هایی که اندروید ۷.۰ (سطح API ۲۴) تا اندروید ۸.۱ (سطح API ۲۷) را هدف قرار می‌دهند، به شرح زیر است:

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

پیکربندی پیش‌فرض برای برنامه‌هایی که اندروید ۶.۰ (سطح API ۲۳) و پایین‌تر را هدف قرار می‌دهند به شرح زیر است:

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

<پیکربندی دامنه>

نحو:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
می‌تواند شامل موارد زیر باشد:
یک یا چند <domain>
۰ یا ۱ <certificateTransparency>
۰ یا ۱ <trust-anchors>
۰ یا ۱ <pin-set>
هر تعداد <domain-config> تو در تو
شرح:
پیکربندی مورد استفاده برای اتصال به مقاصد خاص، همانطور که توسط عناصر domain تعریف شده است.

توجه داشته باشید که اگر چندین عنصر domain-config یک مقصد را پوشش دهند، از پیکربندی با خاص‌ترین (طولانی‌ترین) قانون دامنه منطبق استفاده می‌شود.

دامنه

نحو:
<domain includeSubdomains=["true" | "false"]>example.com</domain>
ویژگی‌ها:
includeSubdomains
اگر "true" باشد، این قانون دامنه با دامنه و تمام زیر دامنه‌ها، شامل زیر دامنه‌های زیر دامنه‌ها، مطابقت دارد. در غیر این صورت، این قانون فقط برای تطابق‌های دقیق اعمال می‌شود.

<گواهی شفافیت>

نحو:
<certificateTransparency enabled=["true" | "false"]/>
شرح:
اگر true ، برنامه از گزارش‌های شفافیت گواهی برای اعتبارسنجی گواهی‌ها استفاده خواهد کرد. وقتی برنامه‌ای از گواهی خود (یا فروشگاه کاربر) استفاده می‌کند، احتمالاً گواهی عمومی نیست و بنابراین با استفاده از شفافیت گواهی قابل تأیید نیست. به طور پیش‌فرض، تأیید برای این موارد غیرفعال است. هنوز هم می‌توان با استفاده از <certificateTransparency enabled="true"/> در پیکربندی دامنه، تأیید را اجباری کرد. برای هر <domain-config> ، ارزیابی به این ترتیب انجام می‌شود:
  1. اگر certificateTransparency فعال است، تأیید را نیز فعال کنید.
  2. اگر هر یک از <trust-anchors> از "user" یا درون‌خطی باشد (مثلاً "@raw/cert.pem" ) ، تأیید را غیرفعال کنید.
  3. در غیر این صورت، به پیکربندی ارثی تکیه کنید.

<اشکال‌زدایی-لغو>

نحو:
<debug-overrides>
    ...
</debug-overrides>
می‌تواند شامل موارد زیر باشد:
۰ یا ۱ <trust-anchors>
شرح:
لغوهایی که باید اعمال شوند زمانی که android:debuggable برابر با "true" باشد، که معمولاً برای نسخه‌های غیر منتشر شده تولید شده توسط IDEها و ابزارهای ساخت اتفاق می‌افتد. لنگرهای اعتماد مشخص شده در debug-overrides به تمام پیکربندی‌های دیگر اضافه می‌شوند و پین‌گذاری گواهی زمانی انجام نمی‌شود که زنجیره گواهی سرور از یکی از این لنگرهای اعتماد فقط برای اشکال‌زدایی استفاده کند. اگر android:debuggable برابر با "false" باشد، این بخش کاملاً نادیده گرفته می‌شود.

<لینک‌های اعتماد>

نحو:
<trust-anchors>
...
</trust-anchors>
می‌تواند شامل موارد زیر باشد:
هر تعداد <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

مشخص می‌کند که آیا CA های این منبع، پین‌گذاری گواهی را دور می‌زنند یا خیر. اگر "true" ، پین‌گذاری روی زنجیره‌های گواهی که توسط یکی از CA های این منبع امضا شده‌اند، انجام نمی‌شود. این می‌تواند برای اشکال‌زدایی CA ها یا برای آزمایش حملات مرد میانی روی ترافیک امن برنامه شما مفید باشد.

مقدار پیش‌فرض "false" است، مگر اینکه در عنصر debug-overrides مشخص شده باشد که در این صورت مقدار پیش‌فرض "true" است.

<تنظیم پین>

نحو:
<pin-set expiration="date">
...
</pin-set>
می‌تواند شامل موارد زیر باشد:
هر تعداد <pin>
شرح:
مجموعه‌ای از پین‌های کلید عمومی. برای اینکه یک اتصال امن قابل اعتماد باشد، یکی از کلیدهای عمومی در زنجیره اعتماد باید در مجموعه پین‌ها باشد. برای قالب پین‌ها به <pin> مراجعه کنید.
ویژگی‌ها:
expiration
تاریخی، به فرمت yyyy-MM-dd ، که در آن پین‌ها منقضی می‌شوند و در نتیجه پین‌گذاری غیرفعال می‌شود. اگر این ویژگی تنظیم نشده باشد، پین‌ها منقضی نمی‌شوند.

انقضا به جلوگیری از مشکلات اتصال در برنامه‌هایی که به‌روزرسانی‌هایی برای مجموعه پین ​​خود دریافت نمی‌کنند، مانند زمانی که کاربر به‌روزرسانی‌های برنامه را غیرفعال می‌کند، کمک می‌کند.

<پین>

نحو:
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
ویژگی‌ها:
digest
الگوریتم خلاصه‌ای که برای تولید پین استفاده شده است. در حال حاضر، فقط "SHA-256" پشتیبانی می‌شود.