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

Несмотря на то, что технология HTTPS существует почти столько же, сколько протокол HTTP, который она дополняет, определенные классы проблем её реализации не решены до сих пор. А именно:

1. Управление сертификатами реализовано без учета реальных потребностей пользователей (включая удобство пользования).

2. Реализация протокола SSL/TLS может содержать ошибки реализации и/или конфигурации.

3. Современные стандарты PKI не поддерживаются в должном объеме.

4. Шифрованные данные недоступны для инспекции сетевыми средствами.

Возникает вопрос: можно ли считать указанные проблемы именно проблемами реализации протокола, если один из пунктов - проблема пользовательского интерфейса, а другой - фундаментальное свойство протокола? С точки зрения пользователя, все перечисленные проблемы возникают во время использования протокола HTTPS в веб-браузере. Именно это и обусловило выбор такой, возможно, не совсем корректной формулировки. В тексте статьи применительно к криптографическому транспорту протокола HTTPS будет применяться термин SSL, а не TLS, так как стандарт TLS содержит некоторые расширения, использование которых мы не рассматриваем. В рамках данной статьи отличия TLS, используемого в протоколе HTTPS, от SSL версии 3.0 не имеют значения: оба могут применяться с одинаковым результатом.

Технологии проксирования SSL

Широкие возможности по решению перечисленных проблем реализации HTTPS предоставляют технологии проксирования.

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

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

Алгоритм работы прокси-сервера, реализованной по методу «человек посередине», достаточно прост:

1. Прокси-сервер принимает TCP-соединение от клиента и получает команду на установление соединения с сервером.

2. Прокси-сервер устанавливает TCP-соединение с сервером и начинает SSL-сеанс.

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

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

5. Прокси-сервер принимает HTTP-запрос от клиента, передает его механизму инспекции содержимого и, при отсутствии ошибок и нарушений политики безопасности, передает HTTP-серверу.

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

Анализ проблем протокола HTTP

Пользовательский интерфейс управления сертификатами

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

Если в рамках интранет-решений мы можем более или менее успешно контролировать все аспекты реализации и внедрения протокола HTTPS, то в «большом грязном интернете» многое не только устроено не так, как нам хотелось бы, но и недоступно нашему влиянию. Так, по различным оценкам, от половины до двух третей сайтов, использующих протокол HTTPS, делают это не вполне корректно: при посещении таких сайтов возникают предупреждения браузера об ошибках[1]. При этом с практической точки зрения интересны два момента: во-первых, эти ошибки почти бесполезны - пользователи их игнорируют[2]. Во-вторых, есть как минимум один распространенный случай, когда мы можем позаботиться о пользователе за него.

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

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

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


Рисунок 1. Ошибка сертификата в окне браузера Firefox 3
Приведенный на Рис. 1. пример представляет ещё не самых худший вариант отображения ошибки сертификата веб-браузером. К примеру, в Google Chrome вообще нет возможности добавить постоянное исключение для подобных ошибок. Учитывая то, что они встречаются достаточно часто, а также то, что пользователи склонны тем меньше обращать внимание на предупреждения, чем их больше, - налицо проблема информационной безопасности.

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


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

Уязвимости в реализации и конфигурации протокола и прикладных библиотек

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

Например, эффективная защита от уязвимости большей части прикладных библиотек для работы с сертификатами, продемонстрированной в июле 2009 года исследователями Kaminsky и Marlinspike[3], реализуется простейшей проверкой всего лишь в несколько строк программного кода. Более того, эта проверка оказывается достаточно универсальной и, предположительно, будет эффективна также против других возможных ошибок парсера ASN.1, которые могли бы создать разночтения в длине интерпретируемых данных.

Еще проще при помощи SSL-прокси контролируются такие потенциальные угрозы безопасности, как:

• Устаревшие версии протокола SSL [4]
• Криптографически нестойкие хэш-функции в подписях сертификатов [5]
• Использование криптографически нестойких алгоритмов шифрования.

Следует, впрочем, отметить, что это решение - не панацея: так, обнаруженная в конце 2009 года атака на пересогласование TLS-сеанса принципиально необнаружима [6] со стороны клиента. Главная задача SSL-прокси, как и других технологий межсетевого экранирования, заключается в создании единой точки контроля, не заменяющей, а дополняющей управление конфигурацией и изменениями.

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

