سؤال هل من السيئ إعادة توجيه http إلى https؟


لقد قمت للتو بتثبيت شهادة SSL على الخادم الخاص بي.

ثم أعد عملية إعادة توجيه لجميع الزيارات على نطاقي على المنفذ 80 لإعادة توجيهها إلى المنفذ 443.

وبعبارة أخرى ، كل ما عندي http://example.com يتم الآن إعادة توجيه حركة المرور إلى المناسب https://example.com نسخة من الصفحة.

تتم عملية إعادة التوجيه في ملف Apache Virtual Hosts الخاص بي مع شيء مثل هذا ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

سؤالي هو ، هل هناك أي عيوب لاستخدام SSL؟

نظرًا لأن هذا ليس 301 إعادة توجيه ، هل سأفقد عصير الارتباط / الترتيب في محركات البحث من خلال التبديل إلى https؟

أنا أقدر المساعدة. لطالما رغبت في إعداد SSL على خادم ، لمجرد ممارسة ذلك ، وقررت في النهاية أن أفعل ذلك الليلة. يبدو أنها تعمل بشكل جيد حتى الآن ، لكنني لست متأكداً ما إذا كانت هذه فكرة جيدة لاستخدامها على كل صفحة. موقعي ليس التجارة الإلكترونية ولا يتعامل مع البيانات الحساسة ؛ انها أساسا لتبدو والتشويق لتركيبها للتعلم.


قضية محدثة

Strangegely Bing يقوم بإنشاء لقطة الشاشة هذه من موقعي الآن باستخدام HTTPS في كل مكان ...

enter image description here 


245
2018-01-28 00:12


الأصل


[WTF - لا يمكنني إضافة الإجابة (على الرغم من أنني أعتقد أن لدي ما يكفي من الممثلين).] ستكون إجابتي (جزئياً) هي تلك في بعض الأحيان أنها سيئة. جرّب تمرير COOKIE أو مفتاح واجهة برمجة التطبيقات في GET عبر HTTP. إذا كان موقعك يعيد توجيه طلبات HTTP لطلبات HTTPS ، فستعمل هذه المكالمات ، ولكن سيتم نقل COOKIE أو مفتاح واجهة برمجة التطبيقات في الوضع واضح المعالم. تعمل بعض واجهات برمجة التطبيقات على إيقاف تشغيل HTTP ، وهو أسلوب أكثر قوة - لا يوجد HTTP على الإطلاق بحيث لا يمكنك حتى تشغيله ما لم تستخدم HTTPS. مثال: "يجب إجراء جميع طلبات واجهة برمجة التطبيقات عبر HTTPS. ستفشل المكالمات التي يتم إجراؤها عبر HTTP العادي" من stripe.com/docs/api؟lang=php#authentication - codingoutloud
codingoutloud - البديل هو أن الشئ كله يحدث عبر HTTP بدون HTTPS على الإطلاق. كيف هذا أفضل؟ - Mark Henderson♦
@ بنكروييل ، ذلك لأن أ بوابة الأسير يبدو الكثير جدا مثل sslstripنمط إعادة توجيه الهجوم (انهم على حد سواء خطف طلب في منتصف - في الشرق) ذلك HSTSسوف المتصفحات -aware منعهم على حد سواء. - Jeffrey Hantin
أن تدرك أن استخدام https يعني أن كل ما تدرجه يجب أن يكون أيضًا https أو قد لا يتم تحميله - على سبيل المثال باستخدام jquery load src="://example.com/jquery.js" - لاحظ نقص http أو https بحيث يقوم المتصفح بتحميل واحد مناسب. كان لي كابوس في محاولة للحصول على بعض الأشياء الأمازون المضمنة لتحميل بشكل صحيح كما API (التي تم تحميلها عبر https) روابط HTTP المنتجة - وهذا يعني أنها لم تعمل بشكل صحيح حتى وجدت المعلمة غير الموثقة لتبديل الروابط https - Basic
جيسون. يجب أن يكون التحديث الخاص بك سؤالاً جديدًا ، ربما على المواقع لأنه غير متعلق (تقنيًا) بسؤالك الأصلي. ولكن من المحتمل أن تكون أوراق أنماطك تأتي من نطاق غير آمن. - Mark Henderson♦


