OpenVPN નિયંત્રણ પેકેટનું ટ્રેસિંગ: TLS પહેલાં tls-auth

tls-auth નિષ્ફળતા સામાન્ય રીતે હેન્ડશેક સમસ્યા તરીકે જણાવાય છે, જ્યારે તે કદી એવી નહોતી. HMAC કોઈપણ TLS પ્રક્રિયા શરૂ થાય તે પહેલાં નિયંત્રણ પેકેટ પર ચકાસાય છે, તેથી વિસંગત કી અથવા દિશા એવી નિષ્ફળતા ઉત્પન્ન કરે છે જે પ્રમાણપત્ર સમસ્યા જેવી લાગે છે અને બે સ્તર પહેલાં નક્કી થાય છે. પરબિડીયાને અલગ ઑબ્જેક્ટ તરીકે ગણવાથી નિદાન ટૂંકું થાય છે: ક્ષેત્રો વાંચો, ચકાસણી વહેલી થાય છે તેની ખાતરી કરો, પછી બંને છેડે સંમત થવાની ત્રણ વસ્તુઓની તુલના કરો.

પરબિડીયું જે ક્રમમાં બને છે તે ક્રમમાં વાંચો

નિયંત્રણ પેકેટ સત્ર ઓળખકર્તા, વૈકલ્પિક tls-auth HMAC, પુનરાવર્તન અને સ્વીકૃતિ માહિતી, અને વિશ્વસનીય સંદેશ ઓળખકર્તા ધરાવે છે, અને તે પછી સંદેશ પ્રકારનો પેલોડ આવે છે. જ્યારે સંદેશ હેન્ડશેક સંદેશ હોય, ત્યારે પેલોડ TLS સાઇફરટેક્સ્ટ હોય છે. આખો સંબંધ આ જ છે: TLS સામગ્રી એવા સંદેશની અંદર મુસાફરી કરે છે જેને પરબિડીયું પહેલેથી સુરક્ષિત કરે છે. જુઓ OpenVPN નેટવર્ક પ્રોટોકૉલ સંદર્ભ જે નિયંત્રણ ચેનલના ક્ષેત્રોને તે જ ક્રમમાં સૂચિબદ્ધ કરે છે.

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

આ જૂથીકરણને વૈચારિક રાખો. તે બાઇટ-ક્રમનું આકૃતિ નથી, અને ટૅગ ગણવા માટે પૂરતું નથી, કારણ કે HMAC માં પ્રવેશતા ક્ષેત્રો અમલીકરણ, આવૃત્તિ અને મોડ પર આધાર રાખે છે.

બતાવો કે ચકાસણી હેન્ડશેક પહેલાં થાય છે

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

ડીમનની વર્બોસિટી વધારો અને tun ઉપકરણને બદલે નિયંત્રણ ચેનલ જુઓ:

openvpn --config /etc/openvpn/server.conf --verb 6

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

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

બંને છેડે કી, દિશા અને digest મેળવો

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

સહિયારું રહસ્ય એડિટરને બદલે સાધનથી બનાવો, અને પરવાનગીઓ ચુસ્ત રાખો:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

જૂની આવૃત્તિઓ કી બનાવવા માટે થોડો અલગ વિકલ્પ ક્રમ સ્વીકારતી હતી, અને તે આવૃત્તિઓ માટે લખાયેલી પ્રોફાઇલ હજી ચલણમાં છે. બનાવેલી ફાઇલ બંને કિસ્સામાં એક જ પ્રકારનો ઑબ્જેક્ટ છે, તેથી ચકાસણી એ છે કે બંને છેડે સમાન બાઇટ છે કે નહીં, નહીં કે કઈ જોડણીએ તે બનાવ્યા.

tls-auth ને tls-crypt સાથે ભેગું ન કરો. બંને નિયંત્રણ ચેનલનું રક્ષણ કરે છે, પરંતુ tls-crypt તેને એન્ક્રિપ્ટ પણ કરે છે અને નિરીક્ષકોથી હેન્ડશેક છુપાવે છે, અને તે દિશા વિભાજનને પોતાની કી સંભાળથી બદલે છે. એક વાપરતી પ્રોફાઇલ બીજા માટે ગોઠવાયેલા સાથી સાથે કામ કરશે નહીં, અને કોઈપણ digest ટ્યુનિંગ તે અંતર બંધ કરતું નથી.

ટૅગ ફક્ત વાસ્તવિક ફોર્મેટમાંથી ફરી બનાવો

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

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

આ કસરતને ઉત્પાદન પ્રોફાઇલથી દૂર રાખો. ટૅગ ફરી બનાવવામાં એવું કંઈ નથી જે તમને કહે કે કોઈ તૈનાતીએ સુરક્ષા સક્ષમ કરવી જોઈએ કે નહીં.

સુરક્ષા દૂર કર્યા વિના વિસંગતતા પાછી ખેંચો

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

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

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