معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 3: "تجاوزات العازلة: المآثر والحماية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 4: "فصل الامتيازات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 5: "من أين تأتي أنظمة الأمن؟"
الجزء 1 /
الجزء 2المحاضرة 6: "الفرص"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 7: "وضع حماية العميل الأصلي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 8: "نموذج أمن الشبكات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 9: "أمان تطبيق الويب"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 10: "التنفيذ الرمزي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 11: "لغة برمجة Ur / Web"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 12: أمن الشبكات
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 13: "بروتوكولات الشبكة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 14: "SSL و HTTPS"
الجزء 1 /
الجزء 2 /
الجزء 3 السبب الأول هو أن بروتوكول OCSP يضيف تأخيرًا لكل طلب تقدمه. في كل مرة ترغب في الاتصال بخادم ، تحتاج أولاً إلى الاتصال بـ OCSP ، وانتظر حتى يستجيب ، ثم تفعل شيئًا آخر. لذا فإن تأخيرات الاتصال لا تساهم في شعبية هذا البروتوكول.
السبب الثاني هو أنك لا تريد أن يؤثر OCSP على قدرتك على تصفح الويب. لنفترض أن خادم OSCP معطل ، وبعد ذلك قد تفقد الإنترنت تمامًا ، لأن البروتوكول يعتبر أنه نظرًا لأنه لا يمكن التحقق من شهادة شخص ما ، فقد تكون جميع المواقع على الإنترنت سيئة ولا يجب السماح لك بالذهاب إلى هناك. ولكن لا يحتاج أي شخص إلى ذلك ، لذا يرى معظم العملاء أن عدم تدخل خادم OCSP هو تطور إيجابي.
هذا أمر سيئ حقًا من الناحية الأمنية. لأنه إذا كنت مهاجمًا وتريد إقناع شخص ما أن لديك شهادة قانونية ، ولكن في الواقع تم إبطال هذه الشهادة ، فكل ما عليك فعله هو بطريقة ما منع العميل من الاتصال بخادم OCSP.
سيقول العميل هذا: "أحاول طلب التحقق من شهادة الموقع الذي أحتاجه ، ولكن يبدو أن OCSP هذا ليس قريبًا ، لذا أذهب فقط إلى هذا الموقع." لذا فإن استخدام OCSP ليس خطة جيدة.
من الناحية العملية ، يحاول الناس إنشاء هذا البديل ، لأن العملاء يميلون ببساطة إلى ارتكاب أخطاء خطيرة. لذلك ، على سبيل المثال ، يتم تسليم متصفح الويب Chrome إلى العميل ، حيث يوجد بالفعل داخله قائمة الشهادات التي تريد Google إبطالها حقًا. لذلك ، إذا أصدر شخص ما شهادة لـ Gmail أو موقع آخر مهم بشكل غير صحيح ، مثل Facebook أو Amazon ، فسيحتوي الإصدار التالي من Chrome بالفعل على هذه المعلومات في قائمة التحقق المضمنة. وبهذه الطريقة ، لا يتعين عليك الوصول إلى خادم CRL والتواصل مع OCSP. إذا تحقق المستعرض من أن الشهادة لم تعد صالحة ، يرفضها العميل.
الطالب: لنفترض أنني سرقت مفتاح CA السري ، لأنه لم يتم تشفير جميع المفاتيح العامة؟
البروفيسور: نعم ، سيكون لذلك عواقب وخيمة. لا أعتقد أن هناك أي حل لهذه المشكلة. بالطبع ، كانت هناك حالات تعرضت فيها مراكز الشهادات للخطر ، على سبيل المثال ، في عام 2011 كان هناك اثنين من مراجع التصديق المخترقة التي أصدرت شهادات بطريقة ما لـ Gmail و Facebook وما إلى ذلك. ليس من الواضح كيف حدث ذلك ، ربما سرق شخص ما مفتاحه السري حقًا. ولكن بغض النظر عن أسباب التسوية ، تمت إزالة مراجع التصديق هذه من قائمة المراجع المصدقة الموثوقة ، والتي تم إنشاؤها في المتصفحات ، لذلك لم تعد في الإصدار التالي من Chrome.
في الواقع ، تسبب ذلك في مشاكل للمالكين الشرعيين للشهادات الصادرة عن هذه المراكز ، لأن شهاداتهم السابقة أصبحت باطلة وكان عليهم الحصول على شهادات جديدة. لذا من الناحية العملية ، كل هذه الضجة مع الشهادات هي مسألة مربكة إلى حد ما.
لذا ، قمنا بفحص المبدأ العام للشهادات. إنهم أفضل من Kerberos بمعنى أنك لم تعد بحاجة إلى هذا الرجل ليكون متصلاً طوال الوقت. بالإضافة إلى ذلك ، فهي أكثر قابلية للتطوير ، لأنه يمكن أن يكون لديك العديد من KDCs ولا تحتاج للتواصل معهم في كل مرة تقوم فيها بإنشاء اتصال.
ميزة أخرى مثيرة للاهتمام في هذا البروتوكول هي أنه بخلاف Kerberos ، لست مطالبًا بمصادقة جانبي الاتصال. يمكنك الاتصال بخادم الويب دون الحصول على شهادة لنفسك ، وهذا يحدث طوال الوقت. إذا ذهبت إلى amazon.com ، فسوف تتحقق من أن Amazon هو الموقع الصحيح ، لكن Amazon ليس لديها أي فكرة عن هويتك ولن تعرف عنه حتى تقوم بالمصادقة على الموقع. وبالتالي ، على مستوى بروتوكول التشفير ليس لديك شهادة ، لكن Amazon لديها شهادة.
هذا أفضل بكثير من Kerberos ، لأنه يجب أن يكون لديك إدخال في قاعدة البيانات الخاصة به من أجل الاتصال بخدمات Kerberos. الإزعاج الوحيد لاستخدام هذا البروتوكول هو أن الخادم يجب أن يكون لديه شهادة. لذا لا يمكنك الاتصال بالخادم وقول "مرحبًا ، لنقم فقط بتشفير أغراضنا. ليس لدي أي فكرة عن هويتك ، ولكن ليس لديك أي فكرة عن هويتي ، ولكن دعنا نقوم بتشفيرها على أي حال. " يسمى هذا التشفير الانتهازي ، وبالطبع ، فإنه عرضة لهجمات الرجل في الوسط. يمكنك تشفير الأشياء الشائعة مع شخص ما ، دون معرفته ، ثم المهاجم الذي يستعد للهجوم ، يمكنك أيضًا تشفير حزمه لاحقًا وحماية نفسه من التطفل.
لذا من المؤسف أن هذه البروتوكولات التي نعتبرها هنا - SSL ، TLS - لا تقدم هذا النوع من التشفير الانتهازي. لكن هذه هي الحياة.
الطالب: أنا فضولي فقط. دعنا نقول فقط أنه مرة في السنة ، يقومون بإنشاء أزواج رئيسية بأسماء جديدة. لماذا لا تحاول استخدام هذا المفتاح الخاص طوال العام؟
الأستاذ: أعتقد أنهم يفعلون ذلك. ولكن يبدو أن هناك خطأ ما في هذه الدائرة. هنا ، كما هو الحال مع Kerberos ، يبدأ الناس باستخدام التشفير القوي ، ولكن بمرور الوقت يزداد الأمر سوءًا. أصبحت أجهزة الكمبيوتر أسرع ، ويجري تطوير خوارزميات جديدة تنجح في كسر هذا التشفير. وإذا لم يهتم الناس بتحسين الموثوقية ، فستزداد المشاكل. لذلك ، على سبيل المثال ، يحدث عندما يتم توقيع عدد كبير من الشهادات.
هناك نوعان من الفروق الدقيقة هنا. يوجد مخطط توقيع مفتاح عام. علاوة على ذلك ، نظرًا لأن المفتاح العام المشفر له بعض القيود ، عند توقيع رسالة ، في الواقع ، يتم توقيع تجزئة هذه الرسالة فقط ، لأنه من الصعب توقيع رسالة عملاقة ، ولكن من السهل توقيع تجزئة مضغوطة.
نشأت المشكلة لأن الأشخاص استخدموا MD5 كدالة تجزئة ، مما أدى إلى تحويل توقيع رسالة ضخمة إلى شيء 128 بت تم تشفيره. ربما كان MD5 جيدًا قبل 20 عامًا ، ولكن بمرور الوقت ، اكتشف الناس نقاط ضعف فيه يمكن أن يستغلها مهاجم.
لنفترض في وقت ما أن شخصًا ما قد طلب حقًا الحصول على شهادة بتجزئة MD5 محددة ، ثم قام بتحليل رسالة أخرى بعناية تم تجزئتها بنفس قيمة MD5. ونتيجة لذلك ، كان لديه توقيع CA مجزأ ، ثم ظهرت رسالة أخرى ، أو مفتاح مختلف ، أو اسم مختلف ، والآن يمكنه إقناع شخص ما بأنه تم توقيعه بالشهادة الصحيحة. وهذا يحدث بالفعل. على سبيل المثال ، إذا كنت تقضي الكثير من الوقت في محاولة كسر مفتاح واحد ، فسوف تنجح في النهاية. إذا كانت هذه الشهادة تستخدم التشفير ، فيمكن تصدعها باستخدام طريقة القوة الغاشمة.
مثال آخر على الاستخدام غير الناجح للتشفير هو خوارزمية RSA. لم نتحدث عن RSA ، ولكن RSA هو أحد أنظمة التشفير ذات المفتاح العام التي تسمح لك بتشفير الرسائل وتوقيعها. في هذه الأيام ، يمكنك إنفاق الكثير من المال ، ولكن في النهاية ، قم بكسر مفاتيح RSA 1000 بت. ربما ستضطر إلى القيام بقدر كبير من العمل ، ولكن من السهل القيام بذلك على مدار العام. يمكنك أن تطلب من المرجع المصدق توقيع رسالة أو حتى أخذ المفتاح العام الحالي لشخص ما ، أو محاولة العثور على المفتاح السري المناسب لها ، أو اختراقها يدويًا.
وبالتالي ، يجب عليك مواكبة المهاجم ، يجب عليك استخدام مفاتيح RSA أكبر أو استخدام نظام تشفير مختلف.
على سبيل المثال ، لا يستخدم الأشخاص الآن تجزئات وشهادات MD5. يستخدمون خوارزمية التجزئة المشفرة SHA-1. لبعض الوقت وفرت الأمن اللازم ، لكنها اليوم دفاع ضعيف. الآن تحاول Google بنشاط إجبار مطوري الويب والمتصفحين على التخلي عن استخدام SHA-1 واستخدام وظيفة تجزئة مختلفة ، لأنه من الواضح تمامًا أنه ربما بعد 5 أو 10 سنوات لن يكون من الصعب مهاجمة SHA-1 بنجاح. وقد ثبت بالفعل ضعفه.
لذا ، أعتقد أن الرصاصة السحرية على هذا النحو غير موجودة. عليك فقط التأكد من أنك تواصل التطور بالتوازي مع المتسللين. بالطبع ، المشكلة موجودة. لذلك ، يجب أن تستند جميع الأشياء التي تحدثنا عنها إلى التشفير المناسب ، أو إلى حقيقة أنه من الصعب جدًا كسرها. لذلك ، يجب عليك اختيار الخيارات المناسبة. على الأقل يوجد تاريخ انتهاء الصلاحية ، لذا من الأفضل اختيار تاريخ انتهاء الصلاحية لسنة واحدة بدلاً من 10 سنوات.
يخلق مفتاح المرجع المصدق هذا مشكلة أكثر خطورة ، لأنه ليس له تاريخ انتهاء صلاحية. لذلك ، يجب عليك اختيار إعدادات أمان أكثر قوة ، على سبيل المثال ، مفاتيح RSA 4000 أو 6000 بت ، أو أي شيء آخر. أو مخطط تشفير مختلف ، أو جميعها معًا ، ولكن لا تستخدم SHA-1 هنا.
الآن دعونا نرى كيف ندمج هذا البروتوكول في تطبيق معين ، وهو متصفح الويب. إذا كنت ترغب في توفير اتصال بالشبكة أو اتصال بالمواقع التي تستخدم التشفير ، فهناك ثلاثة أشياء في المتصفح يجب أن نحميها.
أول شيء ، A هو حماية البيانات على الشبكة. هذا أمر سهل نسبيًا لأننا سنقوم فقط بتشغيل بروتوكول مشابه جدًا للبروتوكول الذي وصفته حتى الآن. سنقوم بتشفير جميع الرسائل ، والتوقيع عليها ، والتأكد من عدم العبث بها ، بشكل عام ، سنقوم بكل هذه الأشياء الرائعة. هكذا نحمي البيانات.
ولكن هناك شيئان آخران في متصفح الويب نحتاج حقًا إلى القلق بشأنهما. لذا ، الأول ، B ، هو الرمز المستخدم في المتصفح ، على سبيل المثال ، JavaScript أو البيانات الهامة المخزنة في المتصفح أو ملفات تعريف الارتباط أو التخزين المحلي ، كل هذا يجب أن يكون محميًا بطريقة ما من المتسللين. في ثانية سأخبرك كيف تحميهم.
آخر شيء ، C ، والذي لا تفكر فيه كثيرًا ، ولكن ما قد يتبين أنه مشكلة حقيقية في الممارسة العملية ، هو حماية واجهة المستخدم. والسبب في ذلك هو أن معظم البيانات السرية التي نهتم بها للحماية تأتي في النهاية من المستخدم. لذلك ، يطبع المستخدم البيانات على بعض المواقع ، وربما يكون لديه العديد من علامات التبويب للمواقع المختلفة المفتوحة في وقت واحد ، لذلك يحتاج إلى أن يكون قادرًا على تمييز الموقع الذي يتفاعل معه بالفعل ، في أي وقت.
إذا قام عن طريق الخطأ بإدخال كلمة مرور Amazon في بعض منتدى الويب ، فلن يؤدي هذا إلى عواقب وخيمة ، اعتمادًا على مدى اهتمامه بكلمة مرور Amazon الخاصة به ، ولكن لا يزال الأمر غير سار. لذلك ، تريد حقًا أن يكون لديك واجهة مستخدم جيدة تساعد المستخدم على فهم ما يفعله ، سواء كان يطبع بيانات حساسة على الموقع الصحيح وإذا حدث شيء ما لهذه البيانات بعد أن يرسلها. لذلك اتضح أن هذه مشكلة مهمة جدًا لحماية تطبيقات الويب.
لذا ، لنتحدث عما تفعله المتصفحات الحديثة بهذه الأشياء A و B و C. كما ذكرت ، لحماية البيانات على الشبكة ، سنستخدم ببساطة هذا البروتوكول ، المسمى SSL أو TLS ، إذا تم استخدام التشفير ومصادقة البيانات.
هذا مشابه جدًا لما ناقشناه ، ويتضمن مراجع التصديق وما إلى ذلك. وبعد ذلك ، بالطبع ، هناك المزيد من التفاصيل. على سبيل المثال ، TLS معقد للغاية ، لكننا لن نعتبره من وجهة النظر هذه. سنركز على حماية المتصفح ، وهو أمر أكثر إثارة للاهتمام. نحتاج إلى التأكد من أن أي رمز أو بيانات يتم تسليمها عبر اتصالات غير مشفرة غير قادرة على تغيير التعليمات البرمجية والبيانات التي يتم تلقيها من اتصال مشفر ، لأن نموذج التهديد الخاص بنا بحيث يمكن العبث بجميع البيانات غير المشفرة بواسطة مهاجم عبر الشبكة.
لذلك إذا كان لدينا نوع من كود جافا سكريبت غير مشفر يعمل في متصفحنا ، فيجب أن نفترض أنه ربما تم العبث به من قبل مهاجم لأنه لم يتم تشفيره. لم يتم المصادقة عبر الشبكة. وبالتالي ، يجب علينا منع تدخلها من أي صفحة تم تسليمها من خلال اتصال غير مشفر.
وبالتالي ، فإن الخطة العامة هي أننا سنقدم لهذا مخططًا جديدًا لعناوين URL ، والذي سنطلق عليه HTTPS. غالبًا ما ترى هذا في عناوين URL. مخطط عنوان URL الجديد هو أن عناوين URL هذه تختلف ببساطة عن عناوين HTTP. لذلك إذا كان لديك عنوان URL مع HTTPS: // ، فهذا يعني أن مصدره مختلف عن عناوين URL HTTP العادية ، لأن الأخيرة تمر عبر تصحيحات غير مشفرة ، فإنها تمر عبر SSL / TLS. وبهذه الطريقة لن تخلط أبدًا بين هذه الأنواع من العناوين إذا كانت سياسة المنشأ نفسها تعمل بشكل صحيح.
هذه قطعة من اللغز. ولكن بعد ذلك ، تحتاج أيضًا إلى التأكد من أنك تميز المواقع المشفرة عن بعضها بشكل صحيح ، لأنها تستخدم لأسباب مختلفة سياسات ملفات تعريف الارتباط لأسباب تاريخية. لذلك دعونا نتحدث أولاً عن كيفية تمييز المواقع المشفرة المختلفة عن بعضها البعض.
الخطة هي أن يكون اسم المضيف من خلال عنوان URL هو الاسم في الشهادة. في الواقع ، اتضح أن سلطات التصديق ستوقع اسم المضيف ، الذي يظهر في عنوان URL كاسم المفتاح العام لخادم الويب. على هذا النحو ، يزعم أن أمازون حاصلة على شهادة
www.amazon.com . هذا هو الاسم في جدولنا الذي يحتوي على المفتاح العام المطابق لمفتاحهم الخاص.
هذا ما سيبحث عنه المتصفح. لذا ، إذا حصل على شهادة ، إذا حاول الاتصال أو الحصول على
عنوان URL لـ foo.com ، فهذا يعني أن الخادم يمثل بدقة شهادة foo.com الأصلية. خلاف ذلك ، على سبيل المثال ، حاولنا الاتصال بشخص ، واتصلنا بشخص آخر ، لأنه يحمل اسمًا مختلفًا تمامًا في الشهادة التي اتصلنا بها. سيكون هذا عدم تطابق الشهادة.
إليك كيفية تمييز المواقع المختلفة عن بعضها البعض: سنجلب CA إلى هذا لمساعدتنا في تمييز هذه المواقع عن بعضها البعض ، لأن CAs تعد بإصدار الشهادات فقط لأعضاء الشبكة المناسبين. إذن هذا جزء من سياسة المنشأ نفسها ، والتي نقسم بموجبها الشفرة إلى أجزاء. كما تتذكر ، فإن ملفات تعريف الارتباط لديها سياسة مختلفة قليلاً. إنها تقريبًا من نفس المصدر ، ولكن ليس تمامًا ، ملفات تعريف الارتباط لها خطة مختلفة قليلاً. تحتوي ملفات تعريف الارتباط على ما يسمى بعلامة الأمان ، العلم الآمن. القاعدة هي أنه إذا كانت ملفات تعريف الارتباط تحتوي على هذه العلامة ، فيتم إرسالها فقط استجابة لطلبات HTTPS أو مع طلبات HTTPS. ترتبط ملفات تعريف الارتباط التي تحمل أو لا تحمل علامة الأمان بعضها البعض كطلبات https و http.
هذا معقد بعض الشيء. سيكون من الأسهل إذا أشار ملف تعريف الارتباط ببساطة إلى أنه كان ملف تعريف ارتباط لمضيف HTTPS ، وكان ملف تعريف ارتباط لمضيف HTTP ، وكانت مختلفة تمامًا. سيكون هذا واضحًا جدًا من حيث عزل المواقع الآمنة عن المواقع غير الآمنة. للأسف ، لأسباب تاريخية ، تستخدم ملفات تعريف الارتباط هذا النوع الغريب من التفاعل.
لذلك ، إذا تم وضع علامة آمنة على ملف تعريف الارتباط ، فإنه ينطبق فقط على مواقع HTTPS ، أي أنه يحتوي على المضيف الصحيح. تنطبق ملفات تعريف الارتباط الآمنة فقط على عناوين URL لمضيف HTTPS ، بينما تنطبق ملفات تعريف الارتباط غير الآمنة على كلا النوعين من عناوين URL ، لكل من https و http ، لذلك في غضون ثانية واحدة فقط سيصبح هذا مصدرًا للمشكلات بالنسبة لنا.
واللمسة الأخيرة التي وضعتها متصفحات الويب لمساعدتنا في هذا الصدد هي جانب واجهة المستخدم التي سيقومون فيها بإدخال نوع من رمز القفل حتى يتمكن المستخدمون من رؤيته. وبالتالي ، يجب الانتباه إلى رمز القفل في شريط عنوان المتصفح وعنوان URL لمعرفة الموقع الذي توجد فيه بالفعل.
يتوقع مطورو متصفح الويب أنك ستتصرف بهذه الطريقة: بمجرد الوصول إلى بعض مواقع الويب ، ستنظر أولاً إلى عنوان URL وتأكد من أن هذا هو اسم المضيف الذي تريد التحدث إليه ، ثم ستجد رمز القفل و نفهم أن كل شيء على ما يرام. هذا جانب من واجهة مستخدم المتصفح.
ومع ذلك ، هذا لا يكفي. اتضح أن العديد من مواقع التصيد ستضم ببساطة صورة رمز القفل في الموقع نفسه ، ولكنها تستخدم عنوان URL مختلفًا. وإذا كنت لا تعرف عنوان هذا الموقع ، فقد يتم خداعك. بهذا المعنى ، فإن هذا الجانب من واجهة المستخدم مربك قليلاً ، ويرجع ذلك جزئيًا إلى أن المستخدمين أنفسهم غالبًا ما يكونون مرتبكين. لذا من الصعب أن نقول ما هنا. لذلك ، سنركز بشكل رئيسي على الجانب الثاني ، ب ، والذي من المؤكد أنه أسهل للمناقشة. هل لديك أسئلة حول هذا؟
الطالب: لاحظت أن بعض المواقع تتغير بمرور الوقت من HTTP إلى HTTPS.
البروفيسور: نعم ، تتطور المتصفحات بمرور الوقت ، وهذا ما يؤكد حقيقة حصولها على رمز القفل. تقوم بعض المتصفحات بتعيين رمز القفل فقط إذا تم أيضًا نقل كل المحتوى أو جميع الموارد على صفحتك عبر https. لذا فإن إحدى المشكلات التي تحاول HTTPS حلها بالقوة هي المحتوى المختلط أو المشكلات المتعلقة بأنواع المحتوى غير الآمنة المضمنة في الصفحة. لذلك ، في بعض الأحيان لن تتمكن من الحصول على رمز القفل بسبب هذا الاختيار. إذا اعتبر متصفح Chrome أن شهادة الموقع ليست جيدة بما يكفي وتستخدم تشفيرًا ضعيفًا ، فلن يمنحك رمز قفل. ومع ذلك ، تعمل المتصفحات المختلفة بشكل مختلف ، وإذا لم يمنحك Chrome رمز قفل ، فيمكن لـ Firefox ذلك. وبالتالي ، مرة أخرى ، لا يوجد تعريف واضح لما يعنيه رمز القفل هذا.
دعونا نرى المشاكل التي قد تنشأ عند تنفيذ هذه الخطة. في HTTP العادي ، اعتدنا على الاعتماد على DNS ، والذي يجب أن يعطينا عنوان IP الصحيح على الخادم. DNS HTTPS URL-? DNS DNS?
: , , , IP-.
: , , , amazon.com.
: , - amazon.com, IP-.
: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?
: , HTTPS?
: , , .
: , HTTP URL.
: , HTTPS, .
: .
: , . . , CA, , , , - , .
, - https , - , , , , , , .
HTTPS , - . , . , , , . -. « , ». , , , - , . , - .
, , , . , amazon.com
www.amazon.com , , , .
-, , , . , : „ , , , , ». , - , . .
, DNS, , , .
, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .
, — , ? , , ? , ?
: , - , . , .
: , , , , , , : « »! , , - , , , , . , .
: , .
: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .
, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .
52:10
MIT « ». 14: «SSL HTTPS», 3.
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30 ٪ لمستخدمي Habr على نظير فريد من خوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجابايت DDR4).
VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps حتى ديسمبر مجانًا عند الدفع لمدة ستة أشهر ، يمكنك الطلب
هنا .
ديل R730xd أرخص مرتين؟ فقط لدينا
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن
كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