יציאה 443: HTTPS

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

יציאה 443 היא הדרך שבה תיקנו את ההנחה הזו מבלי לבנות מחדש את האינטרנט מאפס.

HTTP עטוף בשריון

HTTPS הוא לא פרוטוקול שונה מ-HTTP — הוא HTTP עטוף ב-Transport Layer Security (TLS). פורמט ההודעות נשאר זהה; רק הנראות משתנה. חשבו על גלויות לעומת מעטפות אטומות.

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

ביציאה 80, תוקף שמנטר את תעבורת הרשת רואה הכל: שמות משתמש, סיסמאות, מספרי כרטיסי אשראי, הודעות פרטיות, שאילתות רפואיות, המאמרים שאתה קורא בשעה 2 לפנות בוקר. ביציאה 443, אותו תוקף רואה רעש מוצפן.

הטרנספורמציה

המעבר מ-"HTTPS לבנקים" ל-"HTTPS לכל דבר" הוא אחת מהפיכות האבטחה המוצלחות ביותר בהיסטוריית האינטרנט.

כמה כוחות האיצו אותה. בשנת 2014, גוגל הכריזה ש-HTTPS יחזק את הדירוג בתוצאות החיפוש — פתאום לאבטחה היה מקרה עסקי מעבר ל"עשיית הדבר הנכון". בשנת 2016, Let's Encrypt השיקה, ומציעה תעודות TLS מהימנות בחינם עם חידוש אוטומטי. המחסומים הכספיים והטכניים שהחזיקו אתרים קטנים על HTTP נעלמו בין לילה.

יצרני הדפדפנים הגבירו את הלחץ. אינדיקטורים עדינים של אבטחה התפתחו לאזהרות בולטות של "לא מאובטח". HTTP הפך לדבר שדרש הסבר.

התוצאה: יותר מ-93% מתעבורת הרשת משתמשת כיום ב-HTTPS. דפדפנים מרכזיים מנסים HTTPS ראשון אפילו כאשר אתה מקליד שם דומיין פשוט. השאלה עברה מ"האם עלינו להשתמש ב-HTTPS?" ל"מדוע לא?"

מדוע דפדפנים מזהירים לגבי כל אתר HTTP

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

קהילת האבטחה דחתה את הטיעון הזה, והסיבות חשובות.

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

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

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

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

תעודות ואמון

הפעלת שירות HTTPS מחייבת תעודת TLS חתומה על ידי רשות אישורים מהימנה. התעודה מוכיחה את זהות השרת ומספקת את המפתח הציבורי לביסוס ההצפנה.

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

ניהול תעודות נהג להיות מעיק: בקשות ידניות, חידוש שנתי, לעיתים מצבי חירום בשעה 3 לפנות בוקר כאשר מישהו שכח לחדש. פרוטוקול ACME (שחלוצה על ידי Let's Encrypt) שינה זאת. שרתים כיום מבקשים, מאמתים, מתקינים ומחדשים תעודות אוטומטית. האדם לא נוגע בזה בכלל.

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

מעבר לדפדפנים

HTTPS חשוב בכל מקום, לא רק בדפדפני אינטרנט. ממשקי API, אפליקציות מובייל, מכשירי IoT, תקשורת שרת-לשרת — כולם דורשים יותר ויותר HTTPS כבסיס.

ממשקי API אוכפים HTTPS מכיוון שאסימוני אימות שנשלחים ב-HTTP ניתנים ליירוט בקלות. אסימון גנוב אחד יכול לפגוע במערכת שלמה. מסגרות תאימות כמו PCI DSS, HIPAA ו-GDPR מחייבות הצפנה לנתונים במעבר.

אפליקציות מובייל עומדות בפני אתגר מיוחד: בניגוד לדפדפנים, אין להן ממשק משתמש סטנדרטי לאזהרות אבטחה. משתמשים לא יכולים לדעת אם אפליקציה מבצעת חיבורים לא מאובטחים. פלטפורמות מובייל מודרניות מתמודדות עם זה על ידי דרישת HTTPS כברירת מחדל — iOS דרך App Transport Security, Android דרך Network Security Configuration. HTTP דורש הסכמה מפורשת.

תקשורת מכונה-למכונה משתמשת לעיתים קרובות ב-mutual TLS, שבו הן הלקוח והן השרת מציגים תעודות לאמת זה את זה. אין סיסמאות או מפתחות API לגנוב. לסביבות בטחון גבוה, certificate pinning מקודד תעודות צפויות בתוך אפליקציות, וחוסם התקפות man-in-the-middle אפילו אם רשות אישורים נפגעת.

הלקח

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

האינטרנט תוכנן לפתיחות. יציאה 443 עשתה את הפתיחות הזו ברת-קיום.

שאלות נפוצות על יציאה 443 ו-HTTPS

מדוע יציאה 443 משמשת ספציפית ל-HTTPS?

מספרי יציאות מתחת ל-1024 הם "יציאות ידועות היטב" שהוקצו על ידי IANA לשירותים סטנדרטיים. יציאה 443 הוגדרה ל-HTTPS כאשר הפרוטוקול תוקנן בשנת 1994. הבחירה הייתה שרירותית במידה מסוימת — מה שחשוב הוא שכולם מסכימים להשתמש באותה יציאה, כך שדפדפנים יודעים לאן להתחבר לתעבורה מאובטחת.

האם ניתן להשתמש ב-HTTPS ביציאה אחרת?

כן, אבל זה יוצר חיכוך. אם אתה מפעיל HTTPS ביציאה 8443, משתמשים חייבים להקליד https://example.com:8443 במפורש. דפדפנים מניחים יציאה 443 עבור כתובות URL של HTTPS ללא יציאה מצוינת. יציאות לא סטנדרטיות נפוצות בסביבות פיתוח אך נדירות בייצור.

האם HTTPS מאט אתרים?

לא באופן משמעותי עוד. לחיצת יד TLS מוסיפה שבריר שנייה לחיבור הראשוני, אבל אופטימיזציות מודרניות (TLS 1.3, חידוש סשן, ריבוב HTTP/2) מזערו את העומס הזה. אתרים רבים הם למעשה מהירים יותר ב-HTTPS מכיוון ש-HTTP/2 — שמספק שיפורי ביצועים משמעותיים — נתמך רק על פני חיבורים מוצפנים בדפדפנים.

מה סמל המנעול אכן אומר?

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

מדוע חלק מאתרי HTTPS עדיין מציגים אזהרות?

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