Говорим о том, что собой представляет технология DANE для аутентификации доменных имен по DNS и почему она не получила широкого распространения в браузерах.
Рубрика «SSL» - 4
Есть мнение: технология DANE для браузеров провалилась
2019-06-01 в 18:26, admin, рубрики: 1cloud, DANE, IT-стандарты, SSL, Блог компании 1cloud.ru, браузеры
Потенциальные атаки на HTTPS и как от них защититься
2019-04-28 в 14:07, admin, рубрики: 1cloud, beast, DROWN, Heartbleed, HTTPS, poodle, SSL, TLS, Блог компании 1cloud.ru, информационная безопасностьПоловина сайтов использует HTTPS, и их число стабильно увеличивается. Протокол сокращает риск перехвата трафика, но не исключает попытки атак как таковые. О некоторых их них — POODLE, BEAST, DROWN и других — и способах защиты, мы расскажем в нашем материале.
Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind
2019-04-06 в 21:51, admin, рубрики: Debian, devops, dkim, DNS, dovecot, iptables, IPv6, openvpn, postfix, rdns, roundcube, route, spamassassin, spf, SSL, Настройка Linux, Системы обмена сообщениямиДанная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6. С шифрованием TSL.
С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.
Если вы не хотите изучать эти все технологии, но хотите настроить такой сервер — тогда эта статья для вас.
В статье отсутствуют попытки пояснить каждую деталь. Пояснение идёт к тому, что настроено не стандартно или важно с точки зрения потребителя.
Читать полностью »
HTTPS не всегда такой безопасный, как кажется. Уязвимости найдены у 5,5% сайтов HTTPS
2019-04-04 в 8:24, admin, рубрики: beast, BREACH, CRIME, Heartbleed, HTTPS, poodle, SSL, TLS, Блог компании GlobalSign, информационная безопасность, криптография, Разработка веб-сайтов, Серверное администрирование
Один из топовых сайтов Alexa (центральный кружок), защищённый HTTPS, с поддоменами (серым) и зависимостями (белым), среди которых есть уязвимые (штриховая заливка)
В наше время значок защищённого соединения HTTPS стал стандартным и даже необходимым атрибутом любого серьёзного сайта. Если сертификат отсутствует, почти все последние браузеры показывают предупреждение, что соединение с сайтом «не защищено» и не рекомендуют передавать на него конфиденциальную информацию.
Но оказывается, что наличие «замочка» в адресной строке не всегда гарантирует защиту. Проверка 10 000 ведущих сайтов из рейтинга Alexa показала: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. По словам авторов исследования, сложность современных веб-приложений многократно увеличивает поверхность атаки.
Читать полностью »
IETF одобрили ACME — это стандарт для работы с SSL-сертификатами
2019-03-23 в 15:48, admin, рубрики: 1cloud, acme, IT-стандарты, SSL, Блог компании 1cloud.ruIETF одобрили стандарт Automatic Certificate Management Environment (ACME), который поможет автоматизировать получение SSL-сертификатов. Расскажем, как это работает.
Kорона корпоративной безопасности — как защитить данные на уровне баз данных
2019-03-13 в 18:38, admin, рубрики: database, Microsoft SQL Server, mssql, SSL, TLS, Администрирование баз данных, Анализ и проектирование систем, информационная безопасностьПресса снова весь прошлый год шумела по поводу утечек баз данных.
В то время как многие организации считают это неизбежным злом, но реальность такова, что есть много вещей, которые предприятия могут сделать прямо сейчас, чтобы предотвратить несанкционированный доступ к их системам и данным.
Читать полностью »
Идёт массовый отзыв TLS-сертификатов от множества УЦ, по ошибке сгенерированных на 63-битном ГСЧ вместо 64-битного
2019-03-13 в 13:54, admin, рубрики: EJBCA, RFC5280, SSL, TLS, Блог компании GlobalSign, браузеры, ГСЧ, информационная безопасность, криптография, энтропияТри дня назад в списке рассылки mozilla.dev.security.policy опубликовано сообщение о массовом нарушении в генерации TLS-сертификатов. Как показало расследование, пострадало несколько удостоверяющих центров, в том числе GoDaddy, Apple и Google. Общее количество неправильных сертификатов превышает 1 миллион, а может быть намного больше. GoDaddy первоначально назвала цифру в 1,8 млн сертификатов, а потом уменьшила оценку на два порядка, до 12 000. Представитель Apple назвал цифру 558 000 сертификатов.
Суть в том, что все пострадавцие УЦ использовали open source PKI-решение EJBCA с неправильными настройками, в результате чего для последовательных номеров сертификатов использовались случайные числа из 63-битного пространства, что нарушает требования CA/B Forum по минимальной энтропии (64 бита).
Разница между 263 и 264 превышает 9 квинтиллионов, то есть 9×1018, это очень существенное число (хотя разница всего в два раза). Все сертификаты должны быть отозваны. У SSL.com и GoDaddy процедура займёт 30 дней, у других могут быть примерно такие же сроки, хотя по стандарту RFC5280 они обязаны отозвать некорректные сертификаты в пятидневный срок. Но они очевидно не успевают вложиться в норматив.
Читать полностью »
Анализ последних массовых атак с захватом DNS
2019-02-21 в 16:51, admin, рубрики: Certificate Transparency Logs, DNS, DNS hijacking, DNSpionage, DNSSEC, epp, Extensible Provisioning Protocol, Frobbit, Key-Systems, Netnod, Packet Clearing House, PCH, SSL, информационная безопасность, Сетевые технологии
Правительство США и ряд ведущих компаний в области информационной безопасности недавно предупредили о серии очень сложных и распространённых атак DNS hijacking, которые позволили хакерам предположительно из Ирана получить огромное количество паролей электронной почты и других конфиденциальных данных у нескольких правительств и частных компаний. Но до сих пор подробности произошедшего и список жертв хранились в тайне.
В этой статье постараемся оценить масштаб атак и проследить эту чрезвычайно успешную кампанию кибершпионажа от начала и до каскадной серии сбоев у ключевых поставщиков инфраструктуры интернета.
Читать полностью »
Хостинг Node.js https сервера с авто-обновляемым SSL в облаке и как я настроил цикл разработки (+ git, react)
2019-02-12 в 8:15, admin, рубрики: LetsEncrypt, node.js, React, SSLПредисловие
Начну с того, что однажды мне захотелось создать приложение. Желание такое возникло из-за того, что я люблю читать, а нормальных книжных агрегаторов на просторах русского интернета просто нет. Собственно из боли поиска чего бы почитать и попыток вспомнить как называлась та книжка, которую я недавно читал и на какой же главе я остановился, родилось желание сделать веб-приложение, в котором всё это было бы возможно и удобно. Стоит отметить, что никакого опыта разработки, программирования и т.п. у меня не было, моя работа вообще с этим не связана. Тем не менее желание перебороло лень и переросло в конкретные действия, своеобразное хобби.
Не буду рассказывать как я изучал javascript, node.js, react, html, css и т.п., перейдём к тому, к чему я пришел на данный момент, чем хотел бы с вами поделится и, конечно, послушать конструктивную критику специалистов.
Как и многие я тренировался на собственном ПК на localhost:3000, создавал front/back-end'ы, верстал, работал с api и т.д., но меня всегда тревожила мысль а том, как же всё это потом перенести на хостинг? Будет ли оно работать? Нужно ли будет переписывать из-за этого код? И самое главное, нельзя ли всё настроить так, чтобы я мог работать над приложением с любого ПК и легко переносить всё на хостинг на production? Об этом я и расскажу.
Читать полностью »
Доменные имена с валидным SSL для локальных Docker-контейнеров
2019-02-11 в 9:38, admin, рубрики: DNS, docker, domains, SSL, Программирование, Разработка веб-сайтов, халявка
Использование Docker в процессе разработки стало уже стандартом де-факто. Запускать приложение со всеми его зависимостями, используя всего одну команду — становится всё более и более привычным действием. Если приложение предоставляет доступ используя web-интерфейс или какое-либо HTTP API — скорее всего "фронтовой" контейнер пробрасывает свой, уникальный (среди остальных приложений, разработкой которых вы занимаетесь параллельно) порт в хост, постучавшись на который мы можем взаимодействовать с приложением в контейнере.
И это отлично работает, пока у вас не появляется целый зоопарк приложений, переключение между которыми начинает вызывать некоторые неудобства, так как надо помнить и схему, и порт, и где-то фиксировать какие порты для какого приложения вы когда-то выделили, дабы не возникло коллизии со временем.
А потом ещё тебе хочется проверить работу по https — и приходится либо использовать свой корневой сертификат, либо всегда использовать curl --insecure ..., а когда над приложениями работают различные команды — количество запар начинает возрастать в геометрической прогрессии.
Столкнувшись с такой проблемой в очередной раз — в голове промелькнула мысль "Хватит это терпеть!", и результатом работы на паре выходных стал сервис, который решает эту проблему на корню, о чем будет рассказано ниже. Для нетерпеливых, традиционно — ссылочка.