Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Спасибо за интересный анализ.
Я может быть добавлю, что несмотря на то, что браузеры теперь НЕ отправляют первый запрос на http, это в целом мало помогает.
Рассмотрим вариант с браузером. Если злоумышленник может перехватить ваш трафик http, то вполне возможно он может заблокировать ваше соединение по https (если вы подключены через его wifi, или послать tcp reset если он просто подключен вместе с вами к этому wifi), и первый запрос браузера сфйелится, ибраузкр вероятно пошлет его по http. А дальше история с фишингом, про который вы уже рассказали.
Дальше тоже интересно. Даже если у вас вообще будет выключен http на вашем сервере, то ничего не заставит упомянутые интеграции, в которых захардкожен доступ по http, не делать этих запросов по http. То есть то, что они отправляют - все равно сможет быть перехвачено.
Поэтому, хотя выглядит так, что жёстким, но безопасным способом было бы вообще выключить http - это не так. Безопаснее было бы ОСТАВИТЬ http включенным на своей стороне (дальше уже или редирект, или дроп) но в этом случае вы хотя бы будете знать, кто к вам ходит по http, и можете считать, что их данные потенциально скомпрометированы. Может быть как-то уведомлять клиентов или партнёров, что нужно произвести перенастройку.
Может быть как-то уведомлять клиентов или партнёров, что нужно произвести перенастройку.
Кому нужно? Клиенту, может, не хочется создавать в своём оборудовании точку отказа, связанную с сертификатами. Особенно в наше сложное время.
Ну это вопрос философский.
Можно провести мысленный эксперимент. Если ваш сервис передает какие-то данные, и вы эти данные параллельно (например, в виде логов) можете выложить в открытом доступе в интернет, то значит вам не нужны сертификаты и TLS. Если не можете публично выложить эти данные - то нужны сертификаты и TLS.
Ведь логика простая. Ваш трафик без проверки сертификата может кто-то прочитать. Не значит, что обязательно прочитает, но может.
Тоже самое с логами обмена в интернете. Если вы их выложили, то это не значит, что их кто-то прочитает. Но может кто-то прочитать.
В обоих случаях это не конкретный субъект, а неопределенная группа субъектов, на которую вы не можете повлиять или даже их как-то идентифицировать.
С логами в интернете даже лучше ситуация. Если они на вашем сервере, и их кто-то получал, вы хотя бы знаете, что их кто-то получал. В случае перехвата http вы даже не знаете, что перехват был.
Логично, но может я шифрую на уровне приложения.
В применение https в современном виде заложено слабое место в виде предустановленного удостоверяющего центра, к которому на практике доверие оказывается значительно ниже, чем предполагалось оптимистами.
Согласен с вами.
И противоречия тут нет. Если вы шифруете на уровне приложения, то данные в нашем гипотетическом логе будут зашифрованы так же. Значит их можно опубликовать - они уже защищены.
Самоподписанные сертификаты?
Использование самоподписанного сертификата само по себе не освобождает систему от доверия предустановленным удостоверяющим центрам. Которые, как мы теперь знаем на опыте, по команде от государства способны делать вещи, выходящие за их декларированные функции. А если выковырять из системы ссылки на корневые УЦ, то, боюсь, вообще всё сломается.
Плюс ещё не забывайте про DNS.
Если нужна нормальная защита - то только предустановка клиентского сертификата и информирование пользователя на тему фишинга…
Заблокируй 80 порт на сервере и делов
Предзагрузка hsts это старый костыль (как мне кажется), есть же более современный метод информирования о поддерже шифрования - HTTPS запись в DNS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«У нас редирект с HTTP на HTTPS». Есть клиенты, для которых этого мало