શું સર્વર પ્રમાણપત્ર શૃંખલા ક્લાયન્ટના ટ્રસ્ટ સ્ટોરને બાયપાસ કરી શકે છે?

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

માન્યતા ક્લાયન્ટ પર ચાલે છે, ક્લાયન્ટના એન્કર સાથે

પાથ માન્યતા રજૂ કરેલા પ્રમાણપત્રો લે છે અને એવા ટ્રસ્ટ એન્કર સુધી શૃંખલા બનાવે છે જે માન્યતા પ્રણાલી પાસે પહેલેથી છે. RFC 5280 એ મોડલનું વર્ણન કરે છે, અને એન્કરની પસંદગી સર્વર પાસે નહીં પણ સ્થાનિક અમલીકરણ પાસે મૂકે છે. એપ્લિકેશન તેની પોતાની નીતિ ઉપર ઉમેરી શકે છે: પિન કરેલી ચાવી, એન્ટરપ્રાઇઝ ટ્રસ્ટ સ્ટોર, અથવા વધુ કડક ઓળખ ચકાસણી. સર્વર મોકલે છે તે પ્રમાણપત્ર યાદી એ પ્રક્રિયાને અર્પાયેલો પુરાવો છે, તેને આપેલી સૂચના ક્યારેય નહીં.

તેથી સંપૂર્ણ શૃંખલા સાબિત કરે છે કે સર્વર પાસે ટુકડા છે. તે સાબિત કરતું નથી કે ક્લાયન્ટ તેમને સ્વીકારશે.

સર્વર ખરેખર શું મોકલે છે તે જોવા માટે, ચલાવો openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts અને આઉટપુટમાં પ્રમાણપત્રોની ગણતરી કરો. ત્યાં અપૂર્ણ શૃંખલા સર્વર-બાજુનું સુધારણું છે. સંપૂર્ણ શૃંખલા પ્રશ્નને ક્લાયન્ટ અને તેના એન્કર પાસે ખસેડે છે, જ્યાં સર્વરનો કોઈ મત નથી.

TLS નિરીક્ષણ ખરેખર શું બદલે છે

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

ગોઠવણ જાણી જોઈને અને સ્થાનિક છે. મૂળ સર્વરની શૃંખલામાં કંઈ પણ બિન-મેનેજ કરેલા બ્રાઉઝરને અવેજી ઓળખ સ્વીકારવા ફરજિયાત કરી શકતું નથી, અને તેમાં કંઈ પણ મેનેજ કરેલા ઉપકરણને એમ કરતું અટકાવતું નથી.

VPN સમાપ્તિ એ HTTPS ડિક્રિપ્શન નથી

VPN સ્તર ક્લાયન્ટ અને ગેટવે વચ્ચે પેકેટ વહન કરે છે. તેને દૂર કરવાથી, અથવા તેનું રૂપરેખાંકન વાંચવાથી, અંદરનો HTTPS પેલોડ ખૂલતો નથી.

TLS સત્ર હજી પણ બ્રાઉઝર અને વેબ સર્વર વચ્ચે, સમાન માન્યતા નિયમો સાથે ચાલે છે, સિવાય કે કંઈક તેને સ્પષ્ટ રીતે સમાપ્ત કરે. બે સ્તરોને ભેગા કરવાથી VPN વ્યવસ્થાપકને પ્રમાણપત્ર પૂરું પાડવાની વિનંતી થાય છે, જ્યારે પ્રશ્નમાંનું પ્રમાણપત્ર નિરીક્ષણ પ્રોક્સીનું કે સાઇટનું પોતાનું હોય છે. કોઈ પણ ટ્રસ્ટ સ્ટોર બદલતા પહેલા પૂછો કે કયો ઘટક પ્રમાણપત્ર રજૂ કરે છે.

તમે જે ઘટક નિયંત્રિત કરો છો તેમાં અપેક્ષાઓ સેટ કરો

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

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

પરિણામને સ્વચ્છ ક્લાયન્ટ પ્રોફાઇલ પર ચકાસો, જે મશીન પર પહેલેથી અપવાદ ઉમેરાયો છે તેના પર નહીં. નવું ઉપકરણ શું અનુભવશે તે દર્શાવતી આ એકમાત્ર ચકાસણી છે.