Differences between revisions 11 and 35 (spanning 24 versions)
Revision 11 as of 2008-08-01 22:22:14
Size: 12969
Comment:
Revision 35 as of 2008-10-04 08:13:07
Size: 20293
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Надо иметь две вещи в виду. Вещь первая: если вы хотите, чтобы какая-то сетевая служба при подключении по сети спрашивала логин и пароль (пользовалась учетной записью), то убедитесь, что она шифрует данные при передаче по сети. И что это шифрование достаточно стойкое. Надо, чтобы передачу никому нельзя был расшифровать никому, кроме вас. В новом мане по iptables, есть сводная табличка сервисов, которые уязвимы в этом смысле (ftp, telnet, http, ipmap, pop передают идентификационные данные в не зашифрованном виде, basic_auth передаёт ключи в не зашифрованном виде,а потом шифрует этими ключами). От некоторых из этих служб следует отказываться. От telnet отказались совсем. От ftp с авторизацией тоже следует отказаться. Есть замечательная утилита dsniff, у которой в секции description мана, перечислены протоколы, из которых она выуживает пароли.'''''
Line 5: Line 4:
К сожалению, в ALT Linux не применяются одноразовые пароли, и поэтому рассказа о них не будет. === Проблема открытой передачи пароля ===
Line 7: Line 6:
Поэтому лектор перейдёт к возможности зашифровать сам трафик. Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и гонять пароли в чистом виде. Разумное решение при условии, что канал надёжен. Какие есть варианты в этом случае. К сожалению, лектор не очень знает ipv6, иначе бы он сослался бы на ipsec. Он замечательно реализован в ipv4, но он не работает совсем из коробки, и комплекс мер по его включению и настройке достаточно сложный, и если сделать пару ошибок, то оно либо не заработает, либо секреты утекут. Многочисленные сетевые службы используют идентификацию пользователя по имени (логину) и паролю. Однако для того, чтобы пользователь мог передать свой пароль, охранив его в секрете от третьих лиц, следует убедиться, что он шифруется при передаче по сети и что это шифрование достаточно стойкое. Необходимо достичь того, чтобы передачу никому нельзя было расшифровать --- никому, кроме сетевого сервиса, которому этот пароль и высылается. В противном случае ожидать, что где-то на пути от клиента до службы на одном из компьютеров пароль может быть "подcмотрен".
Line 9: Line 8:
Поэтому будет рассмотрим SSL. SSl --- secure socket layer, это некая прослойка между уровнями прикладным и транспортным. Есть некий аналог с уровнем представления ISO/OSI . Когда мы дошли до уровня TCP, на вход вставляется шифрователь, на выход --- дешифрователь. Мы закладываем в надёжный и зашифрованный канал. У этой штуки есть ручки на уровне прикладного протокола, чтобы приложение знало, что оно использует SSL. Собственно, это связано с тем, что у нас не исо/оси, и поэтому у нас есть https на 443 порту вместо http на 80 и так далее. С помощью утилиты stunnel можно сделать любое обычное соединение поверх SSL. Много протоколов, в частности , http, imap, pop3, xmpp могут работать поверх SLL. В документации man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности. К ним относятся ftp, telnet, http, ipmap и pop3 --- все они передают идентификационные данные в незашифрованном виде.
## В оригинале было просто basic_auth. Я не нашел подтверждания что оно так работает в HTTP.
## Обычная авторизация в протоколе http, называемая basic_auth, передаёт ключи в незашифрованном виде, а потом шифрует остальные данные этими ключами, что так же небезопасно.
От некоторых из этих небезопасных служб следует вообще отказаться, например, от telnet и от ftp с авторизацией пользователя. Есть замечательная утилита dsniff, в документации к которой ({{{man dsniff}}}) перечислены протоколы, из которых она способна "выудить" пароли.
Line 11: Line 13:
приложение ---> || SLL |||| TCP и тд. ||--->Internet--->|| TCP и тд. |||| SLL ||---> приложение ## К сожалению, в ALT Linux не применяются одноразовые пароли, и поэтому мы не станем о них рассказывать.
Line 13: Line 15:
Главное достоинство работы через ssl --- прозрачность для прикладного протокола. Мы поднимаем stunnel, и говорим приложению, что всё как было, так и есть. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), так сразу мы упираемся в то, что приложение должно знать, что есть специальный порт, по которому надо слушать(нестандартный), и внутри прикладного протокола нет специальных способов управления аутентификацией. Это всё за нас должен делать уровень SSL. И приложение обязано сделать это вместо stunnel. Есть другой способ, TLS, он уже не является никаким промежуточным, это чисто модификация прикладного уровня. Очевидно, TLS имеет гораздо больше ручек на прикладном уровне, и можно много чего, чего в SSL сделать нельзя. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. Поскольку на уровне ssl никто о разных именах не знает, и у этих хостов один ip и один ключ. На уровень TLS это всё внедрено на уровень приложения, то есть приложение решает как шифровать, каким ключем. И у протоколов поддерживающих TLS есть опция работать с TLS. И это не SSL где протокол прикладного уровня не знает как он работает с SLL или без него. Поскольку сами протоколы верхнего уровня надежным шифрованием паролей часто не занимаются, то стоит рассмотреть возможности, позволяющие зашифровать сам трафик.
Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и передавать пароли в чистом виде. Это разумное решение при условии, что канал надёжен.
Однако здесь следует напомнить, что транспортный протокол TCP не обеспечивает надежную с точки зрения безопасности доставку: передаваемые данные могут быть как подсмотрены, так и подделаны.
Line 15: Line 19:
В том же протоколе imap есть расширение: начать TLS, это команда протокола imap. С точки зрения приложения TLS --- часть прикладного протокола. Это команда уровня imap. Тоже относится к pop3, ftp и тому же xmpp. Главный недостаток TLS --- мы должны модифицировать протокол прикладного уровня. Зато с помощью TLS можно организовать ftp. В качестве надежного протокола передачи стоило бы обратить внимание на сетевой протокол IPsec (поверх которого может работать TCP), который замечательно реализован в IPv4, но он не работает "из коробки", и комплекс мер по его включению и настройке достаточно сложный, и если совершить какие-нибудь ошибки, то он либо просто не заработает, либо секретность не будет обеспечена. Поэтому из всех протоколов обеспечения безопасной передачи наиболее важно рассказать про SSL. Протокол SSL (''Secure Socket Layer'') --- это некая прослойка между прикладным и транспортным уровнями сети, обеспечивающее шифровку информации перед ее передачей протоколу TCP и дешифровку информацию, полученной от уровня протокола TCP.
Для шифрования данных SSL организует первичный безопасный обмен временными ключами, которые в дальнейшем используются как ключи шифровки и дешифровки. #Для начального обмена
Line 17: Line 22:
SSL. SSL это универсальное туннелирование, TLS --- метод модификации протокола уровня приложения. ##Есть некий аналог с уровнем представления ISO/OSI.В понятиях уровня протокола TCP, на вход подается шифрователь, на выход --- дешифрователь, при этом используемый нами канал надежно зашифрован.
У данного слоя есть выход на прикладной уровень, чтобы приложение знало, что оно использует SSL.
##Собственно, это связано с тем, что мы здесь не используем ISO/OSI, и
Line 19: Line 26:
Как вообще всё это устроено: для того, чтобы организовать вот этот метод шифрования, используется так называемое асимметричное шифрование. Симметричное шифрование --- когда для расшифровки используется тот же ключ, что и для шифровки. Для асимметричного шифрования используется два ключа --- открытый и закрытый. С помощью любого из них можно расшифровать, то что зашифровано с помощью другого ключа. Для того, чтобы кто-то мог расшифровать данные, необходимо ему отдать открытый ключ, и он будет убеждён, что зашифровали их вы (если ваш закрытый ключ не утёк). Это называется электронная подпись. Если вы шифровать открытым ключом, то расшифровать их можно только закрытым ключом. И это уже настоящее шифрование. В чём главное достоинство асимметричного шифрования ---- вероятность утечки закрытого ключа довольно низкая, так как этот ключ нигде не фигурирует в акте передачи. {{attachment:../ssl01.png}}
Line 21: Line 28:
Недостаток главный асимметричного метода --- вы должны иметь подтвержденные открытые ключи всех абонентов. Если вы не знаете, что это их ключи, то возможна следующая ситуация: вы передаёте данные, шифруете их каким-то ключём, но он не тот, который от того кому вы передаете, а тот, который вам подсунул человек сидящий где-то между вами. Человек в середине расшифровывает данные, перешифровывает их и передаёт дальше. Но такой человек должен перехватывать все пакеты между вами двоими. Но таких много. Есть маршрутизатор, а за ним еще маршрутизатор, и дальше тоже. Поскольку SSL не имеет своего набора портов, то разные номера портов TCP применяются для того, чтобы различать обычную службу и такую же службу, использующую SSL. Напрмер, стандартный порт сервера протола HTTP --- 80, а протокола HTTPS (HTTP поверх SSL) --- 443. С помощью утилиты stunnel можно сделать любое "обычное" соединение использующим SSL, в частности, протоколы HTTP, IMAP, POP3, XMPP могут работать поверх него.
Line 23: Line 30:
 ||компьютер Алисы|| ||компьютер Эвы (злоумышленник)|| 1. открытый ключ Боба ||компьютер Боба||
 || || 2. открытый ключ Эвы (выданный за ключ Боба) || || || ||
 || || 3. данные зашифрованные ключом Эвы || || || ||
 || || || || 4. теже данные зашифрованные ключом Боба || ||
Главное достоинство работы через SSL --- прозрачность с точки зрения вышестоящего прикладного протокола. После запуска утилиты stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток SSL --- как только эта схема перестаёт работать (это имеет место быть например в случае протокола FTP), то сразу возникают проблемы: во-первых, клиентское приложение должно знать, что есть специальный нестандартный порт, по которому надо слушать, и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel.
Line 28: Line 32:
Кроме протокола SSL, есть близкий способ обеспечения безопасности --- подобный протоколу SSL протокол TLS. TSL, строго говоря, не является протокола, не являющийся отдельным протоколом --- это модификация какого-либо протокола прикладного уровня. Соответственно, на прикладном уровне возможности TLS гораздо шире, чем у SSL. Например, с точки зрения SSL все веб-сайты на одном IP-адресе являются идентичными, поэтому протокол HTTPS может корректным образом защищать только один веб-сайт на одном IP-адресе.
Поскольку на уровне SSL никто о разных именах доменов не знает (это адреса протокола HTTP), то у этих хостов один и тот же IP-адрес и ключ SSL. В TLS это вынесено на уровень приложения, то есть уже приложение решает, как шифровать и каким ключом. В отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет.
##При использовании HTTP вместе с TLS эту проблему можно было бы обойти.
К примеру, в протоколе IMAP есть расширение, позволяющее включить TLS как команду самого протокола. С точки зрения приложения TLS --- часть прикладного протокола, команда уровня протокола IMAP. Так же дела обстоят и в случае с протоколами POP3, FTP и XMPP. Главный недостаток TLS --- необходимость модификации протокола прикладного уровня, но зато с его помощью можно защитить использование FTP, что невозможно при применении SSL.
Line 29: Line 37:
Есть два варианта: вы должны действительно убедиться в том, что ключ действительно тот самый. Подводя итог, можно сказать, что SSL --- это универсальное туннелирование, а TLS --- метод модификации протокола уровня приложения.
Line 31: Line 39:
Другой способ состоит в том, что этот открытый ключ попадает к вам не просто так, а подписанный с помощью какого-нибудь из открытых ключей, которые у вас уже есть. В случае GPG вы подписываете ключи людей, которым доверяете. В случае web-сайтов есть фирмы, бизнес которых состоит в подписывании ключей. Проблема состоит в трёх вещах:
 * Если хотите подписать ключ, то надо заплатить деньги
''''' * Существуют технологии, достаточно простые, которые ровно этим и занимаются --- подключают корневой сертификат, с помощью которого подписаны на всё остальные '''''
 * Третья проблема в том, что вы не можете знать, подписан сайт или нет.
=== Организация шифрования передаваемых данных ===
Line 36: Line 41:
Допустим, нет человека в середине. Тогда у вас есть достаточно неплохая гарантия , что трафик защищён. Так как закрытый ключ есть только у вашего собеседника, если он не утек. При этом важно чтобы его не было только при первом подключении, так как вы запомните открытый ключ и если он появится потом то вы поймете что он там. Для шифровки информации в SSL используется симметричное шифрование: для расшифровки используется тот же ключ, что и для шифровки. Для того, чтобы обменяться этим ключом, который является временным, стороны используют асимметричное шифрование при обмене служебной информацией.
## Для того, чтобы организовать безопасный метод шифрования, используется так называемое асимметричное шифрование, с помощью которого стороны производят первоначальный обмен служебной информацией. , а
Line 38: Line 44:
При асимметричном шифровании используются два ключа --- открытый и закрытый. С помощью любого из них можно расшифровать то, что зашифровано с помощью другого ключа. Для того, чтобы кто-то мог расшифровать данные, зашифрованные вашим закрытым ключом, необходимо передать ему открытый ключ. В случае успеха расшифровки с использованием закрытого ключа будет знать, что зашифровали их именно вы, если, конечно, ваш закрытый ключ надежно скрыт. Для проверки успешности используется дешифрованная контрольная сумма, которая была приложена к переданным данным. Если дешифрованная контрольная сумма совпадает с контрольной суммой от дешифрованных данных, то расшифровка прошла успешно. Описанный способ называется электронной подписью.
Line 39: Line 46:
Шифровка открытым ключом так же расшифровывается только с помощью закрытого, при это подобрать к открытому ключу закрытый чрезвычайно трудно. Таким образом, асимметричное шифрование позволяет безопасно передать информацию, используя для шифровки открытый ключ, а в роли этой информации может выступать временный ключ для симметричного шифрования.

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

Главный недостаток асимметричного метода --- каждой стороне необходимо обладать подтвержденными открытыми ключами всех других сторон. Если нет уверенности, что это именно их ключи, то возможна следующая ситуация: вы передаёте данные, шифруя их каким-то ключом, но этот ключ принадлежит не вашему адресату, а человеку, подсунувшему его вам на пути к конечной точке. Этот человек в середине (англ. ''man-in-the middle'') расшифровывает данные своим закрытым ключом, перешифровывает их с помощью открытого ключа вашего адресата, и передаёт дальше. Такой человек должен перехватывать все пакеты, проходящие между вами. Мест перехвата потенциально много, так как пакеты, например, зачастую проходят через несколько маршрутизаторов на своём пути, и каждый администратор такого маршрутизатора может провести такую атаку.

{{attachment:../ssl02_attack.png}}

Есть два варианта решения этой проблемы. Первый --- вы должны как-то действительно убедиться в том, что это открытый ключ вашего адресата. Другой способ состоит в том, что этот открытый ключ попадает к вам не просто так, а подписанный с помощью какого-нибудь из открытых ключей, которые у вас уже есть и которому вы доверяете (ключ "цифрового нотариуса"). На практике используются оба подхода: в случае GPG вы подписываете ключи людей, которым доверяете, а в случае web-сайтов есть фирмы, бизнес которых состоит в подписывании ключей сервера, использующего HTTPS. Следует отметить, что метод с доверенным нотариусом не дает 100% гарантию, но является достаточно безопасным для некритичных приложений.

## Этот метод имеет свои проблемы Это не дает 100% гарантию: у адресата может не быть желания тратить деньги на подпись своего ключа доверенной стороной,

### Недостатки 2 и 3 я не смог понять!
## У этого способа есть следующие недостатки.
## * Если вы хотите подписать свой открытый ключ ключом доверенной стороной, то надо заплатить деньги этому "цифровому нотариусу".
## * Существуют технологии, которые ровно этим и занимаются --- подключают корневой сертификат, с помощью которого подписаны всё остальные. Например пришел системный администратор и подписал все известные сертификаты этим сертификатом.
## * Третья проблема в том, что вы не можете знать, подписан сайт или нет.

Допустим, что стороны решили проблему определения аутентичности открытых ключей своих партнеров, а закрытые ключи надежно хранятся. В этом случае SSL дает довольно высокую гарантию, что трафик защищён, так как закрытый ключ есть только у вашего собеседника. При этом важно чтобы его не было только при первом подключении, так как затем можно запомнить открытый ключ абонента. В случае, если абонент стал предъявлять другой закрытый ключ, то об этом следует немедленно уведомить пользователя.
Line 46: Line 73:
|| 0 || 1 || 1 || 1 || || 1 || SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko || || || || 90 || 1 || 1 || 1 || || 1 || SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko || || ||

Безопасность: сетевая секретность

Проблема открытой передачи пароля

Многочисленные сетевые службы используют идентификацию пользователя по имени (логину) и паролю. Однако для того, чтобы пользователь мог передать свой пароль, охранив его в секрете от третьих лиц, следует убедиться, что он шифруется при передаче по сети и что это шифрование достаточно стойкое. Необходимо достичь того, чтобы передачу никому нельзя было расшифровать --- никому, кроме сетевого сервиса, которому этот пароль и высылается. В противном случае ожидать, что где-то на пути от клиента до службы на одном из компьютеров пароль может быть "подcмотрен".

В документации man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности. К ним относятся ftp, telnet, http, ipmap и pop3 --- все они передают идентификационные данные в незашифрованном виде.

От некоторых из этих небезопасных служб следует вообще отказаться, например, от telnet и от ftp с авторизацией пользователя. Есть замечательная утилита dsniff, в документации к которой (man dsniff) перечислены протоколы, из которых она способна "выудить" пароли.

Поскольку сами протоколы верхнего уровня надежным шифрованием паролей часто не занимаются, то стоит рассмотреть возможности, позволяющие зашифровать сам трафик. Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и передавать пароли в чистом виде. Это разумное решение при условии, что канал надёжен. Однако здесь следует напомнить, что транспортный протокол TCP не обеспечивает надежную с точки зрения безопасности доставку: передаваемые данные могут быть как подсмотрены, так и подделаны.

В качестве надежного протокола передачи стоило бы обратить внимание на сетевой протокол IPsec (поверх которого может работать TCP), который замечательно реализован в IPv4, но он не работает "из коробки", и комплекс мер по его включению и настройке достаточно сложный, и если совершить какие-нибудь ошибки, то он либо просто не заработает, либо секретность не будет обеспечена. Поэтому из всех протоколов обеспечения безопасной передачи наиболее важно рассказать про SSL. Протокол SSL (Secure Socket Layer) --- это некая прослойка между прикладным и транспортным уровнями сети, обеспечивающее шифровку информации перед ее передачей протоколу TCP и дешифровку информацию, полученной от уровня протокола TCP. Для шифрования данных SSL организует первичный безопасный обмен временными ключами, которые в дальнейшем используются как ключи шифровки и дешифровки. #Для начального обмена

У данного слоя есть выход на прикладной уровень, чтобы приложение знало, что оно использует SSL.

../ssl01.png

Поскольку SSL не имеет своего набора портов, то разные номера портов TCP применяются для того, чтобы различать обычную службу и такую же службу, использующую SSL. Напрмер, стандартный порт сервера протола HTTP --- 80, а протокола HTTPS (HTTP поверх SSL) --- 443. С помощью утилиты stunnel можно сделать любое "обычное" соединение использующим SSL, в частности, протоколы HTTP, IMAP, POP3, XMPP могут работать поверх него.

Главное достоинство работы через SSL --- прозрачность с точки зрения вышестоящего прикладного протокола. После запуска утилиты stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток SSL --- как только эта схема перестаёт работать (это имеет место быть например в случае протокола FTP), то сразу возникают проблемы: во-первых, клиентское приложение должно знать, что есть специальный нестандартный порт, по которому надо слушать, и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel.

Кроме протокола SSL, есть близкий способ обеспечения безопасности --- подобный протоколу SSL протокол TLS. TSL, строго говоря, не является протокола, не являющийся отдельным протоколом --- это модификация какого-либо протокола прикладного уровня. Соответственно, на прикладном уровне возможности TLS гораздо шире, чем у SSL. Например, с точки зрения SSL все веб-сайты на одном IP-адресе являются идентичными, поэтому протокол HTTPS может корректным образом защищать только один веб-сайт на одном IP-адресе. Поскольку на уровне SSL никто о разных именах доменов не знает (это адреса протокола HTTP), то у этих хостов один и тот же IP-адрес и ключ SSL. В TLS это вынесено на уровень приложения, то есть уже приложение решает, как шифровать и каким ключом. В отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет.

К примеру, в протоколе IMAP есть расширение, позволяющее включить TLS как команду самого протокола. С точки зрения приложения TLS --- часть прикладного протокола, команда уровня протокола IMAP. Так же дела обстоят и в случае с протоколами POP3, FTP и XMPP. Главный недостаток TLS --- необходимость модификации протокола прикладного уровня, но зато с его помощью можно защитить использование FTP, что невозможно при применении SSL.

Подводя итог, можно сказать, что SSL --- это универсальное туннелирование, а TLS --- метод модификации протокола уровня приложения.

Организация шифрования передаваемых данных

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

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

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

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

Главный недостаток асимметричного метода --- каждой стороне необходимо обладать подтвержденными открытыми ключами всех других сторон. Если нет уверенности, что это именно их ключи, то возможна следующая ситуация: вы передаёте данные, шифруя их каким-то ключом, но этот ключ принадлежит не вашему адресату, а человеку, подсунувшему его вам на пути к конечной точке. Этот человек в середине (англ. man-in-the middle) расшифровывает данные своим закрытым ключом, перешифровывает их с помощью открытого ключа вашего адресата, и передаёт дальше. Такой человек должен перехватывать все пакеты, проходящие между вами. Мест перехвата потенциально много, так как пакеты, например, зачастую проходят через несколько маршрутизаторов на своём пути, и каждый администратор такого маршрутизатора может провести такую атаку.

../ssl02_attack.png

Есть два варианта решения этой проблемы. Первый --- вы должны как-то действительно убедиться в том, что это открытый ключ вашего адресата. Другой способ состоит в том, что этот открытый ключ попадает к вам не просто так, а подписанный с помощью какого-нибудь из открытых ключей, которые у вас уже есть и которому вы доверяете (ключ "цифрового нотариуса"). На практике используются оба подхода: в случае GPG вы подписываете ключи людей, которым доверяете, а в случае web-сайтов есть фирмы, бизнес которых состоит в подписывании ключей сервера, использующего HTTPS. Следует отметить, что метод с доверенным нотариусом не дает 100% гарантию, но является достаточно безопасным для некритичных приложений.

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

90

1

1

1

1

SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/04NetworkSecurity (last edited 2008-10-04 08:13:07 by VsevolodKrishchenko)