Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/he/docs/a-warm-welcome-to-asn1-and-der.md
Original file line number Diff line number Diff line change
Expand Up @@ -667,7 +667,7 @@ MIIFajCCBFKgAwIBAgISA6HJW9qjaoJoMn8iU8vTuiQ2MA0GCSqGSIb3DQEBCwUA

כעת יש לך מספיק ידע כדי להסביר מדוע! [אישור הוא SEQUENCE](https://tools.ietf.org/html/rfc5280#page-116), ולכן ייפתח בבית 0x30. הבתים הבאים הם [שדה האורך](#length). אישורים הם כמעט תמיד ארוכים מ־127 בתים, לכן על שדה האורך להשתמש בצורה הארוכה של האורך. משמעות הדבר היא שהבית הראשון יהיה 0x80 + N, כאשר N הוא מספר של אורך עוקב בבתים. N הוא כמעט תמיד 2, מאחר שזאת כמות התווים שנדרשת להצפין אורכים מ־128 ועד 65535 וכמעט לכל האישורים יש אורכים בטווח הזה.

אז עכשיו אנחנו יודעים ששני הבתים הראשונים של הצפנת DER של אישור הם ‎0x30 0x82‎. [הצפנת PEM ](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) משתמשת ב־[base64](https://en.wikipedia.org/wiki/Base64), שמצפין 3 בתים של קלט בינרי לפלט של 4 תווי ASCII. או, במילים אחרות: base64 הופך קלט בינרי של 24 סיביות לפלט של 4 תווי ASCII עם 6 סיביות מהקלט שמוקצות לכל תו. אנחנו יודעים מה תהיינה 16 הסיביות הראשונות של כל אישור. כדי להוכיח שהתווים הראשונים של (כמעט) כל אישור יהיו „MII”, אנחנו צריכים להתבונן ב־2 הסיביות הבאות. הן תהיינה הסיביות המובהקות ביותר של הבית המובהק ביותר מתוך הבתים באורך שתיים. האם הסיביות האלו אי פעם יוגדרו להיות 1? לא, אלמלא אורך האישור הוא מעל 16,384 בתים! לכן אנחנו יכולים לחזות שהתווים הראשונים של אישור PEM תמיד יהיו אותו הדבר. אפשר לנסות לבד:
אז עכשיו אנחנו יודעים ששני הבתים הראשונים של הצפנת DER של אישור הם ‎0x30 0x82‎. [הצפנת PEM ](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) משתמשת ב־[base64](https://en.wikipedia.org/wiki/Base64), שמצפין 3 בתים של קלט בינרי לפלט של 4 תווי ASCII. או, במילים אחרות: base64 הופך קלט בינרי של 24 סיביות לפלט של 4 תווי ASCII עם 6 סיביות מהקלט שמוקצות לכל תו. אנחנו יודעים מה תהיינה 16 הסיביות הראשונות של כל אישור. כדי להוכיח שהתווים הראשונים של (כמעט) כל אישור יהיו „MII”, עלינו להסתכל על שתי הסיביות הבאות. הן תהיינה הסיביות המובהקות ביותר של הבית המובהק ביותר מתוך הבתים באורך שתיים. האם הסיביות האלו אי פעם יוגדרו להיות 1? לא, אלמלא אורך האישור הוא מעל 16,384 בתים! לכן אנחנו יכולים לחזות שהתווים הראשונים של אישור PEM תמיד יהיו אותו הדבר. אפשר לנסות לבד:

```bash
xxd -r -p <<<308200 | base64
Expand Down
4 changes: 2 additions & 2 deletions content/he/docs/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,11 +61,11 @@ Note for translators:

{{% def id="CRL" english="Certificate Revocation List" abbr="CRL" name="רשימת אישורים שנשללו" %}} שיטה ליידע את [סוכני המשתמש](#def-user-agent) על מצב [שלילת](#def-revocation) [אישור](#def-leaf). זו רשימת המספרים הסידוריים של כל האישורים שנשללו על ידי רשות אישורים מסוימת ונחתמו קודם על ידיה. [ויקיפדיה](https://en.wikipedia.org/wiki/Certificate_revocation_list) {{% /def %}}

{{% def id="CSR" english="Certificate Signing Request" abbr="CSR" name="בקשת חתימה על אישור" %}} קובץ חתום שמכיל את המידע שדורשת [רשות האישורים](#def-CA) כדי לייצר אישור. המידע שדרוש ל־[Let's Encrypt](#def-LE) הוא ה־[Common Name](#def-CN) (שם נפוץ),‏ [Subject Alternative Names](#def-SAN) (שמות נושא חלופיים) ו־Subject Public Key Info (פרטי מפתח ציבורי של הנושא). בדרך כלל, [יישומי לקוחות](#def-ACME-client) מייצרים את בקשת החתימה על האישור אוטומטית עבור הלקוח, למרות שספקית אחסון או מכשיר כלשהו גם כן יכולים לייצר בקשה לחתימה על האישור. [ויקיפדיה](https://en.wikipedia.org/wiki/Certificate_signing_request) {{% /def %}}
{{% def id="CSR" name="בקשת חתימה על אישור" abbr="CSR" %}} קובץ חתום שמכיל את הפרטים שנחוצים ל[רשות האישורים](#def-CA) כדי לייצר אישור. המידע שדרוש ל־[Let's Encrypt](#def-LE) הוא ה־[Common Name](#def-CN) (שם נפוץ),‏ [Subject Alternative Names](#def-SAN) (שמות נושא חלופיים) ו־Subject Public Key Info (פרטי מפתח ציבורי של הנושא). בדרך כלל, [יישומי לקוחות](#def-ACME-client) מייצרים את בקשת החתימה על האישור אוטומטית עבור הלקוח, למרות שספקית אחסון או מכשיר כלשהו גם כן יכולים לייצר בקשה לחתימה על האישור. [ויקיפדיה](https://en.wikipedia.org/wiki/Certificate_signing_request) {{% /def %}}

{{% def id="store" english="Certificate Store" name="מאגר אישורים" %}} מאגר אישורים מכיל רשימה של [אישורים עליונים](#def-root) מהימנים. מערכות הפעלה (כגון Windows,‏ Android או דביאן) ו[דפדפנים](#def-web-browser) (כגון Firefox) מחזיקים מאגר אישורים. למעט הדפדפן הזה שאר הדפדפנים מסתמכים על מאגר האישורים של מערכת ההפעלה. [אישורים](#def-leaf) שמסופקים על ידי [Let's Encrypt](#def-LE) נחשבים [מהימנים בעיני רוב מאגרי האישורים](/certificates). {{% /def %}}

{{% def id="subject" english="Certificate subject" name="נושא אישור" %}} השדה „Subject” (נושא) באישור מציין על מה האישור. הוא בדרך כלל מכיל שדות כגון [Common Name](#def-CN) (שם נפוץ), Country (מדינה), ו־Organization (ארגון). {{% /def %}}
{{% def id="subject" name="נושא האישור" %}} השדה „נושא” באישור שמציין על מה האישור. הוא בדרך כלל מכיל שדות כגון [Common Name](#def-CN) (שם נפוץ), Country (מדינה), ו־Organization (ארגון). {{% /def %}}

{{% def id="CT" english="Certificate Transparency" abbr="CT" name="שקיפות אישורים" %}} כדי לשפר את האבטחה, יש לפרסם אישורים (או [קדם אישורים](#def-precertificate)) ליומני שקיפות אישורים: https://www.certificate-transparency.org/‎. מערכת [Let's Encrypt](#def-LE) מייצרת ומפרסמת [אישורי קדם](#def-precertificate) וכוללת ב[אישור](#def-leaf) העוקב רשימה של [SCTs](#def-SCT) (חותמות זמן של אישור חתום) עבור אישור הקדם. חלק מה[דפדפנים](#def-web-browser), כגון Chrome מבית Google, דורש את נוכחותה של הבטחה זו שניתן לאמת כדי לתקף את האישור. [ויקיפדיה](https://en.wikipedia.org/wiki/Certificate_Transparency) {{% /def %}}

Expand Down