HTTPS прокси екі TLS қосылысын білдіреді, біреуін емес

HTTPS прокси белгісі тек клиентіңіз бен прокси арасындағы тасымалды сипаттайды, одан артық ештеңе емес. Ол артындағы веб-сайттың сол қосылыспен шифрланғанын да, проксидің бетті оқи алатынын да айтпайды. Екі қосылысты бөлген бойда сертификат қателері жұмбақ болудан қалады және VPN-мен салыстыру нақты болады.

Екі шет жұбы, екі тексеру

Қарапайым туннель режимінде екі TLS қатынасы бар. Біріншісі клиентіңізден проксиге барады және проксиді аутентификациялайды. Екіншісі клиентіңізден туннель ішіндегі веб-сайтқа барады және веб-сайтты аутентификациялайды. Олар тәуелсіз сәтсіздікке ұшырайды және тәуелсіз конфигурацияланады.

Олардың жеке сенім шешімдері, жеке сертификат тізбектері және жеке қате хабарламалары бар. Ұйымдық CA пайдаланатын прокси мен жалпыға ортақ тізбекті пайдаланатын жалпыға ортақ веб-сайт заңды түрде өзгеше тексеру конфигурациясын қажет етуі мүмкін, және бұл дұрыс емес конфигурация емес.

Оларды кездейсоқ бір сокетті бөлісетін екі қосылыс ретінде қарастырыңыз, өйткені олар дәл солай.

CONNECT шын мәнінде нені туннельдейді

Клиент хост пен портты көрсете отырып CONNECT сұрауын жібереді, ал прокси сол мақсатқа TCP қосылысын ашады. Прокси жауап бергеннен кейін келесі байттар интерпретациясыз жеткізіледі, сондықтан веб-сайттың TLS қол алысуы проксиден өзгеріссіз өтеді. Осылайша прокси межелі атауды және қосылыс метадеректерін біледі, бірақ бұл орналасудан шифры шешілген беттерді алмайды.

Бұл айырмашылық туннель режимінің бүкіл қауіпсіздік дәлелі, және ол оның шегі де.

Прокси секірісінде TLS жоқ HTTP прокси бәрібір CONNECT арқылы HTTPS веб-сайтын тасымалдайды. Клиент пен прокси арасындағы алмасу ашық күйде, ал веб-сайт қосылысы олай емес, және бәрін HTTPS прокси деп атау сол айырмашылықты жасырады.

Қай сертификат сәтсіз аяқталды

Тексеру сәтсіз болғанда, кез келген сенім параметрін өзгертуден бұрын қатеде аталған шетті оқыңыз. Екі сәтсіздік терминалда ұқсас көрінеді және мүлдем басқа түзетулерге нұсқайды, сондықтан бірінші сұрақ әрқашан қай қосылыстың бас тартқаны.

curl опцияларды дәл осы себептен бөледі. Проксидің CA файлы проксиді тексеруді конфигурациялайды, ал CA файлы серверді тексеруді конфигурациялайды, және қолданылатын сенім қоймасының әрекеті де curl қалай құрастырылғанына байланысты.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Тексеруді басу жөндеу емес. Ол екі шеттің ешқайсысы туралы ештеңе дәлелдемейді.

Инспекция басқа орналасу

TLS инспекциясы туннельдеу емес. Тексеретін делдал веб-сайтқа қарай сенім қатынасын тоқтатады және клиентке өз сертификатын ұсынады, сондықтан клиент сайтты емес, делдалды тексереді. Бұл бекітілген дизайн шеңберінде заңды болуы мүмкін, және бұл байт-байт жеткізуден едәуір өзгеше тұжырым. Әрбір прокси инспекция жасайды деп ойламаңыз, және шифрланған прокси секірісі мұны жоққа шығарады деп те ойламаңыз.

Сенім қоймаңыздағы ұйымдық CA қай орналасуда екеніңізге нұсқау, дәлел емес. Сертификат тізбегінен болжаудың орнына дизайнды сұраңыз.

Бұл екі орналасу бетті кім оқи алады деген сұраққа өзгеше жауап береді.

Прокси мен VPN-ді бірдей төрт жолда салыстырыңыз

Салыстыру екі орналастыру да бірдей сипатталғанда ғана пайдалы болады.

Бір сұрауға конфигурацияланған прокси сол сұрауды қамтиды. Ол құрылғыдағы әрбір процесті өзінен өткізбейді, және мысалдағы команда дәл сонша тар. VPN қамтуы оның маршруттауы мен қолданба саясатына байланысты, оларды да болжаудың орнына тексеру керек. Екі нұсқаның ешқайсысы тек орнатылғаны үшін бәрін қамтымайды.

Әр нұсқа үшін төрт жолды жазыңыз, дау әдетте өзі шешіледі. Пайдалы салыстыру қай белгінің шифрланғандай естілетіні емес. Қай сегменттердің қорғалғаны, олардың шеттерінде кімнің тексерілетіні, қай делдалдарға сенетініңіз және саясаттың шын мәнінде қандай трафикті қамтитыны.