ทำไมไม่ใช้ HTTPS สำหรับทุกสิ่ง?

หากฉันกำลังตั้งค่าเซิร์ฟเวอร์และมีใบรับรอง SSL เหตุใดฉันจึงไม่ใช้ HTTPS สำหรับทั้งไซต์แทนที่จะใช้เพียงการซื้อ / การเข้าสู่ระบบ ฉันคิดว่ามันจะสมเหตุสมผลกว่าที่จะเข้ารหัสทั้งไซต์และปกป้องผู้ใช้ทั้งหมด มันจะป้องกันไม่ให้เกิดปัญหาเช่นการตัดสินใจว่าอะไรจะต้องมีความปลอดภัยเพราะทุกอย่างจะเป็นเช่นนั้นและไม่ใช่เรื่องที่ไม่สะดวกสำหรับผู้ใช้

หากฉันใช้ HTTPS เป็นส่วนหนึ่งของไซต์อยู่แล้วเหตุใดฉันจึงไม่ต้องการใช้กับทั้งไซต์

นี่เป็นคำถามที่เกี่ยวข้อง: เหตุใดจึงใช้ https สำหรับล็อกอินเท่านั้น แต่คำตอบไม่น่าพอใจ คำตอบจะถือว่าคุณไม่สามารถใช้ https กับทั้งไซต์ได้

ฉันนึกเหตุผลได้สองสามข้อ

• บางเบราว์เซอร์อาจไม่รองรับ SSL
• SSL อาจลดประสิทธิภาพลงบ้าง หากผู้ใช้กำลังดาวน์โหลดไฟล์สาธารณะขนาดใหญ่อาจมีภาระของระบบในการเข้ารหัสไฟล์เหล่านี้ทุกครั้ง

นอกเหนือจากเหตุผลอื่น ๆ (โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับประสิทธิภาพ) คุณสามารถโฮสต์โดเมนเดียวต่อที่อยู่ IP * เมื่อใช้ HTTPS

เซิร์ฟเวอร์เดียวสามารถรองรับหลายโดเมนใน HTTP ได้เนื่องจากส่วนหัวของเซิร์ฟเวอร์ HTTP ช่วยให้เซิร์ฟเวอร์ทราบว่าจะตอบสนองด้วยโดเมนใด

ด้วย HTTPS เซิร์ฟเวอร์ต้องเสนอใบรับรองให้กับไคลเอ็นต์ในระหว่างการจับมือ TLS ครั้งแรก (ซึ่งก่อน HTTP จะเริ่ม) ซึ่งหมายความว่ายังไม่ได้ส่งส่วนหัวของเซิร์ฟเวอร์ดังนั้นจึงไม่มีทางที่เซิร์ฟเวอร์จะทราบได้ว่าโดเมนใดที่ถูกร้องขอและใบรับรองใด (www.foo.com หรือ www.bar.com) ที่จะตอบสนอง

* เชิงอรรถ: ในทางเทคนิคคุณสามารถโฮสต์หลายโดเมนได้หากโฮสต์ไว้บนพอร์ตที่แตกต่างกัน แต่โดยทั่วไปแล้วไม่ใช่ตัวเลือก คุณยังสามารถโฮสต์หลายโดเมนได้หากใบรับรอง SSL ของคุณมีไวด์การ์ด ตัวอย่างเช่นคุณสามารถโฮสต์ทั้ง foo.example.com และ bar.example.com ด้วยใบรับรอง * .example.com

SSL / TLS ไม่ได้ใช้บ่อยพอ ต้องใช้ HTTPS สำหรับทั้งเซสชันโดยจะไม่สามารถส่งรหัสเซสชันผ่าน HTTP ได้ หากคุณใช้ https สำหรับการเข้าสู่ระบบเท่านั้นแสดงว่าคุณละเมิดOWASP 10 อันดับแรกสำหรับปี 2010 "A3: Broken Authentication and Session Management" อย่างชัดเจน

ทำไมไม่ส่งไปรษณีย์หอยทากทุกฉบับในซองทึบแสงป้องกันการงัดแงะทางไปรษณีย์ลงทะเบียน? ใครบางคนจากที่ทำการไปรษณีย์มักจะได้รับการดูแลเป็นการส่วนตัวดังนั้นคุณจึงมั่นใจได้ว่าไม่มีใครแอบดูจดหมายของคุณ เห็นได้ชัดว่าคำตอบคือแม้ว่าจดหมายบางฉบับจะคุ้มค่ากับค่าใช้จ่าย แต่จดหมายส่วนใหญ่ไม่ใช่ ฉันไม่สนใจว่าใครจะอ่าน "ดีใจที่คุณได้ออกจากคุก!" โปสการ์ดถึงลุงโจ

