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

ما هو SSL وما هو TLS؟

SSL - طبقة المقابس الآمنة، وهي طبقة من المقابس الآمنة. TLS - أمان طبقة النقل، الأمان طبقة النقل. SSL هو أكثر من ذلك النظام المبكر، جاء TLS لاحقًا ويعتمد على مواصفات SSL 3.0 التي طورتها شركة Netscape Communications. ومع ذلك، فإن لهذه البروتوكولات مهمة واحدة - ضمان النقل الآمن للبيانات بين جهازي كمبيوتر على الإنترنت. يستخدم هذا النقل لمواقع مختلفة، ل بريد إلكترونيللمراسلة وأكثر من ذلك بكثير. من حيث المبدأ، يمكنك نقل أي معلومات بهذه الطريقة، المزيد عن ذلك أدناه.

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

SSL 1.0 - لم يتم نشره مطلقًا
SSL 2.0 – فبراير 1995
طبقة المقابس الآمنة 3.0 - 1996
TLS 1.0 - يناير 1999
TLS 1.1 - أبريل 2006
TLS 1.2 – أغسطس 2008

كيف تعمل SSL وTLS

مبدأ تشغيل SSL وTLS، كما قلت، هو نفسه. يتم إنشاء قناة مشفرة أعلى بروتوكول TCP/IP، حيث يتم نقل البيانات عبر بروتوكول التطبيق - HTTP، وFTP، وما إلى ذلك. وإليك كيفية تمثيلها بيانياً:

يتم تغليف بروتوكول التطبيق في TLS/SSL، والذي بدوره يتم تغليفه في TCP/IP. بشكل أساسي، يتم نقل بيانات بروتوكول التطبيق عبر TCP/IP، ولكنها مشفرة. ولا يستطيع فك تشفير البيانات المرسلة إلا الجهاز الذي أنشأ الاتصال. لكل من يتلقى الحزم المنقولةستكون هذه المعلومات بلا معنى إذا لم يتمكنوا من فك شفرتها.

يتم إنشاء الاتصال على عدة مراحل:

1) يقوم العميل بإنشاء اتصال بالخادم ويطلب اتصالاً آمنًا. يمكن تحقيق ذلك إما عن طريق إنشاء اتصال بمنفذ مخصص في البداية للعمل مع SSL/TLS، على سبيل المثال، 443، أو بالإضافة إلى ذلك من خلال مطالبة العميل بإنشاء اتصال آمن بعد إنشاء اتصال عادي.

2) عند إنشاء اتصال، يقدم العميل قائمة بخوارزميات التشفير التي "يعرفها". يتحقق الخادم من القائمة المستلمة بقائمة الخوارزميات التي "يعرفها" الخادم نفسه ويختارها أكثر من غيرها خوارزمية موثوقة، ثم يخبر العميل بالخوارزمية التي يجب استخدامه

3) يرسل الخادم للعميل شهادته الرقمية، موقعة من جهة التصديق، والمفتاح العام للخادم.

4) يمكن للعميل الاتصال بخادم المرجع المصدق الموثوق الذي وقع على شهادة الخادم والتحقق مما إذا كانت شهادة الخادم صالحة. ولكن ربما لا. عادةً ما يكون نظام التشغيل مثبتًا بالفعل شهادات الجذرالسلطات المصدقة التي يتم من خلالها التحقق من توقيعات شهادات الخادم، على سبيل المثال، المتصفحات.

5) يتم إنشاء مفتاح الجلسة للاتصال الآمن. تم التنفيذ بالطريقة الآتية:
- يقوم العميل بإنشاء تسلسل رقمي عشوائي
- يقوم العميل بتشفيرها بالمفتاح العام للخادم ويرسل النتيجة إلى الخادم
- يقوم الخادم بفك تشفير التسلسل المستلم باستخدام المفتاح الخاص
ونظرًا لأن خوارزمية التشفير غير متماثلة، فيمكن للخادم فقط فك تشفير التسلسل. استخدام التشفير غير المتماثليتم استخدام مفتاحين - خاص وعام. يتم تشفير الرسالة المرسلة بشكل عام، ويتم فك تشفير الرسالة المرسلة بشكل خاص. من المستحيل فك تشفير رسالة إذا كان لديك مفتاح عام.

6) يؤدي هذا إلى إنشاء اتصال مشفر. يتم تشفير البيانات المنقولة عبرها وفك تشفيرها حتى يتم إنهاء الاتصال.

شهادة الجذر

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

طلب التوقيع (CSR، طلب توقيع الشهادة)

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

شهادة العميل

يمكن إنشاء شهادة عميل لاستخدام كل من الجهاز والمستخدم. عادةً، يتم استخدام هذه الشهادات في التحقق ثنائي الاتجاه، حيث يتحقق العميل من أن الخادم هو الذي يقوله، ويفعل الخادم نفس الشيء في المقابل. يُسمى هذا التفاعل بالمصادقة الثنائية أو المصادقة المتبادلة. تعمل المصادقة ثنائية الاتجاه على تحسين مستوى الأمان مقارنة بالمصادقة أحادية الاتجاه، ويمكن أيضًا أن تكون بمثابة بديل للمصادقة باستخدام تسجيل الدخول وكلمة المرور.

سلسلة الإجراءات لإنشاء الشهادات

دعونا نلقي نظرة عملية على كيفية حدوث الإجراءات المرتبطة بإنشاء الشهادات منذ البداية، وفي الممارسة العملية.

أول شيء يجب فعله هو إنشاء شهادة جذر. الشهادة الجذرية موقعة ذاتيًا. ومن ثم سيتم توقيع شهادات أخرى بهذه الشهادة.

$ openssl genrsa -out root.key 2048 إنشاء مفتاح خاص RSA، معامل طويل 2048 بت .......+++ ....... ............... .........+++ e هو 65537 (0x10001) $ openssl req -new -key root.key -out root.csr أنت على وشك أن يُطلب منك إدخال المعلومات التي سيتم دمجها في طلب الشهادة الخاص بك . ماذا أنتعلى وشك الدخول هو ما يسمى بالاسم المميز أو الاسم المميز. هناك عدد لا بأس به من الحقول ولكن يمكنك ترك بعضها فارغًا. بالنسبة لبعض الحقول ستكون هناك قيمة افتراضية، إذا قمت بإدخال "."، فسيتم ترك الحقل فارغًا. ----- اسم البلد (رمز مكون من حرفين): اسم الولاية أو المقاطعة RU (الاسم الكامل): غير متوفر اسم المنطقة المحلية (على سبيل المثال، المدينة): سان بطرسبرج اسم المنظمة (على سبيل المثال، الشركة): اسم الوحدة التنظيمية لشركتي (على سبيل المثال، القسم): الاسم الشائع لخدمة تكنولوجيا المعلومات (على سبيل المثال، FQDN للخادم أو اسمك): عنوان البريد الإلكتروني لشهادة الجذر لشركتي: [البريد الإلكتروني محمي]لو سمحت دخولالسمات "الإضافية" التالية التي سيتم إرسالها مع طلب الشهادة الخاص بك كلمة مرور التحدي: اسم شركة اختياري: شركتي $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem التوقيع موافق الموضوع= /C=RU/ST=N/A/L=Saint-Petersburg/O=شركتي/OU=خدمة تكنولوجيا المعلومات/CN=الشهادة الجذرية لشركتي/ [البريد الإلكتروني محمي]الحصول على المفتاح الخاص

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

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

عرض معلومات الشهادة

ويمكن الاطلاع على محتويات الشهادة على النحو التالي:

