אם יש לך שאלות לגבי המדיניות הזו, אפשר להפנות אותן לפורום המדיניות בנושא שקיפות אישורים: ct-policy@chromium.org
כשאישור Transport Layer Security (TLS) של חיבור מאומת באפליקציה שמצטרפת ל-Certificate Transparency (CT), הוא נבדק כדי לוודא שהוא עומד בדרישות של מדיניות ה-CT של Android. אישורים שמצורפים אליהם חותמות זמן של אישורים חתומים (SCT) שעומדים בדרישות המדיניות הזו נחשבים לתואמים ל-CT.
תאימות ל-CT מושגת על ידי אישור וקבוצה של חתימות SCT נלוות שעומדים בסדרה של דרישות טכניות שנאכפות על ידי ספריות TLS פופולריות (כולל Conscrypt המובנה) במהלך אימות האישור, שמוגדרות במדיניות הזו.
מצבים של יומן CT
התאימות ל-CT ב-Android נקבעת על ידי הערכת SCT מיומני CT ועל ידי וידוא שהיומנים האלה נמצאים במצב הנכון בזמן הבדיקה. אלה הסטטוסים האפשריים של יומן CT:
PendingQualifiedUsableReadOnlyRetiredRejected
כדי לעזור לכם להבין את הדרישות לתאימות ל-CT ב-Android, הגדרנו את המצבים האלה, את הדרישות של היומנים בכל מצב ואת ההשפעה של המצבים האלה על ההתנהגות של Android. הסבר מפורט על כך מופיע במאמר בנושא מחזור החיים של יומן CT במסמכי התיעוד של Chrome.
אישורים שעומדים בדרישות של CT
אישור TLS הוא תואם ל-CT אם מצורף אליו סט של SCT שעומד לפחות באחד מהקריטריונים שמוגדרים בהמשך, בהתאם לאופן שבו ה-SCT מועבר ל-Android. באפליקציות של Android שבהן נאכפת שקיפות האישורים, כל אישורי ה-TLS שמהימנים באופן ציבורי צריכים להיות תואמים לשקיפות האישורים כדי שהאימות יצליח. עם זאת, אישורים שלא נרשמו בשקיפות האישורים או שאין להם מספיק אישורי SCT לא נחשבים כאישורים שהונפקו בצורה שגויה.
כשמערכת Android בודקת אם אישור עומד בדרישות של CT, היא מתייחסת לכמה גורמים, כולל מספר ה-SCT שקיימים, מי מפעיל את יומן ה-CT שהנפיק את ה-SCT, ובאיזה מצב היה יומן ה-CT שהנפיק את ה-SCT, גם בזמן האימות של האישור וגם בזמן שיומן ה-CT יצר את ה-SCT.
בהתאם לאופן שבו ה-SCT מוצגים ב-Android, אפשר לעמוד בדרישות התאימות של CT אם מתקיימים אחד מהקריטריונים הבאים:
הצהרות SCT מוטמעות:
- לפחות SCT מוטמע אחד מיומן שקיפות אישורים שהיה
Qualified,UsableאוReadOnlyבזמן הבדיקה; ו - יש לפחות N רשומות SCT מוטמעות מיומני CT נפרדים שעברו
Qualified,Usable,ReadOnlyאוRetiredבזמן הבדיקה, כאשר N מוגדר בטבלה הבאה; ו - מבין הצהרות ה-SCT שעומדות בדרישה 2, לפחות שתי הצהרות SCT צריכות להיות מונפקות על ידי מפעילים שונים של יומני שקיפות אישורים שמוכרים על ידי Android.
- מבין ה-SCT שעומדים בדרישה 2, לפחות אחד מהם צריך להיות מונפק מיומן ש-Android מזהה כיומן תואם ל-RFC 6962.
| תוקף האישור | מספר ה-SCT מיומני שקיפות שונים |
|---|---|
| <= 180 ימים | 2 |
| > 180 ימים | 3 |
SCTs delivered via OCSP or TLS:
- לפחות שני אישורי חתימה על אישור (SCT) מיומן שקיפות אישורים שהיה
Qualified,UsableאוReadOnlyבזמן הבדיקה; ו - מבין חותמות ה-SCT שעומדות בדרישה 1, לפחות שתי חותמות SCT צריכות להיות מונפקות על ידי מפעילים שונים של יומני שקיפות אישורים, כפי שמזוהים על ידי Android.
- מבין ה-SCT שעומדים בדרישה 1, לפחות אחד מהם צריך להיות מונפק מיומן שקיפות אישורים שמוכר על ידי Android כיומן שעומד בתקן RFC6962.
גם לגבי SCT מוטבעים וגם לגבי SCT שמועברים באמצעות OCSP או TLS, הייחודיות של מפעיל היומן מוגדרת כערכים נפרדים בקטע המפעילים של רשימת היומנים.
במקרים נדירים שבהם יומן CT מחליף אופרטורים במהלך חייו, הוא יכול להכיל רשימה של previous_operators, לצד חותמת הזמן הסופית שבה היומן הזה הופעל על ידי האופרטור הקודם.
כדי למנוע שינויים באופרטורים של יומנים שעלולים לגרום לבעיות באישורים קיימים, האופרטור של כל יומן SCT נקבע כאופרטור בזמן הנפקת ה-SCT, על ידי השוואה בין חותמת הזמן של ה-SCT לבין חותמות הזמן של previous_operators, אם הן קיימות.
הערות חשובות
כל עוד אחד מהקריטריונים הקודמים של התאימות ל-CT מתקיים על ידי שילוב כלשהו של אישורי SCT שמוצגים בהעברת הנתונים, אישורי SCT נוספים, ללא קשר לסטטוס של אישור ה-SCT, לא ישפיעו על סטטוס התאימות ל-CT של האישור באופן חיובי או שלילי.
כדי ש-SCT יתרום לתאימות של אישור ל-CT, הוא צריך להיות מונפק לפני חותמת הזמן Retired של היומן, אם קיימת כזו.
מערכת Android משתמשת ב-SCT המוקדם ביותר מבין כל ה-SCT שמוצגים כדי להעריך את התאימות ל-CT בהשוואה לחותמות הזמן של יומן ה-CT Retired.
ההסבר הזה מתייחס למקרים חריגים שבהם יומן CT יוצא משימוש במהלך תהליך שליחת בקשות לרישום אישורים.
"SCT מוטמע" פירושו SCT שמועבר באמצעות התוסף SignedCertificateTimestampListX.509v3 בתוך האישור עצמו. הרבה שרתי TLS לא תומכים ב-OCSP Stapling או בתוסף TLS, ולכן רשויות אישורים (CA) צריכות להיות מוכנות להטמיע 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 יציב, ללא הסכם רמת שירות וללא ערבויות זמינות.
מערכת Android מפרסמת את רשימת היומנים של CT למטרות של שולחי אישורים (כמו רשויות אישורים) ושל מפקחים ומבקרים של CT שרוצים לשמור על תאימות למערכות האקולוגיות של CT ו-WebPKI, או לחקור את התוכן שלהן.
הסתמכות לא מורשית על רשימת היומנים של שקיפות האישורים ב-Android מסכנת לא רק את המשתמשים שלכם, אלא גם את משתמשי Android ואת הסביבה העסקית של שקיפות האישורים בכללותה. אם אתם שוקלים להוסיף אכיפה של CT לאפליקציה שלכם, אתם צריכים להשתמש במנגנון שנתמך על ידי פלטפורמת Android.
שימוש ברשימת היומנים של Android CT שלא בהתאם למדיניות הזו הוא על אחריותכם בלבד, והוא עלול לגרום לשבירה של האפליקציה או הספרייה שלכם. מערכת Android צריכה להיות מסוגלת לבצע שינויים ברשימת היומנים של CT בתגובה לאירועים במערכת האקולוגית של CT, כדי לשמור על הבטיחות והאבטחה של משתמשי Android. יכול להיות שמערכת Android תנקוט צעדים כדי לוודא שתלות של צד שלישי ברשימת יומני שקיפות האישורים לא תסכן את היכולת של Android להגיב לאירועים כאלה, כולל שינויים ברשימת היומנים ללא הודעה מוקדמת כדי לשבש שימוש לא מורשה.