الأجوبة:


ال [R] العلم من تلقاء نفسها هو 302 إعادة التوجيه (Moved Temporarily). إذا كنت تريد حقًا أن يستخدم الأشخاص إصدار HTTPS من موقعك (تلميح: أنت تفعل ذلك) ، فيجب أن تستخدمه [R=301] لإعادة التوجيه الدائم:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

ا 301 يبقي كل ما تبذلونه من google فو و pageranks بجد سليم. تأكد mod_rewrite ممكّن:

a2enmod rewrite

للإجابة على سؤالك بالضبط:

هل من السيئ إعادة توجيه http إلى https؟

الجحيم لا. انها جيدة جدا.


309
2018-01-28 00:27



شكرا على هذه المعلومات ، رئيسي يقول لي السبب في أنه لا يعمل سوى https على صفحات معينة من موقعه ، هو أنه يستخدم الكثير من موارد الخادم لتشغيله في كل صفحة. هل تعرف أي شيء عن ذلك أو إذا كان هذا صحيحًا؟ - JasonDavis
@ jasondavis فقط إذا كنت لا تنفق بضع دقائق ل تحسينها. - Michael Hampton♦
"إنها تستخدم الكثير من موارد الخادم لتشغيلها في كل صفحة." تحتوي وحدات المعالجة المركزية (CPUs) الحديثة على ميزات تسريع تشفير تجعل SSL حرة تقريباً. لا تقلق بشأن النفقات العامة. - Adam Davis
AdamDavis قد تكون خوارزمية التشفير خفيفة الوزن ، ولكن لا يزال هناك مصافحة التحميل. أيضًا ، يمنع HTTPS وكلاء HTTP من التخزين المؤقت للمحتوى الخاص بك. في عظم في الحالات ، يكون الحد الأقصى لنطاق HTTPS ضئيلًا وجديرًا بالاهتمام ، ولكن كن حريصًا على الإفراط في التعميم. - 200_success
إنه يقتل التخزين المؤقت المشترك ، وهو أمر مفيد لأنماط استخدام بعض المواقع ، وغالبا ما يحمي القليل (هل من المهم أن يعرف الناس أنك قمت بزيارة الموقع ، ولكن ليس تفاصيل ما فعلته؟ هذا هو الوضع الوحيد الذي يكون فيه SSL مفيدًا). الميزة الرئيسية لطبقة المقابس الآمنة (SSL) على كل مورد لا تحتاج إلى "آمن" ، على سبيل المثال ، الأشخاص الذين ينظرون إلى "حولنا" ، ولكن لا يمكنك أن تفشل ولا تفشل في استخدامها في حالة يجب عليك فيها. - Jon Hanna


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

  1. تحقق من الموقع بأكمله للارتباطات الداخلية وتأكد من أنهم يستخدمون HTTPS إذا حددت اسم نطاقك الخاص في الروابط ، حتى لا تتسبب في عمليات إعادة التوجيه الخاصة بك.
  2. تحديث الخاص بك <meta property="og:url" لاستخدام إصدار https من نطاقك.
  3. إذا كنت تستخدم <base href= مرة أخرى تحديث لاستخدام HTTPS.
  4. التثبت بروتوكول SPDY اذا كان ممكنا
  5. تأكد من استخدام صور CSS المتحركة حيثما أمكن ، لتقليل عدد الطلبات.
  6. قم بتحديث ملفات sitemap للإشارة إلى حالة https ، لذلك تتعلم العناكب بمرور الوقت هذا التغيير.
  7. تغيير تفضيلات محرك البحث مثل أدوات مشرفي المواقع من Google لتخصيص HTTPS
  8. حيثما أمكن ، تحمّل أي وسائط حافظة إلى خوادم HTTPS CDN.