$ openssl x509 -noout -issuer -enddate -in root.pem source= /C=RU/ST=N/A/L=Saint-Petersburg/O=شركتي/OU=خدمة تكنولوجيا المعلومات/CN=شهادة الجذر لشركتي/ [البريد الإلكتروني محمي] notAfter=22 يناير 11:49:41 2025 بتوقيت جرينتش

نرى من أصدر هذه الشهادة ومتى ينتهي تاريخ انتهاء صلاحيتها.

شهادة الخادم

لتوقيع شهادة للخادم علينا القيام بما يلي:

1) إنشاء مفتاح
2) إنشاء طلب التوقيع
3) أرسل ملف CSR إلى مركز الترخيص أو قم بالتوقيع عليه بنفسك

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

$ openssl genrsa -out server.key 2048 إنشاء مفتاح خاص لـ RSA، معامل طويل 2048 بت ......................... ....... ............................................... . ++ ..........................................+++ e هو 65537 (0x10001) $ openssl req -new -key server.key - out server .csr أنت على وشك أن يُطلب منك إدخال المعلومات التي سيتم دمجها في طلب الشهادة الخاص بك. ما أنت على وشك إدخاله هو ما يسمى بالاسم المميز أو الاسم المميز (DN). هناك عدد لا بأس به من الحقول ولكن يمكنك ترك بعضها فارغًا. بالنسبة لبعض الحقول ستكون هناك قيمة افتراضية، إذا قمت بإدخال "."، فسيتم ترك الحقل فارغًا. ----- اسم البلد (رمز مكون من حرفين): اسم الولاية أو المقاطعة RU (الاسم الكامل): غير متوفر اسم المنطقة المحلية (على سبيل المثال، المدينة): سان بطرسبرج اسم المنظمة (على سبيل المثال، الشركة): اسم الوحدة التنظيمية لشركتي (على سبيل المثال، القسم): الاسم الشائع لخدمة تكنولوجيا المعلومات (على سبيل المثال، FQDN للخادم أو اسمك): www.mycompany.com عنوان البريد الإلكتروني: [البريد الإلكتروني محمي]تفضل الأتىالسمات "الإضافية" التي سيتم إرسالها مع طلب الشهادة الخاص بك كلمة مرور التحدي: اسم شركة اختياري: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 التوقيع موافق الموضوع=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [البريد الإلكتروني محمي]الحصول على مفتاح CA الخاص $ openssl x509 -noout -issuer -subject -enddate -in server.pem source= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =الشهادة الجذرية لشركتي/ [البريد الإلكتروني محمي] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=شركتي/OU=خدمة تكنولوجيا المعلومات/CN=www.mycompany.com/ [البريد الإلكتروني محمي] notAfter=25 يناير 12:22:32 2016 بتوقيت جرينتش

بهذه الطريقة يتم توقيع شهادة الخادم وسنعرف الجهة التي أصدرت هذه الشهادة. بعد التوقيع، يمكن استخدام الشهادة النهائية للغرض المقصود منها، على سبيل المثال، تثبيتها على خادم الويب.

تثبيت شهادة SSL/TLS على خادم باستخدام nginx

لتثبيت شهادة SSL/TLS على خادم الويب إنجينكسعليك اتباع بعض الخطوات البسيطة:

1) انسخ ملفات .key و .pem إلى الخادم. في أنظمة التشغيل المختلفة، قد يتم تخزين الشهادات والمفاتيح في أدلة مختلفة. في دبيان، على سبيل المثال، هذا هو الدليل /etc/ssl/certs للشهادات و/etc/ssl/private للمفاتيح. في CentOS، هذا هو /etc/pki/tls/certs و /etc/pki/tls/private

2) أدخل الإعدادات اللازمة في ملف الضبطللمضيف. هذا ما ينبغي أن يبدو عليه تقريبًا (مجرد مثال):

الخادم ( استمع 443; اسم الخادم www.mycompany.com; جذر html; فهرس الفهرس html.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 غير مستحسن!!! # إنه هنا على سبيل المثال فقط ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on ) )

3) أعد تشغيل nginx

4) انتقل إلى منفذ الخادم 443 باستخدام المتصفح - https://www.mycompany.com وتحقق من وظائفه.

تثبيت شهادة SSL/TLS على خادم يقوم بتشغيل Apache

يبدو تثبيت شهادة SSL/TLS على Apache مشابهًا.

1) انسخ ملفات المفتاح والشهادة إلى الخادم في الدلائل المناسبة

2) قم بتمكين وحدة ssl لـ Apache باستخدام الأمر "a2enmod ssl" إذا لم يتم تمكينها بالفعل

3) قم بإنشاء مضيف افتراضي يستمع إلى المنفذ 443. سيبدو التكوين كما يلي:

مسؤول الخادم [البريد الإلكتروني محمي] DocumentRoot /var/www خيارات FollowSymLinks لا تسمح بالتجاوز لا شيء فهارس الخيارات FollowSymLinks MultiViews السماح بالتجاوز لا شيء ترتيب السماح، رفض السماح من الكلالاسم المستعار للبرنامج النصي /cgi-bin/ /usr/lib/cgi-bin/ السماح بتجاوز لا شيء خيارات +ExecCGI -MultiViews +SymLinksIfOwnerMatch ترتيب السماح، رفض السماح من الكل ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel تحذير CustomLog $(APACHE_LOG_DIR)/ssl_access.log دمج SSLEngine على SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # يضيف هذا التوجيه ملف يحتوي على قائمة # بجميع الشهادات التي وقعت على شهادة الخادم #SSLCertificateChainFile /etc/Apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE" ssl-unclean-shutdown

وفي الوقت نفسه، هناك شيء آخر يجب القيام به. ابحث في الملف httpd.conf، أو apache2.conf، أوports.conf، حسب النظام، عن القسم التالي من التكوين:

استمع 443

إذا لم يكن هناك مثل هذا الشرط، فيجب إضافته إلى التكوين. وشيء آخر: تحتاج إلى إضافة السطر

الاسم VirtualHost *:443

قد يكون هذا السطر موجودًا في ملف httpd.conf أو apache2.conf أوports.conf

4) أعد تشغيل خادم الويب Apache

إنشاء شهادة العميل

يتم إنشاء شهادة العميل بنفس طريقة إنشاء شهادة الخادم.

