VPN દ્વારા HTTPS ને પ્રથમ વિનંતી કેવી રીતે બનાવવી

એક બ્રાઉઝર જે પહેલા http:// ટાઈપ કરે છે અને રીડાયરેક્ટ પછી https:// પર ઉતરે છે તે પહેલાથી જ સ્પષ્ટ રીતે એક વિનંતી મોકલે છે અને VPN તેને બદલતું નથી. ટનલ ક્લાયન્ટથી એક્ઝિટ નોડ સુધીના પગને સુરક્ષિત કરે છે; તે પરિવહન સ્તરની ઉપર કંઈપણ એન્ક્રિપ્ટ કરતું નથી, તેથી બહાર નીકળો અને મૂળ વચ્ચેનો નિરીક્ષક હજી પણ પ્લેનટેક્સ્ટ હોપને જુએ છે. HTTPS ને પ્રથમ વિનંતિ બનાવવી એ ત્રણ ભાગો સાથે ક્લાયન્ટ-સાઇડ ફેરફાર છે: વાસ્તવિક HTTPS સરનામું, બ્રાઉઝરનો અપગ્રેડ મોડ અને સાઇટની પોતાની નીતિ. નીચે આપેલા પગલાઓ હું ઉપયોગ કરું છું તે ઓર્ડર છે, દરેક ચેક સાથે જે તમને કહે છે કે તે લીધો કે કેમ.

પગલું 1: ખાતરી કરો કે પ્રથમ વિનંતી ખરેખર શું છે

કંઈપણ બદલતા પહેલા, બ્રાઉઝર શું મોકલે છે તે જુઓ. કોલ્ડ કેશમાંથી ફરીથી લોડ થયેલ પૃષ્ઠ સાથે નેટવર્ક પેનલ ખોલો અને પ્રથમ પંક્તિ વાંચો: જો સ્કીમ http છે અને સ્થિતિ 301 અથવા 308 છે, તો તે પંક્તિ પછીની દરેક વસ્તુ બીજી વિનંતી છે. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com બ્રાઉઝરની બહાર સમાન ક્રમનું પુનઃઉત્પાદન કરે છે અને તમે જે URL પર સમાપ્ત કર્યું તે પ્રિન્ટ કરે છે.

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

પગલું 2: બ્રાઉઝરના HTTPS-માત્ર મોડને ચાલુ કરો

અપગ્રેડ મોડ એ બીજો ભાગ છે, અને મોડ્સ વિનિમયક્ષમ નથી. તમે તેને સક્ષમ કરો તે પહેલાં તમારું શું કરે છે તે તપાસો: શાંતિપૂર્વક અપગ્રેડ કરો, ચેતવણી સાથે અપગ્રેડ કરો અથવા લોડ કરવાનો ઇનકાર કરો.

ફાયરફોક્સમાં નિયંત્રણો about:configની પાછળ રહે છે અને ગોપનીયતા સેટિંગ્સ પેજમાં dom.security.https_only_mode સાથે સ્વિચ તરીકે અને પેડલોક મેનૂમાંથી મેનેજ કરાયેલ પ્રતિ-સાઇટ અપવાદો સાથે. ક્રોમ અને એજમાં સમાન વિચાર સેટિંગ્સ, ગોપનીયતા અને સુરક્ષા, સુરક્ષા, હંમેશા સુરક્ષિત કનેક્શનનો ઉપયોગ કરો લેબલ હેઠળ બેસે છે. લેબલ ગમે તે હોય, હોસ્ટ સામેની વર્તણૂકને ચકાસો કે જે ફક્ત પોર્ટ 80 પર જ જવાબ આપે છે, કારણ કે મોડ કે જે અપગ્રેડ થાય છે અને પછી ચુપચાપ પાછું આવે છે તે સુરક્ષા નથી જે તમને લાગે છે કે તમે સક્ષમ કર્યું છે. Firefox HTTPS-Only દસ્તાવેજીકરણ તે બ્રાઉઝર માટે અપગ્રેડ, ચેતવણી અને અપવાદ વર્તણૂકની જોડણી કરે છે.

પગલું 3: સંસાધનોને ઠીક કરો, ફક્ત સરનામાં બારને જ નહીં

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

એકાઉન્ટ સાઇટ પર પ્રમાણપત્ર અપવાદ ઉમેરશો નહીં કારણ કે VPN ચાલુ છે. અપવાદ એ ચેકને નિષ્ક્રિય કરે છે કે જેણે VPN ને રોકવા માટે છે તે બરાબર અટકાવ્યું હશે.

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

પગલું 4: HSTS શું ઉમેરે છે અને શું નથી કરતું

એચએસટીએસ એ બ્રાઉઝર પ્રેફરન્સને બદલે સાઇટ પોલિસી છે, અને અહીં તે એકમાત્ર મિકેનિઝમ છે જે નવી પ્રોફાઇલ પર ટાઈપ કરેલ http:// ટકી રહે છે. એકવાર બ્રાઉઝર હોસ્ટ માટે Strict-Transport-Security હેડર જોઈ લે, તે પછીથી વિનંતીઓને મોકલતા પહેલા https પર ફરીથી લખે છે, જે તમને જોઈતી મિલકત છે. તે બ્રાઉઝર ક્યારેય મુલાકાત ન લીધેલ હોસ્ટ માટે કંઈ કરતું નથી, અને સમાન એપ્લિકેશનને સેવા આપતા કોઈ અલગ હોસ્ટનામ માટે કંઈ કરતું નથી.

ચેક કરો કે મૂળ curl -sSI https://example.com | grep -i strict-transport-security સાથે શું મોકલે છે. ગુમ થયેલ હેડર એ સર્વર ફેરફાર છે અને ક્લાયંટ ઇન્સ્ટોલ કરી શકે તેવી વસ્તુ નથી. જો તે હાજર હોય, તો વાંચો max-age અને includeSubDomains સેટ કરેલ છે કે કેમ, કારણ કે મુલાકાતો વચ્ચે ટૂંકી મહત્તમ વય સમાપ્ત થાય છે અને ગુમ થયેલ હોય તો સબડોમેન્સ દરેક સબડોમેનને અસુરક્ષિત છોડી દે છે. RFC 6797 એ વ્યાખ્યાયિત કરે છે કે વપરાશકર્તા એજન્ટ નીતિ કેવી રીતે લાગુ કરે છે અને તે શું અવગણી શકે છે. પ્રીલોડ એ એક અલગ પ્રતિબદ્ધતા છે, તેથી ડોમેન સૂચિમાં છે તેવું કોઈને વચન આપતા પહેલા hstspreload.org API દ્વારા સ્થિતિ તપાસો.

ચકાસણી અને રોલબેક

રોલબેક ક્લાયંટ સેટિંગ્સ માટે સસ્તું અને HSTS માટે મોંઘું છે. HTTPS-માત્ર મોડને બંધ કરવાથી પહેલાની વર્તણૂક તરત જ પુનઃસ્થાપિત થાય છે; લાંબી મહત્તમ વય નથી, અને મુલાકાતીઓ કે જેમણે તેને પહેલેથી જ પ્રાપ્ત કર્યું છે તેઓ તેની સમયસીમા સમાપ્ત થાય ત્યાં સુધી અપગ્રેડ કરતા રહે છે.

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

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