TLS ભૂલો ફક્ત કોર્પોરેટ VPN પર: યોગ્ય ટ્રસ્ટ સ્ટોર સુધારો

Go બિલ્ડ, Composer ઇન્સ્ટોલ અને Python ક્લાયન્ટ—બધા ઘરે કામ કરે છે અને બધા કંપનીના VPN ની અંદર નિષ્ફળ જાય છે. એ પેટર્ન તમને એપ્લિકેશન વિશે નહીં, પથ વિશે કહે છે. ટનલ પર કંઈકે તમારી પ્રક્રિયા જે પ્રમાણપત્ર સાંકળ જુએ છે તે બદલી નાખી, અથવા કોઈ સાંકળ આવે તે પહેલાં જ હેન્ડશેક રીસેટ કરી દીધો. બંને ખામી ટર્મિનલમાં એકસરખી દેખાય છે અને સાવ અલગ પ્રતિસાદ માંગે છે.

ત્રણ સંદેશા, ત્રણ મિકેનિઝમ

x509 certificate signed by unknown authority ભૂલનો અર્થ છે કે સાંકળ બની છે અને તેનું રૂટ એ પ્રક્રિયા જે ટ્રસ્ટ સ્ટોર વાપરે છે તેમાં નથી. self-signed certificate in certificate chain ભૂલનો સામાન્ય અર્થ છે કે નિરીક્ષણ પ્રોક્સીએ પોતાના પ્રમાણપત્ર સાથે જવાબ આપ્યો, જે એવી સાંકળ છે જે તમારું રનટાઇમ ઓળખતું નથી. હેન્ડશેક દરમિયાન SSL EOF નો અર્થ છે કે કોઈ પણ ઉપયોગી પ્રમાણપત્ર મોકલાય તે પહેલાં જોડાણ બંધ થઈ ગયું, અને તે ClientHello ને નકારતું મધ્યવર્તી ઉપકરણ છે, બિલકુલ ટ્રસ્ટ સમસ્યા નથી.

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

પ્રક્રિયા ખરેખર જે બંડલ વાંચે છે તે શોધો

Windows સ્ટોરમાં ઇન્સ્ટોલ કરેલું કોર્પોરેટ રૂટ સિસ્ટમ સ્ટોર જોતા બ્રાઉઝર અને .NET એપ્લિકેશનને સુધારે છે. કન્ટેનરની અંદર ચાલતા બિલ્ડ માટે તે કંઈ કરતું નથી, કારણ કે તેનું પોતાનું CA બંડલ હોય છે, અને certifi વાપરતી Python પ્રક્રિયા કે પોતાની સમાવિષ્ટ યાદી વાપરતી Node પ્રક્રિયા માટે પણ કંઈ કરતું નથી. Go બાઈનરી જે પર્યાવરણમાં ચાલે છે તેનો સિસ્ટમ પૂલ વાંચે છે, એટલે કે કન્ટેનર, લેપટોપ નહીં. તેથી એક જ મશીન એકસાથે કામ કરતું બ્રાઉઝર અને નિષ્ફળ જતું બિલ્ડ સાધન આપે છે.

ધારી લેવાને બદલે સાધનને પૂછો. python3 -c "import ssl; print(ssl.get_default_verify_paths())" Python જે ફાઇલોની સલાહ લેશે તે છાપે છે, અને node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" બતાવે છે કે ઓવરરાઇડ પહેલેથી સેટ છે કે નહીં. કન્ટેનર માટે, ઇમેજની અંદર જ એ જ ચકાસણી ચલાવો, કારણ કે બિલ્ડ ખરેખર એ જ પર્યાવરણ વાપરે છે.

જ્યાં બિલ્ડ ચાલે છે ત્યાં જ એક રૂટ ઇન્સ્ટોલ કરો

IT પાસેથી નિરીક્ષણ રૂટ PEM ફાઇલ તરીકે મેળવો અને તેના પર ભરોસો કરતા પહેલાં અલગ ચેનલ દ્વારા તેની ફિંગરપ્રિન્ટ ચકાસો. Debian આધારિત ઇમેજ પર, તેને /usr/local/share/ca-certificates/ માં કૉપિ કરો અને update-ca-certificates ચલાવો; RHEL કુટુંબની ઇમેજ ફાઇલને /etc/pki/ca-trust/source/anchors/ માં મૂક્યા પછી update-ca-trust વાપરે છે. કન્ટેનર બિલ્ડમાં, નિષ્ફળ જતા આદેશ પહેલાં એ પગલાં ઉમેરો જેથી સ્તર ડિપેન્ડન્સી ઇન્સ્ટોલની ઉપર કેશ થાય.

સ્થાનિક devcontainer માટે, PEM માઉન્ટ કરો અને શરૂઆતમાં એ જ અપડેટ આદેશ ચલાવો, બદલે કે તેને એવી વ્યક્તિગત ઇમેજમાં શેકી નાખો જે બીજું કોઈ પુનઃઉત્પાદન કરી શકે નહીં. પોતાનું બંડલ લાવતાં સાધનોને પોતાનું દસ્તાવેજીકૃત ઓવરરાઇડ જોઈએ: pip પાસે પ્રમાણપત્ર સેટિંગ છે, npm પાસે cafile સેટિંગ છે, અને બાકીનાં મોટાં ભાગ પ્રમાણભૂત પર્યાવરણ ચલ સ્વીકારે છે.

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

જ્યારે હેન્ડશેક પ્રમાણપત્ર પહેલાં મૃત્યુ પામે

જો કંઈ રજૂ ન થાય, તો ટ્રસ્ટ સ્ટોરમાં કોઈ પણ ફેરફાર મદદ કરશે નહીં. એ જ વિનંતીને ટનલ ચાલુ અને બંધ સાથે સરખાવો, પછી openssl s_client -connect host:443 -servername host -showcerts વડે સીધી સાંકળ તપાસો. જે જોડાણ VPN ની બહાર પૂર્ણ થાય અને અંદર રીસેટ થાય તે મધ્યવર્તી ઉપકરણનો નીતિ નિર્ણય છે, અને ઉપાય એ હોસ્ટ માટે અપવાદ છે, બીજું પ્રમાણપત્ર નહીં. પેકેજ રજિસ્ટ્રી કે API એન્ડપોઇન્ટને બદલ્યા વિના પસાર થવા દેવા વિનંતી કરો.

ટનલને વિભાજિત કરીને સાધન VPN ટાળે તેમ કરવાથી એ ટ્રાફિકનું નિરીક્ષણ ટળે છે, જે નીતિનો ભંગ કરી શકે છે અને સાધનને ભરોસાપાત્ર બનાવતું નથી.

દરેક સાધન માટે પરિણામ લખો

બાઈનરી, તે વાંચતી ટ્રસ્ટ ફાઇલ, જે પર્યાવરણ ચલ ચાલમાં છે અને મંજૂર અપવાદની યાદી ધરાવતી ટૂંકી નોંધ આગલી વ્યક્તિનું આખું નિદાન બચાવે છે. નોંધ લેપટોપ પ્રમાણે નહીં, સાધન પ્રમાણે રાખો, કારણ કે લેપટોપ ભાગ્યે જ બદલાયેલી વસ્તુ હોય છે.

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