Нужен ли сайту SSL сертификат?

Стыд Белого Медведя.

Катана теперь
Со сканером пальца.
Иначе не режет.

Довольно давно, ещё в 2014 году, в блоге Гугла для вебмастеров проскочила публикация о благостности HTTPS. Заметка небольшая, и базового английского вполне достаточно, чтобы понять две важных вещи:


  1. Использование SSL сертификата Вашим сайтом (HTTPS протокол) отныне учитывается поисковым алгоритмом Гугла. Пока этот фактор ранжирования является слабым, и влияет «менее чем на 1% глобальных запросов».


  2. При использовании HTTPS протокола его влияние на ранжирование сайта со временем «может стать более сильным». Так обещано в заметке.


Поскольку гипотетические вещи мало кого интересуют, вебмастера учли данную информацию, но мало кто бросился ставить свой сайт под SSL сертификат. Хотя на тот момент и были три-четыре конторы, выдававшие такие сертификаты бесплатно.


На данный момент осталась лишь одна такая контора, letsencrypt.org. Причём нет никакой гарантии, что её не сольют — всё-таки торговля SSL сертификатами это самый настоящий бизнес, так что зачем давать людям бесплатно то, что им можно продать за твёрдую валюту?


Последние новости от Гугла.


В своё время Гугл сделал ход конём, выдав пользователям весьма удобный браузер собственного производства. Вещь изящная, с поддержкой плагинов, и миллионом этих самых плагинов на все случаи жизни. Причём под любую платформу - и на смартфоне, и на каком-нибудь Slax Linux браузер Гугл Хром прекрасно себя чувствует, и работает лучше любого другого. Несёт на борту так называемые «средства разработчика», крайне удобные для вебмастера.


Подсадив абсолютное большинство пользователей (и что самое главное, поголовно всех вебмастеров) на этот браузер, Гугл пошёл дальше. Теперь он начинает лоббировать перевод сайтов на HTTPS протокол, помечая их как «безопасные». Прямо в адресной строке браузера.


Тут, кончено, есть некоторое лукавство, ибо ничто не мешает махровому мошеннику воспользоваться SSL сертификатом, тоже сделав свой сайт «безопасным». Но рядовой пользователь интернета технически безграмотен. Он не понимает, что «безопасность» касается его соединения с сайтом, а вовсе не самого сайта. И растолковать ему этот нюанс никак не получится. Вот хоть главою о сруб.


Дальше — больше.


Начиная с Google Chrome 56 версии, сайты, работающие по HTTP протоколу, могут помечаться как «ненадёжные». Прямо в адресной строке красными буквами, а для нас с вами даже надписью на русском языке.


Посмотреть на это можно уже сейчас - вбейте в адресную строку Хрома chrome://flags/ и найдите по Ctrl-F словосочетание «незащищенные источники». Выберите последний пункт этой выпадающей формы, нажмите кнопку сохранения на дне страницы, и после перезапуска браузера Вы должны увидеть, как у сайтов без сертификата в адресной строке появится обидная иконка. Потом там будут и не менее обидные слова. В своё время.


Опять-таки, технически безграмотный серфер воспримет это не как незащищённое соединение, а как какой-то рейтинг сайтов, согласно которому конкретно этому сайту доверять нельзя. В мире зэков для этого предусмотрены специальные наколки на руках, во времена Третьего рейха практиковалось нашивание жёлтой звезды Давида на верхнюю одежду определённого контингента, и т.п. Ну вот теперь этакое позорное клеймо будет сопровождать сайты в протоколе HTTP.


Но есть оговорка.


Если Ваш сайт не практикует отправку форм (пока не ясно, каких именно - логично полагать, что с персональными данными, а не любых форм вообще), то пометки «ненадёжный» появиться не должно. Правда, лишь пока. Что случится чуть позже, никто не знает, и никакой гарантии не даст.


Как на это реагировать?


