એક જૂનો પીઅર TLS 1.0 ફરજિયાત કરે છે: અપવાદની હદ નક્કી કરો, હોસ્ટની નહીં
TLS 1.0 પર અટવાયેલું એક ઉપકરણ, અથવા પ્રદાતાનું જૂનું પ્રમાણપત્ર, નબળી ન્યૂનતમ મર્યાદા ફરજિયાત કરી શકે છે. અપવાદની હદ નક્કી કરો, પછી માપો કે ખરેખર શું વાટાઘાટ થયું.
એક જૂનું ઉપકરણ આવે છે, કનેક્ટ થઈ શકતું નથી, અને સૌથી ઝડપી દેખાતો ઉપાય એ છે કે આખા હોસ્ટને નબળો કરવો જ્યાં સુધી કનેક્શન સફળ ન થાય. એ બદલો ક્ષણે અદૃશ્ય અને વ્યવહારમાં કાયમી છે, કારણ કે છેવટે કામ કરતી ન્યૂનતમ મર્યાદા કોઈ દૂર કરતું નથી. બે ખૂબ જ અલગ ખામીઓ આ દબાણ ઊભું કરે છે, અને તેમાંથી માત્ર એક જ સાઈફર સાથે સંબંધ ધરાવે છે. પહેલાં ખામીને ગોઠવો, પછી અપવાદને એવી જગ્યાએ મૂકો જ્યાંથી તે ફેલાઈ ન શકે.
નિર્દેશ સંપાદિત કરતાં પહેલાં ભંગને બે ભાગમાં વહેંચો
સર્વર લોગની એ પંક્તિ કે કોઈ વહેંચાયેલું સાઈફર નથી, અથવા અસમર્થિત પ્રોટોકોલ આવૃત્તિ છે, નિયંત્રણ ચેનલમાંથી આવે છે: બંને છેડા વાટાઘાટને જ કેવી રીતે સુરક્ષિત કરવી તે અંગે સહમત થઈ શક્યા નહીં. જ્યારે ક્લાયંટની પંક્તિ કે સર્વર પ્રમાણપત્ર ચકાસવાની કોઈ પદ્ધતિ સક્ષમ નથી, તે સંપૂર્ણપણે બીજી જગ્યાએથી આવે છે, કારણ કે એ ક્લાયંટ કોણે જવાબ આપ્યો તે જ ચકાસતું નથી. ડેટા સાઈફર બદલવાથી બીજા કિસ્સામાં કંઈ થતું નથી, અને ભૂમિકા ચકાસણી ઉમેરવાથી પહેલા કિસ્સામાં કંઈ થતું નથી.
દરેક બાજુથી ડિસ્કનેક્શન પહેલાંની છેલ્લી પંક્તિને બદલે સૌથી પહેલી નિષ્ફળ પંક્તિ લો, કારણ કે છેલ્લી સામાન્ય રીતે પરિણામ હોય છે. પછી નક્કી કરો કે ક્લાયંટે ખરેખર કઈ ફાઇલ ખોલી: આયાત કરેલી પ્રોફાઇલ ઘણી વાર જુદા જુદા દર્શાવેલા નામો હેઠળ બે વાર હોય છે, અને જે નકલ કોઈ વાંચતું નથી તેને સંપાદિત કરવાથી વિશ્વાસપાત્ર બદલાવ-રહિત સ્થિતિ ઊભી થાય છે. ચાલતી પ્રક્રિયા જે સેટિંગ્સ સાથે શરૂ થઈ તે જ રાખે છે, તેથી સાચવેલી ફાઇલ એ લોડ થયેલી ફાઇલ નથી. નીચેની કમાન્ડ એ જ પ્રયાસ પર સર્વરના દૃષ્ટિકોણની બાજુમાં ક્લાયંટની વાટાઘાટ દર્શાવે છે.
openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'
નબળી ન્યૂનતમ મર્યાદા માટે સાચી જગ્યા બીજું શ્રોતા છે
જ્યારે ઉપકરણ 2.5 પહેલાંની ડેટા ચેનલ સાથે TLS 1.0 પર અટકે છે, ત્યારે સર્વરે નિયંત્રણ ચેનલ માટે નીચી ન્યૂનતમ મર્યાદા અને જૂનું ક્લાયંટ ઓળખે એવું ડેટા સાઈફર આપવું પડે છે. ફોલબેક નિર્દેશ બરાબર એ પીઅર માટે જ છે, જ્યારે સાઈફર યાદી આધુનિક ક્લાયંટને આધુનિક સેટ પર રાખે છે. બંને નિર્દેશ શ્રોતાના છે, વપરાશકર્તા કે કનેક્શનના નહીં, અને પછી કોઈ પણ પ્રતિ-ક્લાયંટ વિકલ્પ તેમને સાંકડા કરતું નથી. તેથી મુખ્ય પોર્ટ પર એક જૂનું ઉપકરણ તેને વહેંચતા દરેક પીઅર વિશેનો નિર્ણય છે.
જ્યાં પ્લેટફોર્મ પરવાનગી આપે ત્યાં જૂના શ્રોતાને અલગ પોર્ટ પર તેની પોતાની ઇન્સ્ટન્સ તરીકે ચલાવો, એ પોર્ટને ફક્ત ઉપકરણના સરનામેથી મંજૂરી આપો, અને મુખ્ય સેવાને અડ્યા વિના રહેવા દો. બીજું શ્રોતા કેમ છે તે તેની રૂપરેખા ધરાવતી ફાઇલમાં લખો, નહીં તો ભવિષ્યની સફાઈ તેને બચેલો કચરો તરીકે વાંચશે. વિભાજન ત્યારે જ કીમતી છે જ્યારે નબળી ન્યૂનતમ મર્યાદા ઉપકરણ જ્યાં પૂરું થાય ત્યાં જ પૂરી થાય.
tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC
જૂનું પ્રદાતા પ્રમાણપત્ર ખરેખર શું તોડે છે
ચકાસણીની ભૂલ એ ખૂટતું ભૂમિકા-બંધન છે: તેના વિના ક્લાયંટ વિશ્વસનીય CA સાથે શૃંખલાબદ્ધ થતું કોઈ પણ પ્રમાણપત્ર સ્વીકારશે, પછી તે સર્વર માટે બહાર પાડવામાં આવ્યું હોય કે નહીં. પહેલાં પ્રમાણપત્રને સર્વરની ભૂમિકા સાથે બાંધો, અને બંધનને ટ્યુનિંગ નોબને બદલે જરૂરિયાત ગણો. એ પગલા પછી પણ જે પ્રોફાઇલ નિષ્ફળ જાય તેને જ ખરેખર પ્રમાણપત્રની સમસ્યા હોય છે.
જે જૂનું પ્રદાતા પ્રમાણપત્રનું કી-કદ કે સહી અલ્ગોરિધમ હવે OpenSSLની મૂળભૂત નીતિ સંતોષતું નથી, તે નિયંત્રણ ચેનલ પર મર્યાદિત સુરક્ષા-સ્તર ફેરફારનો કિસ્સો છે. ત્યાં સ્તર નીચું કરવાથી ચકાસણી બંધ થતી નથી, અને તેને કદી ખાલી CA, નિષ્ક્રિય ચકાસણી સેટિંગ કે ન-ચકાસાયેલા હોસ્ટનામ સાથે જોડવું ન જોઈએ. પંક્તિને ફક્ત એ જ પ્રોફાઇલમાં રાખો જેને તેની જરૂર છે; ઢીલી OpenSSL રૂપરેખા આખા સિસ્ટમમાં નિકાસ કરવાથી મશીનના દરેક પ્રોગ્રામને એ જ ઢીલ મળશે.
remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"
બેનર નહીં, વાટાઘાટ થયેલા મૂલ્યો વાંચો
વર્બોસિટી 4 પર બંને છેડા નિયંત્રણ ચેનલની જે TLS આવૃત્તિ અને સાઈફર પર સહમત થયા તે છાપે છે, અને સત્રનું ડેટા સાઈફર પણ. પ્રારંભિક બેનરને બદલે એ પંક્તિઓ વાંચો, કારણ કે બેનર સફળતા જણાવે છે, તેની શરતો નહીં. પછી આધુનિક ક્લાયંટને ફરી મુખ્ય શ્રોતા સાથે જોડો અને ખાતરી કરો કે તે હજી પણ આધુનિક સેટ પર ઉતરે છે, કારણ કે વહેંચાયેલી રૂપરેખામાં સરી પડેલો અપવાદ અહીં પહેલાં દેખાય છે. તમે કૉપી કરેલા મૂલ્યો આગલી સમીક્ષા માટે આધારરેખા બનશે.
જૂના ઉપકરણને એકલું ચકાસો: તેને કનેક્ટ થવું જોઈએ, અને લોગમાં નબળા પરિમાણો દર્શાવતું એ જ એકમાત્ર સત્ર હોવું જોઈએ. જો બીજું પીઅર પણ જૂના સેટ પર વાટાઘાટ કરે, તો અપવાદ ઇચ્છિત કરતાં વધુ વ્યાપક છે અને શ્રોતાનું વિભાજન ખરેખર થયું નથી. ફક્ત તારણ નહીં, બંને અવલોકનો નોંધો.
દરેક અપવાદને માલિક અને તારીખની જરૂર છે
દૂર કરવાની શરત વગરનો અપવાદ શાંતિથી મૂળભૂત બની જાય છે, તેથી ઉપકરણ, માલિક, કારણ અને જે તારીખે તે જાય છે તેને તે જે રૂપરેખાને ન્યાયી ઠેરવે છે તેની બાજુમાં મૂકો. એ પંક્તિ વિના નબળી ન્યૂનતમ મર્યાદા તેને જરૂરી હતું તે હાર્ડવેર કરતાં વધુ જીવે છે.
ક્લાયંટ બદલવો, અથવા પ્રદાતા પાસે વર્તમાન પ્રોફાઇલ માંગવી, એ લક્ષ્ય હોવું જોઈએ; અપવાદ એ વિલંબ છે, રચના નહીં. જ્યારે ઉપકરણ નિવૃત્ત થાય, ત્યારે શ્રોતા અને પ્રોફાઇલ એક જ ફેરફારમાં દૂર કરો જેથી કોઈ અડધું ચાલતું ન રહે. આમાંથી કંઈ પણ જૂના પરિમાણોને સુરક્ષિત બનાવતું નથી, તે ફક્ત એક ઉપકરણની મર્યાદા બધાની આધારરેખા બનવાથી રોકે છે.