-
M27 сен 16График роста мирового объема трафика сети интернет (исследования Cisco) идет по экспоненте:
habrastorage.org
Они думают что все мы и дальше будем по экспоненте увеличивать расходы на всю эту властную паранойю начиная от 10 триллионов рублей? -
-
27 сен 16Тащемто можно вклинится в цепочку клиент-сервер, и при наличия закрытого ключа сервера, дешифровать трафик, заботливо складывать его в сторонку, потом снова зашифровывать своим ключем и отправлять на сервер ) Обяжут законодательно педоставлять закрытый ключ сервера и возможность принятия трафика покрипченного своим ключем, такоеж уже вроде было толи со скайпом толи с вотсапом )-
-
-
-
27 сен 16Совершенно верно — имитировать сервер, об этом в статье и говорится ) ключь ты генери на клиенте сколько хочешь — вторая часть клиентского ключа, которая будет зашифрована на открытом ключе сервера и передана на сервер, может быть расшифрована взломщиком, который имеет приватный ключ сервера, и в дальнейшем эта вторая расшифрованная часть, сможет быть использована для чткния сообщений пользователя )) Ну элементарно же )) Что такое то )) Место видимо такое ) С однм токо соглашусь — это не для всех случаев, это не для всех случаев, поэтому реальные злоусышленники так и будут непрочитаны, а для тотальной слежки за гражданнами — да — самое то ) Ибо процентов 80 трафика так расшифровать можно ))
-
-
-
C27 сен 16Задели за живое…
Public key infrastructure (PKI) предполагает наличие двух ключей: private (личный) и public (открытый). Всё, что зашифровано личным ключом, может быть открыто ключом открытым. Всё, что зашифровано открытым ключом, может быть открытым личным ключом (но не открытым). Личным ключом обладает только владелец (сервер). Открытый ключ доступен всем (с того же сервера). Это позволяет пользователю взять этот ключ и передать серверу информацию, которую только сервер и сможет расшифровать. Таким образом стороны могут установить защищённое соединение и обменяться временными симметричными ключами для сессии обмена информацией, которую никто со стороны не сможет прочитать.
Второй важной составляющей является подтверждение личности (сервера). Упомянутая пара ключей может быть порождена массой свободно доступного программного обеспечения. Так, некто может создать ключи, якобы приписанные к вашему банку и создать сайт, неотличимый от сайта вашего банка в расчёте, что вы придёте туда по ошибке (вам пошлют сообщение по почте о необходимости срочно проверить счёт и готовую ссылку на фальшивый сайт) и сообщите пароль вашего счёта злоумышелнникам.
Истинность ключа и его принадлежность определённому владельцу подтверждаются третьей стороной (Certificate Authorities). Имеется не такое уж большое количество таких сторон (не станем вдаваться в цепочки доверия и т.п.). У них можно получить сертификат/ключи за деньги и после их проверки того, что вы действительно тот, на чьё имя вы пытаетесь ключи получить. Для простого пользователя все эти проверки выполняются браузером автоматически. Браузер проверяет ключи, срок их действия и истинность, связываясь с третьей стороной (CA), якобы выдавшей эти ключи. Он же и предупредит пользователя, если ключи на чьё-то имя, скажем, выданы не тем, кому можно доверять (левой третьей стороной).
Третьи стороны, которым принято доверять, выбираете вы (или предустановки ваших браузеров/операционных систем, которые, разумеется, можно и поменять).
Man-in-the-middle предполагает следующую схему: некто пропускает всю информацию, которой вы обмениваетесь с нужным сервером, через свой сервер. Он устанавливает истинно защищённое соединение с нужным вам сервером как пользователь (вместо вас). Так же он создаёт новый сертификат/ключи на имя нужного вам сервера (это умеют делать даже «на лету»), с помощью которых устанавливается защищённое соединение с вами с сервера, принадлежащего «посреднику». Имеются два защищённых соединения: настоящий-сервер — MITM и MITM — ваш компьютер. Посередине вся ваша информация «посреднику» доступна. Вам будет казаться, будто вы общаетесь напрямую с нужным сервером, хотя «посдредник» будет перекачивать информацию туда-сюда между двумя защищёнными каналами, делая с ней всё, что заблагорассудится.. Ведь сгенерированные MITM ключи будут говорить, что они тому серверу и принадлежат. К слову, подобные схемы используются во многих корпоративных сетях (впрочем, соединения с банками и подобными организациями они не взламывают — так и в суд недолго загреметь).
Единственное, что сможет показать истинное положение дел, это личность того (третьей стороны), которая подтверждает истинность ключей. Ваш браузер, скорее всего, доверяет тем, кто создал ключи вашего банка, но не тем, кто создал ключи для взлома вашего соединения. Это, скорее всего, значит, что вас (поставщиков компьютеров, программного обеспечения и т.п.) обяжут добавлять эту третью сторону в список тех, кому вы, якобы, доверяете. Так что ваш браузер смолчит. Но даже тогда вы сможете проверить, кем были выданы ключи: Verisign, Thawte, Microsoft CA или ФСБ России. Вряд ли серверы, с которыми вы общаетесь, будут получать ключи от ФСБ. И, конечно, ФСБ России в имени фигурировать не будет. Это будет милая спокойно и неприметно названная (и даже, возможно, частная) компания. Хотя, уверен, отечественные серверы обяжут получать ключи там и только там.
Это так вот в двух (долгих) словах. А детали — ищите в интернете. Их там полно. И вряд ли они там пока что фальсифицированы…-
-
C27 сен 16Можно, конечно, и так сказать. Но дополнительное шифрование — это дополнительное время. Поэтому, скажем, согласовывать действия в реальном времени будет сложнее. Во-вторых, большинству заведомо будет лень пользоваться дополнителным шифрованием. Соответственно, те, кто будет таким дополнителным шифрованием пользоваться, составят отдельную группу для более пристального внимания. Наконец, огромное количество людей просто проговариваются или ошибаются. На чём и залетят.
А кроме того, когда в руках имеется огромное количество самой разнообразной информации, масса интересных вещей может быть обнаружена простыми (ну, на самом деле, не такими уж простыми) сопоставлениями и статистической обработкой.
В конечном итоге, всё сводится не к возможности или невозможности тотальной слежки, а к доверию. Я не разделяю принцип «честному человеку нечего скрывать». Человеку всегда есть, что скрывать (и, к слову, в социальных сетях можно проколоться на раз, поставив лишний «лайк» не в том месте). Вопрос в том, что и от кого.
Я, наверное, жутко крамольную мысль скажу, но я больше доверяю Google'у, чем ФСБ. :) Что не означает, будто я считаю Google средоточием мировой добродетели. :)
-
-
N27 сен 16На практике ключ сертификата служит только для обмена разовым ключом, справедливым только в рамках HTTPS сессии. Посему, даже обладая закрытым ключом надо обязательно перехватить сессионный. Т. е. другими словами, тотальная фильтрация трафика требует колоссальных ресурсов. Я уж не говорю о том, что тот, кто слил приватный ключ автоматически себя дискредитировал.
-
C27 сен 16Поясняю ещё раз: не надо перехватывать никаких сессионных ключей. «Посредник» ведёт две разные сессии, и каждая из них имеет свои ключи сессии.
Существуют технологии ведения сессии, которые позволяют определить наличие «посредника» (поскольку на нём происходит терминация протоколов SSL и TCP), но они не получили (пока?) распространения — есть там немало заморочек с прокси и прочая.
-
-
-
-
-
-
Сделано с
NoNaMe