إذا تمت معالجة ما ورد أعلاه ، فأنا أشك في أن لديك العديد من المشكلات.


49
2018-01-28 02:08



SPDY هو اقتراح جيد. يبدو أن هناك وحدة نمطية إضافة دعم SPDY إلى Apache 2.x. - Calrion
باستخدام "//yourserver.com/some-uri" بدلاً من "yourserver.com/some-uri"يحل المشكلة (1) لأن المستعرض سيختار المخطط المناسب (http أو https) بناءً على المخطط الذي تم تحميل الصفحة به. - MauganRa
MauganRa ما لم يكن ، بالطبع ، هو رابط من صفحة مقالة http إلى https صفحة تسجيل الدخول ، على سبيل المثال. - Mołot
يرى Google عنوان URL الذي يزوره شخص ما عبر Referer الرأس. على سبيل المثال ، يستخدم هذا الموقع jQuery من CDN في Google ، ويرسل المتصفح طلبًا إلى Google في كل مرة أقوم بإعادة تحميل الموقع. لذلك أ Referer يتم أيضًا إرسال العنوان إلى Google والذي تم تعيينه على عنوان URL لهذا الموقع. لذا يمكن لشركة Google تتبع المواقع التي أزورها أثناء تغيير عنوان IP الخاص بي (وإذا كنت أستخدم خدمة Google خلال هذا الوقت ، يمكن لـ Google أيضًا توصيل هذه المعلومات بحسابي في Google). - Stephan Kulla
ل 1) أنا فقط بحث واستبدال في http قاعدة بيانات MySQL ل HTTPS ... أنا باستخدام WordPress لذلك جعلت من السهل لتحديث مئات الروابط - JasonDavis


لقد قمت بإعداد https ثم يجب عليك استخدامه في كل مكان على الموقع. سوف تتجنب مخاطر مشاكل المحتوى المختلط وإذا كانت لديك الأدوات المطلوبة ، فلماذا لا تجعل الموقع بأكمله آمنًا؟

فيما يتعلق بإعادة التوجيه من http إلى https الجواب ليس بهذه البساطة.

ستؤدي إعادة التوجيه إلى تسهيل الأمر على المستخدمين ، فهم يكتبون فقط في whateversite.com ويتم إعادة توجيههم إلى https.

لكن. ماذا لو كان المستخدم في بعض الأحيان على شبكة غير آمنة (أو على مقربة من تروي هانت والأناناس له)؟ ثم سوف يطلب المستخدم http://whateversite.com من العادة القديمة. هذا هو HTTP. يمكن اختراق ذلك. قد تشير عملية إعادة التوجيه إلى https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. بالنسبة لمستخدم عادي ، يبدو الأمر شرعيًا تمامًا. ولكن يمكن اعتراض حركة المرور.

لذلك لدينا اثنين من المتطلبات المتنافسة هنا: لتكون سهلة الاستخدام وتكون آمنة. لحسن الحظ ، هناك علاج يسمى رأس HSTS. مع ذلك يمكنك تمكين إعادة التوجيه. سينتقل المتصفح إلى الموقع الآمن ، ولكن بفضل رأس HSTS تذكره أيضًا. عندما يكتب المستخدم في whateversite.com جالسًا على تلك الشبكة غير الآمنة ، سيذهب المتصفح إلى https على الفور ، دون المرور عبر إعادة التوجيه على http. أعتقد أنه لا يمكن التعامل مع بيانات حساسة للغاية ، إلا أن هذا هو المقايضة العادلة بين الأمان وسهولة الاستخدام لمعظم المواقع. (عندما قمت مؤخرًا بإعداد تطبيق يتعامل مع السجلات الطبية ، ذهبت إلى جميع https بدون إعادة توجيه). للأسف ، لا يتوفر لدى Internet Explorer أي دعم لـ HSTS (مصدر) ، لذلك إذا كان جمهورك المستهدف يستخدم في الغالب متصفح IE وكانت البيانات حساسة ، فقد تحتاج إلى تعطيل عمليات إعادة التوجيه.

