Cloudflare-მა მართული OHTTP Gateway-ის დახურული ბეტა გაუშვა

მართული გზა პირადი HTTP-მოთხოვნებისკენ

Cloudflare-მა გაუშვა OHTTP Gateway-ის დახურული ბეტა, IETF-ის სტანდარტზე დაფუძნებული მართული სერვისი, რომელიც აპლიკაციის backend-ებს HTTP-მოთხოვნების მიღების საშუალებას აძლევს მომხმარებლების IP-მისამართების ნახვის გარეშე. OHTTP კლიენტისთვის ხილულ კონფიდენციალურობას მოთხოვნის დამუშავებისგან ორი დამოუკიდებელი კომპონენტით ჰყოფს. Relay დაშიფრულ მოთხოვნებს გადასცემს და კლიენტის იდენტიფიკატორებს აპლიკაციის სერვერისგან მალავს. Gateway მოთხოვნებს დეკაპსულირებს და პასუხებს ინკაპსულირებს, რაც სერვერს ჩვეულებრივი HTTP-ის დამუშავების საშუალებას აძლევს.

დიზაინი იმისთვისაა, რომ არცერთ მხარეს ერთდროულად არ დაინახოს კლიენტის იდენტიფიკატორებიც და მოთხოვნის შიგთავსიც. Relay ხედავს იდენტიფიკატორებს, როგორიცაა IP-მისამართი ან TLS-ის fingerprint, მაგრამ არა მოთხოვნის ღია ტექსტს. Gateway და აპლიკაციის სერვერი შიგთავსს ამუშავებენ, მაგრამ საბოლოო მომხმარებლის ქსელურ იდენტობას არ იგებენ. Cloudflare-ის თქმით, Gateway განსაკუთრებით მის CDN-ის ან Workers-ის უკან ჰოსტდებულ აპლიკაციებსა და მესამე მხარის relay-დან ტრაფიკის მიმღებ სერვისებს ეხმარება. დახურული ბეტა თვითმომსახურებადია, ფასიანი zone-დამატება კი ამ შემოდგომაზე იგეგმება.

Relay-სა და Gateway-ის ვარიანტები

Cloudflare-მა OHTTP relay-ის პროდუქტი, Privacy Gateway, 2022 წელს გაუშვა და ახლა Cloudflare OHTTP Relay-ად იცვლის სახელს. დეველოპერებს, რომელთა აპლიკაციის სერვერები Cloudflare-ის გარეთაა, შეუძლიათ Cloudflare-ის relay გამოიყენონ და საკუთარი gateway გაუშვან. ისინი, ვინც სერვერებს Cloudflare-ით იცავს, ახალ მართულ Gateway-ს დამოუკიდებელი მესამე მხარის relay-თან გამოიყენებენ. ასე OHTTP-ისთვის საჭირო ნდობის განცალკევება შენარჩუნდება.

Cloudflare მაგალითად მოჰყავს Flo Health-ის Anonymous Mode და Apple-ის Private Cloud Compute, როგორც OHTTP-ის უკვე არსებული გამოყენებები. ის ასევე ასახელებს გარე relay-დან მოთხოვნების მიღებას, მათ შორის Apple-ის LiveCallerID SDK-სთან დაკავშირებულ ტრაფიკს, როგორც Gateway-ის გამოყენების სცენარს.

შექმნილია edge-განლაგებისთვის

სერვისი Cloudflare-ის გლობალურ edge-ქსელშია განლაგებული და ავტომატურად სკალირდება. Cloudflare-ის თქმით, anycast არქიტექტურა relay-დან Gateway-მდე დაყოვნებას ამცირებს, CDN-თან გამოყენება კი Gateway-დან origin-მდე დაყოვნებას. Gateway მხარს უჭერს სტანდარტულ და chunked OHTTP-ს; უკეთესი წარმადობისთვის რეკომენდებულია chunked დამუშავება. მისი ჩართვა zone-ზე შეიძლება, წვდომა კი /.well-known/ohttp-gateway მისამართზეა. სერვისი OHTTP-მოთხოვნებს ამუშავებს და დაშიფრულ პასუხებს აბრუნებს, არა-OHTTP ტრაფიკი კი Gateway-ის გარეშე origin-ისკენ მიდის.

Cloudflare მართავს HPKE-ის გასაღებებს, რომლებიც კლიენტებს მოთხოვნების დასაშიფრად სჭირდებათ, და აწვდის საჯარო გასაღების კონფიგურაციებს. Cloudflare Access დეკრიპტირებამდე მუშაობს და ტრაფიკს mutual TLS-ით, სტატიკური სერვისის რწმუნებებით ან გარე ლოგიკით ავთენტიფიკაციას უწევს. Zone binding ხელს უშლის Gateway-ის გამოყენებას დაუკავშირებელი დომენების წინააღმდეგ. OHTTP-ის კონფიდენციალურობის მოდელის დარღვევის თავიდან ასაცილებლად Gateway არ გაშიფრავს Cloudflare Workers-იდან ან Cloudflare-ზე პროქსირებული ჰოსტებიდან მოსულ მოთხოვნებს.

განლაგების მოთხოვნები და შეზღუდვები

დეველოპერებს, რომლებსაც მართული Gateway სურთ, მაინც უნდა შექმნან OHTTP-კლიენტი და მოიყვანონ საკუთარი დამოუკიდებელი relay. Cloudflare-ის თქმით, ეს განცალკევება relay-ის პროვაიდერს საშუალებას აძლევს შემოწმებადად დაჰპირდეს, რომ კლიენტის იდენტიფიკატორების ლოგებს არ შეამოწმებს, რაც ამცირებს მომხმარებლების გაშიფრულ მოთხოვნებთან დაკავშირების რისკს. OHTTP ქსელურ იდენტიფიკატორებს იცავს, მაგრამ შიდა მოთხოვნის body-ს არ ცვლის. ამიტომ დეველოპერებმა იქ პირადი იდენტიფიკატორები, როგორიცაა ელფოსტის მისამართები ან მომხმარებლის სახელები, არ უნდა განათავსონ. Cloudflare ასევე გვაწვდის pvcli კლიენტს ცოცხალი OHTTP განლაგებების ტესტირებისა და გამართვისთვის.