ข้อผิดพลาดใบรับรอง SSL ใน Captive Portals


10

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


วิธีแก้ไขที่เป็นไปได้: WPA2-Enterprise พร้อมเซิร์ฟเวอร์การตรวจสอบสิทธิ์ Radius
Ajedi32

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

คำตอบ:


6

คำจำกัดความทั้งหมดของ "captive portal" revolves around "การเปลี่ยนเส้นทางผู้ใช้โดยไม่มีความรู้ของเขา / เธอ" ซึ่งเป็นหนึ่งในสิ่งที่ SSL สร้างขึ้นเพื่อหลีกเลี่ยง

หาก URL แรกที่เบราว์เซอร์พยายามเปิดเป็น HTTPS จะไม่มีวิธีเปลี่ยนเส้นทางทราฟฟิกโดยไม่สร้างข้อผิดพลาดใบรับรอง


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

5

โครงการ Chromium มีหน้าเว็บที่ดีที่อธิบายถึงวิธีการทำงานของตรรกะในการตรวจจับพอร์ทัลที่ถูกจับ:

  1. พยายามเชื่อมต่อ (HTTP ธรรมดา) กับโฮสต์ที่รู้จักกันดี + URI
  2. คาดหวัง HTTP 204 No Content
  3. หากได้รับการตอบกลับที่ต่างกันให้ถือว่าเป็นพอร์ทัลที่ถูกกักขัง

มีรายละเอียดอื่น ๆ ในลิงค์ที่ให้ไว้เกี่ยวกับวิธีที่พวกเขาจัดการกับ DNS ล้มเหลวเมื่อพยายามแก้ไขโฮสต์ที่รู้จักกันดีเป็นต้นนี่เป็นเพียงตัวอย่างหนึ่ง แต่ (จากประสบการณ์ส่วนตัวของฉัน) การออกแบบระบบปฏิบัติการสมัยใหม่ใช้กระบวนการคล้ายกับสิ่งนี้เพื่อตรวจจับ และแจ้งให้ผู้ใช้ทราบในบางกรณีก่อนที่ผู้ใช้จะเปิดเบราว์เซอร์ (พิจารณา: ใครบางคนที่ต้องการใช้ไคลเอ็นต์ IMAP หรือบริการที่ไม่ใช่ HTTP อื่น ๆ เท่านั้น) ในกรณีนี้การตรวจสอบจะไม่ผ่าน SSL / TLS ดังนั้นคุณจึงหลีกเลี่ยงข้อกังวลของคุณ

RFC 6585 ส่วนที่ 6เสนอรหัสสถานะ HTTP ใหม่511 Network Authentication Requiredที่ไม่ได้ช่วยกรณี SSL / TLS ของคุณ แต่เป็นมาตรฐานอื่นที่คุณอาจพิจารณาหากคุณยังไม่ได้ใช้


Android ยังมีการสนับสนุนการตรวจจับพอร์ทัลเชลย เมื่อตรวจพบพอร์ทัลแบบ Captive จะแสดงข้อความบนแถบสถานะ ถ้อยคำนั้นคล้ายกับ "ลงชื่อเข้าใช้เครือข่ายไร้สาย" สิ่งนี้เกิดขึ้นแม้ว่าจะไม่มีแอปพลิเคชันพยายามใช้การเชื่อมต่อ ในบางครั้งฉันก็สังเกตเห็นว่าพอร์ทัล Captive ส่งการเปลี่ยนเส้นทาง 30x พร้อมกับส่วนหัว HTTP พิเศษซึ่งบ่งชี้ว่านี่เป็นพอร์ทัลแบบ Captive และเนื้อหามีข้อมูล XML บางส่วน ฉันไม่รู้ว่านี่เป็นพฤติกรรมมาตรฐานหรือไม่
kasperd

0

ในกรณีใด ๆ หากผู้ใช้จะได้รับข้อผิดพลาดใบรับรองเป็นเพราะรับรองไม่ตรงกับชื่อโฮสต์เว็บไซต์

ในกรณีของคุณหมายความว่าคุณเปลี่ยนเส้นทางผู้ใช้ไปยังพอร์ทัลของคุณโดยไม่ต้องเปลี่ยน URL ผู้ใช้เห็น " http://www.google.com " ในแถบที่อยู่ แต่พอร์ทัลของคุณในหน้าจอ สิ่งเหล่านี้ไม่ตรงกันแน่นอนและใบรับรองก็ไม่เหมือนกัน

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

ดูhttps://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xxสำหรับวิธีดำเนินการด้วยรหัส HTTP 3xx โดยเฉพาะ 303


ผู้ใช้ส่วนใหญ่อาจไม่พิมพ์ https://แต่บุ๊กมาร์กที่เก็บไว้หรือกลไกการตรึงอื่น ๆ อาจส่งผลให้มีการร้องขอครั้งแรกไปยังบริการที่ใช้ HTTPS ดังนั้นจึงล้มเหลวเนื่องจากการจับมือ TLS ล้มเหลวก่อนถึงเลเยอร์โปรโตคอล HTTP สำหรับการเปลี่ยนเส้นทาง นอกเหนือจากที่คั่นหนังสือตัวอย่างของ "การตรึง" นั้นยังรวมถึงแถบการค้นหาของเบราว์เซอร์ที่มีความรู้มาก่อนว่าผู้ให้บริการการค้นหาต้องการการสืบค้นผ่าน HTTPS; หรือแอพมือถือที่เชื่อมต่อกับบริการเครือข่ายที่ปลอดภัย
William Price

-1

วิธีการแก้ปัญหาชั่วคราวเป็นแนวทางให้ผู้ใช้เริ่ม URL ที่ขึ้นต้นด้วย "http" หลังจากเชื่อมต่อสัญญาณ wifi แล้วเท่านั้น

แต่น่าเสียดายที่ผู้ใช้ไม่ชอบ พวกเขาบอกว่า "คุณมีบริการ wifi ซับซ้อนแค่ไหน"

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