لذلك إذا كنت لا تستهدف مستخدمي IE ، فانتقل إلى الأمام واستخدم إعادة التوجيه ، ولكن قم بتمكين رأس HSTS أيضًا.


38
2018-01-28 07:40



يحتاج المزيد من الناس إلى الانتباه إلى هذا أيضًا. شيء آخر هو أن الناس يفترضون أنهم آمنون لأن نقطة النهاية هي HTTPS ، متجاهلين حقيقة أن جميع المعلومات المرسلة إلى الصفحة في GETs أو POSTs هي في نص عادي. - Velox
Velox - لا أعتقد أن معنى "الناس يفترضون أنهم آمنون لأن نقطة النهاية هي HTTPS ، متجاهلين حقيقة أن جميع المعلومات التي يتم إرسالها إلى الصفحة في GETs أو POSTs في نص عادي" دقيقة للغاية. في حين أن هناك بعض gotchas ، لا تنتقل المعلمات الاستعلام GET في واضحة أثناء النقل عبر HTTPS. انظر على سبيل المثال: stackoverflow.com/questions/323200/... يتم حماية حمولات POST أيضًا ، بينما لا تكون عرضة أيضًا لرؤوس التسجيل والإحالة. - codingoutloud
codingoutloud هذه هي وجهة نظري. عبر HTTPS يتم تشفيرها ، ولكن في الطلب الأولي لصفحة HTTP لم تكن مشفرة. - Velox
Velox - إذا كان الموقع بأكمله يعيد التوجيه إلى HTTPS ، فمن غير المحتمل أن يتم إرسال معلمات GET قبل بدء تشغيل HTTPS (وسيبقى كل شيء HTTPS بعد تلك النقطة). لا يزال هناك طلب مبدئي واحد يتم فيه إرسال ملفات تعريف الارتباط ، والتي يمكن معالجتها باستخدام HSTS ... ونافذة هجوم صغيرة لـ SSLStrip ، والتي ربما يمكن هزيمتها بواسطة JavaScript ، ولكن هذا سباق تسلح خاص بها. - Brilliand
Brilliand نقطة عادلة ، ولكن نقطة ضعف في الأمن يجعل كل شيء ضعيف. دائما يستحق النظر. - Velox


لا يوجد شيء خطأ في هذا ، وفي الواقع أفضل الممارسات (بالنسبة للمواقع ينبغي يتم تقديمه عبر اتصال آمن). في الواقع ، ما تفعله مشابه جدًا للتهيئة التي أستخدمها:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

ال 301 رمز الحالة يشير إلى دائم إعادة التوجيه ، وإرشاد العملاء القادرين لاستخدام عنوان URL الآمن للاتصالات المستقبلية (على سبيل المثال ، تحديث الإشارة المرجعية).

إذا كنت ستخدم فقط الموقع عبر TLS / SSL ، فأنا أوصي بتوجيه إضافي لتمكين HTTP أمن النقل الدقيق (HSTS) في الخاص بك تأمين استضافة افتراضية:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

يرشد هذا الرأس العملاء القادرين (معظمهم في هذه الأيام ، أعتقد) أنه ينبغي عليهم ذلك استخدم HTTPS فقط مع المجال المقدم (secure.example.com، في هذه الحالة) في اليوم التالي 1234 ثواني. ال ; includeSubdomains جزء هو اختياري ويشير إلى أن التوجيه لا ينطبق فقط على النطاق الحالي ، ولكن ينطبق عليه أي توجيه (على سبيل المثال ، alpha.secure.example.com). لاحظ أن رأس HSTS هو فقط مقبولة من المتصفحات عند عرضها عبر اتصال SSL / TLS!

