Insight IT

3 мифа об эффективности SSL

Иван Блинков — Mon, 28 Feb 2011 19:52:00 +0300

К использованию SSL для защиты передаваемых через Интернет данных все относятся по-разному: кто-то пренебрегает и гоняет даже пароли пользователей в незашиврованном виде, а у кого-то паранойя и он готов пройти через все круги ада для получения Extended Validation сертификата от крупного вендора. В результате в народе рождаются различные мифы по этой тематике, которые я и предлагаю сегодня обсудить.

МИФ №1: Использование HTTPS - гарантия безопасности сайта

Вроде бы все просто: все данные передаются между сервером и браузером в зашифрованном виде и украсть их "по пути" невозможно. На практике же запросто могут возникать нюансы...

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

Решением чаще всего становится использование аппаратных решений (так называемых HSM), соответствующих стандарту FIPS 140-2. Они предотвращают как несанкционированный доступ к ключам, так и любые формы его экспорта в незашифрованном виде (даже при резервном копировании и смене аппаратных модулей).

Вторым моментом, на который стоит обратить внимание, является тот факт, что шифрования трафика защищает только от перехвата данных: вирусы, фишинг и опасный для пользователей код остаются таковыми даже в зашифрованном виде. Если сайт генерирует вредоносные ответы через HTTPS они попадут в браузеры пользователей-жертв еще более безопасно для себя :) В такой ситуации маршрутизаторы с защитой от вторжения (IDS/IPS) и прочие системы безопасности, основанные на "глубоком анализе пакетов", становятся бессильными, если не настроить дешифрование и повторное шифрование.

Для избежания подобных казусов максимальное внимание стоит уделять работе отдела QA, грамотной настройке всех компонентов инфраструктуры и регулярным проверкам на предмет возможных эксплойтов на сайте.

МИФ №2: SSL сегодня не является значительной статьей расходов серверных вычислительных ресурсов

Если бы это было так, то F5, Juniper, Cisco и прочие не ставили бы такие ценники на свои решения. Да, вычислительные мощности среднестатистического сервера растут не по дням, а по часам, но эти же самые вычислительные ресурсы используются и для взлома сертификатов. Не смотря на то, что на взлом 1024-битного ключа по-прежнему требуются многие годы и неплохие финансовые вложения, NIST рекомендует переходить на более криптостойким решениям (от 2048 бит), так как теоретически подбор 1024-битного ключа сейчас вполне возможен.

Для разгрузки центрального процессора веб-серверов существует два основных пути:

SSL-акселерация на уровне маршрутизатора (чаще всего от вышеупомянутых вендоров)
Использование HSM с встроенным криптографическим процессором

Вопрос вычислительных мощностей сегодня решается очень лекго, были бы деньги.

МИФ №3: Расходы на управление сертификатами не растут с увеличением количества веб-серверов

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

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

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

Заключение

Полностью технический подход к архитектурным решениям, касающихся использования как SSL, так и других технологий, чаще всего абсолютное неприемлем для ИТ-организаций, пытающихся соответствовать требованиям бизнеса. Подобные решения могут сильно влиять на возможность компании разрабатывать, развертывать и контролировать бизнес приложения и решения. Они не могут приниматься чисто из технических или бизнес соображений, только полностью понимая все аспекты можно сделать верный шаг.

Вообще мифы получились достаточно спорные, но на эту тему недавно прошла довольно горячая волна дискуссии в западной блогосфере, даже с участием довольно крупных игроков в этой сфере (в частности F5). Может быть у читателей Insight IT тоже найдется что добавить, жду в комментариях :)

По традиции напоминаю про подписку на обновления.

Модификация алгоритма хэширования

Иван Блинков — Fri, 15 Feb 2008 13:17:00 +0300

Если Вы уже успели прочитать одну из моих предыдущих записей о хэшировании, то Вы уже имеете базовое представление о теме сегодняшнего разговора. Одним из возможных способов применения хэшей является хранение аутентификационных данных пользователей интернет-приложения, об особенностях реализации формирования и проверки хэшей при регистрации и авторизации пользователей средствами PHP я и хотел бы с Вами поговорить. Сомневаюсь, что Вы услышите что-то новое, если я скажу, что в PHP даже в "стандартной комплектации" реализована масса алгоритмов хэширования, начиная с широкораспространенных md5(); и sha1(); и заканчивая модулями hash и mhash, в которых реализована еще целая масса алгоритмов. Все они давно уже стандартизованы и доступны для изучения всем желающим получить о них какую-либо информацию.

Допустим мы храним пароли пользователей в виде какого-то стандартного хэша, для примера - md5, в базе данных. Все было отлично, но в один прекрасный момент нашелся подлый злоумышленник, который неким хитрым способом получил доступ к базе данных логинов и паролей. Перед ним стоит цель - узнать изначальный пароль у максимального числа пользователей. Посмотрим на ситуацию с его стороны:

