VPN-এর ভিতরে OAuth: কোন ধাপগুলিতে এখনও TLS প্রয়োজন

ব্যক্তিগত রাউটিং ঠিক করে কে সার্ভারে পৌঁছায়; OAuth-এর পরিবহন নিয়ম ঠিক করে প্রতিটি বার্তা কীভাবে যায়। একটি ব্রাউজার, একটি অনুমোদন সার্ভার, একটি টোকেন এন্ডপয়েন্ট এবং একটি রিসোর্স সার্ভার সবই একই VPN-এর পিছনে থাকতে পারে এবং তবুও ভিন্ন ভিন্ন ধাপ দিয়ে বার্তা বিনিময় করতে পারে। প্রতিটি ধাপের নিজস্ব পরিবহন প্রয়োজন আছে, এবং VPN তার কোনোটিই শিথিল করে না। VPN-এর সীমা আর প্রোটোকলের সীমা দুইটি আলাদা রেখা।

সিদ্ধান্তটি সহজ হয় যদি আপনি জিজ্ঞাসা করা বন্ধ করেন যে নেটওয়ার্ক বিশ্বস্ত কি না এবং জিজ্ঞাসা শুরু করেন কোন বিনিময় কোন সীমা অতিক্রম করছে।

নেটওয়ার্ক দিয়ে নয়, ধাপ ধরে সিদ্ধান্ত নিন

এন্ডপয়েন্টগুলি আলাদা করে লিখুন: অনুমোদন এন্ডপয়েন্ট, টোকেন এন্ডপয়েন্ট, রিডাইরেক্ট URI, রিসোর্স সার্ভারের URL, TLS সমাপ্তির বিন্দু এবং VPN গেটওয়ে। তারপর চিহ্নিত করুন কোন পক্ষ প্রতিটি অনুরোধ শুরু করে এবং প্রতিক্রিয়া কোথায় যায়।

গেটওয়েতে শেষ হওয়া একটি VPN সেই গেটওয়ে পর্যন্ত অংশটি এনক্রিপ্ট করে। অনুরোধটি তার পিছনে সাধারণ HTTP হিসেবে চলতে পারে, এবং আগের অংশ এনক্রিপ্ট হওয়ার কারণে সেই অবশিষ্ট ধাপটি HTTPS হয়ে যায়নি। এই ধারাবাহিকতাই সেই ধাপ যা প্রোটোকলের কাছে গুরুত্বপূর্ণ। প্রথম লাফ এনক্রিপ্ট করলে দ্বিতীয় লাফ নিরাপদ হয় না।

পরিবহনটি একটি সেবা-পরিচয় যাচাইও বহন করে। ব্রাউজার অ্যাপ্লিকেশনের URL-এর জন্য সার্টিফিকেট যাচাই করে; একটি VPN ব্রাউজারের পক্ষে সেই যাচাই করে না, এবং এটি একটি অযাচাইকৃত এন্ডপয়েন্টকে গ্রহণযোগ্য করে না। সার্টিফিকেট সেই এন্ডপয়েন্টের নাম বলে যা ক্লায়েন্ট মনে করে সে ডাকছে। গেটওয়েতে যাওয়া একটি টানেল সেই এন্ডপয়েন্টের নাম বদলায় না বা যাচাই করে না।

অনুমোদন প্রতিক্রিয়া এবং রিডাইরেক্ট URI

OAuth-এর নিরাপত্তার বর্তমান সেরা অনুশীলন অ-এনক্রিপ্টেড সংযোগে অনুমোদন প্রতিক্রিয়া প্রেরণ নিষিদ্ধ করে। এটি সেই রিডাইরেক্টকেও কভার করে যা অনুমোদন কোড বা টোকেন ক্লায়েন্টের কাছে ফেরত নেয়, কেবল প্রাথমিক অনুরোধ নয়।

একই নির্দেশনা নির্দিষ্ট নেটিভ-ক্লায়েন্ট লুপব্যাক ক্ষেত্র ছাড়া HTTP রিডাইরেক্ট URI নিষিদ্ধ করে। একটি অভ্যন্তরীণ হোস্টনাম নতুন ব্যতিক্রম তৈরি করে না, এবং একটি DNS নাম যা কেবল VPN-এর ভিতরে সমাধান হয়, স্কিম তা বললে, তবুও একটি HTTP URL। নিবন্ধিত URI-তে স্কিম পরীক্ষা করুন, কেবল হোস্টনাম নয়।

সঠিক HTTPS রিডাইরেক্ট URI অনুমোদন সার্ভারে নিবন্ধন করুন এবং ক্লায়েন্টে সার্টিফিকেট যাচাই সক্রিয় রাখুন। HTTPS প্রয়োজনীয়তাকে চাপা দেওয়া একটি উন্নয়ন শর্টকাট এমন একটি প্রবাহ তৈরি করে যা তার অনুকরণ করার কথা এমন উৎপাদন কনফিগারেশন থেকে ভিন্ন আচরণ করে।