لاختبار تكوين الخادم الخاص بك ضد أفضل الممارسات الحالية ، يكون مورد مجاني جيد إختبار خادم SSL من Qualys الخدمات؛ سأسعى للحصول على درجة A- على الأقل (لا يمكنك الحصول على أكثر من ذلك مع Apache 2.2 بسبب عدم وجود دعم لتشفير المنحنى البيضاوي).


22
2018-01-28 02:20



يجب أن أضيف ، وأرسل الرأس Strict-Transport-Security: max-age=0 سيلغي أي توجيه سابق ؛ كما هو الحال دائما ، هذا يجب إرسالها عبر HTTPS ليتم قبولها ، ولكنها طريقة سهلة لإلغاء الأشياء إذا قررت أنك تحتاج أيضًا إلى استخدام HTTP على النطاق. - Calrion


رائع ! إعادة توجيه HTTP إلى HTTPS أمر جيد جدًا ولا يمكنني رؤية أي عيوب لذلك.

فقط تأكد من أن العملاء لديهم CA الصحيح لتجنب التحذيرات غير سهلة الاستخدام حول الشهادة في المستعرض.

بالإضافة إلى ذلك ، يبدو أن طريقة إعداد Apache لإعادة التوجيه إلى HTTPS جيدة.


5
2018-01-28 00:35





هل من السيئ إعادة توجيه http إلى https؟

لا ، على الإطلاق. في الواقع ، إنه أمر جيد القيام به!

على عمليات إعادة التوجيه:

يمكن أن يكون أكثر كفاءة ، من قبل القضاء تماما على إعادة الكتابة. وهنا التكوين الخاص بي على وضع مماثل ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS ليست مضمونة تمامًا. بطبيعة الحال ، عادةً ما يكون إجبار HTTPS أمر جيد. يمنع المجرمين العاديين من فعل أي شيء سيئ للمستخدمين.

ولكن يرجى تذكر التحقق من إعدادات SSL مثل إعداد SSLCiphers. تعطيل أشياء مثل تشفير RC4 و SSLv2 و SSLv3. أيضا ، يجب عليك معرفة ما إذا كانت libarys نظام التشفير للنظام دعم TLS1.2 (وهو الشيء الذي تريد أن يكون ؛))

قم بتشغيل SSL ، إنه شيء جيد.


4
2018-01-28 07:43



لا يتم استغلال Entropy (على الأقل إذا كنت تدافع ضد المهاجمين على الأرض عوضا عن تفعل الفودو). إما أنك تبدأ بالإنتروبيا غير الكافية ، ولا يمكنك فعل أي شيء يتطلب العشوائية ، أو تبدأ مع الإنتروبيا الكافية ، وتبقى لديك إنتروبيا كافية بغض النظر عن مقدار العشوائية التي تولدها. - Gilles
آسف، ماذا؟ هناك عدد من العمليات على لينكس التي تصر على الإنتروبيا القوية المستمدة من الأجهزة بدلاً من الإنتروبيا الكامنة في الـ PRNG ، والتي يمكن أن تحجب بالفعل إذا كان عمق البركة منخفضًا. من المؤكد أنه من الممكن أن تبدأ مع الإنتروبيا الكافية على نظام لينكس ، ولكن بالإفراط في الاستخدام لتصريف البركة ، مما يتسبب في عرقلة بعض العمليات. - MadHatter


أنا شخصياً أستخدم SSL لتأمين الاتصالات على الويب ، لكنني أشعر بأن هناك إجابات أخرى تفيد بأن جميع الإجابات الأخرى هي أنه لن يتمكن كل جهاز وقطعة من البرامج القادرة على اتصال HTTP من استخدام SSL ، وبالتالي ، سأفكر في توفير بعض الطريق للمستخدمين لتجنبه إذا لم يكن مدعمًا لهم. من الممكن أيضًا ألا يُسمح للأشخاص في بعض البلدان التي تكون فيها تقنية التشفير غير قانونية بالوصول إلى موقعك. سأفكر في إضافة صفحة مقصودة غير مشفرة تحتوي على رابط لإجبار النسخة غير الآمنة من الموقع ، ولكن ما لم يختار المستخدم تحديدًا ما يفعله كما قلته وقم فقط بإعادة توجيهه إلى إصدار HTTPS.


