استخدام HTTPS بأمان

يرسل HTTP العادي كل شيء بصورة مكشوفة. يستطيع أي طرف موجود على مسار الاتصال قراءة بياناتك، بما في ذلك الرموز المميزة أو كلمات المرور. 🔓

يغلّف HTTPS طلبك بتشفير TLS. ولا يرى المتطفلون سوى بايتات مشوشة، لا قراءاتك ولا بيانات اعتمادك.

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

في ESP32 تستبدل العميل العادي بـ WiFiClientSecure. فهذا هو الكائن الذي يتولى التحدث باستخدام TLS نيابةً عنك.

مرّر العميل الآمن وعنوان URL يبدأ بـ https إلى begin(). الحرف s في https هو ما يفعّل المسار المشفّر.

للتحقق من الهوية، زوّد العميل بـ شهادة الجذر الخاصة بالخادم. وتستخدمها اللوحة للتأكد من أن الاتصال أصلي.

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

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

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

تحمي HTTPS البيانات أثناء النقل، لكنها لا تحمي الأسرار المضمّنة في شفرتك. أبقِ مفاتيح API خارج المصدر النصي العادي وخارج المستودعات العامة.

بالنسبة إلى أي بيانات تغادر شبكتك المنزلية، فضّل HTTPS. ولا تعتبر HTTP العادي مناسبًا إلا للتجارب المحلية السريعة.

ما الذي يوفره HTTPS ولا يوفره HTTP العادي؟

انتقلت إلى WiFiClientSecure، واستخدمت عناوين URL تبدأ بـ https، وتحققت من الخادم باستخدام شهادة جذر، وحافظت على صحة الوقت، وحميت أسرارك. 🎉