Comments 31
очередное бездумное творение генерации текстов
Статья из 1994 года?
Ну оно понятно что это тот же HTTP внутри TLS. Точно так же могут ходить внутри TLS любые другие протоколы - SMTP, IMAP, и т.д. Да что там, благодаря CONNECT у прокси, раньше прокладывали шлюзы во внешку вообще для любого TCP соединения.
Но не понимаю зачем на таких мелочках так акцентировать внимание, да ещё спрашивать на собесах? Там разобраться 5 минут, если по каким-то причинам б-г миловал столкнуться ранее.
Статья-инфошум. Таких была куча - достаточно написать в поиска на Хабре "Как работает HTTPS"
Это все конечно хорошо, но статьи подобного уровня обязательно должны содержать ссылку на телегу или хотя бы рефералки. Что бы мы понимали зачем вообще существует этот многократно переваренный кал😘
Ну или какой смысл? ТГ нету, рефералок тоже. Препод зачёт что-ли не хочет ставить?
Всё это хорошо, но интересней другой вопрос. Как перейти с HTTPS на HTTP, чтобы не тратить деньги и время на сертификат? Как правильно перенаправлять?
Да так же, только в обратном порядке, через .htaccess Другой вопрос, зачем? Если у Вас хостинг не предоставляет бесплатный инструмент для автообновления бесплатных сертификатов от LE, то может проще сменить хостинг, а не отказаться от HTTPS?
Как именно настроить .htaccess, чтобы сервер, получая через HTTPS запрос на сайт без сертификата, переправлял на HTTP адрес?
Спасибо!
Если ничего не путаю, то так:
RewriteEngine On
RewriteCond %{HTTPS} =on
RewriteRule (.*) http://MYSITE.ru%{REQUEST_URI} [NE,R=301]
MYSITE.ru меняете на адрес своего сайта.
Без сертификата это не работает.
А, так у Вас https не включен, но возможны заходы по схеме https? Тогда вторая строчка:
RewriteCond %{THE_REQUEST} http:// [NC]
У нас сервер слушает на HTTPS порту, однако не имеет сертификата, поэтому возникла задача перенаправлять всё с HTTPS на HTTP порт. При соединении по HTTPS браузер пишет, что случилась ошибка шифрования.
Установите бесплатный сертификат от lets encrypt и не занимайтесь ерундой с перенаправлением https → http
То есть каждые три месяца вручную обновлять сертификат и вручную его загружать. Это имеет смысл, когда за такую работу платят, однако полностью лишено смысла для бесплатного сайта, где нет никакой выручки.
вручную обновлять сертификат и вручную его загружать
вы делаете что-то не так
Автоматическое обновление хостер считает отдельной услугой.
Тогда я солидарен с @ifap
Если у Вас хостинг не предоставляет бесплатный инструмент для автообновления бесплатных сертификатов от LE, то может проще сменить хостинг, а не отказаться от HTTPS?
Просто потому что, пока вы там приделываете костыли с редиректом, гугл просто с очередным апдейтом хрома запретит пользователям ходить на незащищенные сайты. Во имя безопасности и защиты детей разумеется
Вот в этом и состоит ключевая проблема. Вотсап перенаправляет на HTTPS. Хром запретит ходить без HTTPS. И получается, что сайт, который вообще никак не взаимодействует с читателем, ничего не получает, ничего не продаёт --- должен тратиться на сертификат, чтобы подтвердить... Эээ... А там ничего не надо подтверждать. То есть тратиться на сертификат, чтобы подтвердить ничего.
Мне кажется, что вы рассуждаете в парадигме коммерческого сайта. Пожалуйста, давайте будем рассуждать в парадигме home page. Спасибо.
HTTPS это не только защита от перехвата "финансового" трафика, а от перехвата/модификации любого. Реальный пример - подмешивание мобильными операторами своей рекламы в HTTP-трафик. Вам дело говорят - подумайте над сменой хостера, потому как даже у бюджетных автоматическое развертывание/обновление сертификатов обычно бесплатная опция.
Клиент и сервер обмениваются ключами для симметричного шифрования.
И что помешает злоумышленнику перехватить эти ключи и расшифровать всё?
Что-то уже вторая за сутки статья с автором который не понимает о чём пишет
И что помешает злоумышленнику перехватить эти ключи и расшифровать всё?
Мешает протокол Diffie-Hellman .
DH не мешает. https://habr.com/ru/articles/751634/
"Атака MITM на примере протокола Диффи-Хеллмана "
Для защиты от этой беды в TLS как раз применяется PKI - сервер подписывает рукопожатие а браузер проверяет полученную подпись. Если MithM влезет подделывать трафик DH, подпись сломается и браузер выкинет плашку о незащищенном соединении.
а если нужно только прочитать переписку?
Прочитать трафик сайта MitM не может из-за того, что трафик шифруется сеансовым ключем.
Сеансовые ключи получаются с помощью DH.
Вмешаться в работу DH не дает PKI.
Для компрометации PKI есть два пути:
а) каким-то образом получить настоящий сертификат для этого сайта и использовать его для такой атаки. Такое бывает. Для защиты от этой беды есть Certificate Transparency, Certification Authority Authorization и SSL pinning, но практика показывает, что а-1) подавляющее большинство админов вообще не в курсе и а-2) это можно объехать при наличии серьезных ресурсов (не обязательно технических).
б) создать для этого сайта самоподписанный сертификат и каким-то образом воткнуть его в браузер клиента или даже заставить клиента использовать отдельный браузер с уже встроенным таким сертификатом. Такие случаи так же бывают.
В сухом остатке - это не очень простая затея, она требует серьезных ресурсов, но при наличии ресурсов действительно возможна.
Предположу что каждый генерирует пару RSA ключей. А передается публичный ключ которым шифруют данные. Но им нельзя расшифровать.
Когда это https в transport layer попала OSI?
HTTP и HTTPS: Разница