3
2018-01-28 10:13



هناك مشكلة في الحلول مثل وجود صفحة بسيطة على HTTP للهبوط ، حتى إذا تم فصلها بشكل صحيح ، وهي أن هذه الصفحة تبقى مفتوحة للتلاعب. أي ، ليس هناك ضمان فعلي بأن يتم تسليم رابط إصدار HTTPS للموقع للزائرين. - Håkan Lindqvist


فيما يلي بعض من مشاكل فرشاة الفرشاة:

  • MITM / SSLSTRIP: هذا هو تحذير ضخم. إذا كنت ستخدم موقعك عبر HTTPS ، ثم تعطيل HTTP على الموقع. بخلاف ذلك ، يمكنك ترك المستخدمين مفتوحين لهجمات متنوعة في المتصفحات بما في ذلك SSLSTRIP ، والتي ستقوم باعتراض الطلبات وتقديمها بهدوء عبر HTTP ، وإدخال نص برمجي خاص بها في البرنامج. إذا كان المستخدم لا يلاحظ ، فسوف يفعلون ذلك يفكر جلسة عملهم آمنة عندما لا تكون في الواقع.

    • ومع ذلك ، تكمن المشكلة في ذلك في أنه إذا كان موقعك موقعًا عامًا وكنت تعطل HTTP بشكل غير رسمي ، فقد تفقد الكثير من الزوار. ربما لن يكون كذلك تحدث بالنسبة لهم لتجربة HTTPS إذا لم يتم تحميل الموقع باستخدام HTTP.
  • إذا كان موقعك يتطلب تسجيل دخول آمن ، فيجب تأمين جلسة المستخدم بأكملها. لا تقم بالمصادقة عبر HTTPS ، ثم أعد توجيه المستخدم مرة أخرى إلى HTTP. إذا قمت بذلك ، مرة أخرى ، فأنت تترك المستخدمين عرضة لهجمات MITM. النهج القياسي للتوثيق في هذه الأيام هو المصادقة مرة واحدة ، ثم تمرير رمز مصادقة للخلف والأمام (في ملف تعريف الارتباط). ولكن إذا قمت بالمصادقة عبر HTTPS ثم أعدت التوجيه إلى HTTP ، فيمكن لرجل في الوسط اعتراض ملف تعريف الارتباط هذا واستخدام الموقع كما لو كان مستخدمك المصادق عليه ، متجاوزًا الأمان الخاص بك.

  • تعتبر مشكلات "الأداء" مع HTTPS لجميع الأغراض العملية تقتصر على المصافحة التي ينطوي عليها إنشاء اتصال جديد. افعل ما يمكنك لتقليل الحاجة إلى اتصالات HTTPS متعددة من عنوان URL وستكون على بعد أميال. وهذا صحيح بصراحة حتى إذا كنت تخدم محتواك عبر HTTP. إذا كنت تقرأ على SPDY ، فستدرك أن كل ما تفعله موجه نحو محاولة عرض كل المحتوى من عنوان URL واحد عبر اتصال واحد. نعم ، يؤثر استخدام HTTPS على التخزين المؤقت. ولكن ما عدد مواقع الويب التي تحتوي على محتوى ثابت قابل للتخزين مؤقتًا في هذه الأيام ، على أي حال؟ من المحتمل أن تحصل على المزيد من الدوي لباك الخاصة بك باستخدام التخزين المؤقت على خادم الويب الخاص بك للحد من استعلامات قاعدة البيانات المتكررة استرداد البيانات دون تغيير مرارا وتكرارا ، ومنع تنفيذ مسارات التعليمات البرمجية باهظة الثمن أكثر من اللازم.


3
2018-04-19 10:43



