New HE, IT, ZH-CN translations (#1615)

New HE, IT, ZH-CN translations from Crowdin

Co-authored-by: Ludek Janda <[email protected]>

content/he/certificates.md

@@ -1,7 +1,7 @@
 ---
 title: שרשרת אמון
 linkTitle: שרשרת אמון (אישורים עליונים ומתווכים)
-slug: certificates
+slug: אישורים
 top_graphic: 5
 lastmod: 2021-10-02
 show_lastmod: 1

content/he/docs/a-warm-welcome-to-asn1-and-der.md

@@ -56,7 +56,7 @@ ASN.1 עבר כמה גלגולים במהלך השנים, חלק מהמהדור
 INTEGER
 -------
 
-ה־INTEGER המוכר והטוב. יכול להיות חיובי או שלילי. מה שבאמת חריג ב־INTEGERs של ASN.1 הוא שהם יכולים להיות גדולים באופן שרירותי. אין מספיק מקום ב־int64? אין בעיה. מצב זה הוא שימושי מאוד במקרים של ייצוג דברים כמו שארית חלוקה ב־RSA שהיא גדולה משמעותית מ־int64 (גדול בכיוון של ‎2<sup>2048</sup>). ברמה הטכנית יש מספר שלם מרבי ב־DER אבל הוא גדול באופן חריג: האורך של כל שדה ב־DER ניתן לביטוי כסדרה של עד 126 בתים. לכן ה־INTEGER הגדול ביותר שניתן לייצג ב־DER הוא ‎256<sup>(2\*\*1008)</sup>-1. בשביל INTEGER שבאמת אין לו גבולות יש להצפין ב־BER שמאפשר שדות גדולים ללא סוף.
+ה־INTEGER המוכר והטוב. יכול להיות חיובי או שלילי. מה שבאמת חריג ב־INTEGERs של ASN.1 הוא שהם יכולים להיות גדולים באופן שרירותי. אין מספיק מקום ב־int64? אין בעיה. מצב זה הוא שימושי מאוד במקרים של ייצוג דברים כמו שארית חלוקה ב־RSA שהיא גדולה משמעותית מ־int64 (גדול בכיוון של ‎2<sup>2048</sup>). ברמה הטכנית יש מספר שלם מרבי ב־DER אבל הוא גדול באופן חריג: האורך של כל שדה ב־DER ניתן לביטוי כסדרה של עד 126 בתים. לכן ה־INTEGER הגדול ביותר שניתן לייצג ב־DER הוא ‎256<sup>(2\*\*1008)</sup>-1. בשביל INTEGER שבאמת אין לו גבולות יש להצפין ב־BER שמאפשר שדות גדולים ללא סוף.
 
 מחרוזות
 -------

content/he/docs/cert-compat.md

@@ -2,12 +2,12 @@
 title: תאימות אישורים
 slug: certificate-compatibility
 top_graphic: 1
-lastmod: 2021-10-31
+lastmod: 2023-08-02
 show_lastmod: 1
 ---
 
 
-הגורם מכריע ביכולת של פלטפורמה לתקף את האישורים של Let's Encrypt היא האם הפלטפורמה נותנת אמון באישור „ISRG Root X1” מבית ISRG. לפני ספטמבר 2021, חלק מהפלטפורמות יכלו לתקף את האישורים שלנו אפילו אם אינן כוללות את ISRG Root X1 כיוון שהן נותנות אמון באישור „DST Root CA X3” מבית IdenTrust. מאוקטובר 2021 ואילך, רק הפלטפורמות האלו שיכולות לתת אמון ב־ISRG Root X1 תתקפנה את אישורי Let's Encrypt ([למעט Android](/2020/12/21/extending-android-compatibility.html)).
+הגורם מכריע ביכולת של פלטפורמה לתקף את האישורים של Let's Encrypt היא האם הפלטפורמה נותנת אמון באישור „ISRG Root X1” מבית ISRG. לפני ספטמבר 2021, חלק מהפלטפורמות יכלו לתקף את האישורים שלנו אפילו אם אינן כוללות את ISRG Root X1 כיוון שהן נותנות אמון באישור „DST Root CA X3” מבית IdenTrust. מאוקטובר 2021 ואילך, רק הפלטפורמות האלו שיכולות לתת אמון ב־ISRG Root X1 תתקפנה את אישורי Let's Encrypt ([למעט Android][android-compat]).
 
 אם האישור שלך עובר תיקוף על כמה מהפלטפורמות תחת הרשימה „ידועים כנתמכים” אך לא עובר באחרות, יכול להיות שמדובר בהגדרות שגויות מצד השרת. אם נתקלת בתקלה עם פלטפורמות מודרניות, אחד הגורמים הנפוצים ביותר היא כשל באספקת שרשרת האישורים הנכונה. ניתן לבדוק את האתר שלך עם [שרת הבדיקה של SSL Labs](https://www.ssllabs.com/ssltest/). אם המערכת לא הצליחה לזהות את התקלה שלך, ניתן לבקש עזרה ב[פורומים הקהילתיים](https://community.letsencrypt.org/) שלנו.
 
@@ -25,7 +25,7 @@ show_lastmod: 1
 * [Java 7 >= 7u151](https://www.oracle.com/java/technologies/javase/7u151-relnotes.html)
 * [NSS >= 3.26](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.26_release_notes)
 
-דפדפנים (Chrome,‏ Safari,‏ Edge,‏ Opera) בדרך כלל נותנים אמון באותם אישורי העל כמו מערכת ההפעלה עליהם הם פועלים. Firefox חורג מהדרך הזאת: יש לו מאגר אישורי על משלו. בקרוב, גם בגרסאות חדשות של Chrome [יהיה מאגר אישורי על עצמאי](https://www.chromium.org/Home/chromium-security/root-ca-policy).
+דפדפנים (Chrome,‏ Safari,‏ Edge,‏ Opera) בדרך כלל נותנים אמון באותם אישורי העל כמו מערכת ההפעלה עליהם הם פועלים. Firefox חורג מהדרך הזאת: יש לו מאגר אישורי על משלו. בקרוב, גם בגרסאות חדשות של Chrome [יהיה מאגר אישורי על עצמאי][chrome-root-store].
 
 # פלטפורמות שנותנות אמון ב־DST Root CA X3 אך לא ב־ISRG Root X1
 
@@ -62,4 +62,14 @@ show_lastmod: 1
 
 # ISRG Root X2 (אישור עליון חדש מסוג ECDSA) - בקרוב
 
-הגשנו את ISRG Root X2 לתכניות אישורי העל של Microsoft,‏ Apple,‏ Google,‏ Mozilla ו־Oracle כדי שיכללו אותו. ISRG Root X2 כבר נחשב למהימן בקרב חוגים רבים עקב חתימה צולבת מול האישור ISRG Root X1. למידע נוסף, ניתן לעיין ב[רשומה בפורום הקהילתי שלנו](https://community.letsencrypt.org/t/isrg-root-x2-submitted-to-root-programs/149385).
+הגשנו את ISRG Root X2 לתכניות אישורי העל של Microsoft,‏ Apple,‏ Google,‏ Mozilla ו־Oracle כדי שיכללו אותו.
+
+ISRG Root X2 כבר נחשב למהימן בקרב חוגים רבים עקב חתימה צולבת מול האישור ISRG Root X1. בנוסף, מגוון תוכניות כבר הוסיפו את ISRG Root X2 כעוגן מהימן.
+
+למידע נוסף על מצב הכללה, ניתן לעיין ב[רשומה בפורום הקהילתי שלנו](https://community.letsencrypt.org/t/isrg-root-x2-submitted-to-root-programs/149385).
+
+בזמן שאנו ממתינים ש־ISRG Root X2 יהפוך למהימן בצורה נרחבת, אפשר להירשם להשתמש ב־ISRG Root X2 לאישורי ה־ECDSA שלך. למידע נוסף, ניתן לעיין ב[רשומה בפורום הקהילתי שלנו](https://community.letsencrypt.org/t/root-x2-alternate-chain-for-ecdsa-opt-in-accounts/202884).
+
+[android-compat]: /2020/12/21/extending-android-compatibility.html
+
+[chrome-root-store]: https://www.chromium.org/Home/chromium-security/root-ca-policy

content/he/docs/certificates-for-localhost.md

@@ -20,17 +20,17 @@ show_lastmod: 1
 
 לעתים מפתחים מעוניינים להציע יישום טבעי שניתן להוריד ולהשתמש בו לצד אתר כדי להציע תכונות נוספות. כמו למשל, יישומי שולחן העבודה של Dropbox ושל Spotify מנסים לאתר קבצים במכונה שלך, מה שליישומון דרך הדפדפן אסור לבצע. אחת הגישות הנפוצות ליישומים הטבעיים האלה היא להציע שירות מקוון על גבי localhost ולתכנן כך שהיישומון המקוון ישלח אליו בקשות דרך XMLHTTPRequest (XHR) או דרך WebSockets. היישומון המקוון כמעט תמיד משתמש ב־HTTPS, מה שאומר שהדפדפנים ימנעו ממנו לבצע בקשות XHR או WebSockets לכתובות בלתי מאובטחות. מצב כזה נקרא חסימת תוכן מעורב. כדי לתקשר עם היישומון המקוון, היישום הטבעי יצטרך לספק שירות רשת מאובטח.
 
-למרבה המזל, דפדפנים מודרניים [מתייחסים אל ](https://bugs.chromium.org/p/chromium/issues/detail?id=607878) `http://127.0.0.1:8000/‎` כאל כתובת בעלת [„סבירות גבוהה למהימנות”](https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy) כיוון שהיא מפנה לכתובת לולאה פנימית. מובטח לחלוטין שתקשורת שנשלחת אל `127.0.0.1` אינה עוזבת את המכונה שלך ולכן נחשבת אוטומטית כמאובטחת מפני יירוט דרך הרשת. משמעות הדבר היא שהיישום שלך הוא HTTPS וההיצע שלך הוא שירות מקוון ליישום טבעי על גבי `127.0.0.1`, שני אלו יכולים לתקשר בשמחה דרך XHR. לרוע המזל, [localhost עדיין לא זוכה להתייחסות שכזאת](https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02). כמו כן, WebSockets לא מקבלים טיפול שכזה כלפי אף שם שהוא.
+למרבה המזל, דפדפנים מודרניים [מתייחסים אל ][mcb-localhost] `http://127.0.0.1:8000/‎` כאל כתובת בעלת [„סבירות גבוהה למהימנות”][secure-contexts] כיוון שהיא מפנה לכתובת לולאה פנימית. מובטח לחלוטין שתקשורת שנשלחת אל `127.0.0.1` אינה עוזבת את המכונה שלך ולכן נחשבת אוטומטית כמאובטחת מפני יירוט דרך הרשת. משמעות הדבר היא שהיישום שלך הוא HTTPS וההיצע שלך הוא שירות מקוון ליישום טבעי על גבי `127.0.0.1`, שני אלו יכולים לתקשר בשמחה דרך XHR. לרוע המזל, [localhost עדיין לא זוכה להתייחסות שכזאת][let-localhost]. כמו כן, WebSockets לא מקבלים טיפול שכזה כלפי אף שם שהוא.
 
 אולי יפתה אותך לעקוף את המגבלות האלו על ידי הגדרת שם מתחם ב־DNS הגלובלי שבמקרה מתפענח ל־`127.0.0.1` (למשל: `localhost.example.com`), קבלת אישור עבור שם התחום הזה, שליחת האישור הזה והמפתח הפרטי התואם עם היישום שלך ולהנחות את היישומון המקוון שלך לתקשר עם `https://localhost.example.com:8000/‎` במקום עם `http://127.0.0.1:8000/‎`. *לא עושים דבר כזה.* זה יכול לסכן אותך והאישור שלך עלול להישלל.
 
 הגשת שם תחום במקום כתובת IP מאפשרת לתוקף לבצע התקפת אדם בתווך (MitM) על החיפוש ב־DNS ולהזריק תגובה שמצביעה לכתובת IP אחרת. התוסף יכול להתחזות ליישום המקומי ולשלוח תגובות מזויפות ליישום המקוון, שעשויות לפגוע בחשבון שלך מצד היישומון המקוון, בהתאם לאופן התכנון שלו.
 
-הצלחת מתקפת אדם בתווך (MitM) במקרה שכזה אפשרית כיוון שכדי שהמתקפה תצליח, היה עליך לשלוח את המפתח הפרטי לאישור שלך יחד עם היישום הטבעי שלך. משמעות הדבר היא שכל מי שמוריד את היישום הטבעי שלך מקבל עותק של המפתח הפרטי, לרבות התוקף. מצב שכזה נחשב לפגיעה במפתח הפרטי שלך ורשות האישורים (CA) שלך נדרשת לשלול את האישור שלך אם הם מודעים לכך. ל[מגוון רחב של יישומים טבעיים](https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/wsj5zpbbAQAJ) [נשלל האישור](https://groups.google.com/d/msg/mozilla.dev.security.policy/T6emeoE-lCU/-k-A2dEdAQAJ) עקב [שליחת המפתח הפרטי שלהם](https://groups.google.com/d/msg/mozilla.dev.security.policy/pk039T_wPrI/tGnFDFTnCQAJ).
+הצלחת מתקפת אדם בתווך (MitM) במקרה שכזה אפשרית כיוון שכדי שהמתקפה תצליח, היה עליך לשלוח את המפתח הפרטי לאישור שלך יחד עם היישום הטבעי שלך. משמעות הדבר היא שכל מי שמוריד את היישום הטבעי שלך מקבל עותק של המפתח הפרטי, לרבות התוקף. מצב שכזה נחשב לפגיעה במפתח הפרטי שלך ורשות האישורים (CA) שלך נדרשת לשלול את האישור שלך אם הם מודעים לכך. ל[מגוון רחב של יישומים טבעיים][mdsp1] [נשלל האישור][mdsp2] עקב [שליחת המפתח הפרטי שלהם][mdsp3].
 
-לרוע המזל, המגבלה הזאת משאירה יישומים טבעיים רבים ללא אפשרויות טובות ומאובטחות לתקשר עם האתר התואם שלהם. והמצב נהיה אף מורכב יותר אם דפדפנים [מקשיחים את הגישה ל־localhost מהאינטרנט](https://bugs.chromium.org/p/chromium/issues/detail?id=378566) אף יותר.
+לרוע המזל, המגבלה הזאת משאירה יישומים טבעיים רבים ללא אפשרויות טובות ומאובטחות לתקשר עם האתר התואם שלהם. והמצב נהיה אף מורכב יותר אם דפדפנים [מקשיחים את הגישה ל־localhost מהאינטרנט][tighten-access] אף יותר.
 
-כמו כן, יש לשים לב שחשיפת שירות מקוון שמציע מנשקי API טבעיים עם הרשאות ניהוליות מסוכן מטבעו, כיוון שאתרים שלא תכננת להרשות את הגישה שלהם בכל זאת יכולים לגשת אליהם. אם התחלת לצעוד בדרך שכזו, כדאי לקרוא על [Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) (שיתוף משאבים ממקורות צולבים), להשתמש ב־Access-Control-Allow-Origin, ולוודא שנעשה גם שימוש במפענח HTTP שמגן על הזיכרון (memory-safe) כיוון שאפילו מקורות שלא קיבלו הרשאה לגשת יכולים לשלוח בקשות טרום המראה (preflight), שעלולות לנצל חולשות במפענח שלך.
+כמו כן, יש לשים לב שחשיפת שירות מקוון שמציע מנשקי API טבעיים עם הרשאות ניהוליות מסוכן מטבעו, כיוון שאתרים שלא תכננת להרשות את הגישה שלהם בכל זאת יכולים לגשת אליהם. אם התחלת לצעוד בדרך שכזו, כדאי לקרוא על [Cross-Origin Resource Sharing][cors] (שיתוף משאבים ממקורות צולבים), להשתמש ב־Access-Control-Allow-Origin, ולוודא שנעשה גם שימוש במפענח HTTP שמגן על הזיכרון (memory-safe) כיוון שאפילו מקורות שלא קיבלו הרשאה לגשת יכולים לשלוח בקשות טרום המראה (preflight), שעלולות לנצל חולשות במפענח שלך.
 
 # יצירה ומתן אמון באישורים משלך
 
@@ -43,8 +43,18 @@ show_lastmod: 1
       -subj '/CN=localhost' -extensions EXT -config <( \
        printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
 
-לאחר מכן באפשרותך להגדיר את השרת המקומי שלך עם localhost.crt ועם localhost.key, ולהתקין את localhost.crt ברשימת האישורים העליונים המהימנים שלך.
+לאחר מכן אפשר להגדיר את השרת המקומי שלך עם localhost.crt ועם localhost.key, ולהתקין את localhost.crt ברשימת האישורים העליונים המהימנים שלך.
 
-אם מעניין אותך להעניק ממד מוחשי לאישור שלך למטרות פיתוח, ניתן להשתמש ב־[minica](https://github.com/jsha/minica) כדי לייצר אישור עליון מקומי משלך, ולהנפיק אישורי יישות קצה (ידועים בשם עלה) שנחתמו על ידה. לאחר מכן יהיה עליך לייבא את האישור העליון במקום את אישור יישות הקצה שנחתם עצמית.
+אם מעניין אותך להעניק ממד מוחשי לאישור שלך למטרות פיתוח, ניתן להשתמש ב־[minica][minica] כדי לייצר אישור עליון מקומי משלך, ולהנפיק אישורי יישות קצה (ידועים בשם עלה) שנחתמו על ידה. לאחר מכן יהיה עליך לייבא את האישור העליון במקום את אישור יישות הקצה שנחתם עצמית.
 
 ניתן גם לבחור להשתמש בשם תחום עם הפרדה בנקודות, כגון `www.localhost`, על ידי הוספתו ל־‎/etc/hosts ככינוי ל־`127.0.0.1`. זה משנה במעט את איך שהדפדפנים מטפלים באחסון עוגיות.
+
+[mcb-localhost]: https://bugs.chromium.org/p/chromium/issues/detail?id=607878
+[secure-contexts]: https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
+[let-localhost]: https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02
+[mdsp1]: https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/wsj5zpbbAQAJ
+[mdsp2]: https://groups.google.com/d/msg/mozilla.dev.security.policy/T6emeoE-lCU/-k-A2dEdAQAJ
+[mdsp3]: https://groups.google.com/d/msg/mozilla.dev.security.policy/pk039T_wPrI/tGnFDFTnCQAJ
+[tighten-access]: https://bugs.chromium.org/p/chromium/issues/detail?id=378566
+[minica]: https://github.com/jsha/minica
+[cors]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS