دروازه OHTTP Cloudflare

به همین دلیل است که Cloudflare زیرساخت هایی ایجاد می کند که به توسعه دهندگان کمک می کند حریم خصوصی را در برنامه های خود ایجاد کنند. Oblivious HTTP (OHTTP) یک استاندارد IETF است که برای فعال کردن پشتیبان های برنامه برای دریافت درخواست های HTTP بدون دیدن آدرس های IP کاربر طراحی شده است.

پاییز امسال، دروازه OHTTP Cloudflare را راه‌اندازی می‌کنیم. مشتریان می توانند دروازه OHTTP جدید ما را به عنوان یک افزونه پولی برای منطقه خود فعال کنند و تنها با چند کلیک، ترافیک OHTTP را دریافت کنند. از طریق فرم ما ثبت نام کنید تا به لیست انتظار ما بپیوندید. برای کسب اطلاعات بیشتر به ادامه مطلب مراجعه کنید.

با OHTTP، درخواست ها از طریق دو پرش مستقل حرکت می کنند: یک رله و یک دروازه. یک رله OHTTP کورکورانه درخواست های رمزگذاری شده را به منظور پنهان کردن شناسه های مشتری از سرورهای برنامه ارسال می کند. یک دروازه OHTTP کار رمزنگاری کپسوله کردن درخواست های رمزگذاری شده و کپسوله کردن پاسخ ها را انجام می دهد به طوری که سرورهای برنامه می توانند درخواست های OHTTP را به گونه ای انجام دهند که گویی HTTP ساده هستند. تفکیک اعتماد بین رله و دروازه بسیار مهم است: تضمین می کند که هیچ طرفی هم شناسه های مشتری و هم محتوای درخواست را نمی بیند.

در سال 2022، ما یک محصول رله OHTTP، Privacy Gateway را راه اندازی کردیم. Privacy Gateway مشتریان ما را قادر می سازد تا تجربیات حفظ حریم خصوصی بیشتری را به کاربران خود ارائه دهند. برای مثال، Flo Health از OHTTP برای حالت ناشناس برنامه خود استفاده می‌کند و محاسبات ابری خصوصی اپل از OHTTP برای جدا کردن درخواست‌های استنتاج هوش مصنوعی از هویت کاربر استفاده می‌کند. اما مشتریانی که در حال حاضر از سرورهای خود در پشت Cloudflare محافظت می‌کنند، نمی‌توانند از رله‌های Cloudflare نیز استفاده کنند – در عوض به یک دروازه OHTTP نیاز دارند.

در تجربه خود در اجرای رله های OHTTP، دیدیم که ساخت و راه اندازی یک دروازه OHTTP ایمن و کارآمد در مقیاس چقدر دشوار است. امروز، ما نسخه بتای بسته را برای دروازه خود سرویس Cloudflare OHTTP خود راه‌اندازی می‌کنیم. همچنین برای تشخیص بهتر این دو محصول، «دروازه حریم خصوصی» خود را به «Cloudflare OHTTP Relay» تغییر می‌دهیم.

اکنون، مشتریانی که خواهان معماری OHTTP با تفکیک لازم از اعتماد هستند، دو گزینه دارند:

ما در حال تلاش برای بالا بردن سطح حریم خصوصی در سراسر اینترنت هستیم، و معتقدیم که پروتکل‌هایی مانند OHTTP می‌توانند کمک کنند - اگر به اندازه کافی برای پذیرش آن‌ها آسان‌تر شویم. همیشه هدف ما این بوده است که مجموعه محصولات OHTTP خود را گسترش دهیم و زیرساخت‌های حفظ حریم خصوصی مورد اعتماد خود را برای گستره وسیع‌تری از اینترنت در دسترس قرار دهیم.

از زمانی که محصول OHTTP Relay خود را راه اندازی کردیم، چند چیز را مشاهده کردیم.

اول، ما شاهد بودیم که اشتهای فزاینده ای در میان توسعه دهندگان برای زیرساخت های حریم خصوصی قابل استفاده و قابل دسترس وجود دارد. توسعه دهندگان برنامه های حریم خصوصی می خواهند به طور پیش فرض حریم خصوصی شبکه را در برنامه های خود قرار دهند، اما انجام این کار سخت تر از آنچه باید باشد باقی می ماند.

دوم، ما آموخته‌ایم که ساخت و راه‌اندازی یک دروازه OHTTP می‌تواند برای مشتریان سخت باشد. هر معماری پروکسی نوعی تأخیر ایجاد می کند زیرا درخواست ها باید یک یا دو جهش اضافی در اینترنت داشته باشند. این را با هزینه رمزگشایی درخواست‌ها و رمزگذاری پاسخ‌ها ترکیب کنید، و تأخیر یک راه‌اندازی OHTTP خانگی می‌تواند قابل توجه باشد. ما برای حل این مشکل موقعیت خوبی داریم: همان بلوک‌های ساختمانی که به ما امکان می‌دهند زیرساخت‌های حریم خصوصی سریع و قابل اعتماد را برای محصولاتی مانند 1.1.1.1 و iCloud Private Relay کار کنیم، ما را به خانه خوبی برای دروازه OHTTP تبدیل می‌کند.

به دلیل رویکرد anycast Cloudflare، دروازه OHTTP ما بر روی هر سروری در شبکه لبه جهانی Cloudflare اجرا می‌شود و تاخیر در پرش رله به دروازه را به حداقل می‌رساند. اگر از CDN ما استفاده می‌کنید، درخواست‌های کاربر را می‌توان توسط Gateway ما رمزگشایی کرد و توسط سرورهای برنامه‌تان در همان فلزات Cloudflare حل‌وفصل شد، و باعث صرفه‌جویی در تأخیر دروازه به مبدا می‌شود.

در نهایت، به یاد بیاورید که مدل حریم خصوصی OHTTP مستلزم آن است که رله و سرور برنامه توسط طرف‌های مجزا و بدون تبانی اداره شود. ما می خواهیم بهترین گزینه های ممکن را برای زیرساخت حفظ حریم خصوصی مشتریان خود ارائه دهیم. پیش از این، توسعه دهندگانی که از سرورهای برنامه خود در پشت Cloudflare محافظت می کردند، نمی توانستند از رله OHTTP ما استفاده کنند، زیرا Cloudflare هم ابرداده های مشتری و هم محتوای رمزگشایی شده درخواست ها را می دید و مدل حریم خصوصی OHTTP را زیر پا می گذاشت. اکنون، توسعه‌دهندگان می‌توانند انتخاب کنند که آیا یک Cloudflare OHTTP Relay یا Gateway برای معماری آنها مناسب‌تر است.

یک تعامل معمولی بین یک کلاینت و سرور برنامه اطلاعاتی را در مورد مشتری آشکار می کند. هنگامی که یک سرویس گیرنده و سرور برنامه با یکدیگر صحبت می کنند، سرور برنامه آدرس IP مشتری را می آموزد زیرا هر بسته ای که داده در آن ارسال می شود با یک IP منبع برچسب گذاری شده است - مشابه برچسب "از" روی یک پاکت. سرورهای برنامه همچنین می‌توانند یک کلاینت را بر اساس ویژگی‌هایی مانند نسخه‌های TLS پشتیبانی‌شده یا مجموعه‌های رمزنگاری «اثر انگشت» کنند. این سیگنال ها این امکان را برای سرورهای برنامه فراهم می کند تا چندین درخواست را به یک کاربر مرتبط کنند.

اما اگر بخواهم اپلیکیشنی بسازم که واقعا اطلاعات زیادی در مورد کاربران من نداشته باشد، چه؟ به عنوان مثال: Flo Health می‌خواست یک حالت ناشناس بسازد تا کاربران را قادر سازد به داده‌های سلامت شخصی دسترسی داشته باشند بدون اینکه آن‌ها به شناسه‌های کاربر احتمالی مرتبط شوند.

OHTTP یک پروکسی به نام «رله» معرفی می‌کند که درخواست‌ها و پاسخ‌ها را بین کلاینت و سرور برنامه ارسال می‌کند تا هویت مشتری را از سرور برنامه مخفی کند. رله شناسه‌های مشتری مانند آدرس IP و اثر انگشت TLS را می‌بیند، اما قبل از ارسال در درخواست‌ها، آن‌ها را حذف می‌کند. این امر از پیوند دادن چندین درخواست به یک کاربر توسط سرورهای برنامه جلوگیری می کند و به این معنی است که محتوای درخواست نمی تواند با آدرس IP کاربر مرتبط شود.

به عنوان مثال، یک تبادل مشتری-سرور معمولی ممکن است اطلاعات زیر را در مورد یک مشتری نشان دهد:

درخواستی که ابتدا از طریق یک رله OHTTP ارسال می شود، فقط اطلاعات رله را به سرور برنامه دریافت کننده درخواست نشان می دهد:

این بدان معناست که برای هر درخواست، سرور برنامه مکان و اثر انگشت TLS کاربر نهایی را نمی‌آموزد. به‌علاوه، اگر کاربران مختلف درخواست‌هایی را از طریق رله ارسال می‌کنند، سرور برنامه نمی‌تواند تشخیص دهد که کدام درخواست‌ها از چه کسی می‌آیند، و توانایی آن‌ها را برای ردیابی فعالیت برنامه به یک کاربر نهایی محدود می‌کند. این یک مرز حریم خصوصی قوی ایجاد می کند.