الشيء الذي يمكنك القيام به لمعالجة بالفعل sslstrip هو استخدام HSTS (preferrably الحصول على إعدادات HSTS الخاصة بك مسبقا). سواء كنت تقبل طلبات عبر بروتوكول HTTP عادي أو لا تهم في الواقع في هذا الصدد ، يمكن لـ MITM الإجابة عبر بروتوكول HTTP العادي (ربما بالوكيل إلى موقع HTTPS الخاص بك) حتى لو كنت لا تقبل سوى طلبات HTTPS. - Håkan Lindqvist
@ HåkanLindqvist أنا حقا حصل على downvote منك؟ هل أعطيت نصيحة سيئة أو نصيحة جيدة فيما يتعلق بعدم التصديق على HTTPS ثم التحول إلى HTTP لبقية الجلسة؟ هل قدمت نصيحة سيئة فيما يتعلق بأساطير أداء HTTPS؟ أيضًا ، إذا حاول العميل في البداية الاتصال باستخدام HTTPS ، فلا يمكن لـ MITM اعتراض الاستجابة والرد عليها دون تشغيل تنبيه في المتصفح ، لأن شهاداتهم لن تتطابق ما لم يكن لديهم شهادة مزورة أو مزورة بنجاح. من ناحية أخرى ، إذا كان الموقع يقبل اتصال HTTP ، فإن الاعتراض أسهل. في كلتا الحالتين ، يرفع HTTPS الشريط. - Craig
..و بالطبع أنا أوافق تماما مع استخدام HSTS. - Craig
مشكلتي في الإجابة هي أول عنصر في القائمة يدّعي أنه يعالج sslstrip بينما هو في الواقع لا (يتحدث عن الأساطير). ما كنت أحاول الحصول عليه في تعليقي الأولي هو أنه إذا كان لديك MITM نشط (وهو ما تحتاجه sslstrip في المقام الأول) ، يمكن للمهاجم أن يكون "الموقع" من منظور العميل. إنه المهاجم الذي يقرر ما إذا كان يريد قبول اتصالات HTTP العادية من العميل ، وكيف أن خادم الويب الفعلي الخاص بك يتصرف في هذا الصدد لا يؤثر على ما يمكن للمهاجم القيام به أو القيام به. - Håkan Lindqvist
@ HåkanLindqvist باستثناء أنه إذا كان الزائر يحاول عن قصد الاتصال بـ HTTPS ، لا يمكن للمهاجم تلبية هذا الطلب دون رمي الأعلام في المتصفح ، إلا إذا تمكنوا من سرقة شهادة الخادم أو بطريقة أو بأخرى إنشاء واحدة بنجاح ، والتي يتعين عليهم هل من أجل تبديل الاتصال إلى HTTP. HTTPS ما يزال يرفع العارضة. بالطبع إذا جعل الزائر محاولة الاتصال الأولية عبر HTTP ، فستتوقف جميع الرهانات تمامًا. - Craig


هذا ليس من الناحية الفنية إجابة لسؤالك الأصلي ، ولكن إذا كنت تستخدم إضافة Google Chrome HTTPSEverywhere (فأنا متأكد من وجود إضافات مشابهة في المتصفحات الأخرى) ، فإن الإضافة تعمل تلقائيًا على إعادة توجيه المواقع التي تحتوي على HTTP إلى الموقع نفسه باستخدام HTTPS. لقد كنت أستعمله منذ فترة ، ولم أواجه أي مشاكل (باستثناء التباطؤ ، لكني لم أختبر ذلك). يمكن تغيير HTTPSEverywhere بواسطة قواعد معينة على جانب الخادم ، ولكن بما أنني لم أفعل الكثير في هذا المجال ، فأنا لست متأكدًا من التفاصيل الدقيقة.

بالعودة إلى السؤال الفعلي ، إذا كنت تستخدم شيئًا مثل HTTPSEverywhere ، فهناك حافز أقل لاستخدام HTTP-only ، على الرغم من أنني أتخيل أنه من الصعب إعداد قواعد صحيحة عندما تحتاج إليها.


1
2018-01-28 04:27