И ещё минутка просвещения
Mar. 25th, 2017 12:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitКогда технически грамотные программисты рассказывают, что главное в TLS — шифрование, мне становится понятно, что надо пересказать тот кусок презентаций, который я обычно адресую широкой публике. Это упрощённое изложение, но типичный сценарий покрывает.
Сенситивные данные могут подслушать те, кто читает трафик в произвольной точке между вами и получателем. От этого спасает шифрование данных при передаче. Но когда вы передаёте номер банковской карты и прочие реквизиты, вам надо убедиться, что передаёте вы их именно туда, куда надо.
У протокола TLS есть несколько задач. И перед тем, как мы согласуем ключи шифрования и начнём передавать зашифрованные данные, наша задача — убедиться, что соединились мы именно с тем, с кем хотели. Для этого предусмотрена фаза handshake. На этой фазе клиент и сервер сверяют разные куски информации, которыми они обменялись, между собой. Типичный случай — доменное имя в DNS-запросе и в сертификате. Если они не совпали, то возможно, вы пытаетесь договориться не с тем.
Если они совпали, то надо внимательно посмотреть на сертификат, потому что сертификат может выписать кто угодно кому угодно. Но есть список доверенных корневых сертификатов (сертификатов удостоверяющих центров, УЦ), приходящий с браузерами и операционной системой в целом. Если мы смогли проверить, что предъявленный сертификат (вообще говоря, цепочка сертификатов) кончается одним из доверенных, то мы можем на что-то надеяться. Сертификат конкретного домена, конечно, может быть отозван, и это можно проверять, но на практике это работает довольно странно.
Доверенный потому и доверенный, что предпринимает процедуру проверки того, что ему принесли. Процедура проверки может быть довольно развесистой, включющей в себя обращение с бумажными документами, и в результате на свет родится так называемый EV-сертификат. При соединении с таким сайтом в любом браузере у вас вылезет плашка на половину адресной строки с указанием компании-владельца.
Процедуры проверки удостоверяющими центрами заявителей сильно регламентированы, и на нарушениях УЦ время от времени попадаются. Так, пару месяцев назад пострадал УЦ WoSign. Сейчас Google предъявляет претензии Symantec. Но проблема не в УЦ, а в том, что если сертификат УЦ выпадает из списка доверенных, то страдают все, кто у них сертификаты купил. В результате единожды попавший в браузеры доверенный сертификат порождает проблему "Too big to fail". Из-за этого реальные проверки в браузерах не сводятся к построению цепочки доверия. Кажется, чуть ли не единственный случай, когда доверие отзывалось моментально, был связан с Diginotar, голландским УЦ, который был взломан несколько лет назад.
И только если предъявленный сервером сертификат не вызывает никаких вопросов по всем процедурам проверки, стороны и начнут обмениваться зашифрованным трафиком.
Сенситивные данные могут подслушать те, кто читает трафик в произвольной точке между вами и получателем. От этого спасает шифрование данных при передаче. Но когда вы передаёте номер банковской карты и прочие реквизиты, вам надо убедиться, что передаёте вы их именно туда, куда надо.
У протокола TLS есть несколько задач. И перед тем, как мы согласуем ключи шифрования и начнём передавать зашифрованные данные, наша задача — убедиться, что соединились мы именно с тем, с кем хотели. Для этого предусмотрена фаза handshake. На этой фазе клиент и сервер сверяют разные куски информации, которыми они обменялись, между собой. Типичный случай — доменное имя в DNS-запросе и в сертификате. Если они не совпали, то возможно, вы пытаетесь договориться не с тем.
Если они совпали, то надо внимательно посмотреть на сертификат, потому что сертификат может выписать кто угодно кому угодно. Но есть список доверенных корневых сертификатов (сертификатов удостоверяющих центров, УЦ), приходящий с браузерами и операционной системой в целом. Если мы смогли проверить, что предъявленный сертификат (вообще говоря, цепочка сертификатов) кончается одним из доверенных, то мы можем на что-то надеяться. Сертификат конкретного домена, конечно, может быть отозван, и это можно проверять, но на практике это работает довольно странно.
Доверенный потому и доверенный, что предпринимает процедуру проверки того, что ему принесли. Процедура проверки может быть довольно развесистой, включющей в себя обращение с бумажными документами, и в результате на свет родится так называемый EV-сертификат. При соединении с таким сайтом в любом браузере у вас вылезет плашка на половину адресной строки с указанием компании-владельца.
Процедуры проверки удостоверяющими центрами заявителей сильно регламентированы, и на нарушениях УЦ время от времени попадаются. Так, пару месяцев назад пострадал УЦ WoSign. Сейчас Google предъявляет претензии Symantec. Но проблема не в УЦ, а в том, что если сертификат УЦ выпадает из списка доверенных, то страдают все, кто у них сертификаты купил. В результате единожды попавший в браузеры доверенный сертификат порождает проблему "Too big to fail". Из-за этого реальные проверки в браузерах не сводятся к построению цепочки доверия. Кажется, чуть ли не единственный случай, когда доверие отзывалось моментально, был связан с Diginotar, голландским УЦ, который был взломан несколько лет назад.
И только если предъявленный сервером сертификат не вызывает никаких вопросов по всем процедурам проверки, стороны и начнут обмениваться зашифрованным трафиком.
no subject
Date: 2017-03-25 01:36 pm (UTC)Чтобы обдурить типичную жертву фишинга вполне хватит сертификата от Let's Encrypt. И это большая социальная проблема.
no subject
Date: 2017-03-25 02:18 pm (UTC)no subject
Date: 2017-03-25 05:59 pm (UTC)