การตรวจสอบสิทธิ์ผ่าน HTTPS จะทำให้ใบสมัครของฉันช้าลงหรือไม่


11

ฉันกำลังสร้างเว็บแอปพลิเคชันและบริการเว็บสงบ

ฉันได้อ่านบทความต่าง ๆ เกี่ยวกับวิธีที่ดีที่สุดในการรับรองความถูกต้องของคำขอไปยังบริการเว็บ

ตัวเลือกที่ดีที่สุดสำหรับฉันดูเหมือนจะใช้การตรวจสอบสิทธิ์พื้นฐาน HTTP ค่อนข้างทุกบทความอ่าน ive กล่าวว่าการตรวจสอบควรเข้ารหัสผ่าน SSL หรือเทียบเท่า

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


ความคิดความสามารถในการรับข้อมูลที่โหลดผ่าน https ฉันไม่แน่ใจ 100% ว่าจะเกิดผลกระทบหรือไม่

ฉันไม่แน่ใจว่าฉันทำตาม คุณกำลังบอกว่าแคชเป็นไปไม่ได้?
Gaz_Edge

มีการโต้ตอบระหว่าง ssl / https และเว็บเซิร์ฟเวอร์ที่อาจไม่ได้ตั้งใจกับ REST - cxf.547215.n5.nabble.com/ - ฉันไม่ได้เจาะลึกเข้าไปใน REST ในสภาพแวดล้อมที่ปลอดภัยดังนั้นสิ่งนี้จึงไม่ได้เป็น ปัญหาสำหรับฉัน มันเพิ่มเติมจากความคิดและคำแนะนำจากสมัยของฉันในฐานะผู้ดูแลระบบ Apache

ขอบคุณ คุณบอกว่าคุณไม่ได้ใช้ REST ในสภาพแวดล้อมที่ปลอดภัย หมายความว่าคุณไม่ได้ใช้การพิสูจน์ตัวตนหรือไม่ หรือคุณกำลังใช้วิธี http พื้นฐานอื่น
Gaz_Edge

ไม่ว่าจะเป็นการรับรองความถูกต้องพื้นฐานหรือ IP ... และหมดจดในอินทราเน็ต

คำตอบ:


11

ก่อนอื่นลองทำความเข้าใจว่าการรับรองความถูกต้องของ SSL (HTTPS) และ HTTP ทำงานอย่างไร

วิธีการตรวจสอบความถูกต้อง HTTPตามปกติ(Digest, Basic และรูปแบบการตรวจสอบความถูกต้องตามรูปแบบ + คุกกี้ใด ๆ ที่คุณสามารถนำไปใช้ด้านบนของ HTTP) นั้นไม่ปลอดภัยทั้งหมดด้วยตัวเองเพราะพวกเขาส่งข้อมูลการรับรองความถูกต้อง ไม่ว่าข้อมูลจะอยู่ในเขตข้อมูล POST หรือส่วนหัวและไม่ว่าจะเป็นการเข้ารหัสแบบเบส 64 หรือไม่ก็ตามไม่ว่าจะด้วยเหตุผลใดก็ตาม ซึ่งหมายความว่าการรับรองความถูกต้อง HTTP ผ่านช่องทางที่ไม่น่าเชื่อถือนั้นไม่มีค่าอะไรเลยสิ่งที่ผู้โจมตีต้องอ่านรหัสผ่านของคุณนั้นเป็นเครือข่ายเล็กน้อย

SSLใช้ช่องทางการสื่อสารที่ปลอดภัยผ่านช่องทางที่ไม่ปลอดภัยโดยเนื้อแท้ งานนี้ประมาณดังต่อไปนี้:

  1. เซิร์ฟเวอร์ส่งใบรับรองที่ลงนามแล้ว
  2. ลูกค้าตรวจสอบใบรับรองกับรายการของคีย์การเซ็นชื่อที่รู้จักดี ลายเซ็นใบรับรองสามารถถูกผูกมัดเพื่อให้แต่ละโหนดบอกว่า "ถ้าลายเซ็นที่ลงนามฉันเป็นสิ่งที่ดีแล้วฉันดังนั้น" แต่ในที่สุดห่วงโซ่จำเป็นต้องแก้ไขหนึ่งในหน่วยงานที่เชื่อถือได้กำมือหนึ่งที่กำหนดไว้ล่วงหน้าบนไคลเอนต์
  3. ไคลเอนต์ใช้คีย์การเข้ารหัสสาธารณะของเซิร์ฟเวอร์เพื่อส่งความลับที่ใช้ร่วมกัน
  4. เซิร์ฟเวอร์ถอดรหัสลับที่แชร์โดยใช้ไพรเวตคีย์ (เพราะเฉพาะเซิร์ฟเวอร์ที่ถูกกฎหมายเท่านั้นที่มีไพรเวตคีย์เซิร์ฟเวอร์อื่น ๆ จะไม่สามารถถอดรหัสลับที่แชร์ได้)
  5. ลูกค้าส่งข้อมูลคำขอจริงเข้ารหัสโดยใช้ความลับที่ใช้ร่วมกัน
  6. เซิร์ฟเวอร์ถอดรหัสข้อมูลร้องขอจากนั้นส่งการตอบกลับที่เข้ารหัส
  7. ลูกค้าถอดรหัสการตอบสนองและนำเสนอให้กับผู้ใช้

