מה זה TLS? איך HTTPS מגן על תעבורה

#התשובה הקצרה

TLS ‏(Transport Layer Security) הוא פרוטוקול שעוטף חיבור רשת בהצפנה. HTTPS הוא HTTP רגיל שנשלח דרך חיבור TLS. כשהדפדפן מציג מנעול, הוא עשה שלושה דברים. הוא הצפין את הנתונים. הוא בדק שאיש לא שינה את הנתונים בדרך. והוא בדק שהשרת הוכיח שהוא מחזיק בתעודה מהימנה עבור השם שהוקלד.

הנקודה השלישית היא זו שאנשים קוראים לא נכון. HTTPS אומר עם איזה שרת מדברים. הוא לא אומר כלום על השאלה אם השרת הזה מהימן, ישר או מנוהל היטב.

#למה HTTP רגיל לא מספיק

באיך HTTP עובד, בקשות ותגובות הן הודעות טקסט, ו-HTTP לא עושה כלום כדי להסתיר אותן. כל מכשיר בינך לבין השרת יכול לקרוא אותן: הראוטר הביתי, נקודת הגישה בבית הקפה, ספק האינטרנט והרשתות שבדרך.

צופה פסיבי יכול לקרוא טופס התחברות שנשלח ב-HTTP רגיל. תוקף פעיל בנתיב יכול לעשות יותר. הוא יכול לשנות דף לפני שהוא מגיע אליך, להכניס סקריפט או להחליף הורדה בקובץ ששונה. TLS תוכנן לעצור את שני האיומים. הוא גם נותן ללקוח דרך לבדוק מי עונה, דבר ש-HTTP רגיל אף פעם לא עושה.

#מה TLS 1.3 נותן

הגרסה הנוכחית היא TLS 1.3, שמוגדרת ב-RFC 8446. ‏TLS 1.0 ו-1.1 הוצאו משימוש, כפי ש-RFC 8996 מסביר, ו-TLS 1.2 עדיין פרוס באופן נרחב. גרסה 1.3 הסירה אפשרויות ישנות רבות, כך שיש פחות דרכים להגדיר את לחיצת היד בצורה גרועה.

TLS 1.3 נותן שלוש תכונות.

#סודיות

נתוני האפליקציה מוצפנים במפתחות סשן שרק שתי נקודות הקצה מחזיקות. צופה רואה טקסט מוצפן. הגודל והתזמון של התעבורה נשארים גלויים, אבל התוכן לא.

לחיצת יד מלאה של TLS 1.3 משתמשת בהחלפת מפתחות זמנית. שני הצדדים יוצרים ערכי מפתח זמניים לסשן ומשליכים אותם אחר כך. זה נותן forward secrecy: אם המפתח הפרטי של תעודת השרת דולף שנים מאוחר יותר, סשנים ישנים שהוקלטו אמורים להישאר בלתי קריאים. מפתח שדלף עדיין מאפשר לתוקף להתחזות לשרת מאותה נקודה והלאה, כך ש-forward secrecy מגן על העבר ולא על העתיד.

#שלמות

כל רשומה נושאת תג אימות של צופן AEAD, כמו AES-GCM או ChaCha20-Poly1305. ‏TLS 1.3 מתיר רק צפנים מהסוג הזה. אם תוקף הופך ביט בדרך, בדיקת התג נכשלת והרשומה נדחית.

#אימות שרת

השרת מוכיח שהוא מחזיק במפתח הפרטי שתואם לתעודה שלו. התעודה קושרת את המפתח הציבורי הזה לשם כמו example.com. הלקוח בודק את התעודה ואת שרשרת האמון שמאחוריה, ואז בודק את השם. רוב ההמשך של המאמר עוסק בחלק הזה.

#לחיצת היד, שלב אחר שלב

לחיצת היד קובעת מפתחות ומוכיחה זהות לפני שנתוני HTTP כלשהם עוברים. ב-TLS 1.3 לחיצת היד הרגילה לוקחת סבב אחד. השלבים הבאים הולכים בעקבות RFC 8446 במבט על.

#שלב 1: ה-ClientHello

