SSTP અને SSL 3.0: લેબલ સામે વાટાઘાટ કરેલું સંસ્કરણ

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

એક જ પ્રશ્નના બે જવાબ

લેબલની દલીલ કહેવી સહેલી છે: SSTP ને સુરક્ષિત સોકેટ ટનલિંગ પ્રોટોકોલ કહેવાય છે, ઐતિહાસિક નામ SSL કહે છે, તેથી જોડાણ SSL 3.0 હોવું જોઈએ. તે ટકે છે કારણ કે નામ ખરેખર તે જ પરંપરામાંથી આવ્યું છે, અને કારણ કે પુનરાવર્તન કરનારા મોટા ભાગના લોકોએ કદી હેન્ડશેક જોયો નથી. તે એટલા માટે પણ ટકે છે કે તારણ સાવચેત લાગે છે, જાણે સૌથી ખરાબ ધારી લેવું એ જ સુરક્ષિત પસંદગી હોય. સૌથી ખરાબ ધારવું અને ખરેખરું સંસ્કરણ માપવું બે જુદી પ્રવૃત્તિઓ છે, અને તેમાંથી ફક્ત એક જ કંઈક બદલે છે.

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

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

સેવા ખરેખર જે સંસ્કરણ પસંદ કરે છે તે વાંચો

ઘટકોના નામથી શરૂ કરો: ક્લાયન્ટ અમલીકરણ, સર્વર અમલીકરણ, TLS અંતિમબિંદુ અને વચ્ચેની એ બધી વસ્તુ કે જે TLS સમાપ્ત કરીને ફરી સ્થાપિત કરે છે. જે લોડ બેલેન્સર TLS સમાપ્ત કરે છે અને બેકએન્ડ સાથે સાદું HTTP બોલે છે, તે બદલે છે કે તમારે કયા ઉપકરણની નીતિ વાંચવી છે.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

રેકોર્ડ ક્ષેત્રને વાટાઘાટથી અલગ કરો

એક ક્ષેત્રમાં જૂનો દેખાતો સંસ્કરણ ક્રમાંક SSL 3.0 સત્ર જેવી એ જ હકીકત નથી. RFC 7568 રેકોર્ડ સ્તરના સંસ્કરણ અને વાટાઘાટ કરેલા પ્રોટોકોલને અલગ બાબતો ગણે છે, અને આ જ ભેદમાંથી આત્મવિશ્વાસપૂર્ણ ખોટા જવાબો નીકળે છે. વાટાઘાટ કરેલો પ્રોટોકોલ વાંચો, પછી સાઇફર, અને ત્યાર પછી જ સત્ર વિશે તારણ કાઢો.

એ જ દસ્તાવેજ પ્રોટોકોલ વિશે સ્પષ્ટ છે: SSL 3.0 વાપરવું ન જોઈએ, અને તેના પર વાટાઘાટ કે પાછા જવું મનાઈ છે. કારણ તે તૂટેલી CBC રચના છે જેનો POODLE હુમલાએ ફાયદો ઉઠાવ્યો, અને તે પ્રોટોકોલનો ગુણધર્મ છે, કોઈ એક એપ્લિકેશનની ગોઠવણ નહીં.

તેથી જ “આ ભાર સંભવતઃ શોષણ કરવું અઘરું છે” એ SSL 3.0 સક્ષમ રાખવાની દલીલ નથી. જરૂરિયાત પ્રોટોકોલ દૂર કરવાની છે, કોઈ એક પ્રદર્શન પર ચર્ચા જીતવાની નહીં.

SSL 3.0 ને એવી નીતિ સાથે પાછું ખેંચો જેનો તમે બચાવ કરી શકો

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

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

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

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

ફેરફારને નવા જોડાણો સાથે સ્વીકારો

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

યાદ રાખો હેન્ડશેક શું આવરી લેતું નથી. SSTP TLS સ્તર પછી PPP પ્રમાણીકરણ લઈ જાય છે, તેથી આધુનિક પ્રોટોકોલ સંસ્કરણ એ વિશે કંઈ કહેતું નથી કે કયા વપરાશકર્તાને અધિકૃત કરાયો અથવા સત્ર કયા સ્રોતો સુધી પહોંચી શકે. આ અલગ નિયંત્રણો છે અલગ પુરાવાઓ સાથે.

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