Subject: Re: Проблемы с сертификатами на сайте cypherpunks.ru

From: Taine <[email-masked]>
Date: Thu, 27 Jul 2017 16:22:49 -0400

-------- Original Message --------

> Subject: Re: Проблемы с сертификатами на сайте cypherpunks.ru
> Local Time: July 27, 2017 8:24 AM
> UTC Time: July 27, 2017 8:24 AM
> From: [email-masked]
> To: [email-masked]
> Приветствую!
> *** Taine <[email-masked]> [2017-07-27 10:31]:
>>Хочу обратить ваше внимание на проблемы с сертификатами на ваших ресурсах.
>>https://www.cypherpunks.ru:
>>www.cypherpunks.ru uses an invalid security certificate. The certificate is not trusted because it was signed using a signature algorithm that was disabled because that algorithm is not secure. The certificate is only valid for wkd.stargrave.org Error code: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
>>cypherpunks.ru: unable to connect
>>https://git.cypherpunks.ru: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED
>>Эти проблемы подрывают доверие к ресурсам. Посмотрите, например, обсуждение здесь:
>>https://www.pgpru.com/comment96074
> Во-первых, скорее придирка: официально HTTPS версии www.cypherpunks.ru
> -- нет. По-умолчанию там обслуживается домен wkd.cypherpunks.ru, так как
> WKD система обнаружения ключей OpenPGP в GnuPG требует TLS соединения
> (http://www.opennet.ru/tips/2986_pgp_gnupg_key_sign.shtml). К сожалению,
> у меня один IP адрес обслуживает несколько доменов, в том числе TLS-ных.
> Во-вторых, возникает, естественно вопрос, почему не сделать HTTPS версию
> www.cypherpunks.ru? А зачем? Что это даст?
> Если, допустим, сертификат будет самоподписанным, то аутентификацию это
> не даст (пользователь не может быть уверен что говорит именно с этим
> сервером), но может защитить хотя бы HTTP GET запросы с ссылками от
> просмотра сторонними людьми (которые не делают MitM). Таким образом:
> лучшая *возможная* приватность посещаемых мест, но отсутствие их
> аутентификации.
> Если сертификат будет подписан CA, как это предполагается в большинстве
> случаев, то это даёт аутентификацию того, что навряд ли сосед сможет
> сделать MitM который вы не заметите. Но, сильные мира сего -- всё-равно
> смогут. Центры сертификации, даже самые крупные, не раз пятнали свою
> честь ошибками, халтурой и проблемами с безопасностью. Даже если бы и
> очень грамотно всё делали -- всегда есть возможность прийти ФСБшнику
> (АНБшнику) и потребовать выдать действительный сертификат чтобы провести
> MitM. Таким образом: аутентификация только от некоторых лиц, но
> всё-равно ещё не гарантия и уверенность что MitM не произведён.
> Чтобы гарантировать хорошую аутентификацию и защиту от MitM, то речи о
> посредниках и третьих лицах быть не может -- CA, как и весь PKI в целом,
> не работает на практике, потому-что вместо вопроса "могу ли я доверять
> этому серверному сертификату?", возникает "могу ли я доверять этому
> CA?". Так как у преобладающего большинства пользователей второго вопроса
> не возникает, то создаётся впечатление что PKI работает.
> В идеале, человек должен какими-то сторонними каналами связи попытаться
> получить доверие к сертификату на сервере. В идеале, это личная встреча с
> доверяемыми людьми. Само собой, на практике это мало реализуемо. Однако,
> можно использовать хотя бы сеть доверия, как OpenPGP web-of-trust. Для
> этого я на странице "Доступности ресурса" (http://www.cypherpunks.ru/Availability.html)
> разместил: http://www.cypherpunks.ru/certs.pem.asc
> Каюсь, только сейчас обнаружил что, последний раз как создавал этот
> файл, там была только подпись, но без данных (без самих сертификатов).
> Таким образом, у вас есть возможность получить заверенный серверный
> сертификат с возможностью аутентифицировать его через мой публичный
> ключ, подписанный самыми разными людьми. Я понимаю, что при самом первом
> заходе по HTTP, MitM может вообще вырезать эту ссылку/страницу и никто
> не узнает что там была эта информация. Но эта проблема актуальна везде
> при bootstrap-е: если у вас нет *никакой* для аутентификации, ничего
> чему бы можно было доверять, то возможность MitM неизбежна.

С моей точки зрения, если https использовать, то стоит всё-таки настроить его так, как принято. Использовать Let's encrypt. (Может быть cacert.org, но это уже проблемно). Как минимум это снимет все вопросы. Без этого может создаться впечатление, что вы просто небрежны или не умеете этого делать. Ещё одна неприятность - не работает версия без www.
То, что PKI не работает в общем случае, хорошо известно. Но ничего существенно лучше для публичного использования у нас нет. Convergence и TACK от Moxie Marlenspike не взлетели.
Также нельзя сказать, что PKI не работает во всех случаях. Как минимум она защищает от нетаргетированного примитивного mitm (провайдером или на выходе из tor). При этом от таргетированной атаки серьезной защиты нет в случае простого клиент-серверного приложения или сайта. Например, может быть взломан провайдер и подменено содержимое, при этом https или onion останутся неповрежденными.
В общем, с https всё более-менее ясно, тут речь скорее о том, что либо его совсем отключить, либо сделать как принято. Да, кстати, вы не знакомы с SATtva с pgpru.com? Ваши ресурсы во многом близки по тематике.

> Но есть и ещё одна возможность аутентифицировать сервер к которому
> подключились: зайдя на его .onion адрес, адрес которого, знание
> которого, уже является аутентифицирующей информацией. Вместо получение
> подписанного OpenPGP файлика, создание сети доверия, можно просто хотя
> бы как-то доверенно (от знакомых/друзей/сторонними каналами связи)
> узнать .onion адрес.
> Если пользователь действительно парится о том чтобы его HTTP GET запросы
> не были видны, то я уверен что он достаточно опытен и осведомлён о том
> как пользоваться Tor сетью и наверняка ещё и захочет иметь свой IP адрес
> приватным -- поэтому такой пользователь всё-равно захочет пойти по
> .onion адресу. А всем остальным, я уверен -- плевать. Поэтому просто так
> создавать HTTPS версию www.cypherpunks.ru я и не вижу смысла.

На практике всё немного сложнее. Например, я обычно оставляю ссылки на обычные интернет-ресурсы, а не их скрытые сервисы, поскольку пока не предполагаю, что у большинства есть Тор-браузер. Вот и в этот раз я оставил ссылку на ваш сайт, причем на автомате написал https. В итоге пользователи, которые перешли по ссылке, увидели неправильную конфигурацию https и сделали преждевременные выводы.
Подводя итог, мое мнение такое: или отключить https совсем (перенести ресурс за https на другой адрес), или сделать как общепринято. Да, есть ещё вариант добавить FAQ, почему https нет. Но, боюсь, это не самая эффективная мера.

> Если пользователь доверяет CA, то у меня большие пребольшие сомнения что
> он это делает осознанно -- обычно доверие к ряду CA просто навязывается
> поставщиками броузеров (возможно операционных систем). И обычно это
> какая-нибудь корпорация типа Google за пользователя решила кому можно
> доверять, а кому нет. Недавнее "закрытие" доверия к китайским CA
> показывает только то, что это сплошная необъективная политика: на крупные
> fail-ы "западных" CA закрывают глаза, а на этих мол не могут, ведь они
> же ещё и бесплатно раздавали сертификаты, подрывая бизнес PKI.
> Любой криптограф вам подтвердит что PKI это, в первую очередь, бизнес.
> PKI, признаю, is good enough зачастую, но лично я, автор www.cypherpunks.ru,
> категоричен и считаю что или безопасность "делать" нормально и достойно,
> или это будет лишь иллюзией безопасности. А иллюзия безопасности хуже
> чем осознанное отсутствие -- потому-что риски человек уже не в состоянии
> будет оценить.

Всё это очень резонно. Наверно стоит добавить и FAQ, и https отключить в таком случае.

> Я например никоим образом не хочу сказать что Tor является очень
> достойной технологией и очень безопасной (есть куда более технологически
> развитые), я нисколько не его поклонник, но уж "сломать" аутентификацию
> .onion ресурсов на практике в нём пока невозможно -- поэтому .onion
> предоставляю. А вот OpenPGP уже достойная безопасность -- если конечно
> пользователи аккуратно будут с ним обращаться.
> Я хочу чтобы люди задумывались "почему этот ресурс не делает HTTPS?", а
> не слепо верили иконочке в броузере, где за вас решение, как правило,
> приняла одна из крупных корпораций. Если это подтолкнёт хотя бы к паре
> мыслей о том кому можно доверять, кому нет, как провести аутентификацию
> удалённой стороны -- то, я считаю, цель шифропанка уже начинает достигаться.
> Недавно например я узнал что Gmail, при чтении приходящих писем, он
> показывает что возможно письмо не доверяемое, потому-что SMTP сессия не
> была проведена по TLS. Вот только вопрос: а если бы была, но с
> самоподписанным сертификатом, то стала бы доверенной? Если нет, то
> значит в Google есть личные закрытые критерии оценки кому можно
> доверять, а кому нет. Если это CA типа китайских, то политически они им
> не доверяют и поэтому, видите ли, письмо будет тоже недоверенным. Нет
> ничего хуже чем делать иллюзию безопасности. Вот недействительная
> подпись -- настоящая проблема.
> --
> Sergey Matveev (http://www.stargrave.org/)
> OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF