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

કેપ્ચરમાં સરખા દેખાતા બે ઑબ્જેક્ટ

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

Object in playWhat it establishes
Key-exchange shareCryptographic state for this connection
Server certificateWhich server the client reached
Client certificateClient authentication, when requested
Application sessionAccount identity inside the application

ચાર પંક્તિઓ સ્વતંત્ર છે. કનેક્શનમાં પ્રથમ અને બીજી પંક્તિ હોઈ શકે, ત્રીજી છોડી શકે, અને છતાં કૂકી હેડરમાં ચોથી વહી શકે.

નક્કી કરો કે પકડાયેલ હેન્ડશેક શું સાબિત કરી શકે

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

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

સાઇફરનું નામ નહીં, સંદેશાઓ વાંચો

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

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

પછી ક્લાયન્ટ સર્ટિફિકેટ ગોઠવીને પુનરાવર્તન કરો અને સરખાવો. બીજા રનમાં સર્ટિફિકેટ મોકલાય અને સ્વીકારાય તે દેખાવું જોઈએ; પ્રથમમાં કંઈ દેખાવું જોઈએ નહીં, અને એ જ ચર્ચાનો નક્કર તફાવત છે.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

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

જ્યાં ફરી શરૂ કરવું જવાબ બદલે છે

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

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

એક ચુકાદો નહીં, ચાર ગુણધર્મ લખો

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

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

સંબંધિત લેખો