Camellia в более чем два раза медленее AES. пруф.

Это правда, что сертификат привязывает сайт не только к домменому имени, но и к конкретному IP?

Нет.

Тогда, учитывая ваш ответ в /comment53596 и проблемы с Certificate Patrol, получаем, что подпись домена — не просто фенечка.

А Вам не всё равно? ... Если кому-то сильно понадобится наш/Ваш/мой трафик, его снимут прямо с сервера — опять же, что AES, что Camellia не играет никакой роли.

В общем согласен, но, с другой стороны, если это ничего не стоит (поменять дефолты на сервере), то почему бы этим не воспользоваться? Это можно сделать, только меняя сертификат, или достаточно поменять умолчания в настройках сервера? У меня доверия к AES всё-таки больше, чем к Camellia.

Тогда, учитывая ваш ответ в /comment53596 и проблемы с Certificate Patrol, получаем, что подпись домена — не просто фенечка.

Допустим. И что она обеспечит, применительно к нашей модели угрозы?

В общем согласен, но, с другой стороны, если это ничего не стоит (поменять дефолты на сервере), то почему бы этим не воспользоваться?

Я не говорил, что это ничего не стоит.

Мастерхост просто любит согревать окружающий мир. И не забывайте, что AES — стандартный шифр вероятного противника, а Camellia стандарт Японии (к слову с которой Россия не имеет мирного договора). Шило на мыло менять, да ещё с усилием.

И что она обеспечит, применительно к нашей модели угрозы?

Противник скачивает БД сайта мастерхоста, вместе с сертификатом, а потом поднимает сайт-двойник на другом IP. Как на уровне пользователя исключить такую ситуацию? Как забиндить сайт не только на домен и сертификат, но и на IP? Может быть, /etc/hosts?

AES — стандартный шифр вероятного противника, а Camellia стандарт Японии

AES — победитель открытого конкурса НИСТ. Его канидидаты получали внимание исследовательского сообщества, а победитель — тем более. В силу распространённости AES внимание к нему повышенное, потому и вероятность, что мы узнаем нечто новое о слабостях AES, выше (при прочих равных). Camellia этим похвастаться не может. Писать здесь что-то про «шифр потенциального противника» (это скорей терминология ещё с тех времён, когда открытой криптографии не было как класса) может только отставший на лет 50 от прогресса пользователь.

Противник скачивает БД сайта мастерхоста, вместе с сертификатом, а потом поднимает сайт-двойник на другом IP.

Ну так DNSSEC тоже ничем не поможет отцу русской демократии. Против лома нет приёма.

Почему же не поможет? Хотя бы потенциально можно будет сверить подписи в цепочке руками, а там глядишь, и

для контроля ключей DNSSEC что-нибудь аналогичное непременно появится.

а потом поднимает сайт-двойник на другом IP

Зачем на другом? Это ещё ДНС спуфить надо, что можно заметить. Просто на уровне провайдера все запросы на определённый айпи перенаправляются на нужный компьютер. Если секретный ключ SSL-сертификата украден, то никакие подстраховки не помогут.
Параноить хорошо, но надо голову же включать, а не придумывать ересь.

Писать здесь что-то про «шифр потенциального противника» (это скорей терминология ещё с тех времён, когда открытой криптографии не было как класса) может только отставший на лет 50 от прогресса пользователь.

Какой ты скушный, протокол-кун. Уже в терминологию полез. Не запротоколься вконец.

Ох... Если противник получает доступ к площадке хостинг-провайдера, то в его распоряжении будет и сертификат SSL, и ключ домена DNSSEC, которым он сможет заверить хоть айпишник Марса. Как Вы отличите легитимную смену ключей-подписей-IP-SSL от нелегитимной?

Отпечаток серта SSL Вы и сейчас можете проверять руками, сверяясь с тем, который заверен моим PGP-ключом. IP можете прописать в /etc/hosts — он статичный, а о любых изменениях я, опять же, буду уведомлять, заверяя ключом, который ни на одном компьютере не хранится.

Итого, в нашем случае DNSSEC не добавляет ничего сверх уже имеющегося. Просто появляется ещё один секрет, который зачем-то нужно держать под защитой.

Немного оффтоп. SATtva, а вы не предоставляете какую-нибудь возможность просто сверить ваш фингерпринт? Допустим, я не хочу раскрывать своё истинное имя, поэтому key-signing party не вариант, но в целях предотвращения MITM вашего отпечатка будет достаточно. Может быть по телефону диктуете или как-нибудь ещё?

Да без проблем, конечно, если компьютер под рукой в момент звонка.

Зачем на другом? Это ещё ДНС спуфить надо, что можно заметить. Просто на уровне провайдера все запросы на определённый айпи перенаправляются на нужный компьютер.

А если не на уровне провайдера?

Если секретный ключ SSL-сертификата украден, то никакие подстраховки не помогут.

Не уверен. В общем случае — да, а в частном будет зависеть от того где, в каких обстоятельствах и как этот сертификат будет использоваться. Допустим, я вам дам сертификат сайта (то же самое касается и рядового админа мастерхоста). У вас нет административных полномочий и доступа к моему провайдеру, потому широкий класс эффективных и простых атак будет сразу отсечён.

IP можете прописать в /etc/hosts — он статичный

Спасибо, вопрос с DNSSEC снят.

без проблем, конечно, если компьютер под рукой в момент звонка.

Зачем компьютер? Чтобы отпечаток своего ключа посмотреть? :) Ключу анонимного собеседника SATtva всё равно должен будет доверять почти наобум.

Итого, в нашем случае DNSSEC не добавляет ничего сверх уже имеющегося. Просто появляется ещё один секрет, который зачем-то нужно держать под защитой.

Изначально предполагалось, что подпись DNS будет заверена ещё и вашим ключом, потому все могут убедиться. Впрочем, уже неактуально.