Чаму браўзеры могуць хаваць старонку блакіроўкі Squid для HTTPS
Растлумачце, чаму браўзер можа паказаць уласную памылку тунеля замест уласнага HTML, які вяртаецца на адхілены запыт CONNECT.
Уласная старонка блакіроўкі проксі з'яўляецца для HTTP-сайта. Для HTTPS-сайта браўзер замест яе паказвае памылку тунеля. Паўторная замена HTML-шаблона можа нічога не змяніць.
Пры яўным HTTP-проксі наведванне HTTPS звычайна пачынаецца з CONNECT. Браўзер просіць проксі адкрыць тунель да хоста і порта. Калі Squid адхіляе гэты запыт, сеанс TLS сайта так і не пачынаецца.
Адхіленне можа мець HTTP-статус і змест адказу. Вы можаце праверыць гэты няўдалы адказ CONNECT праз curl незалежна ад старонкі памылкі браўзера. Гэта не патрабуе, каб браўзер паказваў прадастаўлены HTML як вэб-старонку пункта прызначэння. Браўзер можа адкінуць цела памылкі CONNECT і выкарыстаць уласны інтэрфейс памылак проксі; дакладнае прадстаўленне залежыць ад кліента.
Калі адхіленне Squid ужо змяшчае патрэбнае цела deny_info, рэдагаванне яго тэксту, табліцы стыляў або правоў доступу да файла не змяняе таго, на якой стадыі адказу дзейнічае браўзер. Трымайце статус адхілення і журнал доступу даступнымі, каб вызначыць, ці быў CONNECT адхілены і чаму. Звычайная старонка браўзера можа хаваць падрабязнасці палітыкі, пакуль проксі правільна выконвае правіла.
Падача старонкі блакіроўкі ўнутры перахопленага HTTPS-злучэння — гэта іншая архітэктура, якая ўключае завяршэнне TLS, давер кліента і кіраванне сертыфікатамі. Яна не ўключаецца рэдагаваннем deny_info, і ўласны шаблон не дае ніякіх паўнамоцтваў выдаваць сябе за заблакаваны сайт. Выбірайце такі дызайн толькі пры неабходнасці; інакш выкарыстоўвайце даступную справаздачу аб памылках кліента і аперацыйныя журналы проксі.