$ openssl genrsa -out client.key 2048 إنشاء مفتاح خاص لـ RSA، معامل طويل 2048 بت ..........................+++ ..... ..............................................+++ه هو 65537 (0x10001) $ openssl req -new -keyclient.key -outclient.csr أنت على وشك أن يُطلب منك إدخال المعلومات التي سيتم دمجها في طلب الشهادة الخاص بك. ما أنت على وشك إدخاله هو ما يسمى بالاسم المميز أو الاسم المميز (DN). هناك عدد لا بأس به من الحقول ولكن يمكنك ترك بعضها فارغًا. بالنسبة لبعض الحقول ستكون هناك قيمة افتراضية، إذا قمت بإدخال "."، فسيتم ترك الحقل فارغًا. ----- اسم البلد (رمز مكون من حرفين): اسم الولاية أو المقاطعة RU (الاسم الكامل): اسم المنطقة المحلية في سانت بطرسبرغ (على سبيل المثال، المدينة): ^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -keyclient.key -outclient.csr أنت على وشك أن يُطلب منك إدخال المعلومات التي سيتم دمجها في طلب الشهادة الخاص بك. ما أنت على وشك إدخاله هو ما يسمى بالاسم المميز أو الاسم المميز (DN). هناك عدد لا بأس به من الحقول ولكن يمكنك ترك بعضها فارغًا. بالنسبة لبعض الحقول ستكون هناك قيمة افتراضية، إذا قمت بإدخال "."، فسيتم ترك الحقل فارغًا. ----- اسم الدولة (رمز مكون من حرفين): اسم الولاية أو المقاطعة RU (الاسم الكامل): غير متوفر اسم المنطقة المحلية (على سبيل المثال، المدينة): سان بطرسبرغ اسم المنظمة (على سبيل المثال، الشركة): اسم الوحدة التنظيمية لشركتي (على سبيل المثال، القسم): الاسم العام الهندسي (على سبيل المثال، الخادم FQDN أو اسمك): إيفان إيفانوف عنوان البريد الإلكتروني: [البريد الإلكتروني محمي]الرجاء إدخال السمات "الإضافية" التالية ليتم إرسالها مع طلب الشهادة الخاص بك. كلمة مرور اختبارية: اسم شركة اختياري: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 التوقيع موافق الموضوع=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/ [البريد الإلكتروني محمي]الحصول على مفتاح CA الخاص $ openssl x509 -noout -issuer -subject -enddate -in client.pem source= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =الشهادة الجذرية لشركتي/ [البريد الإلكتروني محمي] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=شركتي/OU=Engineering/CN=Ivan Ivanov/ [البريد الإلكتروني محمي] notAfter=25 يناير 13:17:15 2016 بتوقيت جرينتش

إذا كنت بحاجة إلى شهادة عميل بتنسيق PKCS12، فقم بإنشائها:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 أدخل كلمة مرور التصدير: التحقق - أدخل كلمة مرور التصدير:

يمكنك الآن استخدام شهادة العميل للعمل مع خادمنا.

تكوين nginx لاستخدام شهادات العميل

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

# الشهادة (الشهادات) الجذرية التي تم توقيع العميل بها ssl_client_certificate /etc/nginx/certs/clientroot.pem; # الخيارات الممكنة:على | قبالة | اختياري | Optional_no_ca ssl_verify_client اختياري؛ # عمق التحقق من سلسلة الشهادات التي تم توقيع العميل بها ssl_verify_ Deep 2;

بعد ذلك، تحتاج إلى إعادة تشغيل الإعدادات أو الخادم بأكمله ويمكنك التحقق من العملية.

تكوين Apache لاستخدام شهادات العميل

يمكن أيضًا تكوين Apache عن طريق الإضافة خيارات اضافيةإلى القسم استضافة افتراضية:

# الدليل الذي يحتوي على الشهادات الجذرية للتحقق من العميل SSLCARevocationPath /etc/Apache2/ssl.crl/ # أو ملف يحتوي على الشهادات SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # خيار التحقق من العميل. الخيارات الممكنة: # لا يوجد، اختياري، يتطلب و Optional_no_ca SSLVerifyClient يتطلب # عرض عمق سلسلة التوقيع. الافتراضي 1 SSLVerifyDepth 2

كما ترون، فإن الخيارات هي نفسها تقريبًا بالنسبة لـ nginx، نظرًا لأن عملية التحقق منظمة بشكل موحد.

الاستماع إلى معلومات الشهادة باستخدام opensl

لاختبار كيفية تفاعل الخادم مع شهادات العميل، يمكنك التحقق من إنشاء الاتصال باستخدام TLS/SSL.

من جانب الخادم، نبدأ بالاستماع على المنفذ باستخدام opensl:

Openssl s_server -قبول 443 -cert server.pem -key server.key -state

من جانب العميل، يمكننا الوصول إلى الخادم، على سبيل المثال، باستخدام culr:

الضفيرة -ك https://127.0.0.1:443

في وحدة التحكم من جانب الخادم، يمكنك مراقبة عملية تبادل المعلومات بين الخادم والعميل.

يمكنك أيضًا استخدام الخيارين -التحقق من [عمق التحقق] و-التحقق من [عمق التحقق]. يطلب خيار الحالة الصغيرة من العميل الحصول على شهادة، ولكن ليس من الضروري تقديم واحدة. مع الحروف الكبيرة- إذا لم يتم توفير الشهادة، سيحدث خطأ. لنبدأ بالاستماع على جانب الخادم مثل هذا:

Openssl s_server -قبول 443 -cert server.pem -key server.key -state -Verify 3

من جانب الخادم يبدو الخطأ كما يلي:

140203927217808:خطأ:140890C7:إجراءات SSL:SSL3_GET_CLIENT_CERTIFICATE:لم يُرجع النظير شهادة:s3_srvr.c:3287:

من جانب العميل مثل هذا:

حليقة: (35) خطأ: 14094410: إجراءات SSL: SSL3_READ_BYTES: فشل مصافحة التنبيه sslv3

دعونا نضيف مع جانب العميلالشهادة واسم المجال (للتحقق، يمكنك إدخال اسم المضيف للعنوان 127.0.0.1 في الملف /etc/hosts):

الضفيرة https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

الآن سيكون الاتصال ناجحًا ويمكنك تثبيت شهادة الخادم على خادم الويب ومنح شهادة العميل للعميل والعمل معه.

أمان

عند استخدام SSL/TLS، إحدى الطرق الرئيسية هي طريقة MITM (Man In The Middle). تعتمد هذه الطريقة على استخدام شهادة خادم ومفتاح على بعض العقد التي ستستمع إلى حركة المرور وفك تشفير المعلومات المتبادلة بين الخادم والعميل. لتنظيم الاستماع، يمكنك استخدام، على سبيل المثال، برنامج sslsniff. لذلك، يُنصح عادةً بتخزين شهادة الجذر والمفتاح على جهاز غير متصل بالشبكة؛ للتوقيع، وإحضار طلبات التوقيع على محرك أقراص محمول، والتوقيع عليها، وأخذها بعيدًا أيضًا. وبالطبع عمل نسخ احتياطية.

في المخطط العامهذه هي بالضبط كيفية استخدام الشهادات الرقمية وبروتوكولات TLS وSSL. إذا كان لديك أسئلة/إضافات، اكتب في التعليقات.

تم نشر الإدخال بواسطة المؤلف في التصنيف الموسوم , .

آخر الملاحة

: 29 تعليقًا

1. cl-service.com

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

2. كذلك راغب.

   لم يتم تناول موضوع الثدي، لأن تقنية PKI الموصوفة لا علاقة لها بعنوان الموضوع. على الأقل لسبب وجيه قدمت روابط إلى RFC.
   ملاحظة. كانت هناك نكتة عن كلب وبرغوث.

3. كذلك راغب.

   لم أقصد الإساءة إليك بأي شكل من الأشكال. كنت أبحث عن معلومات حول الفرق بين SSL وTLS عمليًا وكان رابطك هو الأول في Google. لقد لفت انتباهي عنوان الموضوع. كل شيء رائع، استمر في ذلك!