โปรดสังเกตประเด็นสำคัญบางประการที่นี่:

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

เห็นได้ชัดว่ามีค่าใช้จ่ายที่เกี่ยวข้อง แต่ก็ไม่เลวร้ายอย่างที่คุณคิด - ส่วนใหญ่อยู่ในระดับที่ "ทิ้งฮาร์ดแวร์ไว้ที่นี่" เป็นการตอบสนองที่เหมาะสมนอกเสียจากว่าคุณกำลังเตรียมพร้อมสำหรับการรับส่งข้อมูลจำนวนมาก ( คิดว่า Google หรือ Facebook) ภายใต้สถานการณ์ปกตินั่นคือการใช้งานเว็บแอปพลิเคชันทั่วไปค่าโสหุ้ย SSL นั้นเล็กน้อยและดังนั้นทันทีที่คุณมีข้อมูลที่เป็นความลับคุณควรรันทุกอย่างบน SSL รวมถึงทรัพยากร SSL เป็นวิธีเดียวที่ใช้ในการรักษาความปลอดภัยการรับส่งข้อมูล HTTP; วิธีการอื่นนั้นไม่ได้มาตรฐานและไม่ได้รับการสนับสนุนอย่างกว้างขวางและคุณไม่ต้องการที่จะใช้สิ่งเหล่านี้ด้วยตัวเองเพราะโดยสุจริตมันง่ายเกินไปที่จะทำให้พวกเขาผิด

TL; DR:ใช่การรับรองความถูกต้องพื้นฐาน SSL + เป็นความคิดที่ดีใช่คุณต้องมีเซิร์ฟเวอร์ที่ปลอดภัย (และใบรับรองที่ถูกต้อง ) ใช่มันจะทำให้ช้าลงเล็กน้อย แต่ไม่ใช่นี่ไม่ใช่สิ่งที่คุณต้องกังวล ตอนนี้


12

HTTPS (SSL) ไม่ใช่การรับรองความถูกต้องของผู้ใช้ FYI มันให้การเข้ารหัสระหว่าง 2 จุดสิ้นสุด

แต่ใช่มีค่าใช้จ่ายเล็ก ๆ น้อย ๆ จากมัน (แต่ไม่เพียงพอที่จะรับประกันการเปลี่ยนแปลงในแผน / ฮาร์ดแวร์) ดูที่นี่:

/programming/548029/how-much-overhead-does-ssl-impose


7
+1 ดีกว่าที่จะปลอดภัยเกินกว่าไม่ปลอดภัยพอที่จะได้รับจากโสหุ้ยเล็ก ๆ
Earlz

2
คำตอบนี้ทำให้เข้าใจผิดมาก SSL คือการตรวจสอบความถูกต้องโดยปกติจะไม่ใช่การตรวจสอบผู้ใช้ SSL รับรองว่าเซิร์ฟเวอร์ที่คุณกำลังพูดคุยนั้นเป็นใครที่บอกว่าเป็น (งานของ CA คือการออกใบรับรองสำหรับ facebook.com ถึง Facebook เท่านั้น) นอกจากนี้ SSL สามารถทำการตรวจสอบผู้ใช้ด้วยใบรับรองไคลเอ็นต์
josh3736

@ ไบรอัน: ฉันเห็นด้วยกับ josh3736 SSL ให้การรับรองความถูกต้องในแง่การเข้ารหัสลับของคำ หากไม่มีการพิสูจน์ตัวตน (เช่นเซิร์ฟเวอร์) คุณจะเปิดให้กับผู้ชายในการโจมตีกลาง SSL สามารถให้การรับรองความถูกต้องของไคลเอนต์ (ผู้ใช้) ที่ปลอดภัยโดยใช้สมาร์ทการ์ดหรือหากมีการรับรองความถูกต้องของเซิร์ฟเวอร์วิธีอื่น ๆ (เช่นชื่อผู้ใช้ / รหัสผ่าน) สามารถใช้ผ่านช่องทางที่ปลอดภัย
Guy Sirton

จริงๆแล้วมันชัดเจนว่า OP ได้ถามเกี่ยวกับการรับรองความถูกต้องของผู้ใช้และไม่ต้องกังวลเกี่ยวกับการรับรองความถูกต้องของลูกค้าที่พวกเขากำลังพูดคุยกับ / คนในการโจมตีกลาง ฉันแก้ไขโพสต์ของฉันในหน้า pedantry รุนแรง;) ถูกต้องทางเทคนิคเป็นชนิดที่ดีที่สุดของความถูกต้อง, afterall
brian

6

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

