Рейтинг
0.00

Leaderssl Хостинг

2 читателя, 66 топиков

Как отключить устаревшие версии 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 вместе с ЛидерТелеком!

Домены .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.

Начиная с сентября 2018, в Google Chrome изменятся визуальные индикаторы для HTTPS



Мы уже писали о том, что Google планирует помечать все HTTP-сайты как небезопасные (Not secure). На днях Google сделали еще один шаг в этом направлении – начиная с сентября 2018, в Google Chrome (в версии 69) будет удалено слово «Secure» из адресной строки браузера для всех HTTPS-сайтов.

Наконец, в октябре с выходом Chrome 70 все сайты, не имеющие SSL-сертификатов, будут помечаться красным текстом «Not secure» в адресной строке браузера при пользовательском вводе данных.

Примечание: по умолчанию текст Not Secure для HTTP-страниц имеет серый вид, однако при заполнении любых форм он станет красным.

Почему были введены такие изменения? Как утверждают представители Google, пользователи должны понимать, что Сеть по умолчанию безопасна.

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

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

Протокол шифрования TLS 1.3 был окончательно доработан и утвержден группой IETF

ый протокол TLS 1.3 был полностью доработан 21 марта 2018 года. До этого протокол обновлялся более 8 лет назад. Среди особенностей TLS 1.3 можно отметить улучшенную безопасность и производительность.


Новый протокол TLS 1.3 был полностью доработан 21 марта 2018 года. До этого протокол обновлялся более 8 лет назад. Среди особенностей TLS 1.3 можно отметить улучшенную безопасность и производительность.

За описание протокола TLS отвечает группа Internet Engineering Task Force (IETF). Прошлая версия TLS, TLS 1.2, была описана в RFC 5246 и использовалась на протяжении 8 лет, имея поддержку в большинстве веб-браузеров. 21 марта 2018 года протокол TLS 1.3 был полностью доработан.

Улучшенная скорость в TLS 1.3
Если говорить о веб-производительности, то TLS и зашифрованные соединения поначалу добавляли дополнительные миллисекунды. С приходом HTTP/2 эта проблема была решена, а TLS 1.3 позволяет еще больше ускорить зашифрованные соединения. В TLS 1.3 появились такие возможности:
  • TLS false start (фальстарт TLS)
  • Zero Round Trip Time (0-RTT) (нулевое время приема-передачи).
  • В TLS 1.2 для совершения TLS-рукопожатия (handshake) требовалось выполнить 2 приема-передачи (round-trip), в то время как в TLS 1.3 для этого требуется только 1 прием-передача (TLS False Start). Это позволяет наполовину сократить задержку для процедуры шифрования.

Еще одно преимущество: нулевое время приема-передачи. Если вы посещали ранее какой-либо сайт, то вы можете отправлять данные в первом же сообщении к серверу. Эта возможность называется 0-RTT. В результате этого страницы загружаются гораздо быстрее.

Улучшенная безопасность в TLS 1.3
В TLS 1.3 были удалены устаревшие и небезопасные алгоритмы, которые существовали в TLS 1.2: SHA-1, RC4, DES, 3DES, AES-CBC, MD5, CVE-2016-0701 и т.д.

Это позволяет исключить атаки на TLS, которые происходили ранее (достаточно вспомнить Heartbleed или POODLE).

Соединения будут по-прежнему откатываться к версии протокола TLS 1.2, если какая-либо из сторон не поддерживает TLS 1.3, однако если злоумышленник попытается обманом вызвать такой откат (с помощью атак man-in-the-middle (MITM)), то в TLS 1.3 это будет обнаружено и предотвращено.

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

Поддержка браузеров:
  • В Chrome 63 поддержка TLS 1.3 включена для исходящих подключений. Поддержка TLS 1.3 появилась в версии Chrome 56.
  • В Firefox 52 протокол TLS 1.3 включен по умолчанию. Также он включен в Quantum.
  • Остальные браузеры обещают включить протокол в течение нескольких месяцев.

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

Скорректированы правила проверки доменов для выпуска SSL-сертификатов

На днях CA/B Forum, регулятор индустрии SSL-сертификатов, принял большинством голосов предложение Ballot 218, связанное с удалением нескольких методов проверки (валидации) домена.


На днях CA/B Forum, регулятор индустрии SSL-сертификатов, принял большинством голосов предложение Ballot 218, связанное с удалением нескольких методов проверки (валидации) домена.

Основные изменения коснулись раздела 3.2.2.4 основного документа «Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates". В этом разделе содержатся разрешенные процессы и процедуры проверки прав владения доменом для заявителя.

