لطفاً هرگونه سؤالی در مورد این خطمشی را به انجمن خطمشی CT ارسال کنید: ct-policy@chromium.org
وقتی گواهی امنیت لایه انتقال (TLS) یک اتصال اعتبارسنجی میشود، از نظر انطباق با خطمشی شفافیت گواهی اندروید (CT) ارزیابی میشود. گواهیهایی که با مهر زمانی گواهی امضا شده (SCT) همراه هستند و این خطمشی را برآورده میکنند، مطابق با CT نامیده میشوند.
انطباق با CT توسط یک گواهی و مجموعهای از SCTهای همراه آن که مجموعهای از الزامات فنی اعمالشده توسط کتابخانههای محبوب TLS (از جمله Conscrypt داخلی) را در طول اعتبارسنجی گواهی برآورده میکنند، حاصل میشود که در این خطمشی تعریف شدهاند.
ایالتهای ثبت سیتی
انطباق با CT در اندروید با ارزیابی SCTها از لاگهای CT و اطمینان از اینکه این لاگها در زمان بررسی در وضعیت(های) صحیحی قرار دارند، تعیین میشود. مجموعه حالتهای ممکنی که یک لاگ CT میتواند در آنها باشد عبارتند از:
-
Pending -
Qualified -
Usable -
ReadOnly -
Retired -
Rejected
برای کمک به درک الزامات انطباق با CT در اندروید، تعریف این وضعیتها، الزامات گزارشها در هر وضعیت، و همچنین نحوه تأثیر این وضعیتها بر رفتار اندروید، به تفصیل در CT Log Lifecycle Explainer از مستندات کروم شرح داده شده است.
گواهینامههای منطبق با CT
یک گواهی TLS در صورتی با CT مطابقت دارد که با مجموعهای از SCTها همراه باشد که حداقل یکی از معیارهای تعریفشده در ادامه را برآورده کنند، بسته به نحوه ارائه SCTها به اندروید. در برنامههای اندروید که CT را اجرا میکنند، برای اعتبارسنجی موفقیتآمیز، لازم است که همه گواهیهای TLS مورد اعتماد عمومی با CT مطابقت داشته باشند. با این حال، گواهیهایی که در CT ثبت نشدهاند یا SCTهای کافی ندارند، به عنوان گواهیهای صادرشده نادرست در نظر گرفته نمیشوند.
هنگام ارزیابی یک گواهی برای انطباق با CT، اندروید عوامل مختلفی را در نظر میگیرد، از جمله اینکه چه تعداد SCT وجود دارد، چه کسی CT Log را که SCT را صادر کرده است، اداره میکند و CT Log که SCT را صادر کرده است، چه زمانی در زمان اعتبارسنجی گواهی و چه زمانی که SCT توسط CT Log ایجاد شده است، در چه وضعیتی بوده است.
بسته به نحوه ارائه SCTها به اندروید، انطباق با CT میتواند با برآورده کردن یکی از معیارهای زیر حاصل شود:
SCT های جاسازی شده:
- حداقل یک SCT جاسازیشده از یک گزارش CT که در زمان بررسی
Qualified،UsableیاReadOnlyبوده است؛ و - SCT های جاسازی شده از حداقل N گزارش CT مجزا وجود دارد که در زمان بررسی
Qualified،Usable،ReadOnlyیاRetiredبودند، که N در جدول زیر تعریف شده است؛ و - در میان SCTهایی که الزام ۲ را برآورده میکنند، حداقل دو SCT باید از اپراتورهای ثبت CT مجزا که توسط اندروید شناخته شدهاند، صادر شوند؛ و
| طول عمر گواهی | تعداد SCT های حاصل از لاگ های CT مجزا |
|---|---|
| <= ۱۸۰ روز | ۲ |
| > ۱۸۰ روز | ۳ |
SCT های ارائه شده از طریق OCSP یا TLS:
- حداقل دو SCT از یک گزارش CT که در زمان بررسی
Qualified،UsableیاReadOnlyبوده است؛ و - در میان SCTهایی که الزام ۱ را برآورده میکنند، حداقل دو SCT باید از اپراتورهای ثبت CT مجزا که توسط اندروید شناخته شدهاند، صادر شوند؛ و
برای هر دو SCT های تعبیه شده و آنهایی که با استفاده از OCSP یا TLS ارائه میشوند، منحصر به فرد بودن عملگر گزارش به صورت داشتن ورودیهای جداگانه در بخش عملگرهای لیست گزارش تعریف میشود.
در موارد نادری که یک گزارش CT در طول عمر خود عملگرها را تغییر میدهد، گزارشهای CT به صورت اختیاری حاوی فهرستی از previous_operators هستند که به همراه آخرین مهر زمانی که این گزارش توسط اپراتور قبلی اجرا شده است، میباشد. برای جلوگیری از اینکه تغییرات اپراتور گزارش، گواهیهای موجود را خراب کند، هر اپراتور گزارش SCT با مقایسه مهر زمانی SCT با مهرهای زمانی previous_operators ، در صورت وجود، به عنوان اپراتور در زمان صدور SCT تعیین میشود.
نکات مهم
مادامی که یکی از معیارهای انطباق با CT قبلی توسط ترکیبی از SCT های ارائه شده در فرآیند دست دادن (handshake) برآورده شود، SCT های اضافی، صرف نظر از وضعیت SCT، تأثیر مثبت یا منفی بر وضعیت انطباق با CT گواهی نخواهند داشت.
برای کمک به انطباق با CT یک گواهی، یک SCT باید قبل از مهر زمانی Retired لاگ، در صورت وجود، صادر شده باشد. اندروید از اولین SCT در بین تمام SCTهای ارائه شده برای ارزیابی انطباق با CT در برابر مهرهای زمانی Retired لاگ CT استفاده میکند. این مورد، موارد حاشیهای را در نظر میگیرد که در آنها یک لاگ CT در طول فرآیند ارسال درخواستهای ثبت گواهی، حذف میشود.
«SCT جاسازیشده» به SCTای گفته میشود که با استفاده از افزونهی SignedCertificateTimestampList X.509v3 در خود گواهی ارائه میشود. بسیاری از سرورهای TLS از OCSP Stapling یا افزونهی TLS پشتیبانی نمیکنند، بنابراین CAها باید آماده باشند تا SCTها را در گواهیهای صادر شده جاسازی کنند تا اعتبارسنجی یا پردازش EV در اندروید با موفقیت انجام شود.
نحوه اضافه شدن گزارشهای سیتی به اندروید
معیارهای چگونگی Qualified شدن گزارشهای CT و همچنین شرایطی که میتواند باعث Retired شدن آنها شود، را میتوانید در سیاست گزارش CT کروم بیابید.
مهلت اجرای CT
هر روز، گوگل یک لیست جدید از گزارشهای CT منتشر میکند که حاوی یک log_list_timestamp جدید است. روزی یک بار، دستگاههای اندروید سعی میکنند آخرین نسخه از این لیست را برای اهداف تأیید دانلود کنند. در هر زمان معین، اگر هیچ لیست گزارشی در دستگاه موجود نباشد یا اگر مهر زمانی لیست گزارش قدیمیتر از ۷۰ روز باشد، اجرای CT غیرفعال خواهد شد. این مهلت زمانی، تضمین مهمی برای اکوسیستم CT فراهم میکند که گزارشهای CT جدید میتوانند پس از Qualified شدن، در مدت زمان مشخصی به طور ایمن به Usable منتقل شوند.
فهرست گزارشهای اندروید
فهرست گزارشهای اندروید در فایل log_list.json منتشر میشود که روزانه بهروزرسانی میشود. این فهرست گزارش بدون API پایدار، SLA یا ضمانت در دسترس بودن ارائه میشود.
اندروید فهرست گزارش CT خود را برای ارائهدهندگان گواهی (مانند مراجع صدور گواهینامه) و ناظران و حسابرسان CT که مایل به سازگاری با اکوسیستمهای CT و WebPKI یا بررسی محتوای آنها هستند، در دسترس قرار میدهد.
اتکای غیرمجاز به فهرست گزارشهای CT اندروید نه تنها کاربران شما، بلکه کاربران اندروید و کل اکوسیستم CT را به خطر میاندازد. اگر در حال بررسی افزودن اجرای CT به برنامه خود هستید، از مکانیسمی استفاده کنید که توسط پلتفرم اندروید پشتیبانی میشود .
استفاده از فهرست گزارشهای CT اندروید خارج از این خطمشی، با مسئولیت خودتان انجام میشود و ممکن است منجر به خرابی برنامه یا کتابخانه شما شود. اندروید باید بتواند در پاسخ به حوادث در اکوسیستم CT، تغییراتی در فهرست گزارشهای CT ایجاد کند تا ایمنی و امنیت کاربران اندروید حفظ شود. اندروید ممکن است اقداماتی را انجام دهد تا اطمینان حاصل شود که وابستگیهای شخص ثالث به فهرست گزارشهای CT، توانایی اندروید در پاسخگویی به چنین حوادثی را به خطر نمیاندازند، از جمله تغییرات اعلام نشده در فهرست گزارشها برای مختل کردن استفاده غیرمجاز.