با این حال، آنچه واقعا OHTTP را از یک پروکسی حمل و نقل اصلی متمایز می کند، رمزگذاری داده ها بین مشتری و سرور برنامه است. درخواست‌ها و پاسخ‌ها با استفاده از رمزگذاری کلید عمومی ترکیبی (HPKE) کپسوله‌سازی می‌شوند، به گونه‌ای که فقط مشتری و سرور برنامه می‌توانند متن ساده را ببینند و رله فقط متن‌های رمزنگاری درهم‌آمیزی را می‌بیند. یک "دروازه" بین رله و سرور برنامه قرار دارد تا همه این رمزنگاری ها را مدیریت کند - درخواست ها را کپسوله می کند، پاسخ ها را محصور می کند - و سرور برنامه فقط HTTP ساده را مدیریت می کند.

این یک مدل حریم خصوصی "دو سو کور" ایجاد می کند: رله فقط شناسه های مشتری را می بیند. دروازه و سرور برنامه فقط محتویات درخواست را می بینند. هیچ طرفی هر دو را نمی بیند.

در ساخت دروازه OHTTP به عنوان یک سرویس، هدف ما این است که زیرساخت حفظ حریم خصوصی ایمن و عملکردی خود را به گستره وسیع تری از اینترنت بیاوریم. عملکرد و نصب آسان بسیار مهم است. بنابراین، ما دروازه خود را به عنوان یک سرویس منعطف ایجاد کردیم که در سراسر شبکه جهانی خود مستقر شده است. تنها با چند کلیک، می توانید Gateway را در منطقه خود فعال کنید و شروع به ارسال OHTTP به https://your-zone.com/.well-known/ohttp-gateway کنید. ما سرویس را به صورت خودکار بالا و پایین می کنیم، بنابراین نیازی نیست نگران ظرفیت باشید.

ما چند نیاز دیگر کاربر را در ذهن داشتیم که با توجه به نقاط دردناکی که مشتریان رله OHTTP هنگام کار با دروازه‌های OHTTP خود با آن مواجه می‌شدند، آگاه بودیم.

اول: ما می خواستیم تا حد امکان پیچیدگی OHTTP را برای سرورهای برنامه شما انتزاعی کنیم. ما می‌خواستیم توسعه‌دهندگان بتوانند در صورت تمایل، دریافت OHTTP را آغاز کنند و در عین حال همچنان ترافیک HTTP معمولی را بپذیرند. بنابراین، ما دروازه را به عنوان یکی از ویژگی های منطقه شما طراحی کردیم، جایی که مشتریان درخواست های OHTTP با فرمت مناسب را به یک نقطه پایانی /.well-known/ohttp-gateway در منطقه شما ارسال می کنند. ما از OHTTP استاندارد و تکه‌ای پشتیبانی می‌کنیم - و توصیه می‌کنیم برای عملکرد بهتر از OHTTP تکه‌ای استفاده کنید، زیرا به ما امکان می‌دهد درخواست‌ها را به صورت تدریجی (در «تکه‌ها») پردازش کنیم.

سرویس Gateway ما هر درخواست را رهگیری می‌کند، آن را رمزگشایی می‌کند، یک درخواست فرعی برای سرور برنامه شما صادر می‌کند و یک پاسخ رمزگذاری شده را به مشتری برمی‌گرداند. تمام درخواست‌های غیر OHTTP بدون فراخوانی Gateway به سرور شما منتقل می‌شوند.

اتصال دروازه شما به منطقه شما همچنین ما را قادر می سازد از دروازه شما در برابر سوء استفاده محافظت کنیم. مشتری که درخواست‌هایی را به منطقه شما « example.com» ارسال می‌کند، ممکن است به «foo.example.com» یا «bar.example.com» ارسال کند، اما نه wikipedia.com. بدون نیاز به نگرانی در مورد آن، این کار از مشتریان غیرمجاز از استفاده از منطقه شما به عنوان راهی برای هدف قرار دادن دامنه های دیگر جلوگیری می کند.

دوم: مدیریت یکپارچه کلید بسیار مهم است. دروازه‌ها باید پیکربندی کلید HPKE عمومی را حفظ کنند تا مشتریان بتوانند درخواست‌ها را رمزگذاری کنند، اما مدیریت ایمن کلیدها یک چالش است. بنابراین، ما دروازه را طوری طراحی کردیم که به طور کامل همه کلیدها را برای مشتریان مدیریت کند و کلیدهای عمومی را به عنوان پاسخ به درخواست های GET به /.well-known/ohttp-gateway ارائه کند. برای حفظ حریم خصوصی قوی تر، مشتریان می توانند کلیدها را از طریق IP متفاوتی نسبت به درخواست دروازه دانلود کنند.

