דף זה תורגם על ידי Cloud Translation API.

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

Chris Palmer

Matt Gaunt

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

יצירת זוג מפתחות ציבורי/פרטי של RSA בגרסת 2048 ביט.
יצירת בקשה לחתימה על אישור (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:
         ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דירוג בחיפוש

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

ביצועים

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

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

כותרות של הפניות

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

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

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

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

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