הלקוח שלך שולח ClientHello. הוא מפרט את גרסאות ה-TLS וחבילות הצפנים שהוא תומך בהן, וכולל key share, הערך הציבורי הזמני של הלקוח להחלפת המפתחות. הוא גם נושא את server name indication ‏(SNI), שם המארח שביקשת, כטקסט גלוי. שרתים שמארחים אתרים רבים צריכים את השם הזה כדי לבחור את התעודה הנכונה.

#שלב 2: ה-ServerHello

השרת בוחר גרסה וחבילת צפנים ושולח key share משלו. כל צד משלב את הערך הפרטי שלו עם הערך הציבורי של הצד השני וגוזר את אותו סוד משותף. צופה שראה את שני הערכים הציבוריים לא יכול לחשב את הסוד הזה. מכאן והלאה לחיצת היד מוצפנת.

#שלב 3: התעודה וההוכחה

השרת שולח את התעודה שלו. ב-TLS 1.2 התעודה הייתה גלויה ברשת. ב-TLS 1.3 היא עוברת בתוך החלק המוצפן של לחיצת היד.

אחר כך השרת שולח הודעת CertificateVerify, חתימה על תמליל לחיצת היד שנעשתה עם המפתח הפרטי של התעודה. זה מוכיח שהשרת מחזיק במפתח במהלך לחיצת היד הזאת. תעודה שהועתקה לבדה חסרת ערך לתוקף. הודעת Finished, ‏MAC על התמליל, סוגרת את החלק של השרת.

#שלב 4: הלקוח בודק ומסיים

הלקוח שלך בודק את שרשרת התעודות, את תאריכי התוקף, את השם שבתעודה מול המארח שביקשת, ואת חתימת ה-CertificateVerify. אם כל הבדיקות עוברות, הלקוח שולח הודעת Finished משלו, ונתוני האפליקציה יכולים לזרום.

אם בדיקה נכשלת, הלקוח עוצר. דפדפן מציג אזהרת תעודה, ו-curl יוצא עם שגיאה. ההודעות האלה הן החלק השימושי ביותר של TLS למתחילים, כי הן מציינות איזו בדיקה נכשלה.

#תעודות ושרשראות אמון

תעודה היא מבנה X.509, ו-RFC 5280 מגדיר את הפרופיל שבשימוש באינטרנט. אלה השדות החשובים ביותר כאן.

לקוחות מודרניים מתעלמים מ-Common Name ‏(CN) שב-Subject בבדיקות שם מארח ומשתמשים ברשימת ה-SAN. מי שמסתכל רק על ה-CN עלול לטעות בהערכת תעודה.

#איך השרשרת נבדקת

שרת כמעט אף פעם לא מציג תעודה שהלקוח יכול לאמת ישירות. בדרך כלל CA ביניים חותם על תעודת הקצה, שמכסה את שם המארח, ו-CA שורש חותם על ה-CA של הביניים. הלקוח סומך על קבוצת שורשים שמגיעה עם מערכת ההפעלה או עם הדפדפן.

הלקוח בונה נתיב מתעודת הקצה לשורש מהימן. בכל חוליה הוא מאמת את החתימה, בודק את תאריכי התוקף ומוודא שהמנפיק רשאי לחתום על תעודות. אחר כך הוא בודק את שם המארח. שתי הבדיקות חייבות לעבור.

כל שורש מהימן יכול, עקרונית, להנפיק תעודה לכל שם. האמון תלוי אפוא בנהלים של הרשויות שבמאגר. בגלל זה ספקים מסירים רשויות שמנפיקות תעודות באופן שגוי.

#ביטול

אפשר לבטל תעודה לפני שהיא פגה, למשל אחרי שהמפתח שלה נפרץ. לקוחות יכולים לבדוק ביטול דרך רשימות ביטול תעודות (CRLs) או OCSP, אבל הבדיקות האלה מתנהגות באופן לא אחיד. חיבור נקי לא מוכיח שתעודה מעולם לא בוטלה.

#על מה TLS לא מגן

#השרת

TLS מאמת את זהות השרת. הוא לא מעריך את ההתנהגות שלו. אתר פישינג יכול להשיג תעודה תקפה עבור דומיין דומה שבשליטתו. המנעול מראה אז שהחיבור מגיע למי שמחזיק במפתח של הדומיין הזה, ולא שהדומיין שייך לבנק שלך. כדאי לקרוא את שם המארח בשורת הכתובת לפני שסומכים על הדף. גם שרת עם תעודה תקינה יכול להיפרץ או להיות מנוהל גרוע.

