Протокол WebRTC [1] уже реализован в браузерах Chrome, Firefox и Opera, а для его поддержки в IE имеется специальный модуль расширения — протокол стал частью технологий HTML5, которые изначально были задуманы для работы с мультимедийным содержанием на уровне браузера без использования закрытых модулей Flash. Реализация протокола — это открытый проект, однако спецификации, которые используются в WebRTC, являются стандартами IETF и описаны в виде RFC. Таким образом, на первый взгляд, нет препятствий для поддержки этого стандарта на уровне браузера или другого приложения, однако возникает ряд вопросов по поводу обеспечения безопасного общения браузеров между собой.

Безопасность коммуникационного протокола WebRTC сильно зависит от защиты сервера и браузера. Если серверы эксплуатируются профессионалами, которые оперативно реагируют на появление новых проблем и исправляют ошибки в сервисах, то обеспечение защиты браузера ложится на плечи не всегда подготовленного пользователя. При этом стоит отметить, что классические средства «индивидуальной защиты», такие как антивирусы, не всегда могут работать на уровне браузера и, хотя содержат модули для обеспечения безопасности работы с Интернетом, не способны контролировать технологию WebRTC, которая является частью браузера. Поэтому для отслеживания поведения браузера, скорее всего, придется разрабатывать специальные инструменты защиты. Конечно, в стандарте безопасности для WebRTC разработчики предусмотрели все необходимые защитные меры, но тем не менее надежность защиты будет зависеть от их реализации. Дело в том, что установкой соединения управляет специальное API на JavaScript, однако если до недавнего времени браузер практически не имел возможности прямого обращения к аппаратуре устройства, на котором работает (только окно для отображения информации, часть файловой системы для хранения файлов, получение данных от клавиатуры и мыши), то протокол WebRTC предполагает возможность прямого доступа к таким важным устройствам, как аудио- и видеовход/выход (микрофон, колонки, видеокамера). При этом конфигурация связи выполняется через JavaScript — наиболее популярный язык управления сценариями в WWW. При распространении этого сервиса у злоумышленников появится возможность создать специальный механизм, который будет открывать посторонние соединения и тем самым получать доступ к видеокамере или микрофону компьютера. Разработчики WebRTC предусмотрели средства защиты от неразрешенного использования периферийного оборудования, однако вполне возможно, что в реализации этих средств окажется уязвимость, которая позволит маскировать несанкционированные мультимедийные вызовы каким-нибудь интерфейсным элементом. В результате возникнет ситуация, при которой коммуникации браузер-браузер будут использоваться для несанкционированного наблюдения или прослушивания.

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

Следует отметить, что злоумышленники пока не торопятся использовать новые технологии, поскольку им еще достаточно старых методов взлома мобильных устройств и компьютеров. Именно поэтому сейчас создается ощущение, что технология WebRTC достаточно безопасна, тем более что в стандарте применяется протокол HTTPS для связи пользователя с сервером, который, собственно, и организует взаимодействие с контрагентом. Этот протокол достаточно надежен для защиты от постороннего вмешательства, но не решает всех проблем. Пользователь должен следить за тем, что он подключен к серверу именно того провайдера сервисов, к которому хотел получить доступ. Вполне возможна фишинговая атака, когда адрес сервера очень похож на легальный, и даже при условии взаимной аутентификации пользователей одного сервиса остается возможность встроиться между ними, если оба абонента невнимательно прочитали адреса контрагентов. Кроме того, протокол WebRTC допускает использование сервера-посредника, организующего многостороннюю конференцию. Например, именно так работает сервис Mind.com, у которого имеется режим организации видеоконференции через сервер самой компании с целью оптимизации пропускной способности канала абонента. Злоумышленники могут построить подобный сервис-посредник, который будет перехватывать мультимедийный поток между абонентами в том числе и стороннего сервиса.

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

Сейчас комитет IETF, понимая важность обеспечения мер безопасности коммуникационного протокола, разрабатывает требования к безопасной реализации WebRTC в браузерах, но пока стандарт не принят и находится в процессе обсуждения, а номер RFC для него еще не определен. Тем не менее уже понятны общие принципы, которые разработчики документа заложили в проект стандарта, разделив меры защиты на четыре части: шифрование, аутентификация, сокрытие адресов и графический интерфейс.

При использовании WebRTC можно пользоваться только зашифрованными соединениями, то есть протоколами HTTPS и SRTP. Первый применяется для взаимодействия пользователя с сервером управления, а второй — для взаимодействия браузеров. Применение незащищенных вариантов HTTP допускается, но каждое такое соединение пользователь должен разрешить отдельно. Незащищенный вариант передачи сообщений RTP (Realtime Transport Protocol) запрещен. Понятно, что для установления зашифрованного канала связи необходимо иметь инфраструктуру открытых ключей, с помощью которой и согласуется общий секрет для создания зашифрованного соединения.

Для аутентификации применяются сертификаты X.509 или стандартные для Web механизмы SSL и федеративной аутентификации. В частности, допускается использование технологий OAuth, BrowserID, Facebook Connect и др. При этом предполагается наличие некоторого провайдера аутентификации, через которого, собственно, и выполняется аутентификация участников взаимодействия, а браузер пользователя получает информацию о том контрагенте, который пытается установить с ним связь. Пользователь может принять вызов или отклонить его вне зависимости от результатов аутентификации. Документ допускает составление списка проверенных абонентов, связь с которыми ранее уже была установлена и проверена. Для знакомых контрагентов правила получения сообщений и вызовов несколько упрощены, чтобы не утомлять пользователя лишними уточняющими вопросами.

В протоколе WebRTC используется специальная инфраструктура, позволяющая пользователю скрывать свои реальные IP-адреса. Для этого используется стандарт ICE (Interactive Connectivity Establishment), который был разработан для протокола SIP, но также применяется и в WebRTC, позволяя вызываемому абоненту до снятия трубки скрывать свой реальный IP-адрес. Этот механизм защиты разработчики протокола предусмотрели для того, чтобы не было тестовых вызовов, когда злоумышленникам нужно не установить связь, а просто определить местоположение абонента по его IP-адресу. Для такого сокрытия адресов служит технология NAT (Network Address Translation), управление которой выполняется с помощью двух дополнительных протоколов — STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT). Эти протоколы позволяют использовать WebRTC даже в сложных сетевых конфигурациях, когда возникает необходимость получить доступ к абонентам внутри корпоративной сети.

Разработчики стандарта предписывают создателям реализации WebRTC соблюдать строгие правила работы с видеокамерой или микрофоном. В частности, пользователь должен видеть, что камера или микрофон включены и передают информацию в Интернет. При этом должна быть кнопка, нажав которую пользователь может прервать передачу данных. Кроме того, браузер должен запрашивать у пользователя разрешение на каждое соединение, если оно не авторизовано, а для авторизованных запрашивать дополнительные разрешения на несколько сеансов. Отдельно указано, что некоторая часть информации о соединении не может быть доступна из JavaScript — в частности, это относится к ключам шифрования, элементам управления камерой и микрофоном, а также диалогам для разрешения соединения.

***

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

Литература

  1. Симон Пьетро Романо, Салваторе Лорето. Коммуникации реального времени: проблемы, достижения, стандарты // Открытые системы.СУБД. — 2012. — № 9. — С. 50–53. URL: http://www.osp.ru/os/2012/09/13032514 (дата обращения: 22.06.2014).

Валерий Коржов (osmag@osp.ru) — обозреватель, «Computerworld Россия» (Москва).