Расширения X509v3 и автоматическая валидация сертификатов

Расширения X509 версии 3 хорошо известны любому, кто занимался построением сервисной архитектуры информационных систем, развертыванием больших виртуальных частных сетей и, наверное, любыми другими сложными случаями внедрения PKI, кроме: собственно, веб-сервисов. Такой странный «перекос» обусловлен удивительным фактом: веб-браузеры не имеют полноценной поддержки этого общепринятого и уже далеко не нового (IETF RFC2459, 1999 год [7]) стандарта! Фактически, поддержка PKI в браузерах ограничивается довольно ненадежной реализацией протокола OCSP, проверкой разрешенных целей использования серитификата удостоверяющего центра (Basic Constraints), альтернативных имен и практически нефункциональным (а именно, настраиваемым вручную и пригодным только для интранета) механизмом использования списков отозванных сертификатов (CRL). Валидация сертификатов в рамках протокола SSL/TLS производится согласно представляемой сервером фиксированной «цепочке доверия», чего зачастую недостаточно.

Рассмотрим ситуацию более подробно на примере произвольно взятого «в дикой природе» сертификата, в котором присутствуют интересующие нас расширения.

Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            1a:40:d3:01:00:00:00:00:22:d9 
        Signature Algorithm: sha1WithRSAEncryption 
        Issuer: DC=ru, DC=yandex, DC=ld, CN=YandexExternalCA 
        Validity 
            Not Before: Aug 25 11:55:37 2009 GMT 
            Not After : Aug 25 11:55:37 2011 GMT 
        Subject: C=RU, L=Moscow, O=OOO Yandex, OU=money.yandex.ru, CN=Yandex.Money 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
            RSA Public Key: (1024 bit) 
                Modulus (1024 bit): 
                    00:bd:bf:56:ca:2d:8a:00:20:6e:a8:24:ca:32:3c: 
                    6c:b9:9b:f2:9c:c2:10:40:01:0d:94:63:8a:10:51: 
                    79:0b:70:29:d5:14:f8:65:7f:ca:36:a9:76:9b:30: 
                    e2:e5:e6:e5:3c:bf:4b:f5:23:7c:c6:c6:7a:c3:de: 
                    fa:76:da:63:56:27:69:e1:53:6c:97:89:9b:19:54: 
                    03:df:c6:45:f6:9c:07:81:c9:45:05:42:de:ff:3f: 
                    25:99:c0:27:6a:2d:4b:02:a0:79:0a:5e:d7:7e:e9: 
                    33:46:ee:bb:28:a0:74:59:c7:56:c8:80:b8:c9:ed: 
                    46:36:4f:de:69:df:d8:69:4f 
                Exponent: 65537 (0x10001) 

        X509v3 extensions: 
            X509v3 Basic Constraints: critical 
                CA:FALSE 
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment 
            X509v3 Subject Alternative Name: 
                DNS:money.yandex.ru, DNS:promo.yandex.ru 
            X509v3 Subject Key Identifier: 
                64:95:3A:17:8F:60:C4:42:BE:19:AF:06:9E:3A:50:2B:DA:98:4B:B5 

            X509v3 Authority Key Identifier: 
                keyid:DB:41:27:30:4F:1A:F5:5B:3E:84:56:C8:EC:85:98:B3:51:2C:2D:27 

            X509v3 CRL Distribution Points: 
                URI:HTTP://crls.yandex.ru/YandexExternalCA/YandexExternalCA.crl 

            Authority Information Access: 
                CA Issuers - URI:HTTP://crls.yandex.ru/YandexExternalCA/YandexExternalCA.der 

            1.3.6.1.4.1.311.21.7: 
                00.(+.....7.....&...U...-.............7....(..d... 
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication 
            1.3.6.1.4.1.311.21.10: 
                0.0 
..+....... 
    Signature Algorithm: sha1WithRSAEncryption 
        99:2d:66:d7:7f:26:6b:69:66:5d:fa:3c:8d:53:5e:e1:0a:e1: 
        68:78:25:d1:e6:b6:94:b6:43:11:90:cb:2b:93:69:fb:f6:82: 
        26:7b:60:8b:5d:b7:ec:0a:9b:2d:b2:e2:22:5d:04:d8:2b:2a: 
        04:0d:43:de:e8:b7:2c:e3:91:19:98:e0:4a:53:b6:15:e9:4a: 
        e2:84:19:11:9e:e2:86:02:74:7a:c4:36:8e:07:fc:b8:f9:c3: 
        23:22:d5:a9:63:c4:9b:a9:e9:1a:9b:97:0a:0a:94:02:23:5b: 
        9c:1c:58:14:2d:b7:7f:00:11:07:c0:c3:a1:a9:22:4c:06:09: 
        11:54:da:6a:76:27:d0:e9:e4:5d:40:f0:54:3f:14:7b:39:f3: 
        ae:52:83:8d:6b:9e:fb:c1:3b:ef:bb:f6:a4:aa:64:ba:60:f3: 
        1c:a0:48:da:aa:e3:f5:38:d3:e3:2c:14:49:6e:f3:01:df:04: 
        ef:62:59:15:a8:18:29:a1:8e:fa:da:38:1d:16:34:55:9a:ce: 
        e5:1c:d1:7b:db:3f:27:ca:6d:ef:49:b6:0c:3d:64:f0:cb:06: 
        aa:a9:aa:de:53:f2:2b:02:1f:c4:e7:d6:98:39:5e:cf:bc:9f: 
        79:55:6e:2f:4e:0e:f9:2f:20:0f:b6:c5:5b:26:c0:ff:c8:97: 
        39:c8:ab:f1 

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

• Authority Key Identifier (AKID). Этот идентификатор указывает, каким сертификатом подписан рассматриваемый нами сертификат. Механизм аналогичен поиску сертификата, поле Subject которого соответствует полю Issuer данного сертификата.
  
  Почему именно этот способ поиска удостоверяющего сертификата рекомендуется в настоящее время? Тому есть несколько причин. Во-первых, в случае перевыпуска сертификата AKID однозначно идентифицирует искомый публичный ключ, поэтому исключена путаница между «старым» и «новым» сертификатами с одинаковым полем Subject. А, во-вторых, современный стандарт PKI предполагает специальное использование сертификатов, имеющих одинаковую ключевую информацию, но разные информационные поля, для установления сложных взаимоотношений доверия между иерархиями сертификации. Поэтому важно, чтобы мы могли идентифицировать сертификат именно по ключу и выбирать подходящий из нескольких вариантов. [8]
  
  
• CRL distribution points. Это URL, по которому можно получить список отозванных сертификатов, в данном случае - по протоколу HTTP.
  
  CRL через HTTP - весьма медленный способ уведомления об отзыве сертификатов: типовое время обновления составляет несколько часов. Объем «списка отзыва» может быть значительным, до десятков и сотен килобайт. Поэтому веб-браузеры обращаются только к тем спискам, использование которых было указано явно в пользовательских настройках.
  
  
• Authority Information Access (AIA). В этом расширении указывается, где можно получить информацию об издателе сертификата.
  
  Вместо этого механизма, как уже упоминалось, веб-приложения либо используют предварительно построенные «цепочки доверия», полученные при установлении связи по протоколу SSL/TLS, либо полагаются на то, что все необходимые дополнительные сертификаты уже есть в хранилище браузера.

Какие преимущества дает использование SSL-прокси применительно к проблеме поддержки расширений X509v3? Мы можем подключить готовую библиотеку валидации сертификатов (в нашем случае был использован Carillon Pathfinder) и, таким образом, реализовать следующие функции, отсутствующие в веб-браузере:

• Корректную валидацию согласно RFC5280[8] с использованием информации AKID
• Кэширование с целью экономии трафика и использование CRL
• Автоматическое получение недостающих сертификатов промежуточных удостоверяющих центров с помощью AIA
• Настраиваемые политики обработки цепочек доверия, содержащих «слабые» звенья, связанные с применением криптографически нестойких хэш-функций.

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

Общие проблемы PKI в «большом плохом интернете»

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

При этом, чтобы скомпрометировать систему, не обязательно вмешательство злоумышленника в функционирование удостоверяющего центра. Достаточно, чтобы слабым звеном в цепочке доверия оказался, например, криптографически нестойкий хэш-алгоритм,что, увы, является не теоретической, а вполне практической угрозой. Еще в 2009 году некоторые корневые удостоверяющие центры продолжали использовать устаревший алгоритм MD5, а если и прекращали, то оставалось большое количество неотозванных MD5-сертификатов. Поэтому специальное внимание при разработке нашего решения для SSL-проксирования было уделено исключению подобных слабых звеньев. Для снижения подобных рисков также может использоваться упомянутый выше параметр расширения Basic Constraints, ограничивающий возможную длину цепочки сертифкатов для конкретного удостоверяющего центра. С другой стороны, распространены случаи «ложной тревоги», когда слабый алгоритм использовался для самоподписи корневого сертификата, что само по себе не представляет угрозу безопасности.

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

Все это достаточно сильно отличается от «тепличных» условий интранета, в котором все компоненты PKI находятся если не под единым контролем, то хотя бы вписываются в обозримые рамки.

Show Me The Code: SSL Proxy

Автором был разработан прокси-сервер для SSL. Продукт SSL Proxy существует в двух вариантах:

1.Бесплатный пакет с исходным кодом (open source). Распространяется в рамках проекта OpenFWTK в виде компонента http-gw, под лицензией «Old BSD with advertisement clause».

2.Коммерческий встраиваемый компонент для межсетевых экранов и DLP-систем.

В состав программы входит ПО Carillon Pathfinder, распространяемое под лицензией GNU LGPL.

Особенности реализации и внедрения

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

• Самоподписанные сертификаты остаются таковыми. Для них лишь создается новый ключ, и возможен контроль непредусмотренной подмены.
• Для мобильных клиентов, использующих разные точки выхода в сеть, во избежание конфликтов серийные номера «новых» сертификатов отличаются от <настоящих> согласно предсказуемому алгоритму.
• Допустимые согласно политики безопасности ошибки сертификатов (такие как истекший срок действия и др.) транслируются без изменений, с сохранением всех диагностических сообщений.
• Сертификаты, подписанные неизвестными удостоверяющими центрами, содержат в поле Issuer строку «UNVERIFIED», что позволяет веб-браузеру выдавать диагностику, аналогичную той, которую можно получить при «прямом» подключении.
• Возможны гибкие настройки исключений: например, для применения авторизации по клиентским сертификатам, обеспечения поддержки нестандартных алгоритмов шифрования клиентом, или для доступа к сайтам с защитой приватности пользователей (таких как интернет-банкинг).

Инспекция содержимого для протокола HTTPS

Это базовая функциональность, ради которой, в основном, и были написаны все существующие реализации технологии проксирования SSL: инспекция содержимого защищенного трафика по принципу «человек посередине». Прикладные особенности реализации данной технологии в программе SSL Proxy заключаются, прежде всего, в использовании интерфейса к дешифрованной сессии, доступного непосредственно для механизма инспекции контента: DLP, антивируса, системы ведения архива и т.п. На настоящий момент наиболее широко распространенным стандартом на такой интерфейс является протокол i-cap (Internet Content Adaptation Protocol[9]) - он и был использован в рассматриваемом продукте.

Выводы

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

Список ссылок

1. Researcher: Poor SSL Implementations Leave Many Sites At Risk. DarkReading.com
2. J. Sunshine, S. Egelman et al. Crying Wolf: An Empirical Study of SSL Warning Efectiveness.
3. M. Marlinspike. Null Prefix Attacks Against SSL/TLS Certificates.
4. 56387 : SSLv2 Protocol Multiple Weaknesses. OSVDB.org
5. A. Sotirov, M. Stevens et al. MD5 considered harmful today: Creating a rogue CA certificate
6. T. Zoller. TLS/SSLv3 renegotiation vulnerability explained
7. RFC2459. Internet X.509 Public Key Infrastructure Certificate and CRL Profile
8. RFC5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
9. RFC3507. Internet Content Adaptation Protocol (ICAP)