to post messages and comments.

Насколько реально влияет на SEO сертификат? HTTPS DV вместо HTTP, HTTPS OV вместо DV? Symantec вместо Comodo? На месте тех, кто продаёт, я бы тоже так писал, как по волшебству подрастёт посещаемость, ну а реально? Вроде только Гугл так делал, и то уже отменил.

Пока что я вижу, что при пересечении всяких там российско-китайских границ на университетских проксях не сможет кешироваться ничего, и в России если с сайта что-то в блок попадёт, то сайт грохнется сразу весь. И, самое неприятное, либо как-то ужимать поддомены сайта в один-два, либо брать несколько вайлдкардов, потому что в отличие от DNS, звёздочка в сертификате работает только на один уровень вложенности. Когда сайты делал, сроду не думал, как потом натянуть на них TLS. Мог, хотел и делал хосты до пятого уровня вложенности. Всё равно виртуально. И-таки потом успешно перетаскиваю по частям на VDS.

Либо как-то на Аде написать, чтоб при обнаружении по SNI запроса на неопознанный поддомен так же на лету по API запрашивался бесплатный DV сертификат от Comodo и/или Let's Encrypt, сохранялся и сразу использовался в соединении. Или скомбинировать: на сайте, где пользователь может тыкнуть адресную строку мышкой, хороший сертификат, а внутри — бесплатные DV.

Смотрю и думаю, а зачем. Может, подождать, вдруг TLS станет не таким дебильным? SNI же как-то дождались.

Рунет перейдёт на отечественное шифрование
В России внедрят собственные средства шифрования, а разработчиков браузеров обяжут поддерживать российские сертификаты безопасности. Это следует из госпрограммы «Цифровая экономика», подготовленной на межведомственной комиссии Минкомсвязи и отправленной на согласование в правительство.
Согласно проекту программы (есть у «Известий»), к 2021 году большинство участников информационного взаимодействия в цифровой экономике будут использовать отечественные средства шифрования. По словам президента Фонда информационной демократии и главы рабочей группы, отвечающей за раздел «Информационная безопасность», Ильи Массуха, в документе поставлена задача заставить производителей браузеров перейти на отечественные средства криптографии.
— Школы шифрования в мире, по сути, две — Россия и США, плюс Китай сейчас занялся этим вопросом. Наши алгоритмы очень надежны. Они одобрены специальным комитетом Международной организации по стандар­ти­за­ции (ISO),—- отметил эксперт. — Но крупнейшие мировые IT-корпорации не хотят их встраивать в свои браузеры. Госпрограммой мы поставили такую задачу. Илья Массух рассказал, что сейчас при безопасном соединении в интернете используются лишь американские сертификаты безопасности. В случае санкций против России владельцы сертификатов смогут очень просто их отозвать.

Прямо в точку! Хорошо, что этим делом занялись. Подпись бинарников ещё не забудьте. Поезд на WebAssembly ещё далёк от отъезда, вот давайте туда вклинивайтесь, сейчас в самый раз этим заняться.

CVE-2016-2183
Block cipher algorithms with block size of 64 bits (like DES and 3DES) birthday attack known as Sweet32

This is a cipher vulnerability, not limited to any specific SSL/TLS software implementation. DES and Tripple DES (3DES) block ciphers with a block size of 64 bits, have a birthday bound of approximately 4 billion blocks (or 2 to the power of 32, hence the name of this vulnerability). A man-in-the-middle (MitM) attacker, who is able to capture a large amount of encrypted network traffic, can recover sensitive plain text data.
CVE: CVE-2016-2183
NVD: CVE-2016-2183
CVSSv2: AV:N/AC:L/Au:N/C:P/I:N/A:N

Reference:
https://sweet32.info/
https://access.redhat.com/security/cve/cve-2016-2183
https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Evidence:
Cipher Suite: TLSv1_1 : DES-CBC3-SHA
Cipher Suite: TLSv1_2 : DES-CBC3-SHA
Remediation:
This issue can by avoided by disabling block ciphers of 64 bit length (like DES/3DES) in all the SSL/TLS servers. Exact procedure depends on the actual implementation. Please refer to the documentation of your SSL/TLS server software and actual service software (http server, mail server, etc).

Получил сертификат Authenticode для подписи Open Source от Certum. Приятно, что вписали имя кириллицей. "CN=Open Source Developer, Левашев Иван Александрович". В качестве дополнительного удостоверяющего личность документа подошёл загранпаспорт, а в качестве проекта — SOM-Delphi, хотя, наверное, лучше иметь в запасе что-нибудь более репрезентативное. Всё по e-mail и достаточно оперативно.

