HTTPS આધારિત બેઝિક પ્રમાણીકરણ વિરુદ્ધ IPsec: દરેક શું રક્ષે છે
બ્રાઉઝરથી એપ્લિકેશન સુધી એક વિનંતીને અનુસરો: TLS થર, 401 પ્રતિસાદ અને ટનલ જુદા જુદા સંબંધોને રક્ષે છે અને જુદા જુદા પુરાવા સાથે નિષ્ફળ જાય છે.
ડેવલપર ટૂલ્સ ખોલો, આંતરિક એપ લોડ કરો અને પૃષ્ઠ રેન્ડર થાય તે પહેલાં એક વિનંતી ચાર ચેકપોઇન્ટમાંથી પસાર થાય તે જુઓ. પહેલા નામ ઉકેલાય છે, પછી TCP કનેક્શન ખૂલે છે, પછી TLS હેન્ડશેક નક્કી કરે છે કે સર્વર કોણ છે, અને ત્યાર પછી જ એપ્લિકેશન પૂછે છે કે તમે કોણ છો. આને અલગ ઘટનાઓ તરીકે લો, કારણ કે દરેક જુદા પુરાવા સાથે નિષ્ફળ જાય છે અને દરેકની માલિકી જુદી ટીમની છે. ઘટનાઓમાં મોટાભાગની ગૂંચવણ 401 ને ટનલ સમસ્યા તરીકે વાંચવાથી, અથવા ટનલ સમસ્યાને ખોટા પાસવર્ડ તરીકે વાંચવાથી આવે છે.
ચેકપોઇન્ટ એક: શું આ એ જ સર્વર છે જેની સાથે તમે વાત કરવા માગતા હતા
કોઈ પણ ઓળખપત્ર મોકલાય તે પહેલાં TLS હેન્ડશેક તે પ્રશ્નનો જવાબ આપે છે. તમારો ક્લાયન્ટ ટ્રસ્ટ સ્ટોર સામે પ્રમાણપત્ર સાંકળની ચકાસણી કરે છે અને પ્રમાણપત્રમાંનું નામ તમે લખેલા હોસ્ટ સાથે મેળ ખાય છે કે નહીં તે તપાસે છે. જો તે નિષ્ફળ જાય, તો બ્રાઉઝર પ્રમાણપત્ર ભૂલ બતાવે છે અને Authorization હેડર બિલકુલ મોકલતું નથી. તેથી પાસવર્ડ પ્રોમ્પ્ટ એ સર્વર અસલી હોવાનો પુરાવો નથી; તે એ પુરાવો છે કે એપ્લિકેશને જવાબ આપ્યો.
અહીં પ્રથમ સીમા દેખાય છે. TLS તેના અંતિમ બિંદુ સુધી કનેક્શનને રક્ષે છે. જો લોડ બેલેન્સર TLS સમાપ્ત કરે છે અને સાદી HTTP એપ્લિકેશનને મોકલે છે, તો એન્ક્રિપ્ટેડ સેગમેન્ટ બેલેન્સર પર પૂરો થાય છે, અને ઓળખપત્રો ફક્ત તે પ્રથમ થર પર જ સુરક્ષિત રહે છે.
ચેકપોઇન્ટ બે: 401 આદાન-પ્રદાનમાં ખરેખર શું મુસાફરી કરે છે
HTTP બેઝિક પ્રમાણીકરણ વપરાશકર્તા ઓળખકર્તા અને પાસવર્ડને હેડરમાં મોકલે છે, Base64 સાથે એન્કોડ કરેલા, જેમ કે વર્ણવ્યું છે RFC 7617 માં. Authorization: Basic dXNlcjpwYXNz તેનું સ્વરૂપ છે; એન્કોડિંગને વિનંતી વાંચી શકે તેવું કોઈ પણ ઉલટાવી શકે છે, તેથી બધી ગુપ્તતા નીચેના પરિવહનમાંથી આવે છે. curl -v બંને WWW-Authenticate: Basic પડકાર અને તમે પરત મોકલેલું હેડર બતાવે છે.
તે હેડર એપ્લિકેશનને કહે છે કે કોણ પૂછે છે. તે નેટવર્કને કહેતું નથી કે કોણ કનેક્ટ કરી શકે છે, અને તે પોતે કંઈ એન્ક્રિપ્ટ કરતું નથી. એપ્લિકેશનને હજી પણ સ્ટોર સામે ઓળખપત્ર ચકાસવું પડે છે અને નક્કી કરવું પડે છે કે તે ખાતું શું કરી શકે, જે અધિકૃતતા છે અને પ્રમાણીકરણ પછી થાય છે.
તે માર્ગમાં IPsec ટનલ ક્યાં બેસે છે
હવે બ્રાઉઝરથી બહારની તરફ ચાલો. ગેટવેથી ગેટવે સુધીની IPsec ટનલ બે સુરક્ષા ગેટવે વચ્ચેના પસંદ કરેલા ટ્રાફિકને રક્ષે છે, તમારા લેપટોપ અને એપ્લિકેશન પ્રક્રિયા વચ્ચે નહીં. ટનલ મોડ ESP મૂળ પેકેટને લપેટે છે, ગેટવે તેને એન્ક્રિપ્ટ અને પ્રમાણિત કરે છે, અને આંતરિક સરનામાં ટકી રહે છે જેથી દૂરની બાજુ વિનંતીને એપ્લિકેશન સુધી રૂટ કરી શકે.
પસંદગી એ ભાગ છે જ્યાં લોકો ઠેકડી ખાય છે. નીતિ-આધારિત ટનલ ટ્રાફિક સિલેક્ટરનો ઉપયોગ કરે છે, જે ઘણી વાર એક્સેસ કંટ્રોલ લિસ્ટ તરીકે વ્યક્ત થાય છે, જેથી નક્કી થાય કે કયા પેકેટ ટનલમાં પ્રવેશે. રૂટ-આધારિત ટનલ તેના બદલે વર્ચ્યુઅલ ઇન્ટરફેસ અને રૂટિંગ ટેબલ વાપરે છે. Linux માં ip xfrm policy સિલેક્ટર બતાવે છે અને ip xfrm state સ્થાપિત સુરક્ષા સંગઠનો બતાવે છે; ફાયરવોલ ઉપકરણમાં સમકક્ષ ટનલનું SA ટેબલ વત્તા પેકેટ ટ્રેસર છે.
પરિણામ સ્પષ્ટ કહેવા લાયક છે. એક પેકેટ સંપૂર્ણ સ્વસ્થ ટનલની અંદર બેસી શકે છે અને તો પણ એવી HTTPS વિનંતી વહન કરી શકે છે જે એપ્લિકેશન નકારે છે, અને માન્ય ઓળખપત્રો કોઈ ટનલ વગરના માર્ગે પણ આવી શકે છે જો રૂટિંગ પરવાનગી આપે.
જે સ્તરે ભૂલની જાણ કરી તે સ્તરે તેને વાંચો
401 નો અર્થ છે કે એપ્લિકેશને ઓળખપત્ર સ્વીકાર્યું નથી. 403 નો અર્થ છે કે તેણે ઓળખ સ્વીકારી અને ક્રિયા નકારી. TLS ભૂલનો અર્થ છે કે ક્લાયન્ટે સર્વર સ્વીકાર્યું નથી. કોઈ રૂટ નથી અથવા નીતિ મેળ ખાતી નથી એટલે પેકેટ ક્યારેય દૂરના ગેટવે સુધી પહોંચ્યું નથી. ચાર જુદી જુદી નિષ્ફળતાઓ, ચાર જુદા જુદા માલિકો, અને લોગિન ફોર્મ સામે જોઈને એમાંથી કોઈનું નિદાન થતું નથી.
દરેક સ્તર જે પુરાવો ઉત્પન્ન કરે તેનો ઉપયોગ કરો: સ્થિતિ અને હેડર માટે બ્રાઉઝરનું નેટવર્ક પેનલ, પ્રમાણપત્ર સાંકળ માટે openssl s_client -connect host:443, ટનલ ટ્રાફિક માટે ગેટવેના SA કાઉન્ટર અને લોગ, અને ખાતાના નિર્ણય માટે એપ્લિકેશન લોગ. જ્યારે બે સ્તર એકસાથે ભૂલોની જાણ કરે, ત્યારે પહેલા નીચેનું સુધારો, કારણ કે મૃત ટનલ પ્રમાણીકરણ નિષ્ફળતાને સરળતાથી છુપાવી શકે છે અને ઊલટું પણ.
એક સેવાને શરૂઆતથી અંત સુધી મેપ કરો
તમે જે સેવાનું નિદાન કરી રહ્યા છો તેના માટે પાંચ લીટી લખો: ટનલ કયા સાથીદારોને જોડે છે, સિલેક્ટર કયા સબનેટ અને પોર્ટની મંજૂરી આપે છે, TLS ક્યાં સમાપ્ત થાય છે અને પ્રમાણપત્ર કઈ ઓળખ દાવો કરે છે, કયું એપ્લિકેશન ખાતું અને ભૂમિકા વપરાય છે, અને દરેક સ્તર ક્યાં લોગ કરે છે. તેમને એક પૃષ્ઠ પર રાખો, કારણ કે નકશાનો હેતુ એ બતાવવાનો છે કે એક સ્તરની જવાબદારી ક્યાં પૂરી થાય છે અને આગળનું ક્યાં શરૂ થાય છે.
પછી દરેક સ્તર માટે એક નકારાત્મક કેસ ચકાસો. ખોટો પાસવર્ડ વાપરો અને ખાતરી કરો કે તમને 401 મળે છે, ટાઇમઆઉટ નહીં. સિલેક્ટરની બહારના સબનેટથી કનેક્ટ કરો અને ખાતરી કરો કે પેકેટ ટનલમાંથી પસાર થતું નથી. ખોટા નામ માટે પ્રમાણપત્ર રજૂ કરો અને ખાતરી કરો કે ક્લાયન્ટ ઓળખપત્રો મોકલતા પહેલા ઇનકાર કરે છે. તે ત્રણ પરિણામો તમને ડિઝાઇન વિશે કોઈ પણ બોક્સ ડાયાગ્રામ કરતાં વધુ કહે છે.
છેલ્લે, દરેક સંબંધને કઈ સુરક્ષા જોઈએ તે સભાનપણે નક્કી કરો. TLS પર બેઝિક પ્રમાણીકરણ ગેટવે પાછળની નાની આંતરિક સાધન માટે વાજબી પસંદગી છે; તે વપરાશકર્તા-દીઠ અધિકૃતતા કે TLS અંતિમ બિંદુની બહારના ટ્રાફિકની સુરક્ષાનો વિકલ્પ નથી. ટનલ માર્ગને રક્ષે છે, પ્રમાણપત્ર થરને રક્ષે છે, અને 401 ખાતાને રક્ષે છે, અને ફક્ત છેલ્લું જ જાણે છે કે તમે કોણ છો.