SSTP ตรวจสอบสิทธิ์เซิร์ฟเวอร์ก่อนแล้วจึงตรวจสอบสิทธิ์ผู้ใช้
SSTP ตรวจสอบใบรับรองเซิร์ฟเวอร์ก่อนและตรวจสอบสิทธิ์ผู้ใช้ในภายหลังผ่าน PPP จับคู่ข้อผิดพลาดกับขั้นตอนที่ถูกต้องแทนที่จะแตะทั้งสองขั้นตอนพร้อมกัน
ไคลเอนต์ SSTP สามารถทำ TLS ให้เสร็จได้แล้วยังปฏิเสธผู้ใช้ในอีกหนึ่งวินาทีถัดมา ลำดับนั้นไม่ใช่บั๊ก แต่เป็นสแต็กโปรโตคอล: ความปลอดภัยของทรานสปอร์ตก่อน การตรวจสอบสิทธิ์ผู้ใช้ทีหลัง เพราะสองขั้นตอนล้มเหลวด้วยข้อความต่างกัน จึงต้องใช้วิธีแก้ต่างกันด้วย การอ่านว่าขั้นตอนใดสร้างข้อผิดพลาดคือส่วนใหญ่ของการวินิจฉัย
ใบรับรองที่เชื่อถือได้พิสูจน์ปลายทาง แต่ไม่บอกอะไรเกี่ยวกับบัญชี
สิ่งที่การจับมือ TLS ยืนยัน
ไคลเอนต์ตรวจสอบใบรับรองที่เซิร์ฟเวอร์นำเสนอกับที่เก็บความเชื่อถือ ชื่อโฮสต์ที่ร้องขอ ช่วงเวลาที่ใช้ได้ และนโยบายเพิ่มเติมใดๆ ที่แพลตฟอร์มใช้ สิ่งนี้ปกป้องการเชื่อมต่อกับปลายทางที่ตั้งใจไว้ แต่ไม่ได้พิสูจน์ว่าบัญชีใดบัญชีหนึ่งเปิดใช้งาน ไม่หมดอายุ หรือได้รับอนุญาตให้ใช้การเข้าถึงระยะไกล นั่นเป็นคำถามแยกต่างหากที่คอมโพเนนต์อื่นจะถามในภายหลัง
ดังนั้นการเอาการตรวจสอบใบรับรองออกเพื่อไปถึงพรอมต์เข้าสู่ระบบจึงเป็นการซ่อมที่ผิด คุณจะได้พรอมต์เข้าสู่ระบบบนการเชื่อมต่อที่คุณตรวจสอบไม่ได้ ข้อผิดพลาดใบรับรองเป็นเรื่องของชื่อโฮสต์ นาฬิกา ห่วงโซ่ หรือการกำหนดค่าความเชื่อถือ
สิ่งที่ SSTP และ PPP เพิ่มเข้ามา
SSTP ทำงานบน HTTPS และบรรจุ PPP ไว้ข้างใน พร้อมการแลกเปลี่ยนควบคุมของตัวเองรอบการเชื่อมต่อ จากนั้น PPP จะทำงานในเฟสลิงก์และการตรวจสอบสิทธิ์ และวิธีการตรวจสอบสิทธิ์ขึ้นอยู่กับนโยบายเซิร์ฟเวอร์และความสามารถของไคลเอนต์ PAP, CHAP, MS-CHAPv2 และ EAP ล้วนเป็นตัวเลือกการตรวจสอบสิทธิ์ของ PPP ที่มีคุณสมบัติต่างกันมาก การตรวจสอบผู้ใช้ของ VPN คือเฟส PPP นั้น ไม่ใช่ชั้น TLS ที่อยู่ข้างใต้
ดังนั้นการปฏิเสธผู้ใช้อาจหมายถึงข้อมูลรับรอง ข้อจำกัดบัญชี หรือวิธีการไม่ตรงกัน
เหตุผลฝั่งเซิร์ฟเวอร์มีประโยชน์กว่าการรีเซ็ตทุกความลับในโปรไฟล์มาก เหตุการณ์บัญชีถูกปิดใช้งานและความล้มเหลวในการเจรจาวีธีดูคล้ายกันที่ไคลเอนต์และไม่มีอะไรเหมือนกันที่เซิร์ฟเวอร์
จับคู่ข้อผิดพลาดกับขั้นตอน
ตรวจสอบว่าการเชื่อมต่อไปถึง TLS หรือไม่ จากนั้นจึงเป็นการแลกเปลี่ยน HTTP ของ SSTP จากนั้นจึงเป็นเฟส PPP รักษาเวลาของบันทึกให้ตรงกันระหว่างการลองใหม่ เพื่อไม่ให้ความล้มเหลวก่อนหน้าสับสนกับความสำเร็จภายหลัง ไคลเอนต์ที่บันทึกความพยายามสองครั้งในหน้าต่างเดียวจะดูเหมือนล้มเหลวในขั้นตอนสุดท้ายที่ไปถึง อ่านข้อผิดพลาดแรกที่เกี่ยวข้อง ไม่ใช่บรรทัดสุดท้าย
การจัดแนวเดียวกันนี้สำคัญฝั่งเซิร์ฟเวอร์ ซึ่งบันทึกการตรวจสอบสิทธิ์และบันทึกทรานสปอร์ตมักเป็นไฟล์แยกที่มีนาฬิกาแยกกัน ความคลาดเคลื่อนสองนาทีก็เพียงพอทำให้สาเหตุที่ชัดเจนดูเป็นไปไม่ได้
หลังเข้าสู่ระบบ การอนุญาตยังแยกต่างหาก
การเข้าสู่ระบบที่สำเร็จไม่ได้ให้สิทธิ์ทุกทรัพยากรส่วนตัว เส้นทางกำหนดว่าอะไรเข้าถึงได้ DNS กำหนดว่าอะไรแก้ไขได้ และแต่ละบริการยังใช้สิทธิ์ของตัวเอง เซสชันที่แสดงว่าเชื่อมต่ออยู่เป็นข้อความเกี่ยวกับอุโมงค์ ไม่ใช่เกี่ยวกับการแชร์ไฟล์ เมื่อผู้ใช้เชื่อมต่อได้แต่ไปไม่ถึงโฮสต์หนึ่ง เฟสอุโมงค์ก็จบไปแล้ว
นั่นคือการแบ่งชั้นเดียวกับการจับมือที่แสดงไว้ หนึ่งระดับสูงขึ้น
เก็บการกู้คืนบัญชีไว้ในกระบวนการที่ผู้ให้บริการสนับสนุน แทนที่จะเปลี่ยนการตั้งค่าทรานสปอร์ตเพื่อตอบสนองการปฏิเสธผู้ใช้อย่างชัดเจน การเปลี่ยนทรานสปอร์ตเพื่อซ่อมบัญชีที่ถูกปิดใช้งานเป็นวิธีซ่อมที่ดูเหมือนได้ผลเมื่อบัญชีถูกเปิดใช้งานอีกครั้งด้วยเหตุผลที่ไม่เกี่ยวข้อง