Обнаружил, что в IceDragon (FireFox) ru.wikipedia.org резолвится не в 91.198.174.192, а в 5.189.172.38 с невалидным самоподписанным сертификатом
/C=AQ/ST=East Antarctica/L=Lake Vostok/O=XYZ/OU=Microbe Division/CN=xyz-httpserver-uates.com/[email protected]

Ни про этот IP, ни про xyz-httpserver-uates.com полезного не нашёл.

Потом протёр глаза и увидел, что домен в браузере на самом деле ru.wikipedia.net.ru, а вовсе не org, который я начал ковырять в командной строке nslokoup, ping, openssl s_client, и перекинул меня на этот домен Яндекс через третью ссылку по запросу "GNAT LLVM". Весь этот wikipedia.net.ru принадлежит какому–то «XYZ», и с DNS серверами q1.jjputx.com и q2.jjputx.com та же история.

Я думал, Chrome и Firefox игнорят сертификат для моих доменов из–за того, что я их понапихал штук 70 в один сертификат, но всё не мог найти в Интернете, а какой же там предел. Нет, оказывается, это ..domain.tld не прокатывает, где бы ни находился, хоть в начале списка, хоть в конце. Причём, .domain.tld в этом списке тоже находится, но не покрывает домен четвёртого уровня. Вот если поставить .subdomain.domain.tld, то работает. Печально, слушай. Придётся больше работать над списком.

ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Synopsis:
The remote service encrypts traffic using a protocol with known weaknesses.
Impact:
The remote service accepts connections encrypted using TLS 1.0. These versions of TLS reportedly suffer from several cryptographic flaws. An attacker may be able to exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients.
Resolution:
Consult the application's documentation to disable TLS 1.0. Use TLS 1.1 or higher instead.

Здравствуйте, дорогие инженеры apple, которые решили не обновлять реализацию TLS в iOS.
Идите нахуй.

P.S. В iOS версия OpenSSL — 0.9.8, и про NPN даже не слышала. Так что никакого блядь SPDY через TLS.

если шифрование станет обязательным То джаббер потеряет многих пользователей. Которые пользуются только джаббер клиентами на j2me. так как нет клиента с шифрованием.

Мне нужно, чтобы у каждого потока была своя переменная. Что для этого можно заюзать легкого? Может быть, есть какой-то изящный хак? Про POSIX TLS знаю, но испытываю перед ним суеверный страх.

pagekite.net PageKite — прикольный реверс прокси с поддержкой туннелирования от бекэндов к фронтэндам. Поддерживает TLS и SNI. Умеет цепочки прокси для туннелей от бэкэнда к фронтэнду. Умеет несколько бэкэндов к одному фронтэнду и несколько фронтэндов к одному бэкэнду.

kousec.com
Заметил, что появилась новая версия OrenOSP, почти единственного реверс прокси, умеющего IPv6, TLS и SNI одновременно. Уже ломанул, осталось проверить, снято ли дурацкое ограничение на 6 дополнительных профилей SSL

Что делать с внешним сертификатом ? к примеру от StartCom
как сделать pem к примеру для ejabberd ?

Имеем
ssl.key (закрытый\приватный ключ созданный нами)
ssl.crt (наш возвращённый от регистратора сертификат)
ca.crt (корневой сертификат регистратора )
sub.class1.xmpp.ca.crt (открытый ключ для сертификатов первого класса — бесплатных)

Снимаем пароль с приватного ключа
openssl rsa -in ssl.key -out ssl_nopass.key

Создание цепочки
cat ssl.crt ssl_nopass.key sub.class1.xmpp.ca.crt >ejabberd.pem

Собственно все, важен порядок ключей и состав иначе будет сыпать ошибками.

PS Проверка openssl s_client -connect your.server.org:5223 -CAfile /path/to/ca.crt

Если
----
verify return:1
CONNECTED(00000003)
---
всё ок

иначе
--------
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
--------
в цепочке ошибки
по мотивам hyperstruct.net

Что-то я запутался нафег в конфигурационных файлах exim'а. Где блин вписать, чтобы он юзал STARTTLS? Сертификаты exim.crt и exim.key созданы, а на EHLO localhost отвечает только PLAIN и CARM-MD5 %) Еще и к DBMail это все нужно прикрутить...