אם יש לך שאלות לגבי המדיניות הזו, אפשר להפנות אותן לפורום המדיניות בנושא שקיפות אישורים: ct-policy@chromium.org
כשמאמתים אישור Transport Layer Security (TLS) של חיבור, הוא נבדק כדי לוודא שהוא עומד בדרישות של מדיניות שקיפות האישורים (CT) ב-Android. אישורים שמצורפים אליהם חותמות זמן של אישורים חתומים (SCT) שעומדים בדרישות המדיניות הזו נחשבים כאישורים שעומדים בדרישות של CT.
התאימות ל-CT מושגת על ידי אישור וקבוצה של SCT נלווים שעומדים בקבוצה של דרישות טכניות שנאכפות על ידי ספריות TLS פופולריות (כולל Conscrypt המובנה) במהלך אימות האישור, שמוגדרות במדיניות הזו.
מצבים של יומן CT
התאימות ל-CT ב-Android נקבעת על ידי הערכת SCT מיומני CT, ומוודאים שהיומנים האלה נמצאים במצב הנכון בזמן הבדיקה. המצבים האפשריים שיומן CT יכול להיות בהם הם:
PendingQualifiedUsableReadOnlyRetiredRejected
כדי לעזור לכם להבין את הדרישות לתאימות ל-CT ב-Android, הגדרנו את המצבים האלה, את הדרישות של יומני הרישום בכל מצב ואת ההשפעה של המצבים האלה על ההתנהגות של Android. הסבר מפורט על כך מופיע בCT Log Lifecycle Explainer במסמכי התיעוד של Chrome.
אישורים שעומדים בדרישות של CT
אישור TLS הוא תואם ל-CT אם מצורף אליו סט של חתימות על הצהרות שקיפות (SCT) שעומד לפחות באחד מהקריטריונים שמוגדרים בהמשך, בהתאם לאופן שבו ה-SCT מועבר ל-Android. באפליקציות של Android שבהן נאכפת שקיפות האישורים, כל אישורי ה-TLS שמהימנים באופן ציבורי צריכים להיות תואמים ל-CT כדי שהאימות יצליח. עם זאת, אישורים שלא נרשמו ב-CT או שאין להם מספיק חתימות על הצהרות שקיפות לא נחשבים כאישורים שהונפקו בצורה שגויה.
כשמערכת Android בודקת אם אישור עומד בדרישות של CT, היא לוקחת בחשבון כמה גורמים, כולל מספר ה-SCT שקיימים, מי מפעיל את יומן ה-CT שהנפיק את ה-SCT, ובאיזה מצב היה יומן ה-CT שהנפיק את ה-SCT, גם בזמן האימות של האישור וגם בזמן שיומן ה-CT יצר את ה-SCT.
בהתאם לאופן שבו מוצגים ה-SCT ל-Android, אפשר לעמוד בדרישות התאימות של CT אם מתקיימים אחד מהקריטריונים הבאים:
SCT מוטמעים:
- לפחות SCT מוטמע אחד מיומן שקיפות אישורים שהיה
Qualified, UsableאוReadOnlyבזמן הבדיקה, וגם - יש לפחות N רשומות SCT מוטמעות מיומני שקיפות אישורים שונים שהיו
Qualified,Usable,ReadOnlyאוRetiredבזמן הבדיקה, כאשר N מוגדר בטבלה הבאה. - מבין אישורי ה-SCT שעומדים בדרישה 2, לפחות שני אישורי SCT צריכים להיות מונפקים על ידי מפעילי יומני שקיפות שונים שמוכרים על ידי Android; ו
| תוקף האישור | מספר ה-SCT-ים מיומני CT נפרדים |
|---|---|
| <= 180 ימים | 2 |
| > 180 ימים | 3 |
SCTs delivered via OCSP or TLS:
- לפחות שני אישורי חתימה על אישורים מיומן שקיפות אישורים שהיה
Qualified,UsableאוReadOnlyבזמן הבדיקה; ו - מבין חתימות ה-SCT שעומדות בדרישה 1, לפחות שתי חתימות SCT צריכות להיות מונפקות על ידי מפעילים שונים של יומני שקיפות אישורים, כפי שמזוהים על ידי Android.
גם לגבי אישורי SCT מוטמעים וגם לגבי אישורי SCT שמועברים באמצעות OCSP או TLS, הייחודיות של מפעיל היומן מוגדרת כהימצאות של רשומות נפרדות בקטע המפעילים של רשימת היומנים.
במקרים נדירים שבהם מפעיל של יומן שקיפות אישורים משתנה במהלך חיי היומן, יומני שקיפות האישורים יכולים להכיל רשימה של previous_operators, עם חותמת הזמן הסופית שבה היומן הזה הופעל על ידי המפעיל הקודם. כדי למנוע שינויים במפעיל היומן שיפגעו באישורים קיימים, המפעיל של כל SCT נקבע כמפעיל בזמן הנפקת ה-SCT, על ידי השוואה בין חותמת הזמן של ה-SCT לבין חותמות הזמן של previous_operators, אם הן קיימות.
הערות חשובות
כל עוד אחד מהקריטריונים הקודמים לתאימות ל-CT מתקיים על ידי שילוב כלשהו של SCT שמוצג בתהליך הלחיצה, SCT נוסף, ללא קשר לסטטוס שלו, לא ישפיע על סטטוס התאימות ל-CT של אישור באופן חיובי או שלילי.
כדי ש-SCT יתרום לתאימות של אישור ל-CT, הוא צריך להיות מונפק לפני חותמת הזמן של היומן Retired, אם קיימת כזו.
מערכת Android משתמשת ב-SCT המוקדם ביותר מבין כל ה-SCT שמוצגים כדי להעריך את התאימות ל-CT בהשוואה לחותמות הזמן של יומן ה-CT Retired.
העיכוב הזה נועד לתת מענה למקרים חריגים שבהם יומן CT יוצא משימוש במהלך תהליך שליחת הבקשות לרישום אישורים.
"SCT מוטבע" פירושו SCT שמועבר באמצעות התוסף SignedCertificateTimestampListX.509v3 בתוך האישור עצמו. הרבה שרתי TLS לא תומכים ב-OCSP Stapling או בתוסף TLS, ולכן רשויות אישורים צריכות להיות מוכנות להטמיע SCT באישורים שהן מנפיקות כדי להבטיח אימות מוצלח או טיפול ב-EV ב-Android.
איך יומני CT מתווספים ל-Android
הקריטריונים להפיכת יומני CT לQualified, וגם הנסיבות שעלולות לגרום להם להפוך לRetired, מפורטים במדיניות יומני ה-CT של Chrome.
הזמן הקצוב לתפוגה של אכיפת CT
בכל יום, Google מפרסמת רשימה חדשה של יומני שקיפות אישורים שמכילה log_list_timestampחדש. פעם ביום, מכשירי Android ינסו להוריד את הגרסה האחרונה של הרשימה הזו למטרות אימות. בכל זמן נתון, אם רשימת היומנים לא זמינה במכשיר או אם חותמת הזמן של רשימת היומנים ישנה יותר מ-70 ימים, אכיפת ה-CT תושבת.
הזמן הקצוב הזה מספק למערכת האקולוגית של CT הבטחה חשובה שלפיה אפשר להעביר בבטחה יומני CT חדשים למצב 'ניתן לשימוש' תוך פרק זמן קבוע אחרי שהם הופכים לQualified.
רשימת היומנים של Android
רשימת היומנים של Android מתפרסמת בקובץ log_list.json, שמתעדכן מדי יום. רשימת היומנים הזו מוצעת ללא API יציב, ללא הסכם רמת שירות (SLA) וללא ערבויות זמינות.
מערכת Android מפרסמת את רשימת היומנים של CT למטרות של שולחי אישורים (כמו רשויות אישורים) ושל מפקחים ומבקרים של CT שרוצים לשמור על תאימות למערכות האקולוגיות של CT ו-WebPKI, או לחקור את התוכן שלהן.
הסתמכות לא מורשית על רשימת היומנים של שקיפות האישורים ב-Android מסכנת לא רק את המשתמשים שלכם, אלא גם את משתמשי Android ואת הסביבה העסקית של שקיפות האישורים בכללותה. אם אתם שוקלים להוסיף אכיפה של CT לאפליקציה שלכם, אתם צריכים להשתמש במנגנון שנתמך על ידי פלטפורמת Android.
שימוש ברשימת היומנים של Android CT שלא בהתאם למדיניות הזו הוא על אחריותכם בלבד, והוא עלול לגרום לשבירה של האפליקציה או הספרייה שלכם. מערכת Android צריכה להיות מסוגלת לבצע שינויים ברשימת יומני ה-CT בתגובה לאירועים במערכת האקולוגית של ה-CT, כדי לשמור על הבטיחות והאבטחה של משתמשי Android. יכול להיות ש-Android תנקוט צעדים כדי לוודא שתלות של צד שלישי ברשימת היומנים של שקיפות האישורים לא תסכן את היכולת של Android להגיב לאירועים כאלה, כולל שינויים ברשימת היומנים שלא יפורסמו מראש כדי לשבש שימוש לא מורשה.