Только технически грамотный человек, которых в интернете, наверное, один на тысячу, будет правильно понимать всю подоплёку классификации сайтов в адресной строке браузера, и отнесёт её к причудам самого браузера. Все остальные пользователи поделят сайты на «надёжные» и «ненадёжные», относясь к ним соответственно.


Вся проблема лежит именно в этой плоскости.
И эту проблему требуется осознать.


Никакие иные доводы, а уж тем более технические аспекты, пока не играют существенной роли. Аспекты мы далее всё равно рассмотрим, но это достаточно вторичные вещи.


Пока же мы имеем маркетинговый ход Гугла, заставляющий вебмастеров покупать для своих сайтов SSL сертификат под угрозой навешивания на эти сайты ярлыка «ненадёжный». Потому как глупые юзеры станут воспринимать тот ярлык дословно.


Скорее всего, Яндекс вскоре поступит сходным образом, причём более топорно (такова традиция). То, что у посетителя Вашего сайта не Гугл Хром, а Яндекс.Браузер, особой роли не играет. Чуть позже в нём будет то же самое, даже не сомневайтесь.


Итого, Вам надлежит дождаться 56 версии браузера Гугл Хром, и если тот начнёт помечать Ваш сайт как «ненадёжный», и это отвратит посетителей, то впереди у Вас квест по переходу на HTTPS.


Реакция Запада.


Справедливости ради стоит сказать, что забугорные хостеры (в частности, немецкие - местный автор столкнулся недавно с таким фактом) сейчас самостоятельно переводят все сайты своих клиентов на HTTPS протокол, выдавая им SSL сертификат, денег за который с пользователя не берут. Они за свой счёт разруливают проблему, свалившуюся на голову пользователя. Просто потому, что сам пользователь, скорее всего, не сможет её решить самостоятельно, ибо так оно и есть.


Отечественный хостер, конечно же, так заботиться о своих клиентах не станет, даже не сомневайтесь. Проблема сама собой не решится. Как реагировать на маркетинговый выверт Гугла, придётся думать самому. Далее как раз об этом.


Плюсы HTTPS протокола. По степени важности:


  1. Так называемый «ЕГЭ-эффект».


    У среднестатистического пользователя далеко не ума палата, и вне IT-шной ниши надпись в адресной строке браузера «ненадёжный» будет ассоциироваться с сайтом, а не каким-то там неведомым юзеру протоколом.


    Причём в русском языке нет понятий «надёжный» и «ненадёжный». Понятия тут совершенно иные - «проверенный» и «мошеннический». Именно так классификация сайтов Гуглом и будет восприниматься.


    Не хотите считаться мошенником, Вам нужен SSL.
    Вот именно так.


  2. Гугл намерен ранжировать сайты с SSL сертификатом выше, чем без него. Такое намерение пока лишь только постулировано, это скорее «дорожная карта». Но ничто не свидетельствует, что данное заявление не будет поэтапно реализовываться. Будет.


    Хотя надо понимать, что говносайт, посаженный на HTTPS, не станет в одночасье трастовым. Надеяться на что-то подобное было бы верхом наивности.


  3. При транзите трафика с одного HTTPS сайта (например, с поисковика Гугла) на другой HTTPS сайт (то есть Ваш сайт) последнему становятся доступны так называемые реферы - информация об источнике трафика. То есть URL страницы, в котором содержится поисковый запрос. Его можно извлечь.


    Обратите внимание, что в случае Яндекса всё не так - сам запрос в рефере не содержится, ибо дополнительно зашифрован хэшем. От Яндекса Вы никакой информации не получите, даже переведя свой сайт на HTTPS протокол. Знайте это чётко.


  4. Шифрование трафика от пользователя до сайта, причём без специальных технических средств и подмены сертификата нельзя этот трафик подсмотреть, либо подменить данные.


    Как ни странно, самый главный плюс HTTPS протокола стоит на самом последнем месте. Этому есть объяснение. Как показывает практика на примере всяких там блокировок сайтов сети интернет и СОРМ, фиксации URL-ов посещаемых страниц HTTPS протокол не помеха, и, в частности, Ваш провайдер точно знает, что именно Вы искали в том же Гугле, и какие страницы каких сайтов посещали. А большего знать никому и не надо.


