HTTPS પ્રોક્સી લેબલ ફક્ત તમારા ક્લાયન્ટ અને પ્રોક્સી વચ્ચેના પરિવહનનું વર્ણન કરે છે, વધુ કંઈ નહીં। તે એમ નથી કહેતું કે તેની પાછળની વેબસાઇટ એ જ કનેક્શનથી એન્ક્રિપ્ટ થયેલી છે, અને એમ પણ નથી કહેતું કે પ્રોક્સી પૃષ્ઠ વાંચી શકે છે। જેવું તમે બે કનેક્શન અલગ કરો છો, પ્રમાણપત્રની ભૂલો રહસ્યમય રહેવાનું બંધ કરે છે અને VPN સાથેની સરખામણી મૂર્ત બને છે।

બે છેડા જોડીઓ, બે ચકાસણીઓ

સામાન્ય ટનલ મોડમાં બે TLS સંબંધો હોય છે। પ્રથમ તમારા ક્લાયન્ટથી પ્રોક્સી સુધી જાય છે અને પ્રોક્સીને પ્રમાણિત કરે છે। બીજું તમારા ક્લાયન્ટથી ટનલની અંદરની વેબસાઇટ સુધી જાય છે અને વેબસાઇટને પ્રમાણિત કરે છે। તે સ્વતંત્ર રીતે નિષ્ફળ જાય છે અને સ્વતંત્ર રીતે ગોઠવાય છે।

તેમની પાસે અલગ વિશ્વાસ નિર્ણયો, અલગ પ્રમાણપત્ર સાંકળો અને અલગ નિષ્ફળતા સંદેશાઓ છે। સંસ્થાકીય CA વાપરતી પ્રોક્સી અને જાહેર સાંકળ વાપરતી જાહેર વેબસાઇટને કાયદેસર રીતે અલગ ચકાસણી રૂપરેખાંકનની જરૂર પડી શકે છે, અને તે ખોટું રૂપરેખાંકન નથી।

તેમને એવા બે કનેક્શન તરીકે ગણો જે એક જ સોકેટ વહેંચે છે, કારણ કે તેઓ એવા જ છે।

CONNECT ખરેખર શું ટનલ કરે છે

ક્લાયન્ટ હોસ્ટ અને પોર્ટનું નામ આપીને CONNECT વિનંતી મોકલે છે, અને પ્રોક્સી તે લક્ષ્ય સાથે TCP કનેક્શન ખોલે છે। પ્રોક્સી જવાબ આપ્યા પછી, પછીના બાઇટ્સ કોઈ અર્થઘટન વિના રિલે થાય છે, તેથી જ વેબસાઇટનું TLS હેન્ડશેક પ્રોક્સીમાંથી અકબંધ પસાર થાય છે। આમ પ્રોક્સી ગંતવ્યનું નામ અને કનેક્શનનું મેટાડેટા જાણે છે, પરંતુ તે ગોઠવણમાંથી ડિક્રિપ્ટ થયેલા પૃષ્ઠો મેળવતું નથી।

એ ભેદ ટનલ મોડની આખી સુરક્ષા દલીલ છે, અને તે તેની મર્યાદા પણ છે।

પ્રોક્સી હોપ પર TLS વગરની HTTP પ્રોક્સી હજી પણ CONNECT દ્વારા HTTPS વેબસાઇટ વહન કરે છે। ક્લાયન્ટ-થી-પ્રોક્સી વિનિમય ખુલ્લો રહે છે જ્યારે વેબસાઇટ કનેક્શન નથી, અને આખી વસ્તુને HTTPS પ્રોક્સી કહેવું એ ભેદ છુપાવે છે।

કયું પ્રમાણપત્ર નિષ્ફળ ગયું

જ્યારે ચકાસણી નિષ્ફળ જાય, ત્યારે કોઈપણ વિશ્વાસ સેટિંગ બદલતા પહેલાં ભૂલમાં દર્શાવેલો છેડો વાંચો। બે નિષ્ફળતાઓ ટર્મિનલમાં સરખી દેખાય છે અને સંપૂર્ણપણે અલગ સુધારા તરફ ઈશારો કરે છે, તેથી જ પહેલો પ્રશ્ન હંમેશા એ હોય છે કે કયા કનેક્શને નકાર્યું।

