Что такое tls-рукопожатие и как оно устроено

Содержание:

Аутентификация в TLS-рукопожатии
Описание
TSL SNOWSHOES?
История и версии
Бесплатные сертификаты SSL/TLS от Let’s Encrypt
Устройство протокола SSL[править]
- Протокол записиправить
Как установить SSL/TLS, если на сервере несколько сайтов
- Пример, как сделать редирект с HTTPS на HTTP в NGINX
Где получить бесплатный сертификат?
Что такое SSL сертификат самыми простыми словами
- Можно ли взломать SSL протокол?
- В чем главная опасность SSL сертификата?

Аутентификация в TLS-рукопожатии

Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.

Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.

RSA использует простую факторизацию и модульную арифметику. Большие простые числа требуют много ресурсов процессора при вычислениях и их сложно подобрать.

Диффи-Хеллмана иногда называют экспоненциальным обменом ключами, что указывает на возведение в степень (в дополнение к модульной арифметике), но на самом деле сам DH вообще ничего не шифрует и не дешифрует. Поэтому называть его «методом шифрования» вместо «математического обоснования» может быть немного неверно.

Небольшой экскурс в историю может пояснить этот момент.

Ещё в 1976 году Уитфилд Диффи и Мартин Хеллман создали протокол обмена ключами, основанный на работе Ральфа Меркля, чьё имя, по мнению обоих, должно также присутствовать в названии протокола.

Они пытались решить проблему безопасного обмена ключами по незащищённому каналу, даже если злоумышленник прослушивает его. У них получилось, но был один серьёзный недостаток: обмен ключами DH не включал в себя проверку подлинности, поэтому не было возможности проверить сторону на другом конце соединения.

Это можно считать рождением криптографии с открытым ключом и ИОК. Вскоре после того, как Диффи и Хеллман представили свой протокол обмена ключами, были завершены самые ранние версии криптосистемы RSA. Диффи и Хеллман создали концепцию шифрования с открытым ключом, но ещё не придумали саму функцию одностороннего шифрования.

Именно Рон Ривест (R в RSA) создал концепцию, которая в итоге стала криптосистемой RSA.

Во многих отношениях RSA является духовным преемником DH. Он осуществляет:

генерацию ключей;
обмен ключами;
шифрование;
дешифрование.

Таким образом, RSA является более функциональным алгоритмом, который может обрабатывать как обмен ключами, так и цифровые подписи, то есть производить аутентификацию в дополнение к безопасному обмену ключами. Поэтому у RSA ключи больше: должна быть обеспечена достаточная безопасность для цифровой подписи.

В то время как RSA осуществляет аутентификацию и обмен ключами, Диффи-Хеллман только облегчает обмен ключами. Существует четыре распространённых варианта семейства DH:

Диффи-Хеллман (DH);
эфемерный (краткосрочный) Диффи-Хеллман (DHE);
эллиптическая кривая Диффи-Хеллмана (ECDH);
эллиптическая кривая эфемерного Диффи-Хеллмана (ECDHE).

Опять же, Диффи-Хеллман сам по себе ничего не аутентифицирует. Его нужно использовать в паре с алгоритмом цифровой подписи. Так, например, если вы использовали ECDH или ECDHE, большинство шифронаборов будут сопряжены с алгоритмом цифровой подписи эллиптической кривой (ECDSA) или RSA.

Описание

Что такое auth key? где он применяется и какова его роль?

TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что нельзя производить прослушивание пакетов и осуществить несанкционированный доступ.

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

Основные шаги процедуры создания защищённого сеанса связи:

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

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

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

TSL SNOWSHOES?

Что такое active directory

