بدأت Cloudflare اختباراً مغلقاً لخدمة Cloudflare OHTTP Gateway، وهي إضافة مدفوعة يمكن تفعيلها على نطاق العميل لاستقبال حركة مرور Oblivious HTTP (OHTTP) عبر بنية مُدارة. وتستهدف الخدمة المطورين الذين يريدون إخفاء عنوان IP ومؤشرات تعريف العميل عن خوادم تطبيقاتهم، خصوصاً عندما تكون هذه الخوادم مستضافة خلف شبكة Cloudflare أو على Workers.
بالتزامن مع ذلك، أعادت الشركة تسمية منتجها السابق Privacy Gateway إلى Cloudflare OHTTP Relay. ويعكس التغيير وجود منتجين مختلفين في نموذج OHTTP: المرحل يمرر الطلبات المشفرة ويخفي هوية العميل، بينما يتولى البوابة فك التغليف المشفر للطلب وإعادة تغليف الاستجابة قبل تسليمها إلى خادم التطبيق.
كيف يعمل نموذج OHTTP؟
في الاتصال التقليدي، يمكن لخادم التطبيق رؤية عنوان IP الخاص بالعميل وخصائص TLS ومعلومات الموقع، ما قد يسمح بربط عدة طلبات بالمستخدم نفسه. في OHTTP، يمر الطلب عبر مرحل مستقل يزيل مؤشرات هوية العميل قبل توجيهه. وتبقى محتويات الطلب مشفرة باستخدام Hybrid Public Key Encryption (HPKE)، بحيث لا يرى المرحل النص الواضح.
بعد ذلك، تعالج البوابة الجزء التشفيري وتقدم الطلب إلى خادم التطبيق بصيغة HTTP المعتادة. وبهذا ينشأ فصل للثقة: المرحل يرى هوية الاتصال ولا يرى محتوى الطلب، بينما ترى البوابة وخادم التطبيق محتوى الطلب من دون هوية العميل المباشرة. ويشترط هذا النموذج ألا تدير الجهتان اللتان تؤديان دور المرحل والبوابة بصورة متواطئة.
ما الذي تضيفه البوابة الجديدة؟
تعمل OHTTP Gateway كميزة ضمن نطاق Cloudflare، ويمكن تفعيلها من خلال نقاط وصول محددة مثل /.well-known/ohttp-gateway. وتدعم الخدمة OHTTP القياسي وChunked OHTTP، مع توصية باستخدام النوع المجزأ لمعالجة الطلبات تدريجياً. كما تتولى Cloudflare إدارة مفاتيح HPKE العامة وتقديمها للعملاء، بدلاً من تحميل العميل مسؤولية إدارة دورة المفاتيح.
تستفيد الخدمة من شبكة Cloudflare العالمية، ما يتيح تشغيل البوابة على حافة الشبكة وتقليل زمن الانتقال بين المرحل والبوابة. وإذا كانت خوادم التطبيق تستخدم CDN الخاص بالشركة، يمكن أن تتم معالجة الطلب والوصول إلى الخادم على البنية نفسها. وتتعامل البوابة مع طلبات OHTTP فقط، بينما تستمر الطلبات العادية في الوصول إلى الخادم من دون المرور بمعالجة OHTTP.
ضوابط الثقة والاستخدام
تتيح Cloudflare Access فرض سياسات مصادقة قبل فك تشفير الطلبات، بما في ذلك mutual TLS وبيانات اعتماد الخدمة الثابتة ومنطق خارجي مخصص. كما ترفض البوابة فك الطلبات القادمة من Cloudflare Workers أو من مضيفات ممررة عبر Cloudflare، لتجنب تشغيل المرحل والبوابة لدى الجهة نفسها وإضعاف فصل الثقة الذي يعتمد عليه OHTTP.
توصي Cloudflare باستخدام OHTTP Gateway عندما تكون خوادم التطبيق خلف Cloudflare أو عندما يأتي الطلب من مرحل وعميل تابعين لجهة خارجية، مثل بعض حالات استخدام Apple LiveCallerID. أما Cloudflare OHTTP Relay، بالاسم الجديد، فيناسب من يريد استخدام مرحل Cloudflare مع تشغيل البوابة بنفسه خارج Cloudflare.
ما الذي يتغير عملياً؟
تخفض الخدمة الجديدة العبء التشغيلي لبناء بوابة OHTTP، لكنها لا تلغي المتطلبات المعمارية الأساسية. فالعميل يحتاج إلى تنفيذ OHTTP، كما يحتاج المستخدم إلى مرحل مستقل؛ وتؤكد Cloudflare أن المرحل يجب أن يكون جهة يمكن الوثوق بها فيما يتعلق بعدم فحص السجلات وربط هويات العملاء بالطلبات المفكوكة. كذلك لا يحمي OHTTP البيانات التعريفية الموجودة داخل نص الطلب نفسه، لذلك تقع على المطور مسؤولية عدم إرسال البريد الإلكتروني أو اسم المستخدم أو أي معرفات أخرى ضمن محتوى الطلب.
الخدمة متاحة حالياً ضمن اختبار مغلق وقائمة انتظار، ولم يحدد الإعلان موعد الإطلاق العام أو تفاصيل الأسعار. لذلك تمثل الخطوة توسعاً مهماً في أدوات الخصوصية الشبكية، لكنها لا تزال تتطلب من فرق التطوير اتخاذ قرارات مستقلة بشأن المرحل، ومحتوى الطلب، ونموذج الثقة بين الأطراف.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.