سوم: دروازه ها باید بتوانند رله ها را احراز هویت کنند. از آنجایی که Gateway (بر اساس طراحی) اطلاعات کمی در مورد ارسال درخواستی توسط مشتری دارد، به رله اعتماد می کند تا مشتریان را احراز هویت کند و ترافیک را به طور مسئولانه ارسال کند. اما چگونه مطمئن می شوید که فقط رله های قابل اعتماد می توانند ترافیک را به دروازه شما ارسال کنند؟

ما دروازه را طوری طراحی کردیم که Cloudflare Access، محصول دسترسی به شبکه بدون اعتماد Cloudflare، قبل از رمزگشایی درخواست‌ها اجرا شود و به شما امکان می‌دهد از هر خط‌مشی استاندارد دسترسی برای احراز هویت ترافیک ورودی و محافظت از دروازه خود در برابر سوء استفاده استفاده کنید. گزینه‌ها شامل TLS متقابل، اعتبار سرویس استاتیک و منطق خارجی سفارشی است.

در نهایت: اشتباهاتی رخ می‌دهد، و ما پیش‌بینی می‌کردیم که مشتریان به‌طور تصادفی با اجرای رله و دروازه خود در Cloudflare، مدل حریم خصوصی OHTTP را بشکنند. بنابراین، برای حفظ تفکیک اعتماد OHTTP و اطمینان از اینکه Cloudflare هرگز هم هویت مشتری و هم درخواست‌های داخلی رمزگشایی شده را نمی‌بیند، دروازه ما از رمزگشایی درخواست‌های ارسال شده از Cloudflare Workers یا میزبان‌های پروکسی در Cloudflare خودداری می‌کند.

اگر می‌خواهید از مجموعه محصولات OHTTP Cloudflare استفاده کنید، اما تعجب می‌کنید که چرا باید دروازه OHTTP Cloudflare را به جای رله OHTTP انتخاب کنید، در اینجا چند نکته وجود دارد.

ابتدا، آیا می‌خواهید سرورهای برنامه خود را روی Cloudflare قرار دهید - برای مثال پشت CDN ما یا ساخته شده بر روی Workers؟ اگر چنین است، دروازه OHTTP برای اطمینان از پایبندی به مدل حریم خصوصی OHTTP مناسب‌تر است.

دوم، مورد استفاده شما چیست؟ اگر می‌خواهید درخواست‌های OHTTP را از یک کلاینت و رله شخص ثالث دریافت کنید - برای مثال، برای استفاده از LiveCallerID SDK اپل - احتمالا Gateway OHTTP راه‌حل بهتری برای شما خواهد بود.

اگر درخواست ویژگی دارید یا می‌خواهید در لیست انتظار ما ثبت‌نام کنید، بنابراین می‌توانیم هنگام راه‌اندازی محصول به شما اطلاع دهیم، اینجا ثبت‌نام کنید.

سپس، شما باید یک کلاینت OHTTP را پیاده سازی کنید. برای کمک به شروع کار، به ohttp.info یا نمونه کتابخانه مشتری ما مراجعه کنید. یک پرچم هنگام ساخت کلاینت: OHTTP حریم خصوصی را در سطح شبکه فراهم می کند و بدنه درخواست داخلی را لمس نمی کند. بنابراین، برای حفظ حریم خصوصی کاربر، این شما هستید که اطلاعات شناسایی (مانند آدرس ایمیل یا نام کاربری کاربر) را در بدنه درخواست ارسال نکنید.

در مرحله بعد، باید رله خود را بیاورید. رله‌ها می‌توانند روی هر ارائه‌دهنده زیرساخت اجرا شوند، و ساده هستند: در اینجا چند کد نمونه وجود دارد. چالش و دلیلی که ممکن است شما یک ارائه دهنده رله OHTTP اختصاصی بخواهید، این است که به طور قابل تایید به کاربران خود قول بدهید که لاگ ها را با شناسه های مشتری بازرسی نخواهید کرد. در غیر این صورت، می توانید مشتریان را در رله با درخواست های رمزگشایی شده در سرورهای برنامه خود مرتبط کنید.

در نهایت، هنگامی که استقرار OHTTP شما فعال شد، مشتری pvcli ما را بررسی کنید تا در تست و رفع اشکال کمک کند. ما هیجان‌زده هستیم که زیرساخت‌های حریم خصوصی قابل دسترس را برای توسعه‌دهندگان در همه جا بیاوریم. اگر می‌خواهید دروازه جدید OHTTP را امتحان کنید و سطح حریم خصوصی آنلاین را بالا ببرید، با ما تماس بگیرید.