Linux પર AnyConnect ની અમાન્ય TLS આવૃત્તિ: પહેલા સુધારણાનો વ્યાપ નક્કી કરો

સમગ્ર હોસ્ટ માટે LEGACY નીતિ, પ્રક્રિયા દીઠ OpenSSL રૂપરેખાંકન અને એક વપરાશનું VM સરખાવ્યાં, સાથે ગેટવેમાં એ ફેરફાર જે ભૂલને કાયમ માટે દૂર કરે છે.

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

નીતિને સ્પર્શ કરતા પહેલાં સંદેશ વાંચો

સંવાદમાંથી ચોક્કસ શબ્દમાળા રાખો. આવૃત્તિની ફરિયાદ પ્રોટોકોલ સ્તર તરફ, પ્રમાણપત્રની ફરિયાદ વિશ્વાસ કે નામકરણ તરફ, અને નિષ્ફળ લોગિન ઓળખપત્ર તરફ ઇશારો કરે છે. TLS 1.0, 1024-બિટ DHE જૂથ, AES-256-CBC અને SHA-1 સહી સાથેનું ગેટવે સંપૂર્ણ માન્ય પ્રમાણપત્ર ધરાવી શકે છે અને તોપણ આધુનિક નીતિ દ્વારા તમારા ઓળખપત્ર મોકલાય તે પહેલાં નકારી શકાય છે.

સિસ્ટમના OpenSSL સાથે એન્ડપોઇન્ટ તપાસો, વાસ્તવિક હોસ્ટનામ અને ક્લાઇન્ટ વાપરે છે તે પોર્ટ સાથે.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com નિષ્ફળ થાય અને -tls1 -cipher DEFAULT@SECLEVEL=0 સફળ થાય તેનો અર્થ છે સીમા આવૃત્તિ અને કી-કદ બંને છે. જો પહેલો આદેશ પ્રોટોકોલ ચેતવણીને બદલે નાની DH કી જણાવે, તો આવૃત્તિ ઠીક છે અને ફક્ત જૂથ પર ધ્યાન આપવાની જરૂર છે. તપાસમાં ક્યારેય ખાનગી કી કે પાસવર્ડ ન મૂકો.

વિકલ્પ 1: ક્રિપ્ટો નીતિથી આખું હોસ્ટ ઢીલું કરો

Fedora અને RHEL 8 અને 9 પર, update-crypto-policies --set LEGACY OpenSSL ની સિસ્ટમ નીતિ નીચી કરે છે, અને update-crypto-policies --show શું સક્રિય છે તેની પુષ્ટિ કરે છે. તે સામાન્ય રીતે ટનલ પુનઃસ્થાપિત કરે છે, પરંતુ પ્રક્રિયા શરૂ થાય ત્યારે નીતિ વંચાય છે, તેથી ફરી પરીક્ષણ કરતા પહેલાં ક્લાઇન્ટ અને તેણે બનાવેલ કોઈપણ સહાયક પ્રક્રિયા ફરી શરૂ કરો. તે મશીન પરના દરેક TLS ક્લાઇન્ટ માટે જૂના પ્રોટોકોલ અને નબળા જૂથોને પણ પરવાનગી આપે છે, બાજુની વિન્ડોના બ્રાઉઝરથી લઈને કર્નલ અપડેટ કરતા પેકેજ મેનેજર સુધી.

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

Debian અને Ubuntu પાસે આ માટે એક જ સ્વિચ નથી. સમકક્ષ છે /etc/ssl/openssl.cnf માં ફેરફાર જે સિસ્ટમ ડિફોલ્ટ વિભાગમાં નીચી MinProtocol અને CipherString = DEFAULT@SECLEVEL=0 સેટ કરે છે. એ જ વ્યાપ, અલગ ફાઇલ, રિલીઝ અપગ્રેડ દરમિયાન થોડું વધુ સહેલાઈથી નજરમાંથી ખસી જાય.

વિકલ્પ 2: એક ક્લાઇન્ટ માટે એક કન્ફિગ ફાઇલ

