سؤال

لقد قمت بإعداد موفر المعرف المفتوح الخاص بي على خادمي الشخصي، وأضفت إعادة توجيه إلى https في ملف تكوين Apache الخاص بي.عند عدم استخدام اتصال آمن (عندما أقوم بتعطيل إعادة التوجيه)، يمكنني تسجيل الدخول بشكل جيد، ولكن مع إعادة التوجيه لا يمكنني تسجيل الدخول مع رسالة الخطأ هذه:

تم إغلاق الاتصال الأساسي:تعذر إنشاء علاقة ثقة لقناة SSL/TLS الآمنة.

أعتقد أن هذا بسبب أنني أستخدم شهادة موقعة ذاتيًا.

هل يمكن لأي شخص تأكيد ما إذا كانت الشهادة الموقعة ذاتيًا هي المشكلة؟إذا لم يكن هناك أي شخص لديه أي أفكار ما هي المشكلة؟

هل كانت مفيدة؟

المحلول

تتمثل الفائدة الأساسية لاستخدام SSL لعنوان URL الخاص بـ OpenID في أنه يمنح الطرف المعتمد آلية لاكتشاف ما إذا كان قد تم التلاعب بـ DNS أم لا.من المستحيل على الطرف المعتمد معرفة ما إذا كان عنوان URL لـ OpenID الذي يحتوي على شهادة موقعة ذاتيًا قد تم اختراقه أم لا.

هناك فوائد أخرى تحصل عليها من استخدام SSL على عنوان URL لنقطة النهاية الخاصة بموفر الخدمة الخاص بك (أسهل في إنشاء الارتباطات، دون التنصت على بيانات الامتداد) والتي ستظل سارية إذا استخدمت شهادة موقعة ذاتيًا، لكنني سأعتبرها ثانوية.

نصائح أخرى

تم تصميم OpenID بطريقة شفافة لإعادة التوجيه.طالما يتم الاحتفاظ بأزواج المفتاح/القيمة الضرورية عند كل عملية إعادة توجيه، إما عن طريق GET أو POST، فسيعمل كل شيء بشكل صحيح.

الحل الأسهل لتحقيق التوافق مع المستهلكين الذين لا يعملون مع الشهادات الموقعة ذاتيًا هو استخدام نقطة نهاية غير مشفرة تقوم بإعادة التوجيه checkid_immediate و checkid_setup رسائل إلى واحدة مشفرة.

يعد القيام بذلك في رمز الخادم الخاص بك أسهل من عمليات إعادة توجيه خادم الويب حيث يمكن للأول التعامل بسهولة أكبر مع طلبات POST، مع الاحتفاظ بالرمز معًا أيضًا.علاوة على ذلك، يمكنك استخدام نفس نقطة النهاية للتعامل مع جميع عمليات OpenID، بغض النظر عما إذا كان ينبغي تقديمها عبر SSL أم لا، طالما تم إجراء الفحوصات المناسبة.

على سبيل المثال، في PHP، يمكن أن تكون عملية إعادة التوجيه بسيطة مثل:

// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
        ($_GET['openid_mode'] == 'checkid_immediate' ||
         $_GET['openid_mode'] == 'checkid_setup'))
    http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");

كما openid.return_to تم إنشاء القيمة مقابل نقطة نهاية HTTP عادية، وبقدر ما يتعلق الأمر بالمستهلك، فهي تتعامل فقط مع خادم غير مشفر.بافتراض التشغيل الصحيح لـ OpenID 2.0 مع الجلسات والأرقام غير المميزة، فإن أي معلومات يتم تمريرها بين المستهلك والخادم الخاص بك يجب ألا تكشف عن معلومات قابلة للاستغلال.تتم العمليات بين متصفحك وخادم OpenID، القابلة للاستغلال (التطفل على كلمة المرور أو اختطاف ملفات تعريف الارتباط للجلسة)، عبر قناة مشفرة.

وبصرف النظر عن منع المتنصتين، فإن إجراء عمليات المصادقة عبر SSL يسمح لك باستخدام secure علامة ملف تعريف الارتباط HTTP.وهذا يضيف طبقة أخرى من الحماية لـ checkid_immediate العمليات، إذا كنت ترغب في السماح بذلك.

(تنصل:أنا جديد على OpenID، لذا قد أكون مخطئًا هنا.) لا يتطلب الاتصال بين عميل Open ID (على سبيل المثال، StackOverflow) وموفر Open ID (الخادم الخاص بك) HTTPS - سيعمل بنفس الجودة والبساطة بشكل آمن عبر HTTP العادي.ما عليك القيام به هو تهيئة الخادم الخاص بك للتبديل إلى HTTPS فقط عندما تظهر لك صفحة تسجيل الدخول الخاصة بك.في هذه الحالة، متصفحك فقط هو الذي يحتاج إلى الاهتمام بالشهادة الموقعة ذاتيًا.يمكنك استيراد الشهادة إلى جهاز الكمبيوتر الخاص بك وسيكون كل شيء آمنًا كما هو الحال مع الشهادة الصادرة عن Verisign، على سبيل المثال.

يبدو الأمر كذلك.لا يثق عميل خادم OpenID الخاص بك في المرجع المصدق الجذر.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top