การเข้ารหัสไม่ฟรีและไม่ได้ช่วยเสมอไป

หากเซสชัน (เช่นการช็อปปิ้งการธนาคาร ฯลฯ ) กำลังจะจบลงโดยใช้ HTTPS ก็ไม่มีเหตุผลที่ดีที่จะไม่ทำให้ HTTPS ทั้งเซสชันโดยเร็วที่สุด

ความเห็นของฉันคือควรใช้ HTTPS เฉพาะเมื่อจำเป็นอย่างหลีกเลี่ยงไม่ได้ไม่ว่าจะเป็นเพราะคำขอหรือการตอบกลับจำเป็นต้องได้รับการปกป้องจากการสอดแนมระดับกลาง ตัวอย่างเช่นไปดู Yahoo! หน้าแรก แม้ว่าคุณจะเข้าสู่ระบบ แต่การโต้ตอบส่วนใหญ่ของคุณจะผ่าน HTTP คุณตรวจสอบสิทธิ์ผ่าน HTTPS และรับคุกกี้ที่พิสูจน์ตัวตนของคุณดังนั้นคุณจึงไม่จำเป็นต้องใช้ HTTPS ในการอ่านข่าวสาร

เหตุผลที่ใหญ่ที่สุดนอกเหนือจากการโหลดของระบบคือการแบ่งโฮสติ้งเสมือนตามชื่อ ด้วย SSL เป็นไซต์เดียว - ที่อยู่ IP เดียว ค่อนข้างแพงและดูแลยากกว่า

สำหรับลิงก์ที่มีเวลาแฝงสูงการจับมือ TLS ครั้งแรกจำเป็นต้องมีการเดินทางไปกลับเพิ่มเติมเพื่อตรวจสอบห่วงโซ่ใบรับรอง (รวมถึงการส่งใบรับรองระดับกลาง) ตกลงเกี่ยวกับชุดการเข้ารหัสและสร้างเซสชัน เมื่อสร้างเซสชันแล้วคำขอในภายหลังอาจใช้การแคชเซสชันเพื่อลดจำนวนการเดินทางไปกลับ แต่ในกรณีที่ดีที่สุดนี้ก็ยังมีการเดินทางไปกลับมากกว่าการเชื่อมต่อ HTTP ปกติ แม้ว่าการเข้ารหัสจะเป็นแบบไปกลับฟรีและสามารถสังเกตเห็นได้ค่อนข้างชัดเจนในการเชื่อมโยงเครือข่ายที่ช้าลงโดยเฉพาะอย่างยิ่งหากไซต์ไม่ได้ใช้ประโยชน์จาก http pipelining สำหรับผู้ใช้บรอดแบนด์ภายในส่วนที่เชื่อมต่ออย่างดีของเครือข่ายนี่ไม่ใช่ปัญหา หากคุณทำธุรกิจในระดับสากลการขอ https อาจทำให้เกิดความล่าช้าที่เห็นได้ชัดเจน

มีข้อควรพิจารณาเพิ่มเติมเช่นการบำรุงรักษาเซิร์ฟเวอร์ของสถานะเซสชันที่ต้องการหน่วยความจำเพิ่มขึ้นอย่างมีนัยสำคัญและแน่นอนการดำเนินการเข้ารหัสข้อมูล ไซต์ขนาดเล็กใด ๆ ในทางปฏิบัติไม่จำเป็นต้องกังวลเกี่ยวกับความสามารถของเซิร์ฟเวอร์ที่กำหนดเทียบกับต้นทุนของฮาร์ดแวร์ในปัจจุบัน ไซต์ขนาดใหญ่ใด ๆ จะสามารถจ่าย CPU / w AES offload หรือการ์ดเสริมเพื่อให้มีฟังก์ชันการทำงานที่คล้ายกัน

ปัญหาทั้งหมดเหล่านี้กลายเป็นปัญหามากขึ้นเรื่อย ๆ เมื่อเวลาผ่านไปและความสามารถของฮาร์ดแวร์และเครือข่ายดีขึ้น ในกรณีส่วนใหญ่ฉันสงสัยว่าวันนี้มีความแตกต่างที่จับต้องได้

