OpenVPN માં dh none સાથે RSA સર્ટિફિકેટ કામ કરી શકે છે?

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

મૂંઝવણ સામાન્ય રીતે માઇગ્રેશન માર્ગદર્શિકા સાથે આવે છે. તે DH પેરામીટર ફાઇલને dh none થી બદલવાનું કહે છે, વાચક જુએ છે કે સર્ટિફિકેટ લંબવૃત્તીય વળાંકનું સર્ટિફિકેટ નથી, અને બંને તથ્યોને વિરોધાભાસ તરીકે લેવામાં આવે છે.

બે સેટિંગ કેમ સંબંધિત દેખાય છે

OpenVPN નું જૂનું રૂપરેખાંકન DH પેરામીટર ફાઇલ માગતું હતું કારણ કે મર્યાદિત ક્ષેત્રનું Diffie-Hellman એવા ડોમેન પેરામીટરની જરૂર રાખે છે જેના પર બંને પક્ષો સહમત હોય. dh નિર્દેશ એ ફાઇલ તરફ ઇશારો કરતો હતો. જ્યારે કોઈ ડિપ્લોયમેન્ટ ECDH તરફ જાય છે, ત્યારે પેરામીટર તેના બદલે નામવાળા વળાંકમાંથી આવે છે, અને ફાઇલની હવે જરૂર રહેતી નથી, જે dh none વ્યક્ત કરે છે.

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

નામકરણ ઓવરલેપને વધુ ખરાબ કરે છે. લંબવૃત્તીય વળાંક ECDHE અને ECDSA બંને સ્યૂટ નામોમાં દેખાય છે, તેથી એવું માની લેવું સહેલું છે કે વળાંકનો ઉલ્લેખ કરતું કોઈપણ જોડાણ વળાંક સર્ટિફિકેટ ધરાવવું જ જોઈએ. એવું નથી.

TLS 1.2 સ્યૂટ નામ યોગ્ય રીતે વાંચવું

ECDHE-RSA-AES256-GCM-SHA384 લો. પહેલું ટોકન કી-એક્સચેન્જ કુટુંબ છે: ક્ષણિક લંબવૃત્તીય વળાંક Diffie-Hellman. બીજું પ્રમાણીકરણ કુટુંબ છે: RSA. બાકીનું રેકોર્ડ સંરક્ષણ અને હેન્ડશેકમાં વપરાતા હેશનું વર્ણન કરે છે.

ECDHE-ECDSA સ્યૂટ એ જ કી-એક્સચેન્જ કુટુંબને અલગ પ્રમાણીકરણ પદ્ધતિ સાથે વાપરે છે, તેથી તેને લંબવૃત્તીય વળાંકનું સર્ટિફિકેટ જોઈએ. DHE-RSA સ્યૂટ RSA પ્રમાણીકરણ સાથે મર્યાદિત ક્ષેત્રનું ક્ષણિક Diffie-Hellman વાપરે છે, અને તેને ખરેખર DH પેરામીટર જોઈએ.

સ્યૂટ નામ ડાબેથી જમણે વાંચો અને દરેક ભાગને તેના કામ સોંપો. ટોકન અલગ થયા પછી પ્રશ્ન «મારું સર્ટિફિકેટ dh none સાથે મેળ ખાય છે?» થી «મારો સર્વર એવી સ્યૂટને મંજૂરી આપે છે જેની કી-એક્સચેન્જને DH ફાઇલની જરૂર નથી?» માં બદલાય છે.

dh none ખરેખર શું નિષ્ક્રિય કરે છે

dh none સર્વરને કહે છે કે મર્યાદિત ક્ષેત્રની DH પેરામીટર ફાઇલ લોડ ન કરે. તે પ્રમાણીકરણ, સર્ટિફિકેટ માન્યતા કે TLS પોતે નિષ્ક્રિય કરતું નથી. પરંતુ તે માગે છે કે સહમત થયેલી કી-એક્સચેન્જ એવી હોય જેને એ પેરામીટરની જરૂર ન પડે, જે વ્યવહારમાં ECDHE સ્યૂટ અથવા TLS 1.3 હેન્ડશેક એમ અર્થ ધરે છે.

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

લંબવૃત્તીય વળાંકની બાજુએ, વળાંક સર્વરની TLS રૂપરેખાંકન પસંદ કરે છે, અને OpenVPN જૂની શાખાઓમાં તેને પસંદ કરવાનો વિકલ્પ આપે છે. TLS 1.3 જૂથ વાટાઘાટને પ્રોટોકોલની અંદર સંભાળે છે અને DH ફાઇલને બિલકુલ જોતું નથી.

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

સંપાદન પહેલાં વાટાઘાટની પુષ્ટિ

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

જો તે TLS 1.2 સાથે ECDHE-RSA સ્યૂટ અને RSA સર્ટિફિકેટ દર્શાવે, તો સંયોજન બરાબર એ છે જે dh none અપેક્ષા રાખે છે, અને સુધારવા જેવું કંઈ નથી. જો તે DHE સ્યૂટ અથવા સામાન્ય સાઇફર વિના હેન્ડશેક નિષ્ફળતા દર્શાવે, તો ઉપાય સાઇફર નીતિમાં અથવા ક્લાયન્ટની ક્ષમતામાં છે, સર્ટિફિકેટમાં નહીં.

તમે જે સૌથી જૂનું ક્લાયન્ટ ટેકો આપવા માંગો છો તેનું પરીક્ષણ કરો, કારણ કે વર્તમાન ક્લાયન્ટ TLS 1.3 પર સહમત થઈ શકે છે જ્યારે જૂનું TLS 1.2 સ્યૂટ સુધી મર્યાદિત હોય. જો સૌથી જૂના ક્લાયન્ટમાં કોઈ ઓવરલેપ ન હોય, તો કાં તો મંજૂર સ્યૂટ વિસ્તારો અથવા એ એન્ડપોઇન્ટ અપગ્રેડ કરો.

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

ચેકલિસ્ટ: સર્ટિફિકેટ RSA છે, ECDHE સ્યૂટ મંજૂર છે, લોગ એ સ્યૂટ દર્શાવે છે, અને સૌથી જૂનું સમર્થિત ક્લાયન્ટ પણ તેના પર સહમત થાય છે? જો ચારેય હા હોય, તો dh none પોતાનું કામ કરી રહ્યું છે.