ההגעה de OpenSSL 4.0 מסמן פריצת דרך משמעותית שדרוג גרסה משמעותי זה אינו סמלי בלבד: הוא מביא שינויים לא תואמים, תכונות חדשות המתמקדות בפרטיות ואבטחה עתידית, ויציאה לטכנולוגיות שהיו מיושנות במשך שנים. זוהי ספריית עיון עבור SSL/TLS וקריפטוגרפיה, הנמצאת בשימוש נרחב בשרתי אינטרנט, יישומים ארגוניים והתקני רשת.
עבור מנהלי מערכת, מנהלי אבטחת סייבר ומפתחים, גרסה זו מייצגת נקודת מפנה בכל הנוגע לעדכון תשתיותהוא מציג שיפורים כגון Encrypted Client Hello ותמיכה מתקדמת בקריפטוגרפיה פוסט-קוונטית, אך גם מסיר תמיכה בפרוטוקולים מדור קודם, מערכת המנוע ומספר ממשקי API, מה שמאלץ סקירה של תהליכי הקוד והקומפילציה לפני ביצוע המעבר.
תכונות חדשות עיקריות של OpenSSL 4.0
OpenSSL 4.0 מוצג כעדכון משמעותי, עם דגש ברור על לחזק את הפרטיות, למודרניזציה של בסיס הקוד ולנקות מטען מדור קודםצוות הפרויקט ניצל את שינוי הגרסה העיקרי כדי להכניס שינויים שאינם תואמים, להסיר תמיכה בפלטפורמות שוליים ולהתאים את התנהגות ברירת המחדל של מספר רכיבים פנימיים.
בין השינויים הבולטים ביותר נמנים שילוב של Encrypted Client Hello (ECH), הרחבת קטלוג האלגוריתמים לסביבות פוסט-קוונטיות, הוצאה משימוש וביטול של פונקציות היסטוריות בטיפול בתעודות וזמנים של X.509, וכן סקירת אפשרויות קומפילציה, סקריפטים ויעדי בנייה במערכות הפעלה שונות.
פרטיות משופרת עם Encrypted Client Hello (ECH)
אחת ההתקדמויות המדוברות ביותר היא שילובן של תואם ל-RFC 9849 עבור לקוח מוצפן HelloECH מאפשר להצפין את הודעת Client Hello של TLS, כך שצופה פסיבי ברשת לא יוכל לגשת ל-Server Name Indication (SNI), כלומר, שם השרת שאליו הלקוח מתחבר.
שינוי זה רלוונטי במיוחד כאשר הגנת פרטיות ומטא-נתונים של חיבור יש לה חשיבות גוברת במסגרת הרגולטורית ובמדיניות של ארגונים רבים. אימוץ ECH מסייע להפחית את היכולת של צדדים שלישיים ליצור פרופיל של תעבורת TLS על ידי זיהוי דומיינים ספציפיים אליהם ניגשים משתמשים וחברות.
עם OpenSSL 4.0, מפתחים המיישמים ECH יוכלו הסתר מידע רגיש מלחיצת היד הראשוניתזה מקשה על בדיקה פסיבית ומגביר את רמת הסודיות של חיבורים, הן בשירותים ציבוריים והן בסביבות תאגידיות שבהן תאימות לתקנות והגנה על נתונים מקבלות עדיפות.
להתראות ל-SSLv3, SSLv2 Client שלום, ולמערכת המנוע
הגרסה החדשה שוברת באופן חד משמעי חלק מעברו של הפרוטוקול, שכן מסיר את התמיכה ב-SSLv3SSLv3, תקן שנחשב לא מאובטח במשך שנים והושבת כברירת מחדל ב-OpenSSL מאז גרסה 1.1.0, יופסק בהדרגה. לכן, כל יישום שעדיין היה תלוי ב-SSLv3 יצטרך לעבור ל-TLS מודרני כדי שיוכל לעבוד עם ענף 4.0.
גם הנעלם לקוח SSLv2 שלום תמיכהתכונה זו, אשר נשמרה לצורך תאימות היסטורית אך הייתה לחלוטין מחוץ לשיטות האבטחה המומלצות, מוסרת כעת. הסרתה מסייעת להפחית את משטח התקיפה ולפשט את הקוד, תוך התאמת OpenSSL לדרישות הנוכחיות להצפנה חזקה בתשתית.
שינוי מבני נוסף הוא ביטול מוחלט של ממשק API של מנוע המשמש לשילוב חומרה ותוכנה קריפטוגרפיים חיצונייםהחל מ-OpenSSL 4.0, אפשרות הקומפילציה ללא מנוע הופכת ליחידה הזמינה, והמאקרו OPENSSL_NO_ENGINE תמיד קיים. זה מחייב סקירה של יישומים שניצלו מנועים מותאמים אישית עבור משימות כגון האצה קריפטוגרפית או שימוש במודולי HSM.
במקביל, מתבצעים גם קיצוצים. שיטות מותאמות אישית שעברו בירושה מ-EVP_CIPHER, EVP_MD, EVP_PKEY ו-EVP_PKEY_ASN1, יחד עם שיטות ניהול גרסאות SSL/TLS מיושנות ופונקציות ניהול מצבי שגיאות (כגון ERR_get_state() והווריאציות שלו להסרת מצבים), מאחדים API נקי יותר העולה בקנה אחד עם הצרכים הנוכחיים.
דחיפה לקריפטוגרפיה פוסט-קוונטית ואלגוריתמים חדשים
במבט קדימה, OpenSSL 4.0 מקדמת את האסטרטגיה שלה ל... היערכות לאיומים הנובעים ממחשוב קוונטיהגרסה מציגה יכולות קריפטוגרפיה ודייג היברידיות חדשות, שמטרתן לחזק את חילופי המידע המרכזיים כנגד התקפות פוטנציאליות בתרחיש פוסט-קוונטי.
בין התכונות החדשות נמצאת ה- curveSM2MLKEM768 של קבוצת החלפת מפתחות היברידית, המשלבת אלמנטים קלאסיים עם סכמות פוסט-קוונטיות, כמו גם את אלגוריתם טביעות האצבע ML-DSA-MU ואת פונקציית cSHAKE לפי NIST SP 800-185. אלמנטים אלה מרחיבים את האפשרויות לתכנון פרוטוקולים עמידים יותר להתקדמות קריפטאנליטית עתידית.
בנוסף, הפרויקט מוסיף תמיכה בחילופי מפתחות FFDHE מוסכמת דרך TLS 1.2זה פועל בהתאם להנחיות שנקבעו ב-RFC 7919. זה מאפשר ליישומים שעדיין פועלים עם TLS 1.2 ליהנות מפרמטרי Diffie-Hellman משופרים של קבוצות סופיות, מה שמעלה את רמת האבטחה בתרחישים שבהם שדרוג מיידי ל-TLS 1.3 אינו אפשרי.
שינויים והתנהגות של API המשפיעים על אינטגרטורים
עבור אלו המתחזקים יישומים המקושרים ל-OpenSSL, גרסה 4.0 מציגה שינויים ישירים ב-API שעלולים לשבור מערכות גיבוי קיימותאחת השינויים המרכזיים היא שסוג ASN1_STRING הופך לאטום, מה שמגביל את הגישה הישירה למבנה הפנימי שלו וכופה על השימוש בפונקציות ברמה גבוהה.
פונקציות רבות, במיוחד אלו הקשורות ל עיבוד תעודות X.509 משלב כעת קוד זיהוי (const qualifiers) בחתימות שלהם, תוך התאמת הסמנטיקה של אי-היכולת לשינוי וכפיית התאמות בקוד שעשו הנחות פחות מחמירות. זה יכול ליצור אזהרות או שגיאות קומפילציה בפרויקטים שאינם מעדכנים את ההגדרות המתאימות.
בתחום ניהול הזמן, היו פונקציות מיושנות הוכרזו כגון X509_cmp_time(), X509_cmp_current_time() ו-X509_cmp_timeframe()השימוש המומלץ כעת הוא X509_check_certificate_times(), הכולל התאמת שגרות אימות אישורים שהסתמכו בעבר על הפונקציות הישנות.
נקודה רלוונטית נוספת היא ש libcrypto מפסיק לבצע ניקוי גלובלי של נתונים שהוקצו באמצעות atexit(). במקום זאת, OPENSSL_cleanup() מופעל כמשמיד גלובלי או לא מופעל כברירת מחדל, בהתאם לתצורה. זה יכול להשפיע על יישומים שהסתמכו על ניקוי אוטומטי בסיום התהליך, מה שכופה ניהול מחזור חיי משאבים מפורש יותר.
בנוסף, BIO_f_reliable(), תכונה ש זה היה שבור מאז ענף 3.0 ועכשיו הוא נעלם ללא תחליף ישירפרויקטים שעדיין משתמשים בו יצטרכו לעצב מחדש את הלוגיקה המשויכת או לאמץ פרימיטיבים אחרים מהספרייה כדי לכסות צרכים דומים.
קפדנות רבה יותר באימות תעודות ובגזירת מפתחות
OpenSSL 4.0 מחזק את אימות קפדני של אישורי X.509 כאשר X509_V_FLAG_X509_STRICT מופעלכאשר דגל זה מופעל, מתבצעות בדיקות נוספות על ההרחבה AKID (Authority Key Identifier), מה שמחמיר את קריטריוני האימות ומתיישר עם שיטות אבטחה תובעניות יותר.
בתהליך אימות רשימות ביטול (CRL), הגרסה החדשה מוסיפה בקרות נוספות כדי להבטיח שהאימות של אישורים מבוטלים יהיה יסודי יותרשינויים אלה משפיעים על סביבות בהן ניהול PKI רגיש במיוחד, כגון מנהלים ציבוריים, בנקים או תאגידים גדולים התלויים בשרשראות אמון חזקות.
הם גם מוצגים מגבלות תחתונות חובה על השימוש ב-PKCS5_PBKDF2_HMAC בעת שימוש בספק FIPSהתאמה זו מבקשת להימנע מתצורות חלשות מדי בגזירת מפתחות מסיסמאות, מה שבפועל כופה שימוש בפרמטרים חזקים מינימלית בסביבות בהן נדרשת תאימות FIPS, דבר נפוץ מאוד במגזרים קריטיים.
הגדרות קומפילציה, פלטפורמות נתמכות וכלים
מבחינת קומפילציה ותמיכה בפלטפורמה, OpenSSL 4.0 נוקט צעדים לקראת... תצורה מודרנית ופשוטה יותרהפרויקט מבטל כברירת מחדל את התמיכה בעקומות אליפטיות מיושנות ב-TLS, כפי שצוין ב-RFC 8422, כמו גם את השימוש בעקומות אליפטיות מפורשות. עם זאת, אפשרויות תצורה נותרות זמינות עבור אלו הזקוקים להפעלתן מחדש מסיבות תאימות מזדמנות.
לגבי יעדי הבנייה, זה היה הם מסירים את גרסאות darwin-i386 ו-darwin-ppcזה באופן רשמי לא כולל מערכות אפל ישנות מאוד המבוססות על ארכיטקטורות i386 ו-PowerPC/PPC64. בפועל, זה לא אמור להשפיע על רוב הפריסות הנוכחיות, שבהן פלטפורמות אלו מיושנות כבר זמן מה, אך זה מקדם את הסרתן מהתמיכה המרכזית.
בנוגע לכלים, הסקריפט ההיסטורי מוסר, ויצירת אינדקסי גיבוב עבור אישורים בספריות היא כעת השיטה המומלצת. בנוסף, עבור התקנות FIPS, האפשרות `-defer_tests` הוצגה בכלי `openssl fipsinstall`, המאפשרת דחיית בדיקות אוטומטיות מסוימות, מה שיכול להקל על פריסות בסביבות עם אילוצי זמן אתחול.
במערכות Windows, העדכון מוסיף אפשרות לבחור בין קישור סטטי או דינמי של זמן הריצה של Visual C++גמישות זו שימושית למפתחים ולצוותי DevOps שאורזים יישומים עבור תרחישי הפצה שונים, מכיוון שהם יכולים להתאים את סוג זמן הריצה בהתבסס על דרישות תאימות או גודל הקבצים הבינאריים.
השפעה על ארגונים ומפתחים
בהקשר שבו חלק ניכר מתשתית האינטרנט והשירותים הקריטיים מסתמכים על OpenSSL, גרסה 4.0 מייצגת שינוי אסטרטגי הדורש תכנוןארגונים ציבוריים, ספקי ענן, מוסדות פיננסיים וחברות טכנולוגיה צריכים להעריך בקפידה את ההשפעות של שינויים ב-API ופרישות פרוטוקולים, במיוחד על מערכות מדור קודם או יישומים שתחזוקהם גרוע.
ניתן לראות את שילוב ה-ECH ואת חיזוק הקריפטוגרפיה הפוסט-קוונטית כ... הזדמנויות להעלות את רמת ברירת המחדל של ההגנהאך יחד עם זאת, הם דורשים בדיקות יסודיות בסביבות טרום-ייצור. במקרים רבים, יהיה צורך לתאם צוותי פיתוח, אבטחה ותפעול כדי להבטיח שהמעבר לא יגרום לשבירת שירותים או יכניס רגרסיות.
עבור פרויקטים בקוד פתוח המסתמכים במידה רבה על OpenSSL, ההתאמה תכלול התאמת חתימות פונקציות, סקירת השימוש בסוגים אטומים כעת ולהחליף רכיבים שאינם בשימוש כגון מנועי תזמון או פונקציות של X.509. היתרון הוא שלאחר העדכון, פרויקטים אלה ייהנו מיסוד קריפטוגרפי התואם יותר לתקנים הנוכחיים ועם פחות חוב טכני.
בסך הכל, OpenSSL 4.0 ממצב את עצמו כ... גרסת ניקוי, מודרניזציה והכנה לטווח הבינוני והארוךזה דורש השקעה במאמץ במיגרציה, אך מציע בתמורה שיפורים ברורים בפרטיות, באבטחה ובעקביות הפנימית של הספרייה, היבטים מרכזיים להמשך תמיכה בתשתית הדיגיטלית על יסודות קריפטוגרפיים איתנים.
