файл отрицательного размера

Утром посмотрел на свой предыдущий пост в LJ, опубликованный вчера, а там почему-то картинка пропала. Зашёл в Edit, там url картинки не поменялся. А когда попробовал посмотреть саму эту картинку, firefox сказал, что небезопасно.. Оказалось, что SSLный сертификат на моём веб-сайте сегодня рано утром закончился.

Хотя у меня там в cron приделана команда “certbot-auto renew” для обновления сертификата, выданного Let’s Encrypt, и раньше она успешно работала, а сегодня почему-то нет.
Попробовал запустить эту команду вручную, но она ругнулась на ошибочный код возврата команды “python -m pip –version”, и до обновления сертификата так и не дошла.
Типа, питон не может запустить модуль pip, потому оно и не работает.
Скачал этот скрипт certbot-auto заново с certbot.eff.org, но он точно такой же, ничего не менялось.

Погуглил, оказалось, в нём стОит заменить “python -m pip –version” на “pip –version”, и далее “python -m pip install –no-index –no-deps -U” заменить на “pip install –no-index –no-deps -U”.
Заменил, и тогда “certbot-auto renew” сработал, успешно обновив сертификат на очередные 3 месяца.

Но отчего такое могло случиться – не понимаю, раньше же этот скрипт успешно обновлял сертификат. А в старом Debian 7 (wheezy) уже давно ничего не обновляется, так что и питон не мог поменяться.

Потом ещё посмотрел на свой домашний сервер, где всё ещё использую тот же Debian 7, и оказалось, что и там сертификат не обновляется из-за такой же ошибки. Подправил и там certbot-auto точно так же, и он тоже стал работать.

Оригинал этой записи в личном блоге.

Хоть и самоподписанный, то есть, запрос никому посылать не надо, всё своими руками делается, но вот оказалось, что если в имени хоста больше 64 символов, то openssl ругается на слишком длинную строку для CommonName, и сертификат не получается.

Я задал этот вопрос в ru_root, и там мне посоветовали для длинных имён использовать в сертификате не CN, а SAN (SubjectAltName) – дополнительное поле, которое существует в сертификатах 3 версии. Это оказалось не сильно просто, целый день потратил, многократно гуглив. Поэтому запишу подробности себе на память, ну и если ещё кому такое понадобится:

( Read the rest of this entry » )

Оригинал этой записи в личном блоге.

Юзеры стали жаловаться, что не могут подключиться к одному OpenVPN-серверу. Ко всем остальным нормально, а к этому никак не получается. Проверял их конфиги, вроде всё правильно, посмотрел на сервер (он под pfSense работает), вроде тоже всё нормально. В логи посмотрел — никаких ошибок нету.

Попробовал сам подключиться — да, в натуре, не работает.. А раньше работало. Посмотрел в свой лог, сервер вполне себе отвечает, соединение устанавливается, аутентификация по SSL проходит, но потом соединение мгновенно рвётся. Клиент ещё три раза пытается соединиться — всё то же самое, соединение устанавливается и мгновенно рвётся Ну и потом клиент выключается.

Пошёл сравнивать настройки с другими серверами, где работает. Вроде как всё примерно одинаково, но там работает, а тут нет. Потом случайно нашёл на том же pfSense ещё один OpenVPN, на другом порту, типа, для служебного пользования, а не для юзеров. Попробовал подключиться к нему — работает! Начал внимательно сравнивать конфигурации, разница оказалась в том, что у неработающего сервера в конфиге был указан Certificate Revocation List, а у работающего — нет. Ясное дело, надо проверить, нет ли там лишних сертификатов. Хотя непонятно, кто и зачем мог бы их туда добавить. Скопировал CRL к себе в файлик, запустил openssl crl -in a.crl -text, а он, блин, ругнулся:
unable to load CRL
140046118483600:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:696:Expecting: X509 CRL