По мнению Tim Hollebeek из DigiCert, эта секция нуждается в переработке, поскольку она содержит методы, не соответствующие целям раздела 3.2.2.4.

Какие конкретно изменения были внесены в документ
  1. Контактные данные о владельце домена могут быть получены напрямую от регистратора доменных имен, что было прописано в пункте 1.6.1.
  2. С 1 августа 2018 года контактные данные домена не должны использоваться для проверки заявителя, и их успешная проверка не может служить причиной для выпуска сертификатов. Вместо этого пункта вводится новая секция 3.2.2.4.12, разрешающая использовать контактные данные домена для проверки заявителя, но только в том случае, если удостоверяющий центр является регистратором доменных имен либо партнером регистратора базовых доменных имен.
  3. С 1 августа 2018 года документ авторизации домена (Domain Authorization Document) не должен использоваться для проверки заявителя, и успешная проверка этого документа не может служить причиной для выпуска сертификатов.
  4. Убрана секция 3.2.2.4.11, описывающая альтернативные методы проверки домена.
Остальные правила проверки доменов остались без изменений.
Подписывайтесь на наши обновления, чтобы оставаться в курсе событий, связанных с SSL!

С 1 февраля все DigiCert сертификаты будут отвечать требованиям прозрачности



Как сообщается в блоге DigiCert, с 1 февраля 2018 года все новые публично доверенные SSL-сертификаты этого удостоверяющего центра по умолчанию будут вноситься в журналы прозрачности (Certificate Transparency logs).

Первоначально журналы прозрачности были введены Google еще в 2015 году и применялись только к выпущенным EV SSL-сертификатам. Однако с целью повышения безопасности Google расширил требования по внесению сертификатов в такие журналы.

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

Согласно анонсу Google, все публично доверенные SSL/TLS сертификаты, выпущенные с 1 апреля 2018 года, должны в обязательном порядке вноситься в журналы прозрачности. Удостоверяющий центр DigiCert решил пойти своим путем и ввести более жесткие сроки внедрения этой возможности.

С 1 февраля 2018 все новые публично доверенные сертификаты DigiCert будут включать в себя специальные данные, которые называются Signed Certificate Timestamps (подписанные временные метки сертификата). Они встраиваются в сам сертификат и сообщают браузерам о том, что сертификат был внесен в журнал прозрачности.

В магазине LeaderSSL вы всегда можете заказать SSL/TLS-сертификаты DigiCert (Symantec, Thawte, RapidSSL, GeoTrust), регистрируемые в журналах прозрачности для максимальной безопасности и соответствия требованиям индустрии.

Спешите: последняя возможность купить трехлетние SSL-сертификаты!



Как мы уже писали ранее, выпуск трехлетних SSL-сертификатов будет прекращен всеми удостоверяющими центрами, начиная с 1 марта 2018 года.

Однако DigiCert внес в эту дату свои коррективы: компания сообщила о том, что последний срок выпуска трехлетних SSL-сертификатов GeoTrust, RapidSSL, Symantec и Thawte — 20 февраля 2018 года. После этой даты выпуск и продление указанных SSL-сертификатов будет возможным только на срок, не превышающий 825 дней.

Если у вас уже имеются активные трехлетние SSL-сертификаты, вам не о чем волноваться — они не потребуют никаких действий и будут работать и после 1 марта.

Только до 20 февраля вы можете заказать трехлетние SSL-сертификаты GeoTrust, RapidSSL, Symantec и Thawte в магазине LeaderSSL по выгодным ценам. При этом последний срок покупки трехлетних SSL-сертификатов Comodo, Entrust и GlobalSign — 28 февраля.

Поторопитесь! Это последняя возможность обзавестись трехлетними SSL-сертификатами!

Компания Francisco Partners приобрела SSL-бизнес Comodo



Бизнес по выпуску сертификатов Comodo был приобретен компанией Francisco Partners. Новости об этом появились в тот же день, что и анонс закрытия сделки между Symantec и DigiCert.

Мелих Абдулхайоглу (Melih Abdulhayoglu), основатель и директор компании Comodo, отметил, что он лишь снизил свою долю в бизнесе, а не продал весь бизнес. Это позволит компании сконцентрироваться на других решениях в области кибербезопасности.

Francisco Partners назначили Билла Хольца (Bill Holtz)в качестве генерального директора Comodo CA. Ранее Билл работал главным операционным директором в Entrust. По его словам, главной задачей для Comodo станет экспансия рынка SSL-сертификатов. Невзирая на то, что Comodo и так занимает лидирующие позиции на этом рынке, их бренд не настолько хорошо узнаваем в мире. Компании удалось избежать проблем, которые постигли ее конкурентов. Серьезное нарушение, связанное с двумя реселлерами, произошло лишь один раз в 2011 году, и с тех пор компания изменила свою бизнес-модель, чтобы обезопасить себя от подобных случаев.

Еще одно назначение в управляющем совете компании – Билл Коннор (Bill Connor), президент и генеральный директор SonicWALL. Компания SonicWALL также принадлежит Francisco Partners. Естественно, SonicWALL уже объявила о том, что в ближайшем релизе будет введена широкая поддержка Comodo сертификатов. По словам Билла Коннера, со временем бизнес Comodo CA может ждать ребрендинг.

Удостоверяющий центр Comodo выпустил более 91 млн сертификатов и имеет свыше 200 000 клиентов по всему миру. Основатель Comodo Мелих Абдулхайоглу остается в качестве миноритарного владельца и наблюдателя в совете директоров.

LeaderSSL — официальный партнер Comodo, поэтому вы всегда можете приобрести у нас любые сертификаты Comodo по выгодным ценам.

DigiCert закрыла сделку с Symantec по приобретению SSL бизнеса



31 октября компания DigiCert объявила о том, что сделка по приобретению активов Symantec – инфраструктуры PKI и инструментов безопасности сайтов – на сумму $950 млн была закрыта. Анонс сделки появился в СМИ еще 3 августа. DigiCert приобрели SSL бизнес Symantec после того, как компания попала под немилость по стороны Google и других крупных поставщиков браузеров. По результатам сделки Symantec сохранит 30% долю в акционерном капитале DigiCert.

Как отметил CEO DigiCert Джон Меррилл (John Merrill), некоторые платформы, используемые Symantec, являлись устаревшими, в то время как инфраструктура DigiCert отличается большей новизной и современностью.

Особенности сделки между Symantec и DigiCert
Symantec изначально приобрела бизнес по выпуску SSL/TLS-сертификатов у VeriSign за $1.28 млрд в 2010. Компания также получила в свое распоряжение такие бренды, как Thawte, GeoTrust и RapidSSL.

Главным импульсом для приобретения DigiCert стал тот факт, что Google публично заявили об отзыве доверия к сертификатам Symantec. По словам Джона Меррилла, представители Google одобрили перенос выпуска SSL/TLS-сертификатов в инфраструктуру DigiCert.

Также Джон рассказал о том, что DigiCert нанял объединенную команду поддержки для всех клиентов Symantec SSL/TLS. Часть плана состоит в том, чтобы удержать уже существующих клиентов, предложив им лучший сервис.

Приобретение SSL бизнеса Symantec – это не первая сделка, заключаемая DigiCert. В июне 2015 года компания приобрела CyberTrust Enterprise SSL бизнес от Verizon Enterprise Solutions. Джон отметил, что у них есть наработанные решения, которые помогли с интеграцией Symantec в инфраструктуру DigiCert.

Как уже было отмечено ранее, DigiCert продолжит работать из своей штаб-квартиры в Лехи (Юта). Компания планирует нанять более 1000 специалистов в дополнительных офисах в Калифорнии, а также в других странах мира. Как отметил Джон Меррилл, добавление решений Symantec для обеспечения безопасности сайтов позволит компании расширить свой глобальный охват.

StartCom закрывается



Удостоверяющий центр StartCom закроется и перестанет выпускать новые сертификаты с начала следующего года. Об этом сообщил председатель управляющего совета организации Xiaosheng Tan. Кроме того, возобновление корневой программы Mozilla больше не обсуждается. Как мы помним, Mozilla и другие крупные производители браузеров удалили корни Startcom и Wosign за нарушение правил выпуска сертификатов.

Startcom принадлежит китайской интернет-компании Qihoo360. Еще до лишения доверия крупные производители браузеров установили, что связь Wosign и Startcom была недостаточно разъяснена. Также имелись технические ошибки в выпуске сертификатов.

Прекращение выпуска сертификатов должна произойти 1 января 2018 года. Сервисы Certificate Revocation List (CRL) и OCSP будут работать еще два года с отмеченной выше даты. По истечении этого времени все три пары корневых ключей StartCom будут уничтожены.

Удостоверяющий центр Startcom недавно попытался обновить собственную инфраструктуру и повторно войти в различные корневые программы. Однако новое программное обеспечение на базе PHP провалилось в тесте безопасности Cure53. Как показал тест, код на PHP содержал много багов, был плохо закомментирован, и в целом выглядел так, словно его писали на скорую руку.

Xiaosheng Tan из StartCom поблагодарил сообщества Mozilla и Cure53 за обратную связь. Он отметил, что аудит Cure53 показал массу возможностей для улучшения.