Первым делом он бы попытался определить, какой именно хэш перед ним находится - чаще всего это делается либо просто взглянув на длину хэша, либо если приложение широко распространено (популярная CMS скажем) - покопавшись в ее исходниках, еще есть вариант найти свой собственный аккаунт - и зная пароль попробовать на нем разные алгоритмы, способов можно придумать множество - все ограничивается лишь воображением. Узнав ответ на свой вопрос ему лишь останется набрать в Google фразу вроде "md5 decrypt", а дальше уже дело техники.
Еще один вариант решения задачи - взглянуть на список хэшей на предмет наличия совпадений. С очень высокой степенью вероятности за значительной группой одинаковых хэшей будет скрываться какой-либо банальный пароль вроде 123456.

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

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

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

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

<?php
function generateHash($input,$salt = false)
{
  if(!$salt)$salt=randomString(2);
  $hash=md5($input.$salt);
  return $salt.substr($hash,2);
}
?>

Как не трудно заметить - используется самодельная функция randomString();, которая возвращает случайную строку, состоящую из указанного количества шестнадцатеричных цифр (надеюсь Вы в состоянии написать ее своими силами). Именно этот момент и гарантирует элемент случайности при каждой новой генерации хэша. В том месте, где я прочитал про этот механизм (ссылку, к сожалению, привести не могу - в bookmark'ах не нашел), этот случайный компонент назывался словом salt, смысл его заключается в том, что он приписывается ко входным данным, передаваемым стандартной функции хэширования, а затем им же подменяется какая-либо фиксированная часть полученного хэша. Наверняка у Вас возник вопрос: а как же потом понять, что пользователь ввел верные данные, ведь для тех же исходных данных получится другой хэш и возможности их сравнить не будет? Ответ достаточно прост, его можно было увидеть даже в коде: при повторной инициализации хэша из базы данных достается заранее известная часть хранящегося там хэша, соответствующего конкретному пользователю - тот самый salt, и передается нашей функции. В этом случае в механизме будет использоваться именно он, а не новое случайное значение, и, как следствие, в случае правильности введенных данных на выходе получатся совпадающие хэши. Вот такой вот простенький, но иногда достаточно полезный трюк.

Если Вам понравился этот пост - возможно Вам придутся по душе и остальные записи из этой серии статей, а не пропустить публикацию новых записей Вам может помочь RSS feed.

Обратного пути нет

Иван Блинков — Fri, 01 Feb 2008 15:43:00 +0300

…или введение в хэширование

Под таким неоднозначным заголовком я решил разместить всеголишь повествование о такой неотъемлимой части криптографии как hash-функции и алгоритмы.

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

Введение

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

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

Свойства

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

Устойчивость к коллизиям

Коллизия – пара различных прообразов, для которых значение хэша совпадает.

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

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

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

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

В научной литературе принята своеобразная классификация алгоритмов хэширования по устойчивости к обнаружению коллизий типов:

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

Однонаправленность

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

Кардинальное изменение хэша при незначительном изменении оригинала

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

Применение

На практике криптографические хэширующие функции имеет несколько вариантов применения, вот основные из них:

Хранение аутентификационных данных пользователей сайтов или программных продуктов. В случае чисто теоретически возможной ошибки программистов или каких-либо других людей или просто имея доступ к базе данных на том или ином основании, потенциальный злоумышленник может получить доступ к закрытым компонентам того или иного проекта, в том числе и к базе данных пользователей. Если такого рода данные хранились бы в открытом виде, он получил бы полный доступ ко всем учетным записям пользователей. Для избежания возможности возникновения подобной ситуации принято хранить не сами логин и пароль пользователей, а их хэши. В этом случае для аутентификации введенные пользователем данные пропускаются через тот же алгоритм хэширования и полученный хэш сравнивается с хранящимся в БД.
Проверка целостности копии данных. Чаще всего этот способ проверки соответствия копии оригиналу используется в отсутствии доступа к оригиналу. В качестве примера можно привести передачу больших объемов информации через ненадежное пространство (чаще всего Интернет), многие файловые серверы хранят рядом с большими файлами вычисленные от них хэши с использованием популярных алгоритмов, посетитель, скачав файл, может убедиться в его соответствии оригиналу, просто вычислив такой же хэш от копии и сравнив с доступным хэшем от оригинала. Но такой же принцип может использоваться и при доступном оригинале, например, многие программы для прожига образов на компакт-диски используют схожий принцип для проверки соответствия полученного диска образу.

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

Заключение

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

Безопасное общение

Иван Блинков — Wed, 09 Jan 2008 17:34:00 +0300

...или введение в криптографию

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

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

Как известно, наукой, посвященной теории и практике сокрытия данных, является криптография (из греческого: κρυπτός - скрытый и γράφω - писать). Несмотря на свою историю, насчитывающую не одну тысячу лет, эта наука и в современном мире нашла множество применений. С применением этой науки возможно решение самых разнообразных проблем, но основной задачей, с которой призвана справляться современная криптография является как раз относительно безопасная передача данных через ненадежное пространство.

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

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

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

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

Алгоритмы с симметричным ключом

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

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

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

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

Алгоритмы с асимметричным ключом

Главной особенностью этого класса алгоритмов является использование пары ключей: публичного и секретного. Их названия говорят сами за себя: публичный ключ участника передачи данных предоставляется им в свободный доступ и привязывается к его личности, а секретный так и остается известен только его владельцу.

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

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

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

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

В качестве заключения...

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