પ્રક્રિયા દીઠ OpenSSL રૂપરેખાંકન ફેરફારને એક પ્રક્રિયા-વૃક્ષમાં રાખે છે, પરંતુ ફક્ત ત્યારે જ જ્યારે ફાઇલ એ રીતે જોડાયેલી હોય જે રીતે લાઇબ્રેરી અપેક્ષા રાખે છે. ssl_conf વિભાગનું નામ આપવું પૂરતું નથી: OpenSSL ટોચના સ્તરની openssl_conf કી વાંચે છે, તેને ઇનિટ વિભાગ સુધી અનુસરે છે અને પછી જ SSL ડિફોલ્ટ સુધી પહોંચે છે.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF ને તે ફાઇલ તરફ નિર્દેશ કરો અને VPN ક્લાઇન્ટને એવા રેપર દ્વારા શરૂ કરો જે તેને એક્સપોર્ટ કરે. હોસ્ટ પરનું બાકીનું બધું ડિફોલ્ટ નીતિ રાખે છે, અને અનુપાલનનો પ્રશ્ન આવે ત્યારે એ જ ગુણ મહત્વનો છે. ગેટવેને દોષ દેતા પહેલાં ખાતરી કરો કે ફાઇલ ખરેખર અમલમાં છે: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 એ TLS 1.0 સાઇફરની યાદી આપવી જોઈએ, અને ખાલી પરિણામનો અર્થ છે કે સાંકળ તૂટી ગઈ છે અને ક્લાઇન્ટે ચૂપચાપ સિસ્ટમ ડિફોલ્ટ રાખ્યા છે.

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

મર્યાદા આવરણ છે. GnuTLS કે NSS સાથે લિંક થયેલું કંઈપણ OPENSSL_CONF ને અવગણે છે, અને ક્લાઇન્ટ જે સહાયક પ્રક્રિયા પર્યાવરણ વારસામાં ન લેતાં શરૂ કરે તે પણ. રેપર બનાવતા પહેલાં ldd થી તપાસો કે બાઇનરી ખરેખર કઈ TLS લાઇબ્રેરી સાથે લિંક છે, કારણ કે જવાબ જ નક્કી કરે છે કે આ વિકલ્પ બિલકુલ છે કે નહીં.

વિકલ્પ 3: એક વપરાશનું VM કે કન્ટેનર

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

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

સરખામણી તમને શું છોડે છે

ત્રણ પ્રશ્નો પર પસંદ કરો: જૂનો પ્રોટોકોલ કોને જોઈએ, કેટલા સમય માટે, અને જો અપવાદ તેના કારણ કરતાં વધુ ટકે તો કોણ ધ્યાન આપશે. એક એપ, એક વ્યક્તિ, થોડા દિવસ — પ્રક્રિયા દીઠ રૂપરેખાંકન તરફ ઇશારો કરે છે. એક ઉપકરણ પાછળનો આખો કાફલો — ગેટવે તરફ જ ઇશારો કરે છે. કાયમી LEGACY હોસ્ટ નીતિની જરૂર હોય તેવી કોઈપણ વસ્તુ ટેકનિકલ વેશમાં ખરીદીનો નિર્ણય છે.

ટકાઉ ઉકેલ ઉપકરણ પર જ છે: TLS 1.2 કે તેથી નવું, ઓછામાં ઓછું 2048 બિટનું જૂથ, AEAD સાઇફર અને આધુનિક સહીવાળું પ્રમાણપત્ર. ઉપકરણના માલિકને એ ફેરફાર માટે કહો, પછી ક્લાઇન્ટ લોગમાં વાટાઘાટ થયેલી આવૃત્તિ અને સાઇફરની પુષ્ટિ કરો. અપવાદને હોસ્ટ, ગેટવે, વાટાઘાટ થયેલ પ્રોટોકોલ, મંજૂરી આપનાર અને સમાપ્તિ તારીખ સાથે લખો, કારણ કે એ નોંધ જ કામચલાઉ ઉકેલને ડિફોલ્ટ બનતા રોકે છે.

સંબંધિત લેખો