И ещё минутка просвещения

[beldmit]

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

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

У протокола TLS есть несколько задач. И перед тем, как мы согласуем ключи шифрования и начнём передавать зашифрованные данные, наша задача — убедиться, что соединились мы именно с тем, с кем хотели. Для этого предусмотрена фаза handshake. На этой фазе клиент и сервер сверяют разные куски информации, которыми они обменялись, между собой. Типичный случай — доменное имя в DNS-запросе и в сертификате. Если они не совпали, то возможно, вы пытаетесь договориться не с тем.

Если они совпали, то надо внимательно посмотреть на сертификат, потому что сертификат может выписать кто угодно кому угодно. Но есть список доверенных корневых сертификатов (сертификатов удостоверяющих центров, УЦ), приходящий с браузерами и операционной системой в целом. Если мы смогли проверить, что предъявленный сертификат (вообще говоря, цепочка сертификатов) кончается одним из доверенных, то мы можем на что-то надеяться. Сертификат конкретного домена, конечно, может быть отозван, и это можно проверять, но на практике это работает довольно странно.

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

Процедуры проверки удостоверяющими центрами заявителей сильно регламентированы, и на нарушениях УЦ время от времени попадаются. Так, пару месяцев назад пострадал УЦ WoSign. Сейчас Google предъявляет претензии Symantec. Но проблема не в УЦ, а в том, что если сертификат УЦ выпадает из списка доверенных, то страдают все, кто у них сертификаты купил. В результате единожды попавший в браузеры доверенный сертификат порождает проблему "Too big to fail". Из-за этого реальные проверки в браузерах не сводятся к построению цепочки доверия. Кажется, чуть ли не единственный случай, когда доверие отзывалось моментально, был связан с Diginotar, голландским УЦ, который был взломан несколько лет назад.

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

Comments

[vitus_wagner]

И все-таки у тебя не достаточно четко прозвучала мысль, что бесполезно шифровать канал, если мы не уверены, что на другом его конце тот, с кем мы, собственно, хотим связаться.

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

Народ ведь не понимает именно этого. Что TLS-соединение может быть терминировано вовсе не там, где ожидает его инициатор и зачем вообще все эти пляски с сертификатами.

[beldmit]

Мне казалось, я повторил это минимум дважды...

[vitus_wagner]

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

Для нас с тобой эта мысль слишком банальна, чтобы ее упоминать не вскользь. А для читателя - слишком неочевидна, чтобы уловить, когда она упомянута вскользь.

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

[beldmit]

Буду дорабатывать куда-нибудь - постараюсь подчеркнуть.

[qkowlew]

Вот буквально ППКС.
Собирался писать практически ту же самую реплику, но вот с каким добавлением:

"При соединении с таким сайтом в любом браузере у вас вылезет плашка на половину адресной строки с указанием компании-владельца." НО НЕ СКАЗАНО, что с этой плашкой ДЕЛАТЬ ПОЛЬЗОВАТЕЛЮ, и что с чем сравнивать и где.

Подавляющее большинство находится в отсостоянии "вижу зелёненькое - и хорошо!"

Иными словами - ничего конструктивного для конечного пользователя из этого описания плашки сейчас не следует.

[beldmit]

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

Чтобы обдурить типичную жертву фишинга вполне хватит сертификата от Let's Encrypt. И это большая социальная проблема.

[yurikhan]

Ну вон в том самом деле Google v. Symantec, насколько я понимаю, основное обвинение — выдали зелёненький сертификат без должной строгости проверки.

[beldmit]

Не. Там обычные сертификаты, как я понял. Плюс тестовые сертификаты на домены *.google.com.

[qkowlew]

Подчёркнуто модельная ситуация.

1. Компания с торговой маркой MAI1 регает домен mai1.ru и получает все нужные сертификаты и пры. То есть адресная строка будет вполне "зелёная".

2. Злоумышленный хакер, получивший контроль над сервером компании, на выходные вешает на этом домене фишинговые страницы, имитирующие интерфейс mail.ru

3. Почтовик компании рассылает кучу писем, имитирующих соответствующие письма от mail.ru и завлекающих пользователей на соотв страницы сайта mai1.ru сменить пароли к почте их ящиков (в том числе - ввести новые пароли к почтам тех ящиков, с которых mail.ru собирает почту по воле этих пользователей).

Что должен делать/проверять получатель письма чтобы не попасться на такой крючок и понять, что "его терминировали не туда"?

[beldmit]

В описанном тобой сценарии - доменное имя проверять. Ну и проверять новости, шлёт ли Mail.ru нотификации массово, потому что не должен без какого-либо падения неба на землю. Писать в поддержку с другого адреса. Но увы, не масштабируется.

Когда я попал на фишинг в ЖЖ в своё время, я не сомневался, что пароль приходится вводить, потому что идиоты что-то наулучшали.

[qkowlew]

доменное имя проверять

дада, отличи mai1.ru от mail.ru
Способов развлечься подобным способом есть слишком много.
;-)

Иными словами - я как раз и говорю о том, ЧТО должен проверить человек.
То есть - на мой взгляд, в тексте на эту тему, предназначенном для ПРОСВЕЩЕНИЯ МАСС, должны быть фразы и картинки такого типа:

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

[beldmit]

Если это именно хакер сломал сайт честного mai1, то там может быть такая же плашка.

[qkowlew]

Естественно.

Тут фишка в том, что "компания mai1" НА САМОМ ДЕЛЕ может и создавалась как "будущая площадка для таких подвигов", а не как "честный бизнес".

И потому сходство фальшивой страницы с настоящей может быть СКОЛЬ УГОДНО хорошим.

Однако я говорю о том, что у тебя в тексте, "просвещающем" пользователей низкого уровня - отсутствуют КОНКРЕТНЫЕ рекомендации и для более простых случаев (для отсева которых и нужны вот эти самые "зелёненькие" и "большие зелёненькие").