НОВОСТИ

04-07-18

Лондонский протокол: новая инициатива по борьбе с фишингом

Совет безопасности центров сертификации (The Certificate Authority Security Council (CASC)) на мероприятии CA/Browser Forum в Лондоне объявил о запуске новой инициативы, которая получила название Лондонского протокола. Данная инициатива преследует следующие цели:

  • более надежное подтверждение идентифицирующих сведений;
  • минимизация фишинга для сайтов с OV и EV-сертификатами.

Учитывая недавний рост фишинговых атак, Лондонский протокол предлагает усилить различие между сайтами с DV-сертификатами и сайтами с OV- и EV-сертификатами.

Реализация инициативы будет осуществляться на добровольных началах с привлечением удостоверяющих центров, которые будут выполнять следующие задачи:

  • Активно отслеживать фишинговые отчеты для сайтов с OV- и EV-сертификатами, выпущенными этим удостоверяющим центром.
  • Уведомлять пострадавшего владельца сайта о том, что был обнаружен фишинговый контент, и предлагать инструкции по устранению проблемы наряду с мерами защиты.
  • Пополнять общую базу данных для сокращения объемов фишингового контента. Эти данные будут доступны другим удостоверяющим центрам, чтобы все они могли провести дополнительное исследование перед выпуском OV- и EV-сертификатов.
  • Разрабатывать систему коллизий имен, чтобы предотвратить вектор угроз Stripe.

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

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

Реализация Лондонского протокола будет происходить поэтапно:

  • Июнь-август 2018. Удостоверяющие центры прорабатывают инициативу и начинают исполнять некоторые базовые процедуры.
  • Сентябрь-ноябрь 2018. Удостоверяющие центры применяют концепции протокола к сайтам клиентов с OV- и EV-сертификатами, опираясь на свои собственные политики и процедуры, обмениваются обратной связью с другими удостоверяющими центрами, уточняют протокол на базе полученного опыта.
  • Декабрь 2018 – февраль 2019. Удостоверяющие центры обновляют политики и процедуры протокола, утверждают план по унификации политик и процедур, которые должны применяться удостоверяющими центрами на добровольной основе.
  • Март 2019. Удостоверяющие центры готовят отчет и свои рекомендации для CA/Browser Forum по возможным изменениям в Baseline Requirements (базовые требования).

Лондонский протокол – это попытка вернуться к тому, ради чего создавались EV- и OV-сертификаты – для обеспечения доверия пользователей и безопасности передаваемых данных.

Подписывайтесь на наши обновления, чтобы всегда быть в курсе событий в сфере SSL и онлайн-безопасности! 

25-06-18

Как отключить устаревшие версии SSL/TLS в Apache

Начиная с 30 июня 2018, для совместимости с PCI владельцы сайтов должны отказаться от поддержки TLS 1.0. Протоколы TLS 1.0/1.1 и SSL 2.0/3.0 являются устаревшими. Они не дают должной защиты при передаче данных. В частности, TLS 1.0 содержит уязвимости для некоторых атак. Представленные выше версии протоколов должны быть удалены в средах, требующих высокого уровня безопасности.

Практически все современные браузеры поддерживают TLS 1.2. Ниже мы рассмотрим, как отключить версии TLS 1.0/1.1 и SSL 2.0/3.0 в Apache.

1.Используем vi (или vim) для редактирования ssl.conf (обычно находится в папке /etc/httpd/conf.d).

2.Ищем раздел SSL Protocol Support. Он имеет вид:

#   SSL Protocol support:

# List the enable protocol levels with which clients will be able to

# connect.  Disable SSLv2 access by default:

SSLProtocol all -SSLv2 -SSLv3 

3.Комментируем строку SSLProtocol all -SSLv2 -SSLv3, добавив перед ней символ решетки.

4.Добавляем под ней строку:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

5.Мы отключили TLS 1.0/1.1 и SSL 2.0/3.0. Далее ищем секцию SSL Cipher Suite.

#   SSL Cipher Suite:

# List the ciphers that the client is permitted to negotiate.

# See the mod_ssl documentation for a complete list.

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

6.Комментируем строку SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA и добавляем под ней следующее:

SSLCipherSuite HIGH:!aNULL:!MD5:!3DES

Этот параметр гарантирует использование SSL-шифров только с высокой степенью защиты.

Также добавьте под SSLCipherSuite HIGH:!aNULL:!MD5:!3DES строку:

SSLHonorCipherOrder on

Этот параметр гарантирует, что будут использоваться предпочтения шифров сервера, а не клиентские предпочтения.

Сохраняем файл и перезапускаем Apache. 

service httpd restart

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

Следуйте за лучшими практиками в области SSL вместе с ЛидерТелеком!

15-06-18

Apple приняли новую политику прозрачности SSL-сертификатов


На конференции Apple Worldwide Developers Conference (WWDC) 2018 компания сделала важное заявление: начиная с 15 октября, все SSL/TLS-сертификаты должны быть внесены в публичные логи прозрачности, иначе Safari и различные платформы Apple не будут им доверять.

Это утверждение соответствует требованиям прозрачности, которые были установлены Google и Mozilla ранее. Требование внесения сертификатов в лог прозрачности совпадает с выходом свежего релиза Safari.

До недавнего момента требование внесения сертификатов в журнал прозрачности распространялось только на EV SSL-сертификаты.

Доля Safari составляет приблизительно 3% от всего объема десктопных браузеров, однако в случае с мобильным сегментом она кардинально увеличивается – почти 27%. Новая политика прозрачности будет распространяться как на десктопный браузер Safari, так и на его мобильную версию.

Требуются ли какие-либо действия от пользователей?

Любой сертификат, выпущенный после 15 октября, будет подпадать под новые требования Apple. Важно отметить, что прозрачность сертификатов – задача, возложенная на удостоверяющие центры. От конечных пользователей никаких действий не требуется.

Большинство ведущих удостоверяющих центров уже начали вносить в логи прозрачности все выпускаемые SSL/TLS-сертификаты.

Любой незарегистрированный в логах прозрачности SSL/TLS-сертификат будет считаться некорректно выпущенным.

Мы пристально следим за всеми изменениями со стороны индустрии SSL. Заказывайте сертификаты у нас в LeaderSSL по самым доступным ценам!

27-05-18

Домены .app от Google, доступные только по HTTPS, открылись для регистрации


8 мая Google открыл регистрацию доменов .app для широкой публики. Как и следует из названия, эти домены предназначены для разработчиков приложений, однако зарегистрировать домен можно и для любых других целей.

Отличительной особенностью доменов .app является то, что они требуют от владельцев сайта установки SSL-сертификата и передачи контента по HTTPS.

Компания Google купила права на доменную зону .app в феврале 2015 года за гигантскую сумму, равную $25,001,000. Этот шаг позволил Google установить свои правила для доменов .app – разрешить только HTTPS-соединения.

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

По программе раннего доступа пользователи зарегистрировали свыше 100 000 доменов. Не так давно компания Google открыла регистрацию доменов .app для широкой общественности.

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