Минусы HTTPS протокола.


  1. Высокая цена.


    SSL сертификат не бесплатный, и пусть даже стоит $10 (на самом деле много больше), это уже соизмеримо со стоимостью домена.


  2. Технические сложности.
    Квест по прописке SSL сертификата домену не всякий пройдёт.


  3. Повышенное время загрузки сайта.


    Защищённое соединение нужно сперва установить, обменяться ключами, произвести проверку подлинности сертификата. В целом отклик сайта будет ниже. А ведь этот показатель тоже является параметром ранжирования, причём с куда большим весом, чем наличие у сайта собственно SSL сертификата. Так что возможна ситуация, когда переход на HTTPS протокол уронит сайт в выдаче, а не возвысит.


  4. Неизбежная просадка трафика на время полной переиндексации сайта (все URL-ы теперь в другом протоколе, то есть они целиком, глобально поменялись). Бывали даже случаи полного вылета сайта из индекса (наблюдалось только с Яндексом, у Гугла такого нет).


    Сюда же можно отнести обвал продажных ссылок в эррор, ибо никто не поручится, что при смене протокола они сохранятся. Как обходят этот момент биржи ссылок, автор не в курсе.


    Правда, можно настроить сайт так, чтобы он продолжал выдаваться и по HTTP протоколу. Старые URL-ы продолжают работать, но навигация уже содержит адреса в HTTPS протоколе. Поисковые боты постепенно их учитывают (если не споткнутся о фактически дубликат сайта - Яндекс тут может повести себя неадекватно). Чтобы не было эксцессов, придётся использовать тег «canonical», например. Или даже городить редиректы, если движок позволяет.


  5. Смешанный контент.


    При работе с двумя протоколами одновременно (например, когда не все ссылки переделаны в HTTPS), посетители сайта будут каждый раз получать уведомления о небезопасном содержимом. Так что все изображения, CSS и прочий JS придётся чуть ли не вручную перевешивать на правильный протокол.


    Хотя современные движки сайтов устроены так, что протокол (или URL морды сайта) указан лишь в одном месте настроек, никто не поручится, что проблема решается столь уж просто.


Ну и есть ещё большой и жирный минус, не внесённый в список, но очень актуальный в этой Стране. Знать про него надо обязательно, ибо предусмотреть невозможно, а последствия фатальные. Суть же трабла такова:


Поскольку Роскомнадзор в поте лица борется с педофилами, и на момент написания этих строк заблокировал 1300000 сайтов, все до одного из которых не имеют никакого отношения к педофилии, среди этих заблокированных сайтов попадается всё, что угодно. В том числе и регистраторы SSL сертификатов.


Если сайт, пользующий такой сертификат, не имеет HTTP версии, то он окажется недоступен вообще.


Всё это может показаться забавным и далёким от жизни, но тот же Гугл Хром (или любой другой браузер) ведёт себя в точности как Роскомнадзор. Он уже неоднократно отзывал сертификаты различных регистраторов SSL, в результате чего сайты с сертификаторами от этих контор тупо падали в даун. До тех пор, пока вебмастер не оформит SSL сертификат в другой конторе, либо не вернётся обратно на HTTP протокол.


С точки зрения SEO всё это очень плохо.
Выпадение из индекса - самое безобидное.


Итого.


Может быть, не все вебмастера пока это осознают, но переход на HTTPS, не всякому сайту и нужный, из гипотетического допущения внезапно переходит в практическую плоскость. Всё будет зависеть от того, насколько агрессивно Гугл будет продвигать силами своего браузера в массы эту идею. Судя по реакции немецких хостеров, всё достаточно серьёзно.