ในทางทฤษฎีคุณสามารถใช้การรับรองความถูกต้องของคุกกี้และใส่ SSL ลงในหน้าเข้าสู่ระบบเท่านั้น (ที่ชื่อผู้ใช้และรหัสผ่านจะถูกส่ง) หากคุกกี้ของคุณปลอดภัยและปลอดภัยจากการโจมตีซ้ำแล้วซ้ำอีกผู้โจมตีจะไม่สามารถทำอะไรกับพวกเขาแม้ว่าพวกเขาจะจัดการเพื่อให้ได้รับ


3

การพิสูจน์ตัวตนพื้นฐานคือการตั้งชื่อผู้ใช้และรหัสผ่านในส่วนหัวของคำขอ http หากคุณไม่ใช้ SSL หรือเทียบเท่าชื่อผู้ใช้และรหัสผ่านนั้นจะถูกส่งเป็นข้อความล้วนและเป็นเรื่องเล็กน้อยสำหรับทุกคนที่จะขโมย

เว็บเซิร์ฟเวอร์ส่วนใหญ่รองรับ HTTPS นอกกรอบทุกวันนี้และแม้ว่ามันจะเพิ่มโอเวอร์เฮดให้กับการโทรทุกครั้งที่โอเวอร์เฮดน้อยที่สุด

คุณสามารถรักษาความปลอดภัยจุดปลายบางจุดและไม่ใช่จุดอื่น (เช่นมีจุดตรวจสอบความถูกต้องที่สร้างโทเค็นที่สามารถใช้สำหรับการโทรอื่น ๆ ) ฉันขอแนะนำ SSL สำหรับบริการทั้งหมดแม้ว่าจะมีความปลอดภัยมากกว่า (หากไม่มีสิ่งอื่นใดมันจะหยุดการดักจับข้อมูลที่สำคัญ)


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

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

2

Jeff Atwood เขียนบล็อกสั้น ๆ เมื่อไม่นานมานี้เกี่ยวกับว่าการเข้ารหัสเต็มรูปแบบเป็นวิธีที่จะไป เขาอธิบายตัวอย่างในโลกแห่งความเป็นจริงและมีข้อควรพิจารณาเกี่ยวกับประสิทธิภาพสองสามบรรทัดเช่นกัน

นอกจากนี้เขาอ้างอิงนี้บทความเกี่ยวกับกรณีศึกษาของ Gmail ข้อความต่อไปนี้:

ในเดือนมกราคมปีนี้ (2010) Gmail เปลี่ยนไปใช้ HTTPS ทุกอย่างเป็นค่าเริ่มต้น ก่อนหน้านี้มีการนำเสนอเป็นตัวเลือก แต่ตอนนี้ผู้ใช้ของเราทั้งหมดใช้ HTTPS เพื่อรักษาความปลอดภัยอีเมลระหว่างเบราว์เซอร์กับ Google ตลอดเวลา ในการทำเช่นนี้เราต้องปรับใช้เครื่องจักรเพิ่มเติมและไม่มีฮาร์ดแวร์พิเศษ บนเครื่องส่วนหน้าการผลิตของเราบัญชี SSL / TLS น้อยกว่า 1% ของโหลด CPU น้อยกว่า 10KB ของหน่วยความจำต่อการเชื่อมต่อและน้อยกว่า 2% ของค่าใช้จ่ายเครือข่าย หลายคนเชื่อว่า SSL ใช้เวลา CPU นานและเราหวังว่าตัวเลขข้างต้น (สาธารณะเป็นครั้งแรก) จะช่วยขจัดสิ่งนั้น

นอกจากนี้เขายังกล่าวถึงการปรับปรุงแล้วล่าสุดบางแคชฝั่งไคลเอ็นต์ของหน้าเว็บผ่าน HTTPS เป็นเบราว์เซอร์

แม้จะมีสิ่งนี้เขาชี้ให้เห็นว่ามีบทลงโทษอื่น ๆ ซึ่งส่วนใหญ่ไม่ได้ทำงาน แต่มีค่าใช้จ่ายในการดำเนินการ:

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

โปรดขยายคำตอบของคุณและรวมถึงไฮไลท์บางอย่างจากบล็อก
วอลเตอร์

เพิ่มไฮไลต์จากโพสต์บล็อก
Daniel Dinnyes

0

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

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

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


0

คุณจะทำการรับรองความถูกต้องเบื้องต้นอย่างไร
หากเป็นชื่อผู้ใช้ / รหัสผ่านที่ใช้รหัสอย่างหนักและคุณใช้ฟังก์ชันการทำงานของเว็บเซิร์ฟเวอร์ของคุณในการใช้งานมันอาจมีผลกระทบเกือบเป็นศูนย์ หากคุณกำลังทำสิ่งที่บ้าในฐานข้อมูลหรือสิ่งที่คล้ายกันใช่แล้วอาจมีผลกระทบ

เช่นเดียวกับที่คนอื่น ๆ ระบุไว้ที่นี่ SSL และการส่งส่วนหัวพิเศษจะทำให้สิ่งต่าง ๆ ช้าลงในทางเทคนิค แต่จะไม่มีความหมายใด ๆ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.