Как да направите HTTPS първата заявка през VPN

Браузър, който въвежда първо http:// и стига до https:// след пренасочване, вече е изпратил една заявка в чист вид и VPN не променя това. Тунелът предпазва крака от клиента до изходния възел; той не криптира нищо над транспортния слой, така че наблюдател между изхода и произхода все още вижда прескачането на обикновен текст. Правенето на HTTPS като първа заявка е промяна от страна на клиента с три части: реален HTTPS адрес, режим на надграждане на браузъра и собствена политика на сайта. Стъпките по-долу са поръчката, която използвам, всяка с чека, който ви казва дали е взета.

Стъпка 1: потвърдете каква всъщност е първата заявка

Преди да промените нещо, вижте какво изпраща браузърът. Отворете мрежовия панел със страницата, презаредена от студен кеш, и прочетете първия ред: ако схемата е http и състоянието е 301 или 308, всичко след този ред е втора заявка. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com възпроизвежда същата последователност извън браузъра и отпечатва URL адреса, на който сте попаднали.

Възможни са два резултата и те се нуждаят от различни поправки. Ако сайтът обслужва HTTPS на същия хост, решението е да спрете публикуването на HTTP формуляра: актуализирайте отметката, wiki връзката, прекия път на работния плот и имейл шаблона, който хората кликват. Ако сайтът изобщо не обслужва HTTPS, никакви настройки на браузъра няма да го създадат и честният отговор е, че дестинацията е проблемът. Не закривайте втория случай с изключение, тъй като изключение на сертификат на страница на акаунт преобразува транспортен проблем в проблем с идентификационни данни. Запишете в кой случай се намирате, преди да докоснете настройка.

Стъпка 2: включете режима само HTTPS на браузъра

Режимът за надграждане е втората част и режимите не са взаимозаменяеми. Проверете какво прави вашият, преди да го активирате: надстройте тихо, надстройте с предупреждение или откажете да се зареди.

Във Firefox контролите се намират зад about:config и в страницата с настройки за поверителност, с dom.security.https_only_mode като превключвател и изключения за всеки сайт, управлявани от менюто на катинар. В Chrome и Edge същата идея се намира в Настройки, Поверителност и сигурност, Сигурност, означено Винаги използвайте сигурни връзки. Какъвто и да е етикетът, проверете поведението срещу хост, който отговаря само на порт 80, защото режим, който надгражда и след това тихо се връща обратно, не е защитата, която смятате, че сте активирали. Документацията за Firefox само за HTTPS описва надстройката, предупреждението и поведението при изключение за този браузър.

Стъпка 3: поправете ресурсите, не само адресната лента

Когато надстройката е неуспешна, прочетете точната грешка вместо адресната лента. Хост без HTTPS слушател, име на хост, което не съответства на сертификата и изтекла верига, създават различни съобщения и принадлежат на различни собственици. Само първият е пропуск от страната на сървъра; втората обикновено е отметка, която никога не е актуализирана; третият е проблем с подновяването, за който VPN връзката няма отношение.

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

Третата част е вътре в страницата и това е, което хората пропускат. Страница, която се зарежда през HTTPS, все още може да изтегля изображения, шрифтове или скриптове от http URL и браузърът или ще ги блокира, или ще понижи индикатора за сигурност за цялата страница. Проверете неуспешните заявки в мрежовия панел и поправете препратките към ресурсите към техния собственик, вместо да приемате, че адресната лента описва всяка заявка. На сайт, който управлявате, това означава коригиране на съхранените URL адреси в CMS или шаблона, вместо да ги пренаписвате в браузъра. Ако не можете да промените източника, запишете смесеното съдържание като известна празнина, тъй като катинар над страница, която изтегля ресурси в обикновен текст, е фалшив сигнал.

Стъпка 4: какво добавя HSTS и какво не

HSTS е политика на сайта, а не предпочитание на браузъра, и това е единственият механизъм тук, който оцелява след въведен http:// в нов профил. След като браузърът види Strict-Transport-Security хедър за хост, той пренаписва по-късни заявки към https, преди да ги изпрати, което е точно свойството, което искате. Не прави нищо за хост, който браузърът никога не е посещавал, и нищо за друго име на хост, което обслужва същото приложение.

Проверете какво изпраща източникът с curl -sSI https://example.com | grep -i strict-transport-security. Липсващ хедър е промяна на сървъра, а не нещо, което клиентът може да инсталира. Ако е налице, прочетете max-age и дали includeSubDomains е зададено, тъй като между посещенията изтича кратка максимална възраст и липсващите includeSubDomains оставят всеки поддомейн незащитен. RFC 6797 определя как потребителският агент прилага правилата и какво може да игнорира. Предварителното зареждане е отделен ангажимент, така че проверете състоянието чрез API на hstspreload.org, преди да обещаете на някого, че даден домейн е в списъка.

Проверка и връщане назад

Връщането е евтино за настройките на клиента и скъпо за HSTS. Изключването на режим само HTTPS възстановява незабавно предишното поведение; дългата максимална възраст не го прави и посетителите, които вече са я получили, продължават да надграждат, докато не изтече.

Така че проверете по ред, преди да го наречете готово. Презаредете от студен кеш и потвърдете, че първата заявка в мрежовия панел е https без предходно пренасочване. След това проверете поддомейн, защото includeSubDomains е мястото, където тези правила обикновено се оказват по-тесни от предполагаемото. След това проверете една страница, която изтегля активи на трета страна, тъй като смесеното съдържание е грешката, която оцелява при всяка друга корекция.

Ако първата заявка все още е http след всичко това, клиентът вече не е променливата: връзката, върху която хората кликват, е. Потърсете на местата, които контролирате, за http формата на името на хоста, актуализирайте ги и тествайте отново със същото презареждане на студения кеш. Дръжте въпроса за VPN отделен навсякъде, защото тунелът променя кой може да види заявката и никога не променя дали заявката е шифрована. Редът, който трябва да поставите в билета, е, че първата заявка е тази, която има значение, а пренасочването е само разписка за вече изпратена заявка.