Главное Авторские колонки Вакансии Образование
1 434 1 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Смерть через TLS

Почему компании занимающиеся криптографией, и разработкой приложений для безопасной корпоративной коммуникации могут отказаться от протоколов TLS?
Мнение автора может не совпадать с мнением редакции

TLS, как и его предшественник SSL — это криптографический протокол, обеспечивающий защищённую передачу данных между узлами в сети Интернет.

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

"А им можно доверять?"

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

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

Ярким примером подобной нечестной игры со стороны удостоверяющего центра стал конфликт между Mozilla Corporation и центром сертификации Trustwave в 2012г. В результате данного инцидента все сертификаты Trustwave использованные Mozilla были помечены браузером FireFox как не заслуживающие доверия пользователей.

Еще один яркий пример произошел летом 2014 года, когда интернет-гигант Google заблокировал несколько сертификатов выданных в Индии. Примечательно то, что данные цифровые сертификаты были выданы Национальным индийским центром информатики (NIC), который является частью Министерства связи и информационных технологий Индии.

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

"Кто сказал что это нельзя взломать?!"

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

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

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

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

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

Что хотелось бы сказать в конце:

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

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

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

Станислав Чепурко

+8
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Ололо Ололо
В любом случае речь идёт о средствах и целях. Какие комбинированные решения вы знаете, чему, как крупная корпорация доверились бы вы?
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.