HTTPS-праксі — гэта два TLS-злучэнні, а не адно

Метка HTTPS-праксі апісвае толькі транспарт паміж вашым кліентам і праксі, і нічога больш. Яна не кажа, што вэб-сайт за ім зашыфраваны тым жа злучэннем, і не кажа, што праксі можа прачытаць старонку. Калі вы раздзяліце два злучэнні, памылкі сертыфікатаў перастануць быць загадкавымі, а параўнанне з VPN стане канкрэтным.

Дзве пары бакоў, дзве праверкі

У звычайным рэжыме тунеля ёсьць два TLS-адносіны. Першае ідзе ад вашага кліента да праксі і аўтэнтыфікуе праксі. Другое ідзе ад вашага кліента да вэб-сайта ўнутры тунеля і аўтэнтыфікуе вэб-сайт. Яны адмаўляюць незалежна і наладжваюцца незалежна.

У іх асобныя рашэнні даверу, асобныя ланцугі сертыфікатаў і асобныя паведамленні пра памылкі. Праксі, які выкарыстоўвае арганізацыйны CA, і публічны вэб-сайт з публічным ланцугом могуць цалкам законна патрабаваць рознай канфігурацыі праверкі, і гэта не памылка налады.

Стаўцеся да іх як да двух злучэнняў, якія проста дзеляць адзін сокет, бо гэта і ёсьць так.

Што CONNECT насамрэч тунелюе

Кліент адпраўляе запыт CONNECT з указаннем хаста і порта, а праксі адкрывае TCP-злучэнне да гэтай мэты. Пасля адказу праксі байты, што ідуць далей, перадаюцца без інтэрпрэтацыі, таму TLS-рукапоцісканне вэб-сайта праходзіць праз праксі непашкоджаным. Такім чынам, праксі даведваецца імя прызначэння і метаданыя злучэння, але не атрымлівае расшыфраваных старонак з гэтай схемы.

Гэта адрозненне — увесь аргумент бяспекі для рэжыму тунеля, і гэта таксама яго мяжа.

HTTP-праксі без TLS на праксі-пераходзе ўсё яшчэ праводзіць HTTPS-сайт праз CONNECT. Абмен кліента з праксі ідзе адкрытым, а злучэнне з сайтам — не, і называць усё гэта 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 залежыць ад яго маршрутызацыі і палітыкі праграм, што таксама трэба правяраць, а не меркаваць. Ні адзін варыянт не ахоплівае ўсё проста таму, што быў усталяваны.

Запішыце чатыры радкі для кожнага варыянта, і спрэчка звычайна вырашаецца сама. Карыснае параўнанне — не тое, якая метка гучыць больш зашыфраванай. А тое, якія сегменты абаронены, хто верыфікуецца на іх канцах, якім пасярэднікам вы давяраеце і які трафік палітыка насамрэч ахоплівае.