Choosing the perfect snowshoe for youEach snowshoe is made up of 3 key elements:• Decking: to bear your weight, keep you above the snow and maintain your grip. It can be rigid or flexible.• The bindings: for comfort and a secure fit• The crampons and point: to keep your traction on a variety of different snow types and slopes.Choose your model according to your body and how you intend to use your snowshoes. Don’t forget, you can also use our snowshoe selection guide!What is the blocker on the snowshoe bindings for?The primary function of a binding lock on beginner-level TSL snowshoes is to make storage and transport easier. It can be used on rare occasions for reassuring beginners during a descent or for walking backwards in certain conditions. For high-end snowshoes, the ergonomic design – which facilitates a natural walking style – is enhanced thanks not only to the telescopic bindings but also to the frames; rocker frames on our Highlander model or super-flexible frames on our Symbioz model. Walking with the binding locked in place is counter-productive when trying to achieve a natural walking style, which is why you won’t find this feature on these models.

Where are the TSL snowshoes manufactured? In France, of course! Our production sites are located in the Haute-Savoie region.

История и версии

Протоколы SSL и TLS
Протокол	Дата публикации	Состояние
SSL 1.0	не публиковался	не публиковался
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0	1999	Признание устаревшим ожидается в 2020 году
TLS 1.1	2006	Признание устаревшим ожидается в 2020 году
TLS 1.2	2008
TLS 1.3	2018

Что такое атака нулевого дня?

Поддержка TLS 1.3 появилась в Mozilla Network Security Services (NSS) в феврале 2017 года (включено в Firefox 60).Google Chrome некоторое время поддерживал TLS 1.3 в 2017, но отключил его ради Blue Coat web proxу.OpenSSL добавил эту версию в выпуск 1.1.1 от сентября 2018 года.Electronic Frontier Foundation похвалил TLS 1.3 и предостерег от путаницы с сходным клептографическим протокольным гибридом «ETS» или «eTLS» (в нём намерено выключены важные свойства безопасности из TLS 1.3).

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

Они бесплатные;
Подойдут большинству проектов;
Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Установка Certbot в Debian 8 Jessie

Помощник Certbot в выборе версии сервера

Выбираем установку

apt-get install certbot -t jessie-backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

```
yum -y install yum-utils
```

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

```
yum install certbot
```

Универсальная инструкция по установке Certbot

Скачиваем Certbot:
```
wget https://dl.eff.org/certbot-auto
```
Даём права на исполнение с помощью chmod
```
chmod a+x certbot-auto
```
Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с
```
mv certbot-auto /usr/local/bin/certbot
```
Проверяем, что получилось:
```
certbot --help
```
Должы увидеть что-то подобное:

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду), советую заглянуть в cron-задачи

cd /etc/cron.d

В директории должен появиться файл с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Добавили, сохраняем.

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt. — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ .
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos --staging

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email  --agree-tos

— путь до директории с файлами сайта
— прописываем имена доменов
— ваш email, куда можно будет восстановить доступ
— согласие с лицензионными требованиями

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию

Идём настраивать NGINX.

Устройство протокола SSL[править]

Работу протокола можно разделить на два уровня:

Слой протокола подтверждения подключения (Handshake Protocol Layer)
Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

Протокол подтверждения подключения (Handshake Protocol)
Протокол изменения параметров шифра (Cipher Spec Protocol)
Предупредительный протокол (Alert Protocol)

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

Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.

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

Протокол записиправить

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

Протокол рукопожатия (handshake protocol);
Протокол тревоги (alert protocol);
Протокол изменения шифра (the change cipher spec protocol);
Протокол приложения (application data protocol);

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это ):