4. دكتور ايبوليت

   شكرًا لك على توضيحاتك الثاقبة حول الشهادة الرقمية. أنا جديد على هذا =)
   آمل أن تتمكن من توضيح السؤال التالي.
   نظرًا لأن موضوع الاحتيال متطور جدًا في صناعة الإنترنت، أود أن أتعلم كيفية تحديد "قمل" المواقع التي أزورها بمفردي (خاصة عندما يكون هناك أموال نقدية ومدفوعات واستثمارات وما إلى ذلك) وعلى أساس هذا يحدد درجة ثقتي (يجب أن أقوم بالتسجيل في كثير من الأحيان، وترك المعلومات الشخصية، وإجراء عمليات الشراء، والمعاملات، والاستثمارات). إذا فهمت بشكل صحيح، فإن الحصول على هذه الشهادة يسمح لك بإجراء مثل هذا التقييم. حسنًا، من ناحية أخرى، الحصول عليه ليس مشكلة، بل إنه مجاني.
   كيف أو مع أي برنامج يمكنك تحديد التواجد شهادة رقميةفي هذا الموقع أو ذاك؟ ويفضل أن تكون فئتها، والتي يتم تعيينها عندما تصدر سلطة خاصة SSL DV (يتم إصدار الشهادة مع التحقق من المجال فقط)، SSL OV (مع التحقق من المنظمة)، EV (مع التحقق الموسع من الكيان القانوني). مواقع الاحتيال على الأرجح الخيار الأخيرلن يتم الاستفادة من الشهادات..
   سأكون سعيدًا إذا أخبرتني المزيد من الطرق لتحديد موثوقية المواقع))

   1. منورينمؤلف المشاركة

      نوعا ما برنامج محددلم أجد واحدًا لهذه الأغراض بعد، لكن يمكنني تقديم بعض النصائح حول هذا الموضوع.
      يمكنك استخدام، على سبيل المثال، الكروم أو جوجل كروم. لنأخذ على سبيل المثال الموقع https://www.thawte.com/ - وهي شركة تتعامل فعليًا مع الشهادات الرقمية.
      في شريط العنوانسيتم كتابة اسم الشركة والقفل الأخضر. وهذا يعني أنه تم التحقق من المؤسسة، وهذا على الأقل SSL OV.
      إذا قمت بالنقر فوق القفل، وفي النافذة المنسدلة "التفاصيل"، ثم "عرض الشهادة"، يمكنك رؤية معلومات حول الشهادة. بالنسبة لـ Thawte، تم توقيع الشهادة بالشهادة التالية: “thawte Extended Validation SHA256 SSL CA”، والشهادة الخاصة بـ click.alfabank.ru موقعة أيضًا بواسطة Thawte، ولكن بشهادة مختلفة. هذا هو "thawte EV SSL CA - G3"، أي أنهم اجتازوا أيضًا التحقق من الصحة الممتد.
      شيء من هذا القبيل.

5. رسلان

   قسم "كيفية عمل SSL وTLS"، "يقوم العميل بإنشاء تسلسل رقمي عشوائي."

   كنت على يقين من أن العميل ينشئ مفاتيح خاصة للجلسة، وبالتالي مفاتيح عامة (والتي من الواضح أنك تسميها "التسلسل الرقمي"). يتم تمرير المفتاح العام إلى الخادم ويقوم الخادم بتشفير الحزم إلى العميل باستخدام المفتاح العام لجلسة العميل.

   الرجاء التوضيح.

6. مبتدئ

   المقال مفيد جدا! بل إن هناك أمثلة عملية =) لكنني لم أفهم شيئًا واحدًا - ما الفرق بين شهادة الجذر وشهادة الخادم؟ أو هو نفس الشيء؟

7. فيتالي

   مرحبًا.
   عرض المضيف خدمة - SSL لـ الخوادم الافتراضية. لقد استفدنا منه. اتضح أنه بالنسبة للمستوى الثالث أي. شهادة http://www.site.ru غير صالحة، فقط لـ site.ru. علاوة على ذلك، يتم إلقاء الزوار بعناد بروتوكول https، لا يهم ما إذا كانوا يذهبون إلى site.ru أو http://www.site.ru. بالطبع، في الحالة الثانية، يبدأ المتصفح في أقسم القلب، ولا يصل الزائر إلى الموقع أبدا.
   لكن بالنسبة لأولئك الذين وصلوا إلى الموقع، بدأ الموقع يبدو ملتويًا، واختفى جزء من القائمة، وتوقف عرض بعض الصور في نتائج البحث بواسطة بعض المكونات.

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

لتصحيح هذه الحالةسيساعدنا استخدام بروتوكول TLS، مما سيضمن ما يلي:

1. سرية (يتم التفاعل بين العميل والخادم بشكل مشفر
حصة)؛

2. نزاهة (من المستحيل التسلل إلى الجلسة دون أن يلاحظها أحد؛ سيتم اكتشاف تلف البيانات على الفور)؛

