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

Chris Palmer
Chris Palmer

בדף הזה מוסבר איך להגדיר HTTPS בשרתים, כולל השלבים הבאים:

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

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

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

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

כדי להתחיל, יוצרים זוג מפתחות 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 באימייל. חלק מהרשויות, או המפיצים שלהן, עשויים להפוך חלק מהתהליך או את כולו לאוטומטי, כולל, במקרים מסוימים, יצירת זוג מפתחות ויצירת 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 באמצעות Qualys' SSL Server Test. האתר צריך לקבל ציון 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 לקישורים לאתרים אחרים, במידת האפשר.

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

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

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

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

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

הפניית HTTP ל-HTTPS

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

הפעלת אבטחת תעבורה קפדנית וקובצי cookie מאובטחים

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

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

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

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

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

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

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

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

דירוג בחיפוש

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

ביצועים

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

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

כותרות Referer

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

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

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

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

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