Погуглил, как должен выглядеть этот файл в PEM-формате, посмотрел в файл, там в первой строчке ------BEGIN X509 CRL-----, в последней -----END X509 CRL-----, посредине что-то закодированное в base64, вроде всё как надо, а openssl’ю что-то не нравится..

Ну, высококвалифицированные сисадмины, кто понял, что тут не так??
Отгадка, как обычно, под катом.

( Read the rest of this entry » )

Оригинал этой записи в личном блоге.

Впервые в жизни встретил в дикой природе отозванный SSL сертификат.
И где бы вы думали? На сайте британской пограничной службы:

Upd: как обычно, я одним из первых наступил на заботливо разложенные грабли. Посмотрел в revocation list, оказалось, что сертификат был отозван буквально сегодня ночью:

    Serial Number: 709187B1FBBE3A9CAAE55D2D44FBB61D
        Revocation Date: Aug 22 01:04:13 2013 GMT

Оригинал этой записи в личном блоге.

Пару дней назад pidgin внезапно ругнулся на сертификат от гугловского джаббер-сервера. В настройках у меня стоит talk.google.com в соответствии с рекомендациями Гугла, а сертификат почему-то от gmail.com:

Хуже того, через несколько минут он опять ругнулся, и оказалось, что сертификаты для gmail.com бывают разные:

Увидеть сертификат целиком мне не удалось, поэтому я не знаю, бардак ли это в самом Гугле, или это кто-то играет в MITM.
Ни у кого такого в последнее время не наблюдалось?

Оригинал этой записи в личном блоге.

Changelog пакета ca-certificates:
ca-certificates (20090814+nmu3) squeeze-security; urgency=high

* Non-maintainer upload by the Security Team.
* Blacklist "DigiNotar Root CA" (Closes: #639744)

-- Raphael Geissert <geissert @ debian.org>  Tue, 30 Aug 2011 21:37:34 -0500

Если кто ещё не в курсе, рекомендую удалить из всех доступных мест, в первую очередь из собственного браузера, корневой сертификат этих голландских молодцов по имени Diginotar.

Ссылки по теме:
Fraudulent Google credential found in the wild
Did Google certificate forgers hit hundreds more sites?
World ostracizes firm that issued bogus Google credential
Mozilla addons site targeted in same attack that hit Google

Товарищам, в общем, уже не отмыться.

Оригинал этой записи в личном блоге.

позволяет man-in-the-middle вставлять в защищенную сессию собственные данные.

Дыра в дизайне протокола, от реализации не зависит.

Ссылки по теме: http://www.phonefactor.com/sslgap/ http://extendedsubset.com/?p=8

Для плохо понимающих по-английски: http://www.opennet.ru/opennews/art.shtml?num=24132

via [ljuser]sem_lj[/ljuser]

Оригинал этой записи в личном блоге.

Безопасный Слой Гнезд, закодированная ведьмой сессия, имена файла мешанины, убейте шифр от списка полностью и другие перлы

via b_a_t

Upd: ух ты! они всё перевели.
"удалить сердцевину Apacheских особенностей Сервера HTTP, которые являются всегда доступными"
"непереплетенный, предразветвляющийся сервер сети"
"довольный тайник работал ключом к URIs"
"настройка HTTP просит и удары головой ответа"
"динамически формируемое массовое действительное оказание гостеприимства"

что ни фраза - то перл.

"Для того, чтобы воспользоваться «Интернет-Помощником», убедитесь, что:

* Ваш браузер поддерживает протокол безопасности SSL с длиной ключа шифрования не менее 128 бит, сертификат на который выписан Thawte Server CA (например, Microsoft Internet Explorer версии не ниже 5.5 или Mozilla версии не ниже 1.0);"

Я что-то никак не проникнусь смыслом выделенной фразы.
Клиентский сертификат для доступа к этому сайту не нужен.
Сертификат сайта действительно выписан Thawte, но публичный ключ в нём ключ 1024-битовый.
Сессия лично у меня шифруется 128-битовым ключом RC4, но сертификат к нему никакого отношения не имеет.

Так о чём это они?