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-а зависи од његовог рутирања и политике апликација, што такође треба проверити, а не претпоставити. Ниједна опција не покрива све само зато што је инсталирана.

Запишите четири линије за сваку опцију и расправа се обично сама реши. Корисно поређење није која ознака звучи шифрованије. Већ који су сегменти заштићени, ко је проверен на њиховим крајевима, којим посредницима верујете и који саобраћај политика заиста обухвата.