อาจมีข้อควรพิจารณาในการปฏิบัติงานเช่นข้อ จำกัด ด้านการดูแลระบบในการรับส่งข้อมูล https (คิดว่าตัวกรองเนื้อหาระดับกลาง .. เป็นต้น) อาจเป็นไปได้ว่าข้อบังคับขององค์กรหรือหน่วยงานรัฐ สภาพแวดล้อมขององค์กรบางแห่งต้องการการถอดรหัสข้อมูลที่ขอบเขตเพื่อป้องกันการรั่วไหลของข้อมูล ... การรบกวนด้วยฮอตสปอตและระบบการเข้าถึงบนเว็บที่คล้ายกันซึ่งไม่สามารถฉีดข้อความในธุรกรรม https ได้ ในตอนท้ายของวันในมุมมองของฉันเหตุผลที่ไม่ใช้ https โดยค่าเริ่มต้นมีแนวโน้มที่จะค่อนข้างน้อย

https มีทรัพยากรมากขึ้นกว่า http ปกติ

ต้องการมากขึ้นจากทั้งเซิร์ฟเวอร์และไคลเอนต์

หากทั้งเซสชันถูกเข้ารหัสคุณจะไม่สามารถใช้แคชสำหรับทรัพยากรแบบคงที่เช่นรูปภาพและ js ในระดับพร็อกซีเช่น ISP

คุณควรใช้ HTTPS ทุกที่ แต่คุณจะสูญเสียสิ่งต่อไปนี้:

1. คุณไม่ควรใช้การบีบอัด SSL หรือการบีบอัด HTTP ผ่าน SSL อย่างแน่นอนเนื่องจากการโจมตี BREACH และ CRIME ดังนั้นไม่ต้องบีบอัดหากการตอบกลับของคุณมีตัวระบุเซสชันหรือ csrf คุณสามารถลดสิ่งนี้ได้โดยวางทรัพยากรแบบคงที่ (รูปภาพ, js, css) บนโดเมนที่ไม่ต้องใช้คุกกี้และใช้การบีบอัดที่นั่น คุณยังสามารถใช้การลดขนาด HTML

2. ใบรับรอง SSL หนึ่งรายการที่อยู่ IP เดียวยกเว้นการใช้ SNI ซึ่งใช้ไม่ได้กับทุกเบราว์เซอร์ (Android รุ่นเก่า blackberry 6 ฯลฯ )

3. คุณไม่ควรโฮสต์เนื้อหาภายนอกใด ๆ บนเพจของคุณที่ไม่ผ่าน SSL

4. คุณสูญเสียส่วนหัว HTTP Referer ขาออกเมื่อเบราว์เซอร์ไปที่หน้า HTTP ซึ่งอาจเป็นปัญหาสำหรับคุณหรือไม่ก็ได้

เหตุผลที่ชัดเจนคือประสิทธิภาพ: ข้อมูลทั้งหมดจะต้องถูกเข้ารหัสโดยเซิร์ฟเวอร์ก่อนที่จะส่งและจากนั้นไคลเอ็นต์จะถอดรหัสเมื่อได้รับซึ่งจะเสียเวลาหากไม่มีข้อมูลที่ละเอียดอ่อน นอกจากนี้ยังอาจส่งผลต่อจำนวนไซต์ของคุณที่ถูกแคช

นอกจากนี้ยังอาจสร้างความสับสนให้กับผู้ใช้หากใช้ที่อยู่ทั้งหมด https://http://มากกว่าที่คุ้นเคย ดูคำตอบนี้ด้วย:

ทำไมไม่ใช้ https เสมอเมื่อรวมไฟล์ js

https กำหนดให้เซิร์ฟเวอร์เข้ารหัสและถอดรหัสคำขอและการตอบกลับของไคลเอ็นต์ ผลกระทบด้านประสิทธิภาพจะเพิ่มขึ้นหากเซิร์ฟเวอร์ให้บริการลูกค้าจำนวนมาก นั่นเป็นเหตุผลที่การใช้ https ในปัจจุบันส่วนใหญ่ จำกัด เฉพาะการตรวจสอบรหัสผ่านเท่านั้น แต่ด้วยพลังการประมวลผลที่เพิ่มขึ้นสิ่งนี้อาจเปลี่ยนไปหลังจากที่ Gmail ทั้งหมดใช้ SSL สำหรับทั้งไซต์

