Браузърът показва предупреждение за сертификат на сайт, чиято верига е пълна, и първият инстинкт е да се поправи сървърът. Обикновено сървърът представя точно това, което трябва. Клиентът решава кои котви приема и никакво подреждане на междинни сертификати не може да промени това решение от другия край на връзката. Тази граница обяснява повечето от онова, което изглежда проблем със сертификата.

Проверката се извършва на клиента, с котвите на клиента

Проверката на пътя взема представените сертификати и изгражда верига до котва за доверие, която проверяващата система вече притежава. RFC 5280 описва този модел и поставя избора на котва в локалната реализация, а не в сървъра. Приложението може да добави своя политика отгоре: закачен ключ, корпоративно хранилище за доверие, или по-строга проверка на самоличността. Списъкът със сертификати, който сървърът изпраща, е доказателство, предложено на този процес, никога инструкция към него.

Така пълната верига доказва, че сървърът има частите. Тя не доказва, че клиентът ще ги приеме.

За да видите какво всъщност изпраща сървърът, изпълнете openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts и пребројте сертификатите в изхода. Непълна верига там е поправка от страна на сървъра. Пълната верига премества въпроса към клиента и неговите котви, където сървърът няма глас.

Какво всъщност променя инспекцията на TLS

Устройство за инспекция прекратява TLS сесията от страна на клиента и отваря отделна сесия към реалната услуга. След това клиентът проверява сертификата на устройството, който трябва да води до котва, на която клиентът се доверява. Затова управляваните устройства получават корена за инспекция чрез управление на устройствата и затова лично устройство без него показва предупреждение.

Подредбата е умишлена и локална. Нищо във веригата на оригиналния сървър не може да принуди неуправляван браузър да приеме заместващата самоличност и нищо в нея не пречи на управлявано устройство да го направи.

Прекратяването на VPN не е разшифроване на HTTPS

VPN слоят пренася пакети между клиент и шлюз. Премахването му или четенето на конфигурацията му не разкрива HTTPS товар вътре.

TLS сесията все още тече между браузъра и уеб сървъра, със същите правила за проверка, освен ако нещо изрично не я прекрати. Объркването на двата слоя води до искане администраторът на VPN да предостави сертификата, докато въпросният сертификат принадлежи на инспекционен прокси или на самия сайт. Попитайте кой компонент представя сертификата, преди да промените каквото и да е хранилище за доверие.

Задайте очакванията в компонента, който контролирате

Ако управлявате приложението и неговия клиент, дефинирайте заедно очакваната самоличност на услугата, приеманите издатели и всяко изискване за закачане или клиентска автентикация. Планирайте подновяване и възстановяване, така че законна промяна на сертификат да не се превърне в прекъсване. Ако управлявате само публичния сървър, документирайте каква автентикация изисквате и кои клиентски среди поддържате. Изпращането на предпочитана верига не сертифицира чуждо устройство.

На управлявано оборудване решавайте несъвместимостта чрез собствениците на приложението и мрежата. Изключването на проверката, добавянето на необяснен корен или опитът да се надживее политика за инспекция не установяват желаната връзка между страните.

Тествайте резултата в чист клиентски профил, а не на машината, където вече е добавено изключение. Това е единствената проверка, която показва какво ще изпита ново устройство.

Подобни статии