הפעלת HTTPS בשרתים

Chris Palmer
Chris Palmer

בדף הזה מפורטות הנחיות להגדרת HTTPS בשרתים, כולל השלבים הבאים:

  • יצירת זוג מפתחות ציבורי/פרטי של RSA 2048 ביט.
  • יצירת בקשה לחתימה על אישור (CSR) שמטמיעה את המפתח הציבורי שלך.
  • לשתף את הודעת CSR עם רשות האישורים (CA) כדי לקבל אישור סופי או שרשרת אישורים.
  • מתקינים את האישור הסופי במקום שלא נגיש באינטרנט, כמו /etc/ssl (Linux ו-Unix) או בכל מקום שבו נדרש IIS (ב-Windows).

יצירת מפתחות ובקשות לחתימה על אישורים

בקטע זה נעשה שימוש בתוכנת שורת הפקודה opensl, הכוללת את רוב מערכות Linux, BSD ו-Mac OS X, כדי ליצור מפתחות פרטיים וציבוריים ונציג שירות לקוחות.

יצירת זוג מפתחות ציבורי/פרטי

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

כדי ליצור זוג מפתחות RSA, משתמשים בפקודה הבאה:

openssl genrsa -out www.example.com.key 2048

מתקבל הפלט הבא:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

יצירת בקשה לחתימה על אישור

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

מריצים את הפקודה הבאה:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

יוצר את הפלט הבא:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

כדי לוודא את חוקיות ה-CSR, מריצים את הפקודה הבאה:

openssl req -text -in www.example.com.csr -noout

התגובה אמורה להיראות כך:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

שלח את ה-CSR לרשות אישורים

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

שולחים את נציג שירות הלקוחות ל-CA ופעלו לפי ההוראות שלו כדי לקבל את האישור הסופי או את שרשרת האישורים.

רשויות אישורים שונות גובה סכומי כסף שונים על השירות לערוב למפתח הציבורי שלכם.

יש גם אפשרויות למיפוי המפתח ליותר משם DNS אחד, כולל כמה שמות ייחודיים (למשל כל example.com, www.example.com, example.net ו-www.example.net) או שמות עם תווים כלליים כמו *.example.com.

מעתיקים את האישורים לכל שרתי הקצה במקום שלא נגיש באינטרנט, כמו /etc/ssl (Linux ו-Unix) או בכל מקום שבו הם צריכים אותם על ידי IIS (Windows).

הפעלת HTTPS בשרתים

הפעלת HTTPS בשרתים היא שלב קריטי בשמירה על אבטחה לדפי האינטרנט.

  • השתמש בכלי תצורת השרת של Mozilla כדי להגדיר את השרת לתמיכה ב-HTTPS.
  • כדאי לבדוק את האתר באופן קבוע באמצעות בדיקת שרת ה-SSL של Qualys כדי לוודא שמקבלים לפחות A או A+.

בשלב הזה עליכם לקבל החלטה תפעולית חיונית. בוחרים אחת מהאפשרויות הבאות:

  • צריך להקצות כתובת IP ייחודית לכל שם מארח ששרת האינטרנט שלכם מציג ממנו את התוכן.
  • שימוש באירוח וירטואלי מבוסס-שם.

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

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

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

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

הפיכת כתובות URL בתוך האתר ליחסיות

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

מוודאים שכתובות URL בתוך האתר וכתובות URL חיצוניות לא תלויות בפרוטוקול ספציפי. צריך להשתמש בנתיבים יחסיים או לא לכלול את הפרוטוקול כמו ב-//example.com/something.js.

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