#מטא־דאטה

TLS מסתיר תוכן, ולא כל עובדה על החיבור. כל מי שנמצא בנתיב עדיין רואה את כתובות ה-IP בכל קצה, את הפורט, את הגודל והתזמון המשוערים של התעבורה ואת שם השרת ב-ClientHello, כי SNI נשלח כטקסט גלוי. Encrypted Client Hello הוא מאמץ של IETF להסתיר את ה-SNI, אבל כדאי לבדוק עד כמה הוא פרוס לפני שמניחים שאתר משתמש בו. שאילתות DNS הן פרוטוקול נפרד וחושפות את השמות שמבוקשים, אלא אם משתמשים ב-DNS מוצפן.

#נקודות הקצה

TLS מגן על נתונים בזמן שהם עוברים בין שתי נקודות קצה. הוא לא מגן על נקודות הקצה. נוזקה במחשב שלך יכולה לקרוא נתונים מפוענחים, ותוסף דפדפן יכול לקרוא כל דף שנפתח. חברה יכולה גם להתקין שורש מהימן משלה על המחשב שלך ולפענח את תעבורת ה-HTTPS שלך דרך proxy לבדיקת תעבורה. הלקוח עובד אז בדיוק כפי שהוגדר, והחלטת האמון שייכת למי ששולט במאגר השורשים.

#מעבדה מעשית: בחינת HTTPS מול example.com

example.com הוא אחד השמות ש-IANA שומר לתיעוד ולדוגמאות. כל פקודה בהמשך מתחברת רק לדומיין example.com. המעבדה לא משנה כלום בשרת ולא צריכה חשבון. צריך טרמינל עם curl ו-openssl. פקודות ה-openssl הורצו עם OpenSSL 3.2.4.

הפלט אצלך יהיה שונה מהפלט שמופיע כאן. כתובות IP משתנות, תעודות מתחדשות ותאריכים מתקדמים.

#שלב 1: קריאת החילופים עם curl

curl -vI https://example.com

הדגל -v מדפיס פרטי חיבור, והדגל -I שולח בקשת HEAD, שמבקשת כותרות בלבד. במחשב שבו השתמשנו למאמר הזה (Windows 11 עם Git Bash, curl 8.12.1, בהרצה ב-8 בנובמבר 2026), השורות הרלוונטיות נראו כך:

* Host example.com:443 was resolved.
* IPv4: 172.66.147.243, 104.20.23.154
* Connected to example.com (172.66.147.243) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: example.com
< HTTP/1.1 200 OK

ה-build הזה של curl משתמש ב-Schannel, ספריית ה-TLS של Windows, והפלט המפורט שלו שונה מזה של curl שנבנה עם OpenSSL. כאן curl לא הדפיס את גרסת ה-TLS, הצופן או שורות התעודה שהמעבדה מבקשת. ב-curl מבוסס OpenSSL מחפשים את השורה שמציינת את גרסת ה-TLS ואת הצופן, ואת בלוק התעודה עם subject, ‏issuer ותאריך תפוגה. השלבים הבאים מקבלים את אותן עובדות מ-openssl.

200 OK אומר שהשרת ענה בתוך חיבור ה-TLS. הכותרות עוברות מוצפנות, ו-curl מפענח אותן מקומית.

#שלב 2: תקציר קצר עם openssl

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null

פלט:

Connecting to 172.66.147.243
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
DONE

קוראים שורה אחר שורה:

• Protocol version: גרסת ה-TLS שסוכמה לחיבור הזה.
• Ciphersuite: ‏AES-256-GCM מגן על הרשומות, ו-SHA-384 משמש ב-key schedule.
• Signature type: ‏ECDSA, האלגוריתם של מפתח התעודה.
• Verification: ‏OK, כלומר השרשרת אומתה מול מאגר האמון של ה-build הזה של openssl.
• Server Temp Key: ‏X25519, החלפת המפתחות הזמנית שנותנת forward secrecy.

הדגל -servername מגדיר SNI. בלעדיו, שרת שמארח כמה אתרים עשוי להחזיר תעודת ברירת מחדל שלא תואמת לשם המבוקש. ההפניה </dev/null סוגרת את הקלט הסטנדרטי כדי שהפקודה תסתיים.