Внимательно следите за ситуацией. Если пользователи Вашего сайта поведут себя именно так, как местный автор предполагает, то не играет никакой роли, насколько SSL нужен или не нужен Вашему сайту. Его просто придётся покупать, и переводить сайт на HTTPS, матерясь над всем этим примерно неделю, а потом ещё пару месяцев над последствиями перехода. Но деться-то некуда...


Местный автор пока воздержится от лишних телодвижений - у него вебмастерская аудитория, то есть чуть более продвинутая. Вебмастера уже должны понимать, что если сайт не собирает никакую приватную информацию, кроме e-mail адреса покупателя, то «защищать» тут абсолютно нечего, а сам HTTPS даром не нужен.


Для тех, кого интересует поведение скриптов местного автора под HTTPS протоколом, то всё работоспособно. Разве что в CSP политике протокол разрешённых к импорту с чужих сайтов элементов требуется указывать обязательно. Иначе может возникнуть так называемое смешанное содержимое, которое CSP на HTTPS сайте склонна блокировать как небезопасное. Но до таких вещей можно и самому додуматься.


Ну, народ, с новым Вас головняком!


Судя по фразеологии, этому посту релевантны статьи:

  1. Интересная радиостанция - выбор и обзор BaoFeng UV-5R.

    Интересная радиостанция - выбор и обзор BaoFeng UV-5R. Периодически у всего мужского населения планеты возникает остро выраженная потребность сбежать из дома. Хотя бы ненадолго. Ибо мужики постоянно страдают — то от недостатка общения с женским полом, то от избытка.

  2. Выбираем и покупаем гуглофон.

    Выбираем и покупаем гуглофон. Раз в несколько лет местный автор, обнаружив признаки издыхания у своего текущего телефона, озадачивается выбором нового. Прошлый раз такое случилось в эпоху царствования платформы Windows Mobile и устройств на жёсткой логике (так называемых «звонилок»).

  3. Хадж бродячих самураев к подножию Белухи.

    Хадж бродячих самураев к подножию Белухи. Умные люди давно заметили — размеренная жизнь в стиле «хомяк в колесе» утомляет. Если есть возможность, настоятельно рекомендуется периодически помещать организм в непривычные для него условия.

Хомячковый рай. Уйти и потеряться:

Адрес заметки: http://lasto.com/blog/post_1483952400.html

12 января 2017, 14:13
3. При транзите трафика с одного HTTPS сайта...

Специально ставил сайт под HTTPS.
Яндекс точно поисковые запросы не отдает.
Гугл не отдает на 99,9%. Исключением могут быть запросы с его импортных доменов типа .by, .kz и .т.п., но это малюсенькое исключение никакого эффекта на общую картину не оказывает.
Так что "рыбы там нет". Поправьте, если ошибаюсь.

3. ...URL страницы, в котором содержится поисковый запрос. Его можно извлечь.

Как? Научите. Буду очень благодарен.
В коде выдачи Гула адрес страницы для перехода на неё стоит в обычном теге ссылки, так что согласно спецификации рефер с адресом страницы выдачи должен передаваться сайту-реципиенту, если тот поднят также в протоколе https.

Ну а поскольку сам запрос содержится в URL-е из рефера, в виде параметра q=... то он может быть вытащен оттуда (стандартное URL-кодирование с предшествующим конвертированием в UTF).

Это по классике.

Если в теге ссылки в выдаче навтыкать всякие там OnMouseDown и прочие прокладки между ссылкой и сайтом назначения, всё уже не так однозначно. С отключенным JavaScript браузер точно передаст рефер на сайт в https протоколе, если только сама ссылка останется при этом работоспособной. Со включенной Джавой может быть всё, что угодно - обычно там как минимум редирект. Или парочка.

