×

Отправьте заявку

и мы перезвоним вам в ближайшее время

*поля, обязательные для заполнения

НОВОСТИ

17-05-17

Chrome 68 будет помечать все страницы с HTTP как небезопасные в инкогнито-режиме

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

С октября 2017 предупреждение «not secure», содержащееся в адресной строке браузера, будет выводиться для всех HTTP-страниц, на которых содержатся любые формы ввода информации. Также это предупреждение будет выводиться в режиме «Инкогнито» браузера для всех HTTP-страниц.

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

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

Предпосылки перехода к HTTPS

Главная опасность HTTP-страниц заключается в том, что любые передаваемые данные являются незашифрованными, что делает их уязвимыми для злоумышленников. Перехват данных, отслеживание Wi-Fi сетей или осуществление man-in-the-middle атак – все это ставит под удар вполне легитимные веб-сервисы. Причем это касается не только паролей и данных кредитных карт. Любая информация, вводимая пользователями на сайтах, должна быть защищенной.

Все крупные сайты, включая Google, Twitter, Facebook и т.д., уже давно перешли на HTTPS. По словам Google, использование пометки «not secure» для HTTP-страниц, запрашивающих пароли или данные кредитных карт, привело к падению трафика на них на 23%. Это означает, что пользователи стали меньше доверять страницам, на которых выводится подобное предупреждение.

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

12-05-17

Внимание: внеплановые технические работы в Comodo

Уважаемые клиенты и партнеры!

В связи с проведением Центром Сертификации Comodo внеплановых технических работ, сегодня 12 мая 2017 года, возможны сбои при оформлении заказов на сертификаты Comodo на нашем сайте и через контрольную панель. Кроме того, возможны задержки обработки заказов и выпуска сертификатов.

Если Вам нужна дополнительная консультация, пожалуйста, не стесняйтесь обратиться к нашим специалистам:

- по телефонам: 8 (495) 225-2235; 8 (800) 555-5737

- e-mail: info@leaderssl.ru

- или в чате на нашем сайте.

Приносим свои извинения за доставленные неудобства.

Команда ЛидерТелеком.  

11-05-17

Фишинг с использованием Punycode: будьте бдительны!

Punycode – метод преобразования доменного имени в альтернативный формат с использованием только ASCII-символов. К примеру, URL вида «пример-сайта.рф» будет иметь следующий вид в Punycode: " xn----8sbarojrwjdmo.xn--p1ai». Скорее всего, вы уже сталкивались с такими URL-адресами.

Домены в Unicode создают определенную проблему в плане безопасности, поскольку символы Unicode сложно отличить от традиционных символов ASCII. К примеру, можно зарегистрировать домен «xn--pple-43d.ru», что будет являться эквивалентом «аpple.ru». На первый взгляд все хорошо, но здесь используется кириллическая «а», а не ASCII «a». На этом факте основаны атаки с использованием IDN-омографов.

Современные браузеры позволяют защищаться против атак с IDN-омографами. К примеру, Google Chrome выводит URL в формате Punycode, если имя домена содержит символы из нескольких разных языков. Однако обойти этот фильтр достаточно просто: можно зарегистрировать домен, в котором используются только кириллические символы. В результате этого идентифицировать сайт как мошеннический довольно сложно – нужно тщательно проверять URL-адрес и SSL-сертификат.

К счастью, данный баг был исправлен в версии Chrome 58. Пользователи Firefox по-прежнему остаются уязвимыми, поскольку разработчики браузера считают, что с этой проблемой должны бороться регистраторы доменов. Чтобы оградить себя от злоумышленников в Firefox, достаточно зайти в about:config и задать network.IDN_show_punycode в true. В итоге Firefox будет выводить IDN-домены в формате Punycode, что поможет сразу же определить домены-хамелеоны.

Защита от подобных подделок – установка EV SSL-сертификата

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

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

03-05-17

Проверка CAA с сентября 2017 станет обязательной для всех удостоверяющих центров при выпуске SSL/TLS-сертификатов

По существующим правилам, утвержденным CA/B Forum, удостоверяющие центры должны гарантировать, что запросы на SSL-сертификаты идут либо от самого владельцев домена, либо от тех, кто управляет данным доменом.

Обычно проверка прав на домен происходит с помощью создания DNS TXT-записи с определенным значением либо загрузки кода в определенное место сайта. Это и подтверждает факт владения доменом.

При этом взлом сайта порой позволяет злоумышленникам пройти подобные проверки и получить доверенный сертификат для домена от любого удостоверяющего центра. Этот сертификат нередко применяется для атак man-in-the-middle или перенаправления пользователей на фишинговые страницы. Справиться с этим позволяет введение CAA.

Что представляет собой CAA

CAA (сокращение от Certification Authority Authorization) – это специальная DNS-запись, которая была принята в качестве стандарта еще в 2013 году, но с тех пор являлась необязательной. С помощью данной записи владельцы доменов могли указывать удостоверяющие центры, имеющие право выпускать SSL/TLS-сертификаты для заданных доменов.

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

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

Структура CAA является следующей:

FQDN CAA флаги свойство значение

Пример: yandex.ru 86400 IN CAA 0 issue "comodo.com"

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

Чтобы разрешить выдачу только wildcard сертификатов для домена, применяется следующая CAA-запись (со свойством issuewild):

example.org. CAA 0 issuewild certificate_authority.com

Предложение Ballot 187 от регулятора CA/B Forum закрепляет обязательную проверку CAA для всех УЦ

Не так давно SSL-регулятором CA/B Forum был принят Ballot 187, который делает обязательным проверку CAA для всех удостоверяющих центров. За предложение проголосовало 17 удостоверяющих центров (94%) и 3 производителя браузеров (100%). Предложение вступит в силу 8 сентября. Если удостоверяющий центр проигнорирует данные правила, на него будут наложены санкции.

Помимо тега issue, в записи CAA применяется тег iodef – он также станет обязательным для удостоверяющих центров. Этот тег позволяет указать email или URL для связи с владельцем домена – это позволит отправлять отчеты обо всех запросах на сертификаты для данного домена, которые будут конфликтовать с политикой CAA. Владелец домена узнает о том, что кто-то попытался получить сертификат на его домен без должной авторизации и примет соответствующие защитные меры.

Пример записи CAA с определенным iodef:

example.org. CAA 0 iodef mailto:site@example.org

example.org. CAA 0 iodef https://site.example.org/

Существующие проблемы с введением CAA

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

Во-вторых, отсутствует программное обеспечение, которое поддерживало бы CAA на уровне DNS и УЦ. Это станет сильным ударом для небольших удостоверяющих центров, поскольку они могут не успеть обзавестись должным инструментарием к сентябрю.

Заключение

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

Начните 14-дневный пробный период

Попробуйте SSL сертификат с 14-дневным бесплатным тестовым периодом и убедитесь в великолепном качестве наших услуг. Начать очень просто - Вы не рискуете ничем. Если Вас что-либо не устроит, просто не платите по окончании тестового периода. Никакой предоплаты!

Готовы попробовать?

Остались вопросы? Звоните! 8 (800) 555-5737
×

Не нашли то, что искали?

У нас настолько много информации по этому запросу, что вы могли бы уточнить Ваш запрос?

Man webinar Бесплатный вебинар
Зарегистрироваться

Оставьте свои контакты, чтобы получить FAQ на почту

Ссылка на скачивание PDF версии FAQ была успешно выслана на ваш email.

Ошибка отправки письма. Повторите попытку позже.

*поля, обязательные для заполнения
SSL