curl બરાબર આ જ કારણસર વિકલ્પોને અલગ રાખે છે। પ્રોક્સી CA ફાઇલ પ્રોક્સીની ચકાસણી ગોઠવે છે, જ્યારે CA ફાઇલ સર્વરની ચકાસણી ગોઠવે છે, અને લાગુ પડતા ટ્રસ્ટ સ્ટોરનું વર્તન પણ curl કેવી રીતે બનાવાયું તેના પર આધાર રાખે છે।

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

ચકાસણીને દબાવવી એ સમારકામ નથી। તે બંને છેડાઓમાંથી કોઈના વિશે કંઈ પણ સાબિત કરતું નથી।

નિરીક્ષણ એ એક અલગ ગોઠવણ છે

TLS નિરીક્ષણ ટનલિંગ નથી। નિરીક્ષક મધ્યસ્થ વેબસાઇટ તરફનો વિશ્વાસ સંબંધ સમાપ્ત કરે છે અને ક્લાયન્ટ સમક્ષ પોતાનું પ્રમાણપત્ર રજૂ કરે છે, તેથી ક્લાયન્ટ સાઇટને બદલે મધ્યસ્થની ચકાસણી કરે છે। મંજૂર ડિઝાઇન હેઠળ તે કાયદેસર હોઈ શકે છે, અને તે બાઇટ-બાય-બાઇટ રિલે કરવાથી દ્રવ્ય રીતે અલગ દાવો છે। દરેક પ્રોક્સી નિરીક્ષણ કરે છે એમ ધારો નહીં, અને એન્ક્રિપ્ટેડ પ્રોક્સી હોપ તેને બાકાત રાખે છે એમ પણ ધારો નહીં।

તમારા ટ્રસ્ટ સ્ટોરમાં રહેલી સંસ્થાકીય CA એ તમે કઈ ગોઠવણમાં છો તેનો સંકેત છે, પુરાવો નહીં। પ્રમાણપત્ર સાંકળમાંથી અનુમાન કરવાને બદલે ડિઝાઇન પૂછો।

તે બે ગોઠવણો પૃષ્ઠ કોણ વાંચી શકે છે એ પ્રશ્નના અલગ જવાબ આપે છે।

એ જ ચાર લાઇન પર પ્રોક્સી અને VPNની સરખામણી કરો

બંને તૈનાતીઓને એક જ રીતે વર્ણવવામાં આવે ત્યારે જ સરખામણી ઉપયોગી બને છે।

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

એક વિનંતી માટે ગોઠવાયેલી પ્રોક્સી તે વિનંતીને આવરી લે છે। તે ઉપકરણની દરેક પ્રક્રિયાને પોતાનામાંથી પસાર કરતું નથી, અને ઉદાહરણ આદેશ બરાબર એટલો જ સાંકડો છે। VPNનું આવરણ તેના રૂટિંગ અને એપ્લિકેશન નીતિ પર આધાર રાખે છે, જે પણ ધારવાને બદલે ચકાસવું જોઈએ। કોઈપણ વિકલ્પ ફક્ત સ્થાપિત હોવાને કારણે બધું આવરી લેતું નથી।

દરેક વિકલ્પ માટે ચાર લાઇન લખો અને દલીલ સામાન્ય રીતે જાતે જ ઉકેલાઈ જાય છે। ઉપયોગી સરખામણી એ નથી કે કયું લેબલ વધુ એન્ક્રિપ્ટેડ સંભળાય છે। પરંતુ એ છે કે કયા સેગમેન્ટ સુરક્ષિત છે, તેમના છેડે કોની ચકાસણી થાય છે, કયા મધ્યસ્થો પર તમે વિશ્વાસ કરો છો, અને નીતિ ખરેખર કયો ટ્રાફિક આવરી લે છે।

સંબંધિત લેખો