Браузер пользователя тоже может вносить сумятицу - в нём можно принудительно отключить передачу реферов. Обычно пользователь об этом даже не знает - в таком случае блог местного автора пишет красные буквы по верху страницы "Функционал нашего сайта ограничен настройками Вашего браузера". Намекая, что всякая подсветка поисковых слов при визите в сюда с поисковика тупо не работает.
Денис
13 января 2017, 05:17
>> фиксации URL-ов посещаемых страниц HTTPS протокол не помеха, и, в частности, Ваш провайдер точно знает, что именно Вы искали в том же Гугле

Запрос передается GET-ом, то есть в урле, а урлы протокол шифрует.
Потому и блокируют сайты с https по IP целиком - отдельную страницу провайдер не может увидеть в урле
Возможно, ошибаюсь, но на примере великого китайского файервола вроде как и такое можно, через некие технические ухищрения, конечно. Всевозможный роскомнадзор - по сути филиал "Золотого Щита", и чем дальше, тем это очевиднее. С соответствующими последствиями.

Другой вариант - приключения с государственным сертификатом в Казахстане. Это легко гуглится. Не всё пошло гладко с первого раза, но полный контроль над https таким путём гарантирован.

Стало быть, на горизонте у нас МногоХодовОчка, симбиоз методов и способов, и много нам открытий чудных готовит просвещенья дух. Строго по классику.

Будьте уверены, Вас не оставят в покое, пока не поставят под полный контроль. Насколько в курсе, СОРМ все необходимые вещи уже умеет. https ему не шибко мешает.

И да, уже сейчас Роскомнадзор заблокировал 1.3 миллиона сайтов. Если продолжить в том же духе, то всего через 8 лет сайты кончатся. Это, конечно, интересно, и хотелось бы на такое посмотреть, но борцы с педофилами уже поняли, что тупо банить IP вскоре не получится. Надо уметь блокировать конкретные документы, даже если сайт в https протоколе.
judgefog
14 января 2017, 10:47
Час Добрый.

Надо ли в robots.txt для Yandex в строке Host: перед доменом вписывать https:// ?
Протокол меняется на нужный везде, где протокол указан в явном виде. В файле настроек, в файле роботса, htaccess-а, в css файлах, если по старой доброй традиции там используется абсолютная адресация вместо относительной, в шаблоне дизайна, если морда сайта там не подставляется через переменную, а прописана Вами прямо руками, и т.д.
Олег
16 января 2017, 15:58
Если я правильно понимаю то все эти SSL простых сайтов (блоги информационные не имеющие разных там форм для сбора информации) пока не коснутся.
Теоретически да.
На самом деле - не известно.
Может быть всякое.
Сергей
21 января 2017, 17:43
Если сайт зарегистрирован в Гугл вэбмастер тулс, то вы получите такое письмо:

Message type: [WNC-10026400]
Search Console

В Chrome 56 будет появляться предупреждение о проблемах с безопасностью на сайте ХТТР://example.com/

Владельцу сайта ХТТР://example.com/

С января 2017 г. страницы, на которых Вы не используете протокол HTTPS и собираете данные кредитных карт или пароли, будут помечаться в браузере Chrome версии 56 или более поздней как небезопасные.

Ниже перечислены URL Ваших страниц, для которых будет показываться такое предупреждение, поскольку на них собираются данные о кредитных картах и пароли. Проверьте эти страницы и примите необходимые меры для защиты пользователей. Обратите внимание, что этот список может быть неполным.

ХТТР://example.com/example-example.html

В будущем мы планируем помечать любые страницы, не использующие протокол HTTPS, как небезопасные.

Как устранить проблему

Используйте протокол HTTPS при сборе конфиденциальной информации

Чтобы у посетителей Вашего сайта не появлялось в браузере Chrome описанное выше предупреждение, используйте протокол HTTPS на страницах, где пользователи указывают данные своих кредитных карт или пароли.