מעקב אחר קישורים מבוססי HTTP אל דפים אחרים באתר יכול גם לשדרג לאחור את חוויית המשתמש מ-HTTPS ל-HTTP. כדי לפתור את הבעיה, צריך להפוך את כתובות ה-URL בתוך האתר ליחסיות ככל האפשר. לשם כך צריך להגדיר אותן כיחסיות בפרוטוקול (בלי פרוטוקול, החל ב-//example.com) או יחסיות למארח (שמתחילות בנתיב, כמו /jquery.js).

מה מותר לעשות
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
שימוש בכתובות URL יחסיות בתוך האתר.
מה מותר לעשות
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
לחלופין, אפשר להשתמש בכתובות URL פנימיות יחסית לפרוטוקולים.
מה מותר לעשות
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
כשהדבר אפשרי, כדאי להשתמש בכתובות URL מסוג HTTPS עבור קישורים לאתרים אחרים.

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

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

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

אם האתר תלוי בסקריפטים, בתמונות או במשאבים אחרים של צד שלישי, כמו CDN או jquery.com, יש לך שתי אפשרויות:

  • השתמש בכתובות URL יחסיות-לפרוטוקול עבור המשאבים האלה. אם הצד השלישי לא תומך ב-HTTPS, בקשו ממנו לעשות זאת. רובם כבר עושים זאת, כולל jquery.com.
  • הפעלת המשאבים משרת שנמצא בשליטתכם, עם HTTP וגם HTTPS. בדרך כלל זה כדאי לעשות את זה, כי כך יש לכם שליטה טובה יותר במראה, בביצועים ובאבטחה של האתר, ואתם לא צריכים לסמוך על צד שלישי שישמור על אבטחת האתר.

הפניה אוטומטית מ-HTTP ל-HTTPS

על מנת להנחות מנועי חיפוש להשתמש ב-HTTPS כדי לגשת לאתר שלך, עליך להוסיף קישור קנוני בראש כל דף באמצעות תגי <link rel="canonical" href="https://…"/>.

הפעלת Strict Transport Security וקובצי cookie מאובטחים

בשלב הזה אתם מוכנים 'לנעול' את השימוש ב-HTTPS:

  • השתמשו ב-HTTP Strict Transport Security (HSTS) כדי להימנע מהעלות של ההפניה האוטומטית מסוג 301.
  • דגל האבטחה תמיד מוגדר בקובצי Cookie.

קודם כול, השתמשו ב-Strict Transport Security כדי לומר ללקוחות שהם צריכים תמיד להתחבר לשרת באמצעות HTTPS, גם אם הם עוקבים אחר ההפניה ל-http://. דרך זו מבטלת מתקפות כמו Stripping של SSL, מונעת את העלות הלוך ושוב של 301 redirect שהפעלתם ב-Redirect HTTP to HTTPS.

כדי להפעיל את HSTS, צריך להגדיר את הכותרת Strict-Transport-Security. דף HSTS של OWASP מכיל קישורים להוראות לסוגים שונים של תוכנות שרת.

רוב שרתי האינטרנט מציעים אפשרות דומה להוספת כותרות מותאמות אישית.

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

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

רוב שרתי האינטרנט מציעים תכונה פשוטה של הפניה מחדש. משתמשים ב-301 (Moved Permanently) כדי לציין למנועי חיפוש ולדפדפנים שגרסת ה-HTTPS היא קנונית, ולהפנות את המשתמשים מ-HTTP לגרסת ה-HTTPS של האתר.

דירוג בחיפוש

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

ביצועים

כשהשכבות של התוכן והאפליקציה מכוונים היטב (לעיון בספרים של סטיב סודרס), החששות לגבי הביצועים הנותרים של TLS (אבטחת שכבת התעבורה) בדרך כלל קטנים יחסית לעלות הכוללת של האפליקציה. אפשר גם להפחית את העלויות האלה ולהקטין אותן. לקבלת ייעוץ לגבי אופטימיזציה של TLS, ראו את המאמר High Performance Browser Networking מאת Ilya Gragorik, וכן ה-OpenSSL Cookbook של איוואן ריסטיקה וSSL ו-TLS חסינים מפני תבליטים.

במקרים מסוימים, השימוש ב-TLS יכול לשפר את הביצועים, בעיקר כתוצאה מהפעלת HTTP/2. למידע נוסף, עיינו בהרצאה של כריס פאלמר בנושא HTTPS ו-HTTP/2 בכנס Chrome Dev Summit 2014.

כותרות של גורמים מפנים

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

  • יש להעביר את שאר האתרים ל-HTTPS. אם האתרים של הגורמים המפנים משלימים את הקטע הפעלת HTTPS בשרתים של המדריך, תוכלו לשנות את הקישורים באתר שלכם מ-http:// ל-https://, או להשתמש בקישורים יחסיים לפרוטוקול.
  • כדי לעקוף מגוון בעיות בכותרות של גורמים מפנים, אפשר להשתמש בתקן המדיניות החדש של הגורמים המפנים.

הכנסות מפרסום

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

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