টোকেন এন্ডপয়েন্ট এবং বেয়ারার টোকেন অনুরোধ

টোকেন অনুরোধ শনাক্তকরণ তথ্য বা একটি কোড বহন করে যা প্রবেশাধিকারের বিনিময়ে বদলানো যায়। একটি অরক্ষিত ধাপে এটি পাঠানো এমন উপকরণ উন্মোচন করে যা রিসোর্স সার্ভার পরে বিশ্বাস করবে, আশপাশের নেটওয়ার্ক ব্যক্তিগত হলেও। যে প্রক্সি অনুরোধ পড়তে পারে সে তার বহন করা শনাক্তকরণ তথ্যও পড়তে পারে।

বেয়ারার টোকেন রিসোর্স অনুরোধের জন্য RFC 6750 সেই স্পেসিফিকেশনে বাস্তবায়ন ও ব্যবহারের জন্য TLS-কে বাধ্যতামূলক বলে গণ্য করে। অফিস সাবনেটকে বিশ্বস্ত বলা সাধারণ প্রোটোকল ব্যতিক্রম নয় যা একটি প্লেইনটেক্সট বেয়ারার স্থাপনার দরকার।

উভয় ধাপের জন্য নথিভুক্ত নিরাপদ এন্ডপয়েন্ট URL ব্যবহার করুন। যদি একটি লাইব্রেরি HTTP টোকেন এন্ডপয়েন্ট ডাকতে অস্বীকার করে, সেই অস্বীকৃতি হলো স্পেসিফিকেশন কাজ করছে, এড়িয়ে যাওয়ার মতো কনফিগারেশন ত্রুটি নয়। সেই URL চলমান অবস্থায় বের না করে ক্লায়েন্ট কনফিগারেশনে লিখে রাখুন।

TLS কোথায় শেষ হয় এবং তা কী রেখে যায়

যদি TLS একটি অনুমোদিত ফ্রন্টএন্ডে শেষ হয়, সেই ফ্রন্টএন্ডের নাম দিন এবং তা থেকে অ্যাপ্লিকেশন পর্যন্ত পথটি পর্যালোচনা করুন। ফ্রন্টএন্ড অবশিষ্ট অংশে ফরোয়ার্ডিং, বিশ্বাস এবং গোপনীয়তার দায়িত্ব নেয়, এবং সেবার সমর্থিত আর্কিটেকচার সেই ব্যবস্থা বর্ণনা করা উচিত।

পথের অন্য কোথাও থাকা একটি VPN সেই দায়িত্বগুলি মেটায় না। এটি আপনাকে এটিও বলে না যে ব্রাউজার যে অ্যাপ্লিকেশন URL দেখে তা ফ্রন্টএন্ড যে সার্টিফিকেট উপস্থাপন করে তার সঙ্গে মেলে কি না।

অভ্যন্তরীণ স্থাপনার জন্য সমাপ্তির বিন্দু এবং এটি যে পরিচয় উপস্থাপন করে তা লিখুন। যে ফ্রন্টএন্ড ভিন্ন নামের সার্টিফিকেট দিয়ে TLS শেষ করে, সেটি একটি ব্রাউজার সতর্কবার্তা তৈরি করে যা অপারেটররা ঠিক করার বদলে প্রায়শই চাপা দেয়।

নেটিভ লুপব্যাক ব্যতিক্রমটি সংকীর্ণ

লুপব্যাক রিডাইরেক্ট ব্যতিক্রমটি ব্যবহারকারীর নিজের ডিভাইসে একটি কলব্যাক সম্পর্কে, যেখানে ক্লায়েন্ট ও ব্রাউজার সেই ডিভাইস ভাগ করে। সেই ব্যবস্থাটি এক ডিভাইসের কলব্যাকের অন্তর্গত, এবং এটি অফিস সাবনেটে HTTP দিয়ে একটি সাধারণ অনুমোদন সার্ভার বা টোকেনবাহী API পরিবেশন করার অনুমতি দেয় না।

ব্যতিক্রমটি ক্লায়েন্টের ধরন এবং যে কলব্যাকের কথা এটি বলে তার মধ্যেই সীমিত রাখুন। এটি একটি ওয়েব অ্যাপ্লিকেশন, একটি শেয়ার্ড অভ্যন্তরীণ সেবা বা অন্য হোস্টে থাকা রিডাইরেক্ট URI-তে প্রয়োগ করলে স্থাপনাটি বদলায়, ব্যতিক্রমটি নয়।

প্রতিটি সীমায় প্রকৃত প্রবাহ পরীক্ষা করুন এবং ক্লায়েন্টের ধরনের সঙ্গে তুলনা করুন। কাজ করা একটি রিডাইরেক্ট বলে না যে টোকেন বহনকারী প্রতিটি ধাপ প্রয়োজনীয় সুরক্ষা ব্যবহার করেছে, এবং একটি সবুজ VPN আইকন পরবর্তী অনুরোধের স্কিম সম্পর্কে কিছুই বলে না।