3. موثوقية المصادقة (يمكن للعميل والخادم تبادل الشهادات المصادق عليها من قبل مركز معتمدشهادة (سلطة التصديق - CA).

كيف يعمل TLS

يقوم بروتوكول TLS بتشفير الاتصال بين مضيفين فقط. تستمر الجلسة التي تستخدم هذا البروتوكول على النحو التالي:

1. يقوم العميل بإنشاء اتصال بالخادم.

2. يبدأ المضيفون الاتصال باستخدام بروتوكول SMTP.

3. يقترح الخادم، باستخدام الكلمة الأساسية STARTTLS، استخدام TLS ضمن تفاعلات SMTP.

4. إذا كان بإمكان العميل استخدام TLS، فإنه يستجيب للخادم الكلمة الرئيسيةستارتلس.

5. يتم توقيع الشهادة العامة للخادم بالمفتاح الخاص وإرسالها إلى العميل.

6. يتحقق العميل من صحة شهادة الخادم عن طريق التحقق من توقيع المرجع المصدق مع التوقيع العام للمرجع المصدق الموجود لديه في المتجر الجذر.

7. يقوم العميل بفحص شهادة الخادم مقابل السلسلة التي تحتوي عليها اسم شائع اسم النطاقالخادم.

8. يقوم العميل والخادم بتمكين وضع تشفير البيانات.

9. يتبادل المضيفون البيانات.

10. تنتهي الجلسة.

لنبدأ في إنشاء شهادات لخادم البريد server.mydomain.ru ، حيث يعمل Postfix كـ MTA، ويؤدي Dovecot دور MDA.

يخلق شهادة جديدةالأمر بسيط – ما عليك سوى تشغيل البرنامج النصي وتشغيل بعض الأوامر.

لنقم بإنشاء ملفين - المفتاح السري للخادم وطلب توقيع الشهادة باستخدام الأمر:

# openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr

حيث الخادم هو اسم الخادم (في في هذه الحالةممكن ان يكون اي شيء)

املأ الحقول (الضغط على "Enter" يترك القيمة الافتراضية):

اسم الدولة (رمز مكون من حرفين): رو
اسم الولاية أو المقاطعة (الاسم الكامل): أورينبورغ
اسم المنطقة (على سبيل المثال، المدينة): أورسك
اسم المنظمة (على سبيل المثال، الشركة): شركتي
اسم الوحدة التنظيمية (على سبيل المثال، القسم): هو - هي
الاسم الشائع (على سبيل المثال، اسمك): server.mydomain.ru
عنوان البريد الإلكتروني: مدير مكتب البريد @mydomain.ru
كلمة مرور التحدي:
اسم الشركة اختياري:

من المهم جدًا الإشارة إلى هذا المجال اسم شائع الاسم الكاملالمضيف (FQDN) المتوافق مع سجلات DNS من النوع MX وA

دعونا نستفيد من هذه الفرصة إيصال مجانيشهادات COMODO بفترة صلاحية 90 يومًا على خدمة FreeSSL.su. يتم التعرف على هذه الشهادات بسهولة بواسطة جميع المتصفحات وعملاء البريد الإلكتروني.

في الصفحة الرئيسية، املأ جميع الحقول المطلوبة، وفي عمود "تحديد البرنامج المراد استخدامه"، حدد "أخرى". في الميدان المسؤولية الاجتماعية للشركاتأدخل محتويات الملف الذي تم إنشاؤه مسبقًا server.csr .

وبعد إرسال الطلب وتأكيده نحصل على أرشيف certs.zip ، يحتوي على الملفات التالية:

1. AddTrustExternalCARoot.crt;
2. server_mydomain_ru.crt;
3. comodoUTNSGCCA.crt;
4. EssentialSSLCA_2.crt;
5. UTNAddTrustSGCCA.crt

الملف server_mydomain_ru.crt هو الشهادة المطلوبة. ماذا يجب أن نفعل مع الملفات المتبقية؟ دعونا نفعل هذا - نجمع محتوياتها في ملف واحد ca.txt (شهادة CA موثوقة سي.أ. ) في الترتيب التالي:

1. أساسيSSLCA_2.crt
2. كومودوUTNSGCCA.crt
3. UTNAddTrustSGCCA.crt
4. AddTrustExternalCARoot.crt

الملف المستلم ca.txt سوف نستخدم كذلك:

دعونا نقوم بتكوين خادم البريد الخاص بنا. للقيام بذلك، نقوم بإجراء تغييرات على التكوينات حمامة و postfix .

للحمامة:

حمامة.conf:

البروتوكولات = pop3، imap، imaps، pop3s

بروتوكول البوب ​​3 (
استمع = *:110
ssl_listen = *:995
...........
}

صورة البروتوكول {
استمع = *:143
ssl_listen = *:993
...........
}

Disable_plaintext_auth = no # نحن لا نمنع تسجيل الدخول بالطريقة المفتوحة
ssl = Yes # تمكين دعم SSL
ssl_cert_file = /etc/ssl/certs/dovecot.pem # ملف الشهادة،
# تعيين الأذونات عليه: root:root 0444
ssl_key_file = /etc/ssl/private/dovecot.pem # مفتاح الخادم،
# يوصى بتعيين الأذونات: root:root 0400

ssl_verify_client_cert = Yes # التحقق من صحة شهادات العميل
ssl_parameters_regenerate = 1 # إعادة إنشاء المعلمات كل ساعة
# (القيمة "0" تعطل عملية التجديد)
ssl_cipher_list = ALL:!LOW:!SSLv2 # تشفير SSL
Verbose_ssl = Yes # سجل أخطاء SSL في السجل

ليحصل ssl_cert_file تحتاج إلى دمج محتويات الملفات server_mydomain_en.crt و ca.txt ، أعد تسمية الملف الناتج إلى dovecot.pem. في الدور ssl_key_file يظهر ملف المفتاح السري للخادم المعاد تسميته server.key ، تم إنشاؤها في وقت سابق.

بالنسبة للإصلاح التالي:

main.cf

Smtp_use_tls = Yes # استخدم TLS if السيرفر المتحكمتعلن عن دعم TLS
smtpd_use_tls = Yes # إبلاغ العملاء بدعم TLS
smtpd_tls_auth_only = no # استخدم مصادقة SMTP لأكثر من مجرد اتصالات TLS
smtp_tls_note_starttls_offer = نعم # سجل أسماء الخوادم،
# إصدار رسالة STARTTLS التي لم يتم تمكين دعم TLS لها

smtpd_tls_CAfile = /etc/ssl/ca.txt # شهادة موثوقة
smtpd_tls_key_file = /etc/ssl/smtpd.key # مفتاح الخادم الخاص
smtpd_tls_cert_file = /etc/ssl/smtpd.crt # شهادة الخادم

smtpd_tls_loglevel = 2 # إسهاب رسائل نشاط TLS
smtpd_tls_received_header = Yes # طلب رؤوس الرسائل بالمعلومات
# حول إصدار البروتوكول وخوارزمية التشفير
smtpd_tls_session_cache_timeout = 3600 ثانية # وقت تخزين البيانات مؤقتًا
# جلسات TLS تعتبر حديثة
tls_random_source = dev:/dev/urandom # اسم جهاز المولد أرقام عشوائية زائفة(برنج)

لكي يقبل Postfix اتصالات TLS على منفذ خاص (465/SMTPS، وليس 25/SMTP)، في الملف master.cf تحتاج إلى إلغاء تعليق الأسطر:

master.cf

Smtps إنت n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

أعد تشغيل postfix وdovecot وتحقق من السجلات.

لا تنسى أن تفتح المنافذ المطلوبةفي جدار الحماية: 993 (imaps)، 995 (pop3s)، 465 (smtps)

خادم البريد لدينا جاهز للعمل معه TLS !

ل عملاء البريد الإلكترونيإذا كان بإمكانك استخدام إمكانات الخادم الجديدة بشكل صحيح، فأنت بحاجة إلى ضبط إعدادات البروتوكول FQDN الخادم، كما تم تحديده أثناء المفتاح والطلب، وحدد نوع أمان الاتصال طبقة المقابس الآمنة/طبقة النقل الآمنة وذات الصلة الموانئ.

في نهاية فترة صلاحية الشهادات البالغة 90 يومًا، يجب عليك اتباع نفس الإجراء باستخدام نفس الملف للطلب server.csr ، لذا عليك الاحتفاظ بنسخة منه في مكان آمن. لن تستغرق عملية التحديث بأكملها أكثر من 10 دقائق!

TLS هو خليفة SSL، وهو بروتوكول يوفر اتصالاً موثوقًا وآمنًا بين العقد على الإنترنت. يتم استخدامه في تطوير العديد من العملاء، بما في ذلك المتصفحات و تطبيقات خادم العميل. ما هو TLS في متصفح الانترنت?

قليلا عن التكنولوجيا

تستخدم جميع المؤسسات والمنظمات التي تشارك في المعاملات المالية هذا البروتوكوللمنع التنصت على الحزم والوصول غير المصرح به من قبل المتسللين. تم تصميم هذه التقنية لحماية الاتصالات المهمة من هجمات المتسللين.

في الأساس، تستخدم مؤسساتهم متصفحًا مدمجًا. في بعض الحالات - موزيلا فايرفوكس.

تمكين أو تعطيل البروتوكول

في بعض الأحيان يكون من المستحيل الوصول إلى بعض المواقع بسبب تعطيل دعم تقنيات SSL وTLS. يظهر إشعار في المتصفح. إذًا، كيف يمكنك تمكين البروتوكولات لمواصلة الاستمتاع بالاتصالات الآمنة؟
1. افتح لوحة التحكم عبر ابدأ. طريقة أخرى: افتح Explorer وانقر على أيقونة الترس في الزاوية اليمنى العليا.

2. انتقل إلى قسم "خيارات المتصفح" وافتح القسم "خيارات متقدمة".

3. حدد المربعات بجوار "استخدام TLS 1.1 وTLS 1.2".

4. انقر فوق "موافق" لحفظ التغييرات. إذا كنت تريد تعطيل البروتوكولات، وهو أمر لا يوصى به بشدة، خاصة إذا كنت تستخدم الخدمات المصرفية عبر الإنترنت، فقم بإلغاء تحديد نفس العناصر.

ما الفرق بين 1.0 و 1.1 و 1.2؟ 1.1 هو مجرد نسخة محسنة قليلاً من TLS 1.0، والتي ورثت عيوبها جزئيًا. 1.2 هو الأكثر نسخة آمنةبروتوكول. ومن ناحية أخرى، لا يمكن فتح جميع المواقع مع تمكين هذا الإصدار من البروتوكول.

وكما هو معروف، سكايب رسولترتبط مباشرة ببرنامج Internet Explorer مكون ويندوز. إذا لم يكن لديك بروتوكول TLS محددًا في الإعدادات، فقد تنشأ مشكلات مع Skype. البرنامج ببساطة لن يتمكن من الاتصال بالخادم.

إذا تم تعطيل دعم TLS في إعدادات Internet Explorer، فلن تعمل جميع وظائف البرنامج المتعلقة بالشبكة. علاوة على ذلك، فإن سلامة بياناتك تعتمد على هذه التقنية. لا تهمل ذلك إذا فعلت العمليات الماليةفي هذا المتصفح (التسوق في المتاجر عبر الإنترنت، أو تحويل الأموال من خلال الخدمات المصرفية عبر الإنترنت أو المحفظة على الانترنتإلخ.).

بروتوكول التسجيل TLS. يوفر هذا البروتوكول اتصالات آمنة لها خاصيتين رئيسيتين.

• الاتصال سري. يتم استخدام التشفير المتماثل (مثل DES وRC4 وما إلى ذلك) لتشفير البيانات. يتم إنشاء مفاتيح التشفير بشكل مستقل لكل اتصال وتعتمد على رمز سري تم الحصول عليه باستخدام بروتوكول آخر (مثل بروتوكول محادثة TLS). بروتوكول التسجيليمكن استخدامها دون تشفير.
• الاتصال موثوق. يتضمن إجراء إرسال الرسالة التحقق من السلامة باستخدام حساب MAC. تُستخدم وظائف التجزئة (مثل SHA وMD5 وما إلى ذلك) لحساب MAC. بروتوكول التسجيليمكن أن يعمل بدون MAC، ولكن في هذا الوضع يتم استخدامه فقط عند استخدام بروتوكول آخر بروتوكول التسجيلكوسيلة نقل عند تحديد المعلمات الأمنية.

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

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

إحدى مزايا TLS هي أنها مستقلة عن بروتوكول التطبيق. يمكن وضع بروتوكولات الطبقة العليا فوق TLS بطريقة شفافة. ومع ذلك، لا يحدد معيار TLS كيفية تعزيز البروتوكولات للأمن باستخدام TLS؛ يُترك القرار الخاص بكيفية تهيئة محادثة TLS وكيفية تفسير شهادات المصادقة لتقدير مطوري البروتوكولات والبرامج التي تعمل فوق TLS.

الأهداف

أهداف بروتوكول TLS، حسب الأولوية، هي:

1. أمن التشفير. يجب استخدام TLS للتأسيس اتصال آمنبين شريكين.
2. التوافق. يجب أن يكون المبرمجون المستقلون قادرين على تطوير التطبيقات باستخدام TLS التي يمكنها التواصل بنجاح معلمات التشفيردون معرفة مميزات برامج بعضهم البعض.
3. القابلية للتوسعة. يبحث TLS عن طريقة لدمج مفاتيح وطرق تشفير جديدة في النظام حسب الحاجة. هناك هدفان ثانويان هنا: إلغاء الحاجة إلى إنشاء بروتوكول جديد (والذي قد يتضمن إدخال بروتوكولات جديدة نقاط الضعف) وجعل التنفيذ غير ضروري مكتبة جديدةضمان السلامة.
4. الكفاءة النسبية. عمليات التشفيرتتطلب قوى كبيرة لوحدة المعالجة المركزية، وعمليات معها المفاتيح العامة. لهذا السبب، يحتوي بروتوكول TLS على نظام تخزين مؤقت اختياري للجلسة، مما يقلل من عدد الاتصالات التي تم إنشاؤها باستخدام مخازن مؤقتة جديدة.

لغة العرض

يشبه عرض البيانات في هذا المستند بناء جملة لغة C وXDR [XDR]، ولكن هذه التوازيات تقريبية تمامًا ولا علاقة لها ببروتوكول TLS نفسه. يتم استخدام هذه التمثيلات فقط لغرض تبسيط تصور المادة.

تعتبر كتلة البيانات الأساسية بايت واحد (أي 8 بت). عناصر المعلومات متعددة البايت عبارة عن سلسلة من البايتات من اليسار إلى اليمين ومن أعلى إلى أسفل. يتم استرداد العناصر متعددة البايت من دفق البايت (باستخدام تدوين C) على النحو التالي:

القيمة = (بايت<< 8*(n-1)) | (байт << 8*(n-2)) | ... | байт;

يعد ترتيب البايت هذا للتسلسلات متعددة البايت أمرًا قياسيًا للشبكات (النهاية الكبيرة).

تبدأ التعليقات بـ "/*" وتنتهي بـ "*/". يتم تمييز المكونات الاختيارية بوضعها بين قوسين مربعين مزدوجين "". الكائنات أحادية البايت التي تحتوي على بيانات غير قابلة للتفسير لها نوع معتم.

المتجه (مصفوفة أحادية البعد) هو تيار من عناصر المعلومات المتجانسة. يمكن تحديد حجم المتجه في وقت التوثيق أو البقاء غير محدد حتى يبدأ العمل. على أية حال، الطول هو الذي يحدد عدد البايتات، وليس عدد العناصر في المتجه. بناء جملة المواصفات للنوع الجديد T" وهو متجه ذو طول ثابت من النوع T هو TT"[n] ؛

هنا "T" يحتل n بايت في تدفق المعلومات، حيث n هو مضاعف لحجم T. ولا يتم تضمين طول المتجه في التدفق المشفر.

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

مسند مبهمة؛ /* ثلاث بايتات غير مفسرة */ Datum Data; /* 3 متجهات متتالية 3 بايت */

يتم تعريف المتجهات ذات الطول المتغير عن طريق تحديد نطاق فرعي من الأطوال القانونية باستخدام الترميز . عند التشفير، يسبق الطول الحقيقي تدفق البايتات الذي يشكل المتجه. يكون الطول على شكل رقم، ويشغل أكبر عدد ممكن من البايتات لتحديد الحد الأقصى لطول المتجه المحتمل (السقف). المتجه ذو الطول المتغير مع مجال الطول الحقيقي يساوي الصفر هو متجه فارغ.

تي تي" ;

في المثال التالي، المتجه المطلوب هو، والذي يجب أن يحتوي على 300 إلى 400 بايت من النوع غير الشفاف. لا ينبغي أن تكون فارغة. مجال الطول الفعلييستغرق وحدتي بايت، uint16، وهو ما يكفي لتمثيل القيمة 400. ومن ناحية أخرى، يمكن أن يمثل ما يصل إلى 800 بايت من البيانات، أو 400 عنصر uint16، ويمكن أن يكون فارغًا. وسيتضمن تمثيله المشفر بايتين من حقل الطول الحقيقي، متبوعًا بمتجه. يجب أن يكون طول المتجه المشفر مضاعفًا لطول العنصر المفرد (على سبيل المثال: سيكون ناقل uint16 ذو 17 بايت غير قانوني).

إلزامية مبهمة<300..400>; /* طول الحقل 2 بايت، ولا يمكن أن يكون فارغًا */ uint16 أطول<0..800>; /* 0 - 400 عدد صحيح غير موقّع 16 بت */

نوع البيانات الرقمية الأساسية هو بايت غير موقعة (uint8). يتم تشكيل أنواع البيانات الرقمية الأطول بشكل متزايد من تسلسل ثابت من البايتات غير الموقعة المتسلسلة معًا. الأنواع الرقمية التالية محددة مسبقًا.

فصول الكتاب الرائع "شبكات المتصفح عالية الأداء" للكاتب إيليا جريجوريك. تم تنفيذ الترجمة كجزء من كتابة عمل الدورة التدريبية، وبالتالي فهي مجانية للغاية، ولكنها مع ذلك ستكون مفيدة لأولئك الذين ليس لديهم فكرة تذكر عن ماهية TLS وما يتم استخدامه من أجله.

فهم TLS

يعتمد بروتوكول TLS (أمان طبقة النقل) على بروتوكول SSL (طبقة المقابس الآمنة)، الذي تم تطويره في الأصل بواسطة Netscape لتحسين أمان التجارة الإلكترونية عبر الإنترنت. تم تنفيذ بروتوكول SSL في طبقة التطبيق، مباشرة فوق TCP (بروتوكول التحكم في الإرسال)، والذي يسمح للبروتوكولات ذات المستوى الأعلى (مثل HTTP أو بروتوكول البريد الإلكتروني) بالعمل دون تعديل. إذا تم تكوين SSL بشكل صحيح، فيمكن للمراقب الخارجي معرفة معلمات الاتصال فقط (على سبيل المثال، نوع التشفير المستخدم)، بالإضافة إلى تكرار عمليات النقل والكمية التقريبية للبيانات، ولكن لا يمكنه قراءتها أو تغييرها.

يظهر في الرسم البياني المكان المحدد لـ TLS (SSL) في مكدس بروتوكول الإنترنت:

بعد أن تم توحيد بروتوكول SSL بواسطة IETF (فريق عمل هندسة الإنترنت)، تمت إعادة تسميته إلى TLS. لذلك، على الرغم من استخدام الأسماء SSL وTLS بالتبادل، إلا أنهما لا يزالان مختلفين لأن كل منهما يصف إصدارًا مختلفًا من البروتوكول.

الإصدار الأول من البروتوكول الذي تم إصداره كان يسمى SSL 2.0، ولكن تم استبداله بسرعة بـ SSL 3.0 بسبب نقاط الضعف المكتشفة. كما ذكرنا سابقًا، تم تطوير SSL بواسطة Netscape، لذا في يناير 1999 قامت IETF بتوحيدها علنًا تحت اسم TLS 1.0. ثم في أبريل 2006، تم نشر TLS 1.1، مما أدى إلى توسيع القدرات الأصلية للبروتوكول وأغلق نقاط الضعف المعروفة. الإصدار الحالي من البروتوكول في الوقت الحالي هو TLS 1.2، الذي تم إصداره في أغسطس 2008.

كما ذكرنا سابقًا، تم تصميم TLS للعمل عبر TCP، ولكن للعمل مع بروتوكولات مخططات البيانات مثل UDP (بروتوكول مخطط بيانات المستخدم)، تم تطوير إصدار خاص من TLS يسمى DTLS (Datagram Transport Layer Security).
 

التشفير والمصادقة والنزاهة

تم تصميم بروتوكول TLS لتوفير ثلاث خدمات لجميع التطبيقات التي تعمل عليه، وهي التشفير والمصادقة والتكامل. من الناحية الفنية، لا يمكن استخدام الثلاثة جميعًا، ولكن من الناحية العملية، لضمان الأمان، عادةً ما يتم استخدام الثلاثة جميعًا:

• التشفير – إخفاء المعلومات المنقولة من كمبيوتر إلى آخر؛
• المصادقة – التحقق من مؤلف المعلومات المرسلة؛
• النزاهة - الكشف عن استبدال المعلومات بمعلومات مزيفة.

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

وأيضًا، كجزء من إجراء TLS Handshake، من الممكن التحقق من هوية كل من العميل والخادم. على سبيل المثال، يمكن للعميل التأكد من أن الخادم الذي يزوده بمعلومات الحساب البنكي هو بالفعل خادم بنكي. والعكس صحيح: يمكن لخادم الشركة التأكد من أن العميل المتصل به هو موظف في الشركة، وليس طرفًا ثالثًا (تسمى هذه الآلية "سلسلة الثقة" وسيتم مناقشتها في القسم المناسب).

أخيرًا، يضمن TLS أن كل رسالة يتم إرسالها باستخدام رمز MAC (رمز مصادقة الرسالة)، وتكون خوارزمية إنشائها عبارة عن وظيفة تجزئة تشفير أحادية الاتجاه (في الواقع مجموع اختباري)، ومفاتيحها معروفة لكلا المشاركين في الاتصال . في كل مرة يتم إرسال رسالة، يتم إنشاء قيمة MAC الخاصة بها، والتي يمكن أيضًا إنشاؤها بواسطة المتلقي، مما يضمن سلامة المعلومات والحماية من استبدالها.

وبالتالي، تتم مراجعة الآليات الثلاث الكامنة وراء الأمن المشفر لبروتوكول TLS بإيجاز.
 

مصافحة TLS

قبل البدء في تبادل البيانات عبر TLS، يجب أن يتفق العميل والخادم على معلمات الاتصال، وهي: إصدار البروتوكول المستخدم، وطريقة تشفير البيانات، وكذلك التحقق من الشهادات، إذا لزم الأمر. يسمى نظام بدء الاتصال TLS Handshake ويظهر في الشكل:

دعونا نلقي نظرة فاحصة على كل خطوة من هذا الإجراء:

1. وبما أن TLS يعمل فوق TCP، يتم إنشاء اتصال TCP أولاً بين العميل والخادم.
2. بعد تثبيت TCP، يرسل العميل المواصفات بنص عادي (أي إصدار البروتوكول الذي يريد استخدامه وطرق التشفير المدعومة وما إلى ذلك) إلى الخادم.
3. يوافق الخادم على إصدار البروتوكول المستخدم، ويختار طريقة تشفير من القائمة المتوفرة، ويرفق شهادته ويرسل ردًا إلى العميل (إذا رغبت في ذلك، يمكن للخادم أيضًا أن يطلب شهادة عميل).
4. يتم اعتبار إصدار البروتوكول وطريقة التشفير معتمدين في هذه المرحلة، ويتحقق العميل من الشهادة المرسلة ويبدأ إما تبادل مفاتيح RSA أو Diffie-Hellman، اعتمادًا على المعلمات المحددة.
5. يقوم الخادم بمعالجة الرسالة التي يرسلها العميل، ويتحقق من MAC، ويرسل الرسالة النهائية ("منتهية") إلى العميل في نموذج مشفر.
6. يقوم العميل بفك تشفير الرسالة المستلمة، والتحقق من جهاز MAC، وإذا كان كل شيء على ما يرام، فسيتم اعتبار الاتصال قائمًا ويبدأ تبادل بيانات التطبيق.

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

يوجد أيضًا امتداد إضافي لإجراء المصافحة يسمى TLS False Start. يسمح هذا الامتداد للعميل والخادم بالبدء في تبادل البيانات المشفرة بمجرد إنشاء طريقة التشفير، مما يقلل من إنشاء الاتصال بتكرار رسالة واحدة. تمت مناقشة ذلك بمزيد من التفصيل في فقرة "TLS False Start".
 

تبادل المفاتيح في بروتوكول TLS

لأسباب تاريخية وتجارية مختلفة، فإن تبادل المفاتيح الأكثر استخدامًا في TLS هو RSA: حيث يقوم العميل بإنشاء مفتاح متماثل، وتوقيعه باستخدام المفتاح العام للخادم، وإرساله إلى الخادم. وفي المقابل، يتم فك تشفير مفتاح العميل على الخادم باستخدام المفتاح الخاص. بعد ذلك، يتم الإعلان عن اكتمال عملية تبادل المفاتيح. هذه الخوارزمية لها عيب واحد: يتم أيضًا استخدام نفس زوج المفاتيح العامة والخاصة لمصادقة الخادم. وبناء على ذلك، إذا تمكن المهاجم من الوصول إلى المفتاح الخاص للخادم، فيمكنه فك تشفير جلسة الاتصال بأكملها. علاوة على ذلك، يمكن للمهاجم ببساطة تسجيل جلسة الاتصال بأكملها في نسخة مشفرة وفك تشفيرها لاحقًا، عندما يتمكن من الحصول على المفتاح الخاص للخادم. في الوقت نفسه، يبدو أن تبادل مفاتيح Diffie-Hellman أكثر أمانًا، نظرًا لأن المفتاح المتماثل المحدد لا يترك العميل أو الخادم أبدًا، وبالتالي، لا يمكن للمهاجم اعتراضه، حتى لو كان يعرف المفتاح الخاص للخادم. تعتمد خدمة تقليل مخاطر اختراق جلسات الاتصال السابقة على ما يلي: لكل جلسة اتصال جديدة، يتم إنشاء ما يسمى بالمفتاح المتماثل "المؤقت" الجديد. وفقًا لذلك، حتى في أسوأ الحالات (إذا كان المهاجم يعرف المفتاح الخاص للخادم)، فيمكن للمهاجم فقط الحصول على المفاتيح من الجلسات المستقبلية، ولكن لا يمكنه فك تشفير المفاتيح المسجلة مسبقًا.

حاليًا، عند إنشاء اتصال TLS، تفضل جميع المتصفحات مزيجًا من خوارزمية Diffie-Hellman واستخدام المفاتيح المؤقتة لزيادة أمان الاتصال.

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

استئناف جلسة TLS

كما ذكرنا سابقًا، فإن إجراء مصافحة TLS الكامل طويل جدًا ومكلف من الناحية الحسابية. ولذلك، تم تطوير إجراء يسمح باستئناف الاتصال الذي انقطع مسبقًا بناءً على البيانات التي تم تكوينها بالفعل.

منذ الإصدار العام الأول من البروتوكول (SSL 2.0)، يمكن للخادم إنشاء وإرسال معرف جلسة 32 بايت كجزء من مصافحة TLS (أي رسالة ServerHello الأولية). وبطبيعة الحال، في هذه الحالة، يقوم الخادم بتخزين ذاكرة تخزين مؤقت للمعرفات التي تم إنشاؤها ومعلمات الجلسة لكل عميل. وفي المقابل، يقوم العميل بتخزين المعرف المرسل وإدراجه (بالطبع، إذا كان موجودًا) في رسالة ClientHello الأولية. إذا كان لدى كل من العميل والخادم معرفات جلسة متطابقة، فسيتم إنشاء اتصال مشترك وفقًا للخوارزمية المبسطة الموضحة في الشكل. إذا لم يكن الأمر كذلك، فستكون هناك حاجة إلى الإصدار الكامل من TLS Handshake.

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

ومع ذلك، هناك قيود عملية: نظرًا لأنه يجب على الخادم تخزين البيانات حول جميع الجلسات المفتوحة، فإن هذا يؤدي إلى مشكلة في الموارد الشائعة التي يطلبها آلاف أو ملايين العملاء في نفس الوقت.

وللتحايل على هذه المشكلة، تم تطوير آلية “Session Ticket”، والتي تلغي الحاجة إلى تخزين بيانات كل عميل على الخادم. إذا أشار العميل، عند إنشاء اتصال في البداية، إلى أنه يدعم هذه التقنية، فعند مصافحة TLS، يرسل العميل ما يسمى بتذكرة الجلسة - معلمات الجلسة المشفرة بالمفتاح الخاص للخادم - إلى الخادم. في المرة التالية التي يتم فيها استئناف الجلسة، يرسل العميل تذكرة الجلسة الحالية الخاصة به مع ClientHello. وهذا يلغي حاجة الخادم إلى تخزين البيانات حول كل اتصال، لكن الاتصال يظل آمنًا لأن تذكرة الجلسة مشفرة بمفتاح معروف للخادم فقط.
 

بداية خاطئة لـ TLS

لا شك أن تقنية استئناف الجلسة تعمل على تحسين أداء البروتوكول وتقليل التكاليف الحسابية، ولكنها لا تنطبق على الاتصال الأولي بالخادم، أو في حالة انتهاء صلاحية الجلسة السابقة بالفعل.

للحصول على أداء أفضل، تم تطوير تقنية TLS False Start، وهي امتداد اختياري للبروتوكول وتسمح بإرسال البيانات عند اكتمال TLS Handshake جزئيًا فقط. يظهر في الشكل مخطط TLS False Start المفصل:

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

سلسلة الثقة TLS

تعد المصادقة جزءًا لا يتجزأ من كل اتصال TLS. دعونا نلقي نظرة على أبسط عملية مصادقة بين أليس وبوب:

1. يقوم كل من أليس وبوب بإنشاء المفاتيح العامة والخاصة الخاصة بهما.
2. يتبادل أليس وبوب المفاتيح العامة.
3. تقوم أليس بإنشاء رسالة، وتشفيرها باستخدام مفتاحها الخاص، وإرسالها إلى بوب.
4. يستخدم بوب المفتاح المستلم من أليس لفك تشفير الرسالة وبالتالي التحقق من صحة الرسالة المستلمة.

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

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

ما تم وصفه في الفقرة السابقة هو إنشاء "سلسلة ثقة" (أو "سلسلة الثقة" باللغة الإنجليزية).
في بروتوكول TLS، تعتمد سلاسل الثقة هذه على شهادات المصادقة المقدمة من سلطات خاصة تسمى سلطات التصديق (CA). تقوم سلطات التصديق بإجراء عمليات التحقق، وإذا تم اختراق الشهادة الصادرة، فسيتم إبطال الشهادة.

يتم تشكيل سلسلة الثقة التي تمت مناقشتها بالفعل من الشهادات الصادرة. جذرها هو ما يسمى بـ "شهادة Root CA" - وهي شهادة موقعة من مركز كبير لا يمكن إنكار مصداقيتها. بشكل عام، تبدو سلسلة الثقة كما يلي:

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

آلية هذا الفحص بسيطة وتعتمد على ما يسمى ب. "قائمة إلغاء الشهادات" (CRL - "قائمة إلغاء الشهادات"). تحتفظ كل جهة من المراجع المصدقة بهذه القائمة، وهي عبارة عن قائمة بسيطة من الأرقام التسلسلية للشهادات الملغاة. وبناء على ذلك، فإن أي شخص يريد التحقق من صحة الشهادة ما عليه سوى تنزيل هذه القائمة والبحث فيها عن رقم الشهادة التي يتم التحقق منها. إذا تم العثور على الرقم، فهذا يعني أنه تم إلغاء الشهادة.

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

• يجب على المراجع المصدقة التعامل مع الحمل في الوقت الحقيقي؛
• ويجب أن تضمن المراجع المصدقة توافرها في جميع الأوقات؛
• نظرًا للاستعلامات في الوقت الفعلي، تتلقى المراجع المصدقة معلومات حول المواقع التي زارها كل مستخدم محدد.

في الواقع، في جميع المتصفحات الحديثة، يكمل كلا الحلين (OCSP وCRL) بعضهما البعض، علاوة على ذلك، كقاعدة عامة، من الممكن تكوين السياسة المفضلة للتحقق من حالة الشهادة.

وبالتالي، تتناول هذه المقالة كافة الميزات الأساسية التي يوفرها بروتوكول TLS لحماية المعلومات. وأعتذر عن بعض الكمامات الواردة في المقال، وهذه هي تكاليف الغرض الأصلي من إجراء الترجمة.