От себя добавлю, что на этой странице моего сайта ничего не собирается :)
McDonnell Douglas
02 февраля 2017, 13:32
мой хостер не спросясь поставил все мои сайты под протокол https то есть подарил всем моим сайтам, как я понимаю, временный сертификат на этот самый ssl
вот я и не знаю радоваться этому или ругаться, ведь для поисковых систем сайт по другому протоколу это уже другой сайт
вот и этот блог так же открывается по https, потому как хостер у нас с автором этого блога я думаю один,
если что, то
cPanel -> вкладка SSL/TLS - там все сертификаты
Да, верно.
Хорошо, что это не насильственно.
И HTTPS не идёт вместо HTTP.

Подобные SSL сертификаты от Comodo даются на три месяца. По истечении этого срока сертификат может быть и не продлён, ибо замануха (дальше - за денежку).

Все размышления о дарёном коне далее сводятся к медитации над размерностью этой денежки. Если размерность не большая, то и фиг с ним, можно мигрировать на HTTPS. А вот если всё иначе, да и не очень понятно, зачем этот HTTPS вам вообще сдался, то и смысл в нём?
Михаил
04 марта 2017, 02:50
Вадим, в Lastoblog предусмотрен переход на https?
Я имею ввиду ссылки, которые формируются самим движком, например, при подстановке картинок и т.д., сами будут формироваться в виде "https..."?
Ведь сейчас в коде пишутся полные, а не относительные ссылки

Движок просто обязан создавать абсолютные ссылки, ибо с относительными можно нарваться на фейл. При неправильной ссылке индексирующий бот может увидеть несуществующие страницы, а оказавшись там, вследствие рекурсии узреть ещё больше несуществующих страниц. Причём движок не всегда возвращает 404 хедер, так что возможно появление громадного по объёму однотипных страниц сайта, который поисковик с удовольствием побанит за что-то там некошерное. Так что навсегда забудьте про относительную адресацию.


Если в экспериментальных целях запустить вот этот самый блог с приписыванием ему перед URL-ом https://, то он вполне себе работает и отображает все картинки, которые, естественно, как и у Вас, прописаны в постах статично, и совсем в другом протоколе.

Чтобы разрешить это противоречие, понадобилось лишь прописать подменялку URL-ов для всех таких картинок и файлов типа архивов, открываемых из используемых ЛастоБлогом папок (у местного автора список папок и расширений в коде вот такой, у Вас может быть чуть иной) - подменялка прописывается в конце файла дизайна, ибо больше Вы никуда доступа и не имеете.


Сам код такой:

global $_s;
$url=parse_url($_s['base_url']);
$url='https?\:\/\/'.$url['host'].$url['path'];
if (preg_match_all(
'~'.$url.'(i\/[s|p|userpic|docs|'.
$_s['design']['worktemplate'].
']+\/[^.]+\.[jpg|gif|png|bmp|zip|pdf|htm]{3})~Usi' ,
$content,$n))
{
foreach ($n[1] as $i => $v) {
$n[1][$i]=$_s['base_url'].$v;
}
$content=str_replace($n[0],$n[1],$content);
}

С этим кодом на борту ЛастоБлог будет работать и в обратном направлении - если все ссылки в контенте сформированы для https протокола, то перевод сайта на http протокол не поломает его. Сайт вообще этого перевода не заметит.


Чтобы ЛастоБлог имел возможность работать с любым протоколом, какой захотите, причём одновременно (для проведения опытов, при миграции с одного протокола на другой), в сеттингах пхп, там, где прописывается урл морды ЛастоБлога, вместо стандартной записи по мануалу, следует сделать так:

'http' . ((isset($_SERVER['HTTPS'])
and $_SERVER['HTTPS']=='on') ? 's': '').'://site.ru/',

Понятно, что домен должен быть подставлен реальный

Владимир Тимошенко

Оставить комментарий:

Через авторизацию в Гугле, либо по старинке




  • январь, 2017
  • пн вт ср чт пт сб вс
    1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31