cert.pem — это сертификат SSL/TLS;
key.pem — это ключ к сертификату.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта , мы можем использовать следующую конфигурацию ( заменяем на свой домен, — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

Где получить бесплатный сертификат?

1. Let’s Encrypt

Это серьезная некомерческая организация, которая предоставляет бесплатные сертификаты. Возможно, вы даже слышали о компаниях, которые спонсируют ее на более $300,000 в год каждая: Facebook, Mozilla, Cisco и Chrome (Google).

На https://clickget.ru, кстати, используется их сертифкат. Можете зайти и посмотреть если хотите.

Единственная проблема, их сайт работает не так, как вы думаете. На нем нельзя получить сертификат. Вот как это сделать если у вас:

1. Виртуальный хостинг

Если у вас виртуальный хостинг, то, возможно, он уже поддерживает выпуск сертификатов через Let’s Encrypt. Лично я знаю что Timeweb, Reg.ru и многие другие это уже поддерживают.

Покажу на примере Таймвеба (которым мы пользуемся), как выглядит выпуск сертификата. Заходите в “Дополнительные услуги”, потом в “SSL сертификаты” и в поле “Сертификат” выбираете SSL Let’s Encrypt:

Все, сертификат будет выпущен в течении пары минут и будет автоматически продлеваться каждые 3 месяца. То есть это сделать проще простого.

Если ваш хостинг не поддерживает Let’s Encrypt, спросите их, возможно, скоро они добавят эту возможность.

2. Свой сервер

Если у вас свой сервер(облачный, VPS, Dedicated и т.п.), то воспользуйтесь сайтом certbot.eff.org. Выбираете там операционную систему и сервер (Apache/Nginx) и получаете пошаговую инструкцию, как все настроить. Правда сможет сделать это только человек, который в этом разбирается.

По идее, можно еще воспользоваться сайтом sslforfree.com, но имейте ввиду, что Let’s Encrypt выпускает сертификаты только на 3 месяца. И каждые 3 месяца нужно его обновлять. Поэтому устанавливать его руками проблематично. Воспользовавшись же способами выше, сертификат будет продляться автоматически, без вашего участия.

2. CloudFlare

Это бесплатный CDN провайдер, используя который, вы получаете кучу полезного, включая бесплатные SSL сертификаты.

Минимальные требования к браузерам и ОС для работы сертификата можно найти внизу этой страницы (Windows Vista+, Firefox 2+, Android 4.0+ и т.п.)

Если вкратце, вам нужно зайти туда, где покупали домены, и перенастроить DNS сервера на CloudFlare, после этого ваш сайт станет доступен через HTTPS. Если вы в этом не разбираетесь, вам стоит попросить сделать это другого человека. Процедура не должна занять более 30 минут и стоить будет недорого.

1. Сначала регистрируетесь здесь

2. Вводите ваши домены через запятую в поле:

Cloudflare автоматически просканирует и добавит DNS записи

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

4. На следующем шаге выбираете бесплатный тариф. После этого вы получите имена 2х серверов. Теперь вам нужно зайти туда, где вы покупали домен и сменить (делегировать) ваши неймсервера (nameserver или DNS сервер) на новые:

Если все DNS записи вы перенесли корректно, то ваши посетители никаких изменений не заменят(то есть сайт будет работать без перебоев).

5. Когда все перенесется, зайдите в настройки вашего домена на вкладку “Crypto” и там где SSL выберите “Flexible”. Все, теперь SSL соединение с вашим сайтом будет работать

Другие варианты:

Еще бесплатные сертификаты выдает StartCom. Я пользовался им пока, в конце 2016 Mozilla, Apple и Google решили перестать доверять этим сертификатам в новых версиях браузеров. И, пока что, StartCom это не исправил.

На будущее:

Перед тем как ставить переадресацию с HTTP на HTTPS проверьте все ли работает (переадресацию обычно можно настроить в панеле хостинга)
Нужно заменить все пути к картинкам и т.п. в коде сайта с http:// на // иначе соединение не будет считаться защищенным. Для WordPress можно воспользоваться плагином типа этого.
При переадресации с HTTP на HTTPS, используя CloudFlare, будьте аккуратны, плагин переадресации должен их поддерживать, иначе будет бесконечная переадресация. Для Вордпресса есть вот этот плагин. Дело в том, что запрос на ваш сайт идет через HTTP в любом случае, нужно читать данные, посылаемые CloudFlare, чтобы понять, открыт ли ваш сайт через HTTP или HTTPS у посетителя.

Вот и все. Даже если вы уже купили сертификат, надеюсь вы перейдете на бесплатный в следующем году

P.S. Если же ваш хостинг не поддерживает это, или, по каким-то причинам, вы хотите сертификат от известной компании, попробуйте этот сайт (там самые дешевые).

Что такое SSL сертификат самыми простыми словами

Вспомните, как часто происходит дело в шпионских детективах. Нам нужно отправить послание сообщнику в другую страну, и нам очень не хочется, чтобы враги перехватили наше послание и прочитали его.

Поэтому мы с сообщником условились о специальном шифре. У меня есть книга (допустим «Пикник на обочине» Стругацких), и у него есть такая же книга. Я пишу письмо сначала простыми человеческими словами, а потом каждое слово заменяю на цифру. Например, цифра «137» будет обозначать, что данное слово находится на первой странице книги, на третьей строчке, седьмое слово по счету.

Мой сообщник получает письмо с цифрами «137-536-9978», берет свой томик Стругацких, и в обратной последовательности расшифровывает мое послание. Понятно, что даже если письмо будет перехвачено по дороге – никто не поймет, что там написано, потому что только мы с сообщником знаем, какую именно книгу мы используем для шифрования.

Вот и SSL протокол работает схожим образом. Только вы с сообщником каждого нового письма используете новую книгу. Кроме того, ваши книги – уникальны. То есть, нигде в мире больше нет ни одного экземпляра этой книги – только у вас и у сообщника.

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

Вы – это ваш сайт. Ваш сообщник – это ваш хостер-провайдер. Сообщение, которое вы передаете – это любая информация, которую пользователи вводят у вас на сайте – номера банковских карточек, пароли, емейлы и прочее. Быстрый ястреб-камикадзе – это прямой цифровой туннель для сообщения между вашим сайтом и сервером.

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

Можно ли взломать SSL протокол?

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

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

Но вот другой вопрос. Означает ли это, что ваш сайт и ваши данные в безопасности? Как ни удивительно, но вовсе не означает.

В чем главная опасность SSL сертификата?

То, что вы используете уникальные книги для шифрования, не значит, что злоумышленник не может притаиться где-нибудь на втором этаже вашего дома. В бинокль он увидит все, что вы пишите на листочке бумаги, и ему не придется даже ничего расшифровывать – он считает сообщение еще до того, как оно будет хитро зашифровано.

Кроме того, получить SSL сертификат сегодня очень просто. Самый распространенный вариант – это сертификат для подтверждения домена (так называемые DV – Domain Validation). То есть для его получения достаточно подтвердить, что у вас есть доступ к емейлу, на который зарегистрирован домен, вот и все. Никто не проверяет, что это за сайт, какой деятельностью он занимается, нет ли на нем вирусов.

Соответственно, любой хакер может сделать сайт, купить для него SSL (или даже взять бесплатный, их сейчас хватает) – и собирать ваши данные себе в копилку. Да, на его сервер они попадут в безопасности. Но куда они отправятся оттуда? Вопрос открытый.

И главной опасностью всей этой истории с SSL я считаю то, что у рядовых пользователей возникает ложное ощущение безопасности (либо наоборот — опасности), когда они видят, что сайт на https-протоколе (либо наоборот – на обычном «http»).

А масла в огонь подливает мой любимый Гугл.

Мол, и сайты-то без «https» мы будем помечать как «небезопасные» (читай – «мошеннические» с точки зрения пользователей), и как сигнал для SEO-ранжирования это включим. И все вебмастера в срочном порядке бросились переходить на SSL. Вот тут-то и открылась вся страшная правда.

Далеко не для всех сайтов SSL одинаково полезен. А во многих случаях даже вреден.