Kitabı oku: «Защита от хакеров корпоративных сетей», sayfa 2
Правовое обеспечение хакинга
Автор – не юрист: грубо говоря, это означает следующее: «Он не может дать вам никакого уместного юридического совета, а читатель не обязан ему следовать. Если читатель что-то сделает, то не подумайте, что его не предупреждали о последствиях. Но автор попытается заставить читателя прислушаться к своему мнению тем или иным способом».
В этой книге читатель узнает о методах, которые в случае неправильного их применения приведут его к нарушению законодательства и связанным с этим последствиям. Слова автора подобны словам инструктора по вождению автомобиля: «Я собираюсь научить вас ездить на автомобиле, но если вы водите плохо, то можете кого-нибудь сбить». В обоих случаях вам придется отвечать за причиненный ущерб.
Автор использует очень простое правило, заключающееся в ответе на вопрос: «У меня есть разрешение сделать это на этом компьютере?» Если ответ – нет, то не делайте этого. Ваши действия принесут вред и почти наверняка будут противозаконны. Но если ответ не столь очевиден, то, возможно, есть исключения, ну и т. д. Например, в большинстве мест (нет, не в вашей организации, по этому поводу проконсультируйтесь у юриста) сканирование порта разрешено. Хотя это рассматривается как предпосылка к незаконному проникновению в систему со злым умыслом, но это законно – кроме тех случаев, когда сканирование портов запрещено.
Самый простой способ обезопасить себя заключается в хакинге своей собственной сети (автор подразумевает домашнюю сеть читателя, а не сеть на работе, потому что иначе у вас могут быть неприятности). Вы хотите освоить тонкости сложной программы, работающей на платформе Sun Sparc? Идите и купите старый Sparc за 100$. Вы хотите заняться хакерством на многомиллионной универсальной ЭВМ? Хорошо, но, вероятно, вас постигнет неудача.
Можно было бы склониться к предположению о полной безопасности хакерских действий на собственном оборудовании. Но, строго говоря, это не так в случае действий, направленных на вскрытие программного обеспечения. Много людей думают также, то есть если я купил копию программы, то я имею естественное право делать с ней все, что я захочу на своем собственном компьютере. Право интеллектуальной собственности так не считает. В Соединенных Штатах, а также в соответствии с международным соглашением в ряде других стран обход средств недопущения копирования материалов, защищенных авторским правом, противозаконен. Это – часть акта DMCA. Формально противозаконно заниматься этим даже у себя дома, но если вы все-таки сделали это и пользуетесь результатами своих действий только сами, то кажется маловероятным, что у вас появятся проблемы. Но при попытке поделиться полученными результатами с другими людьми вам следует проявить осторожность.
Предупреждая о безопасности, автор хотел бы рассказать о чрезвычайной истории, произошедшей в результате нарушения новых законов. Это касается российской компании – разработчика программного обеспечения ElcomSoft Co. Ltd., специализирующейся на вскрытии паролей, снятии защиты от копирования и восстановлении поврежденных файлов. Имейте в виду, что на тот момент времени в России не было никакого закона против восстановления алгоритма работы программы по ее коду. Один из программистов компании ElcomSoft Co. Ltd., Дмитрий Скляров, прибыл на конференцию DEF CON 9 в Лас-Вегасе и сделал доклад относительно формата электронных документов eBook компании Adobe. Формат содержит некоторые смехотворные попытки безопасности. На следующий день Дмитрий был арестован и обвинен в «распространении изделия, предназначенного для обхода средств защиты авторского права». При этом упоминалась программа его компании, которая конвертировала формат eBook документа в стандартный формат Adobe Acrobat.PDF файлов. Выполнение подобного конвертирования покупателем одного из этих средств eBooks для себя юридически законно, поскольку пользователю разрешается делать резервные копии.
Короче говоря, Дмитрий был арестован 17 июля 2001 года и отпущен домой только 31 декабря 2001 года. Компания Adobe отозвала свою жалобу из-за повсеместных протестов, но американское правительство отказалось снять обвинения. Поскольку вопрос не закрыт до сих пор, Дмитрий все еще полностью не освобожден от ответственности.
Относительно сказанного хочется добавить, что используемые им методы для разгадывания системы безопасности изделия были относительно просты. Мы осветим подобные методы декодирования в главе 6.
Пожалуйста, будьте осторожны с информацией, которая изложена в книге.
Конспект
В этой книге авторы собираются рассказать о подробностях поиска брешей в системе безопасности и их использования на основании таких методов, как анализ пакетов, пиратское подсоединение, имитация соединения для получения доступа, схем раскрытия шифров, уклонение от систем обнаружения атак и даже хакинг аппаратных средств ЭВМ. Это не книга о проектировании безопасности, политике, архитектуре, управлении рисками или планировании. Если читатель так думает, то его ввели в заблуждение.
Все обнаруженные бреши в системе защиты должны быть преданы огласке. Публичное сообщение об ошибках приносит пользу каждому, включая вас самих, поскольку это может способствовать вашему признанию.
Вы должны научиться хакерским методам, для того чтобы знать, как защитить вашу сеть или сеть вашего работодателя. Вы должны это знать, потому что это интересно. Если вы не соглашаетесь с чем-либо, о чем говорится в этой главе или книге, то это хорошо! Первое, что хакеры должны уметь делать, – это самостоятельно думать. Нет никаких причин для слепой веры в изложенный авторами книги материал. Если у вас есть замечания к книге, то зайдите на Web-сайт www.syngress.com/solutions, найдите адрес электронной почты авторов и пошлите им письмо. Возможно, ваше опровержение будет помещено на сайт.
Часто задаваемые вопросы
Вопрос: Могу ли я назвать себя хакером?
Ответ: Существует два ответа на этот вопрос. Первый, созвучный мыслям многих: хочешь быть хакером – будь им. Второй: если вы называете себя хакером, то будьте готовы к широкому диапазону оценок вследствие большого количества определений слова «хакер» и их двусмысленности. Одни будут думать, что вы только что сказали им, что вы – преступник. Другой, кто сам себя считает хакером, осмеет вас, если вы будет заподозрены в недостаточной квалификации. Некоторые не будут знать, что и подумать, но затем попросят вас о хакерской услуге для себя… Автор советует вам сначала приобрести необходимые навыки и практику. Лучше всего, если кто-либо другой назовет вас хакером.
Вопрос: Законно ли написание вирусов, Троянских коней и червей?
Ответ: Фактически (в большинстве случаев) да. Пока. Это утверждение заслуживает серьезного разъяснения. Существует ряд программистов, которые открыто пишут вирусы и делятся результатами своей работы. До сих пор они, кажется, никому не мешали. Однако если хотя бы часть написанного ими кода выйдет из-под контроля и привлечет к себе внимание, то дело примет серьезный оборот. Если вы пишете программы вирусов, будьте осторожны, чтобы не потерять контроль над ними. Вы можете захотеть ограничить их способность к распространению, проявляя необходимую предосторожность. В этой связи задумайтесь, как вы будете выглядеть, если кто-то доработает ваш вирус и выпустит его на волю. Также обратите внимание на то, не противоречит ли отправление по почте подобного кода правилам, установленным вашим Интернет-провайдером, особенно если вы – учащийся. Ваши действия могут и не противоречить установленным правилам, но могут легко привести к разрыву соединения с вашим Интернет-провайдером, получения предупреждения или лишения вас прав пользователя.
Вопрос: Несете ли вы ответственность за хакинг систем?
Ответ: Вообще, если вы санкционированный (авторизованный) пользователь, нет. Пожалуйста, примите во внимание если. Когда есть сомнения, получите письменное разрешение от юридического лица – владельца компьютерной системы, например школы или работодателя. Множество людей, отвечающих за безопасность компьютерных систем, регулярно тестируют их хакерскими методами. Дополнительные сведения и примеры вы сможете найти по адресу www.lightlink.com/spacenka/fors.
Глава 2
Законы безопасности
В этой главе обсуждаются следующие темы:
• Обзор законов безопасности
• Закон 1. Невозможно обеспечить безопасность клиентской части
• Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации
• Закон 3. От кода злоумышленника нельзя защититься на 100 %
• Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза
• Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника
• Закон 6. От любой системы обнаружения атак можно уклониться
• Закон 7. Тайна криптографических алгоритмов не гарантируется
• Закон 8. Без ключа у вас не шифрование, а кодирование
• Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем
• Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
• Закон 11. Безопасность нельзя обеспечить покровом тайны
· Резюме
· Конспект
· Часто задаваемые вопросы
Введение
Для обнаружения уязвимостей в безопасности компьютерных систем используется ряд экспресс-методов (shortcuts). Один из них основан на мысленном составлении списка требований, которым должна удовлетворять исследуемая система. Каждое требование из этого списка несет информацию о безопасности системы и может быть проанализировано. Выявление при подобном анализе специфических особенностей в работе системы позволяет подозревать ее в ненадежности еще до начала детального тестирования.
Этот список назван законами безопасности. Причем под законами понимаются руководящие принципы, которые должны использоваться для того, чтобы не упустить из виду вопросы безопасности при анализе или проектировании системы. Система в этом случае может состоять как из единственной программы, так и полномасштабной сети компьютеров, включая сетевые экраны (firewalls), фильтрующие шлюзы (filtering gateways) и вирусные сканеры. Не важно, в чьих интересах исследуется система: в интересах защиты или нападения. Важно понять, где у нее уязвимости.
Законы безопасности помогают распознать слабые места и сосредоточить на них внимание. Эта глава познакомит читателя с законами безопасности. Большая часть остальной части книги посвящена подробному рассмотрению методов использования уязвимостей, выявленных при помощи законов безопасности.
Если читатель достаточно квалифицирован в области информационной безопасности, то он может пропустить эту главу. Хотя авторы рекомендуют, по крайней мере, бегло просмотреть ее, чтобы удостовериться в том, что читатель знает эти законы и согласен с ними.
Обзор законов безопасности
Начав с обзора законов, авторы детально обсудят их по ходу книги. При обсуждении будет рассмотрено содержание законов, способы их применения для поиска слабых мест, а также разрешаемые с их помощью вопросы. В список входят следующие законы безопасности.
1. Невозможно обеспечить безопасность клиентской части.
2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации.
3. От кода злоумышленника нельзя защититься на 100 %.
4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза.
5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника.
6. От любой системы обнаружения атак можно уклониться.
7. Тайна криптографических алгоритмов не гарантируется.
8. Шифрование без ключа является кодированием.
9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем.
10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности.
11. Безопасность нельзя обеспечить покровом тайны.
Известны различные точки зрения на законы безопасности. В этой главе авторы решили обратить особое внимание на теоретические основы безопасности систем или, другими словами, на строгие формулировки законов. (По крайней мере, настолько, насколько это возможно. Такой сложный предмет исследования, как безопасность систем, плохо поддается строгому математическому описанию.) Существует и иной способ построения списка законов: в список включается не то, что является возможным, а то, что применяется на практике. Естественно, что отчасти эти два принципа перекрываются: если что-то невозможно, то это нереализуемо на практике. Скотт Кулп (Scott Culp), менеджер консультационного центра по вопросам безопасности компании Микрософт (Microsoft's Security Response Center Manager), сформулировал десять законов на основе своего опыта и опыта клиентов. Он назвал этот список как «Десять абсолютных законов безопасности». К ним относятся следующие:
1. Закон № 1: Если злоумышленник смог убедить вас запустить его программу на вашем компьютере, то компьютер уже не ваш.
2. Закон № 2: Если злоумышленник может изменить операционную систему на вашем компьютере, то компьютер уже не ваш.
3. Закон № 3: Если злоумышленник имеет неограниченный физический доступ к вашему компьютеру, то компьютер уже не ваш.
4. Закон № 4: Если вы позволяете злоумышленнику загружать программы на ваш Web-сайт, то Web-сайт уже не ваш.
5. Закон № 5: Слабые пароли сводят на нет хорошую систему безопасности.
6. Закон № 6: Компьютерная система защищена настолько, насколько заслуживает доверия обслуживающий ее администратор.
7. Закон № 7: Безопасность зашифрованных данных определяется безопасностью ключа их расшифровки.
8. Закон № 8: Устаревший сканер вирусов ненамного лучше никакого.
9. Закон № 9: Абсолютная анонимность практически недостижима ни в реальной жизни, ни в Web-пространстве.
10. Закон № 10: Технология – не панацея.
Полный список (с разъяснениями смысла каждого правила) может быть найден на сайте www.microsoft.com/technet/columns/security/10imlaws.asp. Этот список приведен для иллюстрации подхода к теме с точки зрения администратора безопасности. По большей части читатель найдет, что приведенные законы – обратная сторона исследуемых авторами законов безопасности.
Перед применением законов для обнаружения потенциальных проблем следует сформулировать их рабочее определение. В следующих разделах рассмотрены законы безопасности и их значение для обеспечения безопасности вычислительных сетей и систем.
Закон 1. Невозможно обеспечить безопасность клиентской части
В первом законе безопасности следует определить пару понятий. Что именно имеется в виду, когда говорят о клиентской части (client-side)? Рассматривая сетевое (клиент-серверное) окружение, авторы определили бы клиента как приложение, которое инициирует запрос на обслуживание или соединение, а сервер – как приложение, которое или ожидает запрос на обслуживание и установление связи, или способно выполнять эти запросы. Термин «клиентская часть» применительно к вычислительным сетям используется для обозначения компьютера, за которым работает пользователь и при помощи которого пользователь (или злоумышленник) получает контроль над системой. В сформулированном законе отличие в использовании термина «клиентская часть» заключается в том, что он применяется без связи с какой-либо сетью или сервером, то есть авторы говорят о безопасности клиентской части даже в случае одного компьютера с частью программного обеспечения на дискете. Главное состоит в том, что подчеркивается мысль о возможности получения контроля пользователей (или злоумышленников) над собственными компьютерами и их способности сделать с ними все, что они захотят.
После определения термина клиентской части выясним, что понимается под ее безопасностью. Безопасность клиентской части – это некоторый механизм безопасности, работающий исключительно у клиента. В одних случаях его реализация допускает привлечение сервера, как в традиционной архитектуре клиент-сервер. В других – это может быть частью программного обеспечения, которое выполняется на компьютере клиента в интересах предотвращения действий пользователя, нежелательных с точки зрения безопасности.
Основная проблема безопасности клиентской части состоит в том, что человек, физически сидящий за клиентским компьютером, имеет абсолютный контроль над ним. Закон № 3 Скотта Кулпа (Scott Culp) иллюстрирует это более упрощенным способом: Если у злоумышленника неограниченный физический доступ к вашему компьютеру, то компьютер уже не ваш. Для полного понимания тонких моментов этого вопроса требуются дополнительные разъяснения. Вы не сможете разработать механизм безопасности клиентской части, который пользователи не смогли бы, если они этого захотят, преодолеть. В лучшем случае вы сможете усложнить им эту задачу. Проблема состоит в том, что поскольку большинство программного обеспечения и аппаратных средств ЭВМ – результат массового производства, то один профессионал, разгадавший, как обойти механизм безопасности, может, вообще говоря, рассказать кому-либо об этом или часто пользоваться результатами своего решения. Посмотрите на пакет программ, в котором предусмотрено ограничение его использования тем или иным способом. Какие инструменты нападающий имеет в его или ее распоряжении? Он или она могут использовать отладчики, дизассемблеры, редакторы шестнадцатеричного кода, модификацию операционной системы и системы мониторинга, не говоря уже о неограниченных копиях программного обеспечения.
А если программное обеспечение обнаружит, что оно было модифицировано? Тогда удалите часть кода, которая обнаруживает модификацию. Что, если программное обеспечение скрывает информацию где-нибудь в компьютере? Контролирующие механизмы немедленно найдут это изменение. Имеется ли защита аппаратных средств ЭВМ от преступного использования? Нет. Если нарушитель может потратить неограниченное время и ресурсы, атакуя аппаратные средства вашего компьютера, то любое средство защиты в конечном счете признает себя побежденным. Это особенно справедливо для аппаратуры массового производства. Поэтому в общем случае следует полагать, что безопасность клиентской части невозможно обеспечить.
Примечание
Этот закон используется в главах 5 и 14.
Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации
Для человека, знакомого с криптографией, этот закон может показаться очевидным. Тем не менее закон является уникальным вызовом защите данных и процедур обмена информацией. Основная проблема обмена зашифрованными данными заключается в надежности ключей сеансов обмена. Обмен ключами между клиентом и сервером обязателен и происходит до обмена данными (для дополнительной информации см. главу 6).
Для иллюстрации этого давайте рассмотрим процесс установления зашифрованной связи через Интернет. Пусть как на вашем компьютере, как и на компьютере, с которым вы, как предполагается, соединяетесь, установлена ныне модная программа CryptoX. Вы вводите известный вам IP-адрес другого компьютера и ударяете на клавишу Connect (установить соединение). Программное обеспечение сообщает вам об установке соединения и обмене ключами. Теперь вам доступна надежная связь с 1024-битным шифрованием. Следует ли вам верить этому? Да, следует. Ведь за простым интерфейсом работы этой программы скрывается сложная криптоинфраструктура, обеспечивающая описанный процесс соединения (позднее в этой главе будет объяснено, что это означает). К сожалению, похитить IP-связь не только не невозможно, но даже не слишком трудно (см. главу 11).
Проблема состоит в том, как узнать, с каким компьютером вы обменялись ключами. Вы могли установить соединение именно с тем компьютером, с которым вы и хотели осуществить обмен, так и со злоумышленником, ожидающим ваших действий по установке соединения, для того чтобы попытаться подменить IP-адрес компьютера, с которым вы соединяетесь, на свой. Единственный способ удостовериться в факте соединения с требуемым компьютером состоит в наличии на обоих компьютерах порции информации, которая позволила бы удостовериться в идентичности друг друга. Как это осуществить? Сразу приходит на ум пара методов. Во-первых, можно воспользоваться открытыми ключами, распространяемыми сертификационными центрами в Интернете. Во-вторых, можно использовать разделяемый секретный ключ или средства аутентификации протокола защищенных сокетов SSL, гарантирующего безопасную передачу данных по сети в результате комбинирования криптографической системы с открытым ключом и блочного шифрования данных. Конечно, все перечисленное является разделяемыми порциями информации, необходимой для проверки отправителя информации.
Отсюда следует необходимость решения задачи управления ключами, поэтому исследуем некоторые аспекты этого процесса, ответив на следующие вопросы. Как переслать ключи туда, где они необходимы? Защищен ли маршрут распространения ключей от злоумышленника, готового к атаке типа «злоумышленник посередине» (man-in-the-middle – MITM)? Какие затраты ресурсов необходимы и насколько оправдано их использование по отношению к ценности защищаемой информации? Участвует ли доверенное лицо в обмене ключей? Может ли оно быть атаковано? Какие методы используются для обмена ключей и насколько они уязвимы?
Давайте рассмотрим некоторые способы распределения и обмена ключами. После обмена ключами шифрования нужна дополнительная информация, чтобы удостовериться в том, что обмен состоялся именно с тем, с кем нужно, и ключи не стали добычей злоумышленника в результате его успешной атаки типа MITM. Доказать это трудно потому, что доказательство сводится к рассмотрению всевозможных протоколов обмена ключами, которые когда-либо могли быть изобретены, и поиску уязвимости каждого из них к атакам типа MITM.
Как и в случае большинства нападений, может быть, разумнее всего положиться на то, что люди, как правило, не следуют хорошим советам по обеспечению безопасности, или на то, что результат шифрования обычно менее криптостоек, чем примененный алгоритм шифрования.
Давайте проанализируем часть документации, посвященной обмену общедоступными ключами, для того чтобы получить представление о реализации одного из способов их обмена. Подробнее познакомиться с документацией можно в Интернете: www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt4/scencryp.htm#xtocid211509.
Это – документ компании Cisco Systems, Inc., который описывает, помимо всего прочего, как обмениваться ключами стандарта цифровой подписи DSS. DSS – стандарт открытых/секретных ключей (public/private key standard), который Cisco использует для аутентификации одноранговых маршрутизаторов. Шифрование с использованием открытых/секретных ключей обычно считается слишком медленным для шифрования в реальном масштабе времени, поэтому для обмена информацией применяются симметричные сеансовые криптографические ключи (типа ключей DES или 3DES алгоритмов). DES – американский правительственный стандарт алгоритма шифрования, принятый в 70-х годах. 3DES – улучшенная версия алгоритма DES, связывающая вместе три отдельных выполнения алгоритма DES для двукратного или трехкратного, в зависимости от реализации, повышения криптостойкости алгоритма. Для успешной работы по описываемой схеме у каждого маршрутизатора должен быть правильный открытый ключ другого маршрутизатора. Если в случае атаки типа MITM злоумышленнику удастся обмануть каждый маршрутизатор, подсунув свой ключ вместо открытого ключа другого маршрутизатора, то сначала он сможет узнать все ключи сессии, а затем контролировать любой трафик сети.
Cisco признает это и идет дальше, заявляя, что вы «должны устно проверить» открытые ключи. В документации описан сценарий, по которому два администратора маршрутизатора, имея безопасную связь с маршрутизатором (возможно, при помощи терминала, физически подключенного к консоли), связываются друг с другом по телефону. Во время обмена ключей они должны сообщить друг другу по телефону полученный ключ. Безопасность этого сценария основывается на предположении, что, во-первых, эти два администратора узнают голос друг друга, а во-вторых, трудно фальсифицировать чей-либо голос.
Если администраторы хорошо знают друг друга и каждый из них сможет получить ответы на свои вопросы, если они оба зарегистрированы на консоли маршрутизаторов и маршрутизаторы не скомпрометированы, если нет ошибок в алгоритме шифрования, то эта процедура безопасна.
Никто не собирается учить вас подражанию чьему-либо голосу или как захватывать коммутаторы телефонных компаний для неправильного соединения незнакомых друг с другом администраторов. В первую очередь критически разберем предположение о достижении безопасности при использовании двух администраторов и рассмотренного механизма безопасности.
Есть подозрение, что вопреки документации компании Cisco большинство обменов ключами между маршрутизаторами этой компании осуществляются одним администратором с использованием двух Telnet-окон. Если дело обстоит именно так и если злоумышленник в состоянии сыграть роль «нарушителя посередине» и похитить Telnet-окна и ключевой обмен, то он сможет взломать зашифрованную передачу данных.
Сформулируем выводы. Безопасность сети не может быть обеспечена в большей степени, чем безопасность наиболее уязвимого соединения. Если в нашем примере маршрутизатор может быть взломан и похищены секретные ключи, то не нужно никаких атак типа MITM. Кажется, в настоящее время компания Cisco уделяет большое внимание совершенствованию защиты секретных ключей. Их не могут просматривать даже уполномоченные администраторы. Однако ключи хранятся в памяти. Тот, кто захочет вскрыть маршрутизатор и воспользоваться той или иной разновидностью циклического опроса, сможет легко восстановить секретный ключ. К тому же до последнего времени в IOS Cisco не было проведено открытого изучения вопросов переполнения буфера и т. п. Авторы уверены, что когда-нибудь это произойдет, поскольку ряд известных нападений убедительно свидетельствует о возможности переполнения буфера.
Другой способ реализации обмена заключается в использовании протокола SSL вашим браузером. При нормальном режиме обмена информацией, если от вас не запросили никакой информации, криптозащита должна быть отключена. Как в этом случае работает протокол SSL? Когда вы посещаете защищенную Wed-страницу, то от вас не требуется никаких действий по обеспечению безопасности. Подразумевает ли это, что SSL – жульничество? Нет, некоторая часть информации действительно используется совместно. Прежде всего это открытый ключ основного сертификата полномочий. Всякий раз, когда вы загружаете программное обеспечение браузера, оно активизирует встроенные в программу сертификаты. Эти сертификаты содержат необходимую информацию для обеспечения безопасности. Да, сохраняется вероятность атаки типа MITM во время загрузки файла. Если кто-то подпортил файл во время его нахождения на сервере, с которого файл был загружен, или во время загрузки по пути к вашему компьютеру, то теоретически весь ваш трафик по протоколу SSL может быть скомпрометирован.
SSL особенно интересен, так как это один из лучших работающих образцов массового рынка средств обеспечения защиты, поскольку он управляет ключами и т. д. Конечно, протокол не без недостатков. Если вам интересны технические детали работы SSL, посетите сайт: www.rsasecurity.com/standards/SSL/index.html.
Примечание
Этот закон используется в главе 6.
