Symantec рекомендует переход на 2048-битные SSL-сертификаты

Symantec рекомендует переход на 2048-битные SSL-сертификаты

Symantec напоминает о том, что риск взлома хакерами SSL-сертификатов с ключами длиной менее 2048 бит растет вместе с ростом вычислительных возможностей компьютеров. Поскольку такие ключи больше не обеспечивают надлежащего уровня защиты, все сертификационные центры прекратят выдачу 1024-битных сертификатов и отзовут любые сертификаты с ключами длиной менее 2048 бит начиная с 31 декабря 2013 года. Данная мера будет иметь глобальный характер, а своевременное обновление сертификатов позволит избежать нарушений работы веб-сайтов.

Тем, кто все еще использует SSL-сертификаты с ключами длиной менее 2048 бит, пришло время делать апгрейд. Группа Certification Authority/Browser (CA/B) Forum и Национальный Институт стандартов и технологий США пришли к заключению, что ключи длиной менее 2048 бит больше не обеспечивают надлежащего уровня защиты, поскольку, в связи с ростом вычислительных возможностей компьютеров, появился риск взлома таких ключей хакерами, которые обладают необходимыми мощностями. Данная мера направлена на обеспечение надлежащего уровня безопасности и должна иметь глобальный характер.

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

Последствия данных мер:

  • Клиенты, использующие SSL-сертификаты с ключами короче 2048 бит, истекающими до 31.12.2013, должны обновить их, сгенерировав CSR-запрос на получение 2048-битного сертификата. Сертификаты, истекающие до конца этого года, не будут автоматически отозваны 1 октября;
  • Клиенты, использующие SSL-сертификаты с ключами короче 2048 бит, истекающими после 31.12.2013, должны отозвать их и сгенерировать CSR-запрос на получение 2048-битного сертификата, иначе их сертификаты автоматически будут отозваны уже 1 октября;
  • Клиентов, уже использующих сертификаты с ключами длиной 2048 бит и выше, данные меры не затронут.

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

Непринятие необходимых мер в указанные сроки может привести к ряду негативных последствий:

  • блокировке браузером доступа к вашему веб-сайту;
  • появлению предупреждений о небезопасности вашего веб-сайта при посещении;
  • незащищённости транзакций, осуществляемых через вебсайт;
  • исчезновению «печати доверия» с вашего веб-сайта.

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

ТСПУ начали перенаправлять DNS-запросы к Google и Cloudflare на НСДИ

С вечера 26 августа открытые DNS-запросы к серверам Google и Cloudflare начали перехватываться на российских технических средствах противодействия угрозам (ТСПУ). При обычном UDP-запросе к этим серверам для доменов YouTube и RuTracker возвращался ответ NXDOMAIN, будто таких адресов вообще не существует. Однако запрос по TCP успешно доходил до сервера и получал настоящие IP-адреса.

Об этом сообщил пользователь Хабра angry_agent, изучивший поведение адресов 8.8.8.8 и 1.1.1.1.

Анализ трафика показал ещё более интересную картину. Когда автор отправил DNS-запрос с малым значением TTL, в ответе ICMP TTL Exceeded обнаружился адрес 195.208.5.1, принадлежащий Национальной системе доменных имён (НСДИ), хотя исходный пакет предназначался для 8.8.8.8.

С произвольными UDP-пакетами такой подмены не происходило, система реагировала именно на DNS-трафик.

По версии исследователя, ТСПУ распознаёт открытый DNS-запрос и выполняет направленный DNAT: незаметно меняет адрес назначения и отправляет пакет на сервер НСДИ. Тот уже решает, какой ответ вернуть пользователю. При этом для оператора связи запрос выглядит направленным не к Google, а сразу к НСДИ.

Механизм оказался неидеальным. При быстрой отправке нескольких одинаковых запросов первый получал NXDOMAIN, а следующие всё-таки добирались до Google и возвращали реальные адреса. Кроме того, перенаправление срабатывало не для всех DNS-серверов.

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

RSS: Новости на портале Anti-Malware.ru