LINUX.ORG.RU
решено ФорумTalks

Почему https реализовали на сертификатах, а не на E2E, например по протоколу Диффи-Хеллмана?

 , ,


0

1

Интересно почему так исторически сложилось. Наверняка этот вопрос обсуждался где-то и были альтернативы. Кто-нибудь в курсе? А то я даже не знаю как правильно составить запрос в гугл.

★★★★★

Как я понимаю потому что надо не только зашифровать, но и удостоверить.

torvn77 ★★★★★
()
Ответ на: комментарий от MrClon

Я не силён в криптографии. Поэтому интересно от чего топили за центры сертификации, наверняка были независимые алгоритмы.

InterVi ★★★★★
() автор топика
Ответ на: комментарий от InterVi

Если и были, то где-то в зоне 51, рядом с зелёными человечками, ковчегом завета и третьей частью Халфлайф.
Мне о таких ничего не известно. Без третьей доверенной стороны, или предварительного обмена публичными ключами по доверенному каналу, защитить первое (а значит и все последующие) соединение от MitM, который может вмешиваться в трафик, нельзя. Если знаешь какой-то способ, то расскажи о нём разрабам ssh, напрягает при первом конекте к хости перепроверять отпечаток ключа или полагаться на авось

MrClon ★★★★★
()
Ответ на: комментарий от InterVi

реализовали на сертификатах, а не на E2E, например по протоколу Диффи-Хеллмана?

TLS как раз по сути «E2E», ключ должен быть известен только серверу и клиенту. И алгоритмы самые обычные, в том числе протокол Диффи-Хеллмана (в TLS 1.3 для обмена ключом - только протокол ДХ, для forward secrecy).
А сертификаты нужны, чтобы можно было убедиться, что ты подключаешься к ЛОРу, а не серверу тов.майора, иначе можно сделать активный MitM. Вот пока что придумали PKI с центрами сертификации.

TheAnonymous ★★★★★
()
Ответ на: комментарий от InterVi

Потрать 10 минут на подумать, поищи способы удостоверить (проверить отсутствие MitM) того, с кем впервые говоришь. Из здравого смысла понятно, что фиг это сделаешь без доверенной третьей стороны.

PKI же - всего лишь кривая, но хорошо масштабируемая реализация этой третьей стороны.

t184256 ★★★★★
()
Ответ на: комментарий от t184256

нельзя бутстрапнуть без доверенной третьей стороны

В принципе, если как биткоины с proof-of-work, то можно проверить эвристически - какие бы вычислительные мощности потребовались, чтобы намайнить такую цепь на данный момент времени.
Если это будет глобальная сеть, которая постоянно майнит, то никакой майор даже с суперкомпьютером не сможет сравниться и выдать похожую картинку.

TheAnonymous ★★★★★
()
Последнее исправление: TheAnonymous (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

то можно проверить эвристически - какие бы вычислительные мощности потребовались, чтобы намайнить такую цепь на данный момент времени.

А товарищ майор подвинет дату запуска блокчейна и ты обломишься.

Все равно получается доверие третьей стороне нужно, теперь в датах и оценках на мощность.

t184256 ★★★★★
()

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

CaveRat ★★
()
Ответ на: комментарий от t184256

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

Хотя тогда можно сказать, что получается доверие к диску с дистрибутивом, но тогда доверие нужно в любом случае. «Бутстрапиться» с чистого винта в любом случае не получится, а так товарищ майор может встроить троянов в твой установочный CD с убунтой и дальше всё не имеет смысла.

TheAnonymous ★★★★★
()
Ответ на: комментарий от TheAnonymous

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

Поздравляю, ты изобрел текущую схему бутстрапа PKI, только хуже =)

t184256 ★★★★★
()
Ответ на: комментарий от CaveRat

да я тупанул и не подумал о митм, только про шифрование трафика

InterVi ★★★★★
() автор топика
Ответ на: комментарий от t184256

Речь не про бутстрап, а про саму PKI. Допустим, локальному винту мы доверяем (иначе всё совсем плохо) и чистую ОС с браузером мы где-то взяли.

Тогда с текущей PKI майор может выпустить левый сертификат от любого доверенного CA, слушать трафик, и ты этого никак не узнаешь (если не настроил пиннинг). Даже когда запилят Certificate Transparency, т.к. он централизованный, майор в принципе может занести гуглу, чтобы тот сказал тебе, что сертификат подлинный (а остальным про него ничего не говорил).
В случае с блокчейном такое не пройдёт, потому что заносить тупо некому.

только хуже

Хотя да, проблем тоже хватает

TheAnonymous ★★★★★
()

Потому что тут ошибка в самом вопросе

HTTPS (вернее, SSL/TLS) вполне себе может использовать DH, как и ECDH для обмена ключами. Вот только надобность аутентификации это никак не отменяет, для этого и используется PKI.

segfault ★★★★★
()
Ответ на: комментарий от CaveRat

атака [...], которая использует слабости DH

Logjam основана на понижении уровня шифрования до экспортного уровня, где длина ключа составляет 512 бит.

downgrade-атака на неаутентифицированый хендшейк

И действительно.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от TheAnonymous

Кстати, а блокчейн защищает от МиТм? Разве активный посредник не может эмулировать существование внешней сети с 99% большими мощностями? В случае криптовалют не актуально, т.к. хеш имеет ценность, только попав в настоящую внешнюю сеть.

next_time ★★★★★
()
Ответ на: комментарий от next_time

эмулировать существование внешней сети с 99% большими мощностями

Может, но тогда ему нужны эти мощности, иначе откуда он возьмет хеши?

TheAnonymous ★★★★★
()
Ответ на: комментарий от TheAnonymous

1) можно скорректировать целевое число

2) блокчейн в оригинале требует хранить информацию обо всех транзакциях, а там опять нужна цифровая подпись => сертификаты

next_time ★★★★★
()
Ответ на: комментарий от next_time

1) можно скорректировать целевое число

Это будет видно и если сложность вдруг внезапно станет на много порядков ниже, чем была обычно, значит будет понятно, что что-то не так

2

Что имеется в виду?

TheAnonymous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.