Э, дарагой. Шифрованное соединение незнамо с кем эквивалентно нешифрованному соединению. Называется Man in the middle.

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

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

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

Ну и SNI тут уже немножко ни при чем. SNI это всего лишь желание web-хостеров сэкономить на IP-адресах. До появления SNI приходилось каждому HTTPS-серверу давать отдельный IP, чтобы тот всегда был уверен в том, по какому имени к нему пришли и предъявлял сертификат на это имя.

Теперь можно делать несколько HTTPS-серверов на одном IP.

(Reply to this) (Thread)

это не желание съэкономить, а результат очень слабого отношения доменного имени к проблеме доверия.

(Reply to this) (Parent) (Thread)

Ну другого идентификатора кроме URL у сайта все равно нет. Поэтому хошь не хошь, а доверять/не доверять приходится именно доменному имени.

(Reply to this) (Parent) (Thread)

ну это до того как установлено соединение -- да нету.
это всё равно что сказать: "у банка кроме уличного адреса никакого ИД нету поэтому приходится доверять номерку дома на стене"

(Reply to this) (Parent) (Thread)

Не все равно. Потому что когда ты пришел ногами в банк, между тобой и банком нет двух десятков промежуточных роутеров, на каждом из которых может сидеть злоумышленник фильтрующий информацию. Почитай выдачу traceroute www.amazon.com и задай себе вопрос "кто все эти люди?"

(Reply to this) (Parent) (Thread)

вы всегда очень правильно разсуждаете!

вот поэтому вопрос о доверии к банку должен быть решён путём получения ключа банка РУКАМИ.

А кто эти люди в верисайне я не знаю и не желаю знать.

(Reply to this) (Parent) (Thread)

Ну верисайгн - это такое РАО. Люди которые стригут купоны на контенте, который они не создавали.

(Reply to this) (Parent)

я живо представил эту картину :-)

- товарищ милиционер это правда дом номер 13?
- да
- я вам денег принёс.

(Reply to this) (Parent)

да и по поводу вашей страшилки об Абсолюном MiM
что помешает ему отдать мне валидный сертификат моего адресата при установке соединения?
какие ДОПОЛНИТЕЛЬНЫЕ возможности возникают у него после установления соединения по сравнению с ДО?

(Reply to this) (Parent) (Thread)

Как что - ему же нужно отдать тебе не абы какой сертификат, а сертификат на тот самый публичный ключ, владение секретной половинкой которого он подтвердил во время TLS-хэндшейка (подписав этим ключом некоторые переданные тобой данные).

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

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

Подробности - в rfc2246.

(Reply to this) (Parent) (Thread)

каким образом я окажусь ЛИШЁН этой возможности удостоверения подлинности после установления шифрованного соединения?

(Reply to this) (Parent) (Thread)

Весь смак в том, что удостоверение подлинности и сеансовый ключ шифрования слиты воедино. Так чтобы выработанный общий сеансовый ключ был общим именно с тем, кто удостоверил свою подлинность. Поэтому после аутентификации сервера вам все равно обоим придется ChangeCipherSpec сделать.

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

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

Бывают случаи, правда, когда используется авторизация клиента по сертификату. Тогда клиент устанавливает соединение, аутентифицирует сервер (устанавливает шифрованное соединение) а потом говорит "а вот хочу того, что требует дополнительных прав". Сервер ему "а сертификат давай", после чего выполняется ПОВТОРНЫЙ ХЭНДШЕЙК и они аутентифицируют друг друга заново и МЕНЯЮТ СЕАНСОВЫЙ КЛЮЧ ШИФРОВАНИЯ. Чтобы оба были уверены в том что ключ у них общий ровно с тем, кого они аутентифицировали.

(Reply to this) (Parent) (Thread)

> Соответственно, а нафига тебе шифрованное соединение до установления подлинности второй стороны?

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

(Reply to this) (Parent) (Thread)

Увы! На существующем уровне компьютерной техники мы не можем доверять "одному из тысячи скриптов" а 999 остальным - не доверять.
Либо мы доверяем всему серверу/кластеру (хотя бы в том, что он не позволит этим 999 скриптам ковыряться в памяти нашего, тысячного), либо не доверяем вообще.

(Reply to this) (Parent) (Thread)

ну это с памятью вы уже в полный неадекват ушли (намеренно упразднив все степени защиты кроме двух: Никакой и Абсолюной).