#שלב 3: קריאת שדות התעודה

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

פלט:

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

ה-subject מחזיק רק CN. ה-issuer הוא CA ביניים ולא שורש. חלון התוקף היה פתוח ביום המעבדה והוא נסגר ב-25 בדצמבר 2026. כדאי להשוות את notAfter לתאריך במערכת שלך, כי תעודה שפג תוקפה נכשלת גם כשהשרשרת שלה תקינה.

ה-subject לא מפרט את השמות המכוסים, ולכן מבקשים את רשימת ה-SAN:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

פלט:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

ה-wildcard מכסה שמות כמו www.example.com. הלקוח משווה את הרשימה הזאת למארח שב-URL.

#שלב 4: רשימת השרשרת שהשרת שלח

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'

פלט:

 0 s:CN=example.com
   i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
 1 s:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
   i:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
 2 s:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
   i:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
 3 s:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services

כל שורת s: היא subject וכל שורת i: היא ה-issuer שלו. רשומה 0 היא תעודת הקצה, וכל רשומה מונפקת על ידי זו שאחריה. תעודות יכולות לעבור חתימה צולבת, כך ששרשרת יכולה להגיע לשורש ביותר מנתיב אחד. הלקוח צריך נתיב תקף אחד שמסתיים בשורש שבמאגר שלו.

#שלב 5: אישור שהשרשרת מאומתת

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'

פלט:

Verify return code: 0 (ok)

אפס אומר שמאגר האמון של ה-build הזה של openssl קיבל את השרשרת. ערכים אחרים מציינים כשל מסוים, כמו תעודה שפג תוקפה.

#שלב 6: הכשלה מכוונת של בדיקת השם

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.org -brief </dev/null

פלט, מקוצר:

depth=0 CN=example.com
verify error:num=62:hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Verification error: hostname mismatch

הפקודה עדיין מתחברת רק לדומיין example.com. הדגל -verify_hostname מבקש מ-openssl לבדוק את התעודה מול example.org, שהתעודה לא מכסה. דפדפן מציג כשל מאותו סוג. הבדיקה הזאת היא מה שמונע משרת עם תעודה תקפה לדומיין אחד להיראות כדומיין אחר.

#מה לוקחים מהמעבדה

בחיבור סוכם על TLS 1.3, והלקוח קיבל שרשרת עבור example.com ודחה את אותה תעודה עבור example.org. אף אחת מהתוצאות לא אומרת אם החברה שמאחורי example.com מהימנה. המעבדה מראה שהלקוח שלך הגיע למי שמחזיק במפתח של example.com, ותו לא.

#טעויות נפוצות

• קריאת המנעול כדירוג אמון. הוא אומר שהערוץ מוצפן ושהתעודה עברה בדיקה. הוא לא מדרג את האתר.
• בדיקת ה-CN בלבד. לקוחות מודרניים מתאימים את שם המארח מול רשימת ה-SAN.
• דילוג על אזהרת תעודה בלחיצה. האזהרה אומרת שבדיקה נכשלה. לפני שממשיכים, מבררים איזו.
• הוספת -k או --insecure ל-curl כדי להעלים שגיאה. זה מכבה את הבדיקות שתוארו כאן. משתמשים בזה רק מול שרת בדיקה חד־פעמי, ולעולם לא עם פרטי התחברות אמיתיים.
• כתיבת קוד עם אימות מכובה, כמו verify=False בלקוח HTTP של Python. הנתונים עדיין מוצפנים, אבל למי שענה.

#איך ממשיכים

קוראים את סעיפי הסקירה ולחיצת היד ב-RFC 8446, ואז עוברים על RFC 5280 כדי להכיר את שדות התעודה. קוראים את המדריך של Mozilla ל-TLS בצד השרת ומריצים בדיקת קונפיגורציה מול שרת שבניהולך.

המאמר הבא בסדרה עוסק במפתחות ציבוריים ופרטיים, המתמטיקה שמאחורי התעודה. אם שלב חיפוש השם חדש, כדאי לקרוא קודם את מה זה DNS?, כי התוצאה שלו קובעת לאיזו כתובת לחיצת היד מגיעה.

#מקורות

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Mozilla: Security/Server Side TLS
• OpenSSL documentation: openssl-s_client
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IANA: Example domains