นอกเหนือจากการตอบสนองของ WhirlWind แล้วคุณควรพิจารณาค่าใช้จ่ายและความสามารถในการใช้งานใบรับรอง SSL ปัญหาการเข้าถึง (แม้ว่าจะไม่น่าเป็นไปได้ที่ไคลเอนต์อาจไม่สามารถสื่อสารผ่านพอร์ต SSL ได้) เป็นต้น

การใช้ SSL ไม่ใช่การรับประกันความปลอดภัยแบบครอบคลุม การป้องกันประเภทนี้จำเป็นต้องสร้างไว้ในสถาปัตยกรรมของแอปพลิเคชันแทนที่จะพยายามพึ่งพากระสุนเวทย์มนตร์

ฉันได้รับแจ้งว่าในโครงการหนึ่งที่ บริษัท ของเราพวกเขาพบว่าแบนด์วิดท์ที่ใช้กับข้อความ SSL นั้นมากกว่าข้อความธรรมดาอย่างมาก ฉันเชื่อว่ามีคนบอกฉันว่ามันเป็นข้อมูลที่น่าประหลาดใจมากถึง 12 เท่า ฉันยังไม่ได้ตรวจสอบสิ่งนี้ด้วยตัวเองและมันก็ฟังดูสูงมาก แต่หากมีการเพิ่มส่วนหัวบางประเภทในแต่ละหน้าและหน้าเว็บส่วนใหญ่มีเนื้อหาจำนวนเล็กน้อยนั่นอาจจะไม่ไกลนัก

นั่นคือความยุ่งยากในการกลับไปกลับมาระหว่าง http และ https และการติดตามว่าหน้าใดที่ดูเหมือนว่าฉันใช้ความพยายามมากเกินไป ฉันพยายามสร้างไซต์ที่ผสมเข้าด้วยกันเพียงครั้งเดียวและเราก็ล้มเลิกแผนเมื่อเราสะดุดกับสิ่งที่ซับซ้อนเช่นหน้าต่างป๊อปอัปที่ Javascript สร้างขึ้นโดยแนบโปรโตคอลที่ไม่ถูกต้องเข้ากับพวกเขาและสิ่งนั้น เราลงเอยด้วยการทำให้ https ทั้งไซต์มีปัญหาน้อยลง ฉันเดาว่าในกรณีง่ายๆที่คุณมีเพียงแค่หน้าจอเข้าสู่ระบบและหน้าจอการชำระเงินที่ต้องได้รับการปกป้องและเป็นหน้าที่เรียบง่ายมันคงไม่ใช่เรื่องใหญ่ที่จะมิกซ์แอนด์แมทช์

ฉันจะไม่กังวลมากนักเกี่ยวกับภาระของไคลเอ็นต์ในการถอดรหัส โดยปกติไคลเอนต์จะใช้เวลาในการรอข้อมูลมากกว่าที่จะใช้ในการประมวลผล จนกว่าผู้ใช้จะมีการเชื่อมต่ออินเทอร์เน็ตกิกะบิต / วินาทีเป็นประจำพลังในการประมวลผลของไคลเอ็นต์อาจไม่เกี่ยวข้อง กำลังของ CPU ที่เซิร์ฟเวอร์ต้องการเพื่อเข้ารหัสเพจเป็นปัญหาที่แตกต่างกัน อาจมีปัญหาที่ไม่สามารถติดตามผู้ใช้นับร้อยหรือหลายพันคนได้

จุดเล็ก ๆ อีกจุดหนึ่ง (อาจมีคนตรวจสอบได้) หากผู้ใช้พิมพ์ข้อมูลลงในไอเท็มฟอร์มเช่นกล่องข้อความจากนั้นด้วยเหตุผลบางอย่างรีเฟรชหน้าหรือเซิร์ฟเวอร์หยุดทำงานเป็นเวลาหนึ่งวินาทีข้อมูลที่ผู้ใช้ป้อนจะหายไปโดยใช้ HTTPS แต่จะเก็บรักษาไว้โดยใช้ HTTP

หมายเหตุ: ฉันไม่แน่ใจว่านี่เป็นเบราว์เซอร์เฉพาะหรือไม่ แต่เกิดขึ้นกับเบราว์เซอร์ Firefox ของฉัน

windows Server 2012 ที่มี IIS 8.0 มี SNI ซึ่งเป็น Server Name Indication ซึ่งอนุญาตให้มีการโฮสต์เว็บแอปพลิเคชัน SSL หลายรายการใน IIS บนที่อยู่ IP เดียว