по-вашему выходило сначала:
(1) если я не хочу чтобы Вася из соседнего отдела подглядел мой пароль на амазоне, я должен предположить что есть инет провайдер который хочет купить за мой счёт книшку.
а теперь и вовсе выходит (2) что все пользователи амазона хотят сломать амазон чтобы заполучить мой пароль.

(Reply to this) (Parent) (Thread)

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

Но со SNI, с которой треп начался - все еще хуже. Там речь идет не об амазоне, у которого на выделенные сервера денег хватает, а о shared-хостинге. Магазине эксклюзивных компакт-дисков "Вася Пупкин и Ко", который хостится на одном провайдерском сервере с фирмой по доставке шаурмы на дом "Рекорд Надоев и сыновья". И подозрении, что нехороший russo fascisto Пупкин хочет спереть пароли у клиентов честного кавказского предпринимателя Надоева.

(Reply to this) (Parent) (Thread)

нет мы живём в мире где юзеру (желающему один товар (шифрование)) насильно навязывают второй товар (доверие (к нечту именуемому "сервер")). и в итоге юзер начинает думать одно из двух:
(1) второй товар никогда никому не нужен как "блокнот агитатора" с журналом "вокруг света"
(2) если у меня в браузере зелёная строка значит я в полной безопасности от пожаров и наводнений -- слава всемогущим богам верисайна!

(Reply to this) (Parent) (Thread)

К сожалению, шифрование от доверия неотделимо по природе вещей.

Шифрование - это сокрытие информации от посторонних глаз.


Соответственно, во всех случаях, когда прочитать зашифрованное сообщение может кто-то кроме его автора (в частности во всех случаях шифрования канала связи), возникает вопрос доверия к тем не-посторонним, кому автор сообщения дает право его читать.

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

Можно еще рассмотреть вопрос использования javascript-функции crypto.signData и соответствующих микрософтовских аналогов, и вопрос кому и как должен доверять юзер в таком случае, чтобы от его имени не подписали платежку на миллион баксов в пользу нигерийских спамеров. Там тоже вопросы доверия нетривиальны, хотя вроде как шифрвоания и нет.

Вообще по вопросу выполнения untrusted кода уже такая куча копий поломана...

(Reply to this) (Parent) (Thread)

> К сожалению, шифрование от доверия неотделимо по природе вещей.

отсюда не следует что юзер хочет это _доверие_ (как услугу) у вас купить !!!
оно у него может УЖЕ БЫТЬ на момент покупки шифрования.

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

И (если вы скажете что юзерам нужна только абсолютная супер-пупер неломаемая защита) я вас пойму - вы лицо материально заинтересованное (глупо было бы признавать частичную ненужность своего товара (когда его можно в самых топовых модификациях продать каждому гражданину)), но внутри мне конечно будет смешно (потому что у меня есть тайное знание: любая защита измерима ценой взлома, а цена ограничена сверху стоимостью терморектального криптоанализа)

(Reply to this) (Parent) (Thread)

Говорить о доверии к кому-то, которое уже есть, можно только после аутентификации. Пока мы не знаем кто у нас на другой стороне канала, речи о доверии идти не может.

О супер-неломаемой защите речь не идет. Речь идет о МИНИМАЛЬНОМ комплексе мер, который при разумном анализе обеспечивает защиту от реалистичных угроз.

При этом цена этой защиты, естественно, не должна превосходить цену защищаемой информации.

Но цена защиты в случае TLS стремится к нулю. Поскольку реализации уже написаны и тиражирование их денег не стоит. Так что в любой операционной системе оно уже есть.

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

Либо владелец сайта предлагает пользователю активно поучастовать в установлении цепочки доверия, скачав корневой сертификат самостоятельно и проверив его контрольную сумму глазками (так делает, например, WebMoney).

Единственное, что никто не делает - это не предлагают пользователю ВЫБОР из этих двух вариантов. При дизайне X.509 как-то забыли предусмотреть такую возможность. Вот в GPG - это есть - возможность выстроить к одному и тому же ключу несколько разных цепочек доверия от разных trust anchors.

(Reply to this) (Parent) (Thread)

к искренней изустной рекламе я отношусь лояльно. с пониманием. да.

(Reply to this) (Parent)

формально я ответил не на поставленый вопрос потому что вы ответили не на поставленый вопрос. надеюсь все всё поняли -- нить разсуждений ни разу не была прервана.

(Reply to this) (Parent)