Рубрика «SSL»

Говорим о том, что собой представляет технология DANE для аутентификации доменных имен по DNS и почему она не получила широкого распространения в браузерах.

Есть мнение: технология DANE для браузеров провалилась - 1Читать полностью »

Половина сайтов использует HTTPS, и их число стабильно увеличивается. Протокол сокращает риск перехвата трафика, но не исключает попытки атак как таковые. О некоторых их них — POODLE, BEAST, DROWN и других — и способах защиты, мы расскажем в нашем материале.

Потенциальные атаки на HTTPS и как от них защититься - 1 Читать полностью »

Данная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6. С шифрованием TSL.
С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.
Если вы не хотите изучать эти все технологии, но хотите настроить такой сервер — тогда эта статья для вас.
В статье отсутствуют попытки пояснить каждую деталь. Пояснение идёт к тому, что настроено не стандартно или важно с точки зрения потребителя.
Читать полностью »

HTTPS не всегда такой безопасный, как кажется. Уязвимости найдены у 5,5% сайтов HTTPS - 1
Один из топовых сайтов Alexa (центральный кружок), защищённый HTTPS, с поддоменами (серым) и зависимостями (белым), среди которых есть уязвимые (штриховая заливка)

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

Но оказывается, что наличие «замочка» в адресной строке не всегда гарантирует защиту. Проверка 10 000 ведущих сайтов из рейтинга Alexa показала: многие из них подвержены критическим уязвимостям протоколов SSL/TLS, обычно через поддомены или зависимости. По словам авторов исследования, сложность современных веб-приложений многократно увеличивает поверхность атаки.
Читать полностью »

IETF одобрили стандарт Automatic Certificate Management Environment (ACME), который поможет автоматизировать получение SSL-сертификатов. Расскажем, как это работает.

IETF одобрили ACME — это стандарт для работы с SSL-сертификатами - 1Читать полностью »

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

Kорона корпоративной безопасности — как защитить данные на уровне баз данных - 1

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

Три дня назад в списке рассылки 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 - 1

Правительство США и ряд ведущих компаний в области информационной безопасности недавно предупредили о серии очень сложных и распространённых атак DNS hijacking, которые позволили хакерам предположительно из Ирана получить огромное количество паролей электронной почты и других конфиденциальных данных у нескольких правительств и частных компаний. Но до сих пор подробности произошедшего и список жертв хранились в тайне.

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

Предисловие

Начну с того, что однажды мне захотелось создать приложение. Желание такое возникло из-за того, что я люблю читать, а нормальных книжных агрегаторов на просторах русского интернета просто нет. Собственно из боли поиска чего бы почитать и попыток вспомнить как называлась та книжка, которую я недавно читал и на какой же главе я остановился, родилось желание сделать веб-приложение, в котором всё это было бы возможно и удобно. Стоит отметить, что никакого опыта разработки, программирования и т.п. у меня не было, моя работа вообще с этим не связана. Тем не менее желание перебороло лень и переросло в конкретные действия, своеобразное хобби.

Не буду рассказывать как я изучал javascript, node.js, react, html, css и т.п., перейдём к тому, к чему я пришел на данный момент, чем хотел бы с вами поделится и, конечно, послушать конструктивную критику специалистов.

Как и многие я тренировался на собственном ПК на localhost:3000, создавал front/back-end'ы, верстал, работал с api и т.д., но меня всегда тревожила мысль а том, как же всё это потом перенести на хостинг? Будет ли оно работать? Нужно ли будет переписывать из-за этого код? И самое главное, нельзя ли всё настроить так, чтобы я мог работать над приложением с любого ПК и легко переносить всё на хостинг на production? Об этом я и расскажу.
Читать полностью »

preview

Использование Docker в процессе разработки стало уже стандартом де-факто. Запускать приложение со всеми его зависимостями, используя всего одну команду — становится всё более и более привычным действием. Если приложение предоставляет доступ используя web-интерфейс или какое-либо HTTP API — скорее всего "фронтовой" контейнер пробрасывает свой, уникальный (среди остальных приложений, разработкой которых вы занимаетесь параллельно) порт в хост, постучавшись на который мы можем взаимодействовать с приложением в контейнере.

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

А потом ещё тебе хочется проверить работу по https — и приходится либо использовать свой корневой сертификат, либо всегда использовать curl --insecure ..., а когда над приложениями работают различные команды — количество запар начинает возрастать в геометрической прогрессии.

Столкнувшись с такой проблемой в очередной раз — в голове промелькнула мысль "Хватит это терпеть!", и результатом работы на паре выходных стал сервис, который решает эту проблему на корню, о чем будет рассказано ниже. Для нетерпеливых, традиционно — ссылочка.

Читать полностью »