הפעלת 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:
         ...

שליחת נציג שירות הלקוחות שלך לרשות אישורים

רשויות אישורים (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 אחרים, סוכני המשתמש לא שולחים את הכותרת של הגורם המפנה. אם הבעיה הזו נתקלת, יש כמה דרכים לפתור אותה:

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

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

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

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