Минцифры предложило запретить протоколы шифрования

это уже будет другой сайт. получить сертификат на чужой домен невозможно, чтоб потом делать митм атаку с валидным сертификатом.

ближайшее будущее будет таким: браузеры запретят вообще http, останется только https протокол, без него ничего не будет работать. и не надо разбираться, пароли там или блог домохозяйки или фотки ее киски.

Эм, согласен, но я о просто шифровании передаваемых данных писал. Для этого не нужны глобальные центры сертификации, достаточно самоподписанного сертификата. От фишинга центры тоже не спасут, поскольку тайпин трафик никто не отменял, подставные ссылки и рекламу по группам и всяким авито - тем более. Сколько народу ведется именно на фишинг с левым доменом, схожим на официал. Центры сертификации наоборот, дезориентируют пользователя, ведь в браузере же показывают "ЗАЩИЩЕННЫЙ". А то, что это вообще сайт не принадлежащий официалу - они и не догадываются. https в данном контексте я рассматриваю лишь как возможность относительно безопасно вводить логины-пароли, будучи подключенным через публичные сети.

А вот в плане защиты от митм и идентификации сайта - тут сам сайт должен иметь определенную степень защиты и самоидентификации. Например, у меня в банкинге при входе показывают уникальную, выбранную мной картинку. Если в процессе авторизации вдруг картинки нет или она будет не моя - все, я не там и дальше просто не авторизуюсь. Это и есть правильная защита: нормальный уровень защиты на сайте + шифрование. И ни для того, ни для другого не нужны центры сертификации, которых расплодилось полным полно и они сами, порой, не вызывают доверия.

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

Я бы на месте браузеров "ЗАЩИЩЕННЫЙ" вообще не показывал, а вот когда "НЕ ЗАЩИЩЕННЫЙ", то информировал.

Я точно говорил "изменить post"? Или может всё-таки об изменении механизма передачи post-запросов? Или для тебя это одно и тоже?

Категорически согласен.

Вот это одно из правильных реализаций!

Передавать, батенька, передавать. Такие ляпы в серьёзных обсуждениях недопустимы ящетаю.

А кто, интересно, "защищенный"? Кем/как?

Считай, что я так сократил фразу "механизм передачи post-запросов". Сути это не меняет, поскольку об этом и речь. Изменить процесс передачи - это создать новый механизм, и получить, например, GET. Вот только по факту, как ты его не меняй, пока ты его не зашифруешь - данные будут идти в открытом виде и доступны для перехвата. Собственно об этом тема. Можно, конечно, предложить шифровать данные, передающиеся через POST, но выльется это в ровной степени в ту же задачу, что и общее сквозное шифрование. А потом начнется, что ой, надо зашифровать еще и GET, а потом зашифровать еще что-то и понеслась. Именно потому проще сделать общее шифрование на поток, а не усложнять каждый отдельный этап. Ибо ты на весь поток поставил одну процедуру "открыть шифрование", а если делать позапросно, то на каждый пук от сайта, на каждую форму, тебе придется заново пересоздавать шифрованное соединение. Короче, мысль об "изменить post" в контексте обсуждения сама по себе крамольна и бессмысленна )

Это-то серьёзное обсуждение? Не смешите мои тапочки ) Прежде чем их передать, их нужно ввести. Не надоедает бессмысленное буквоедство? )

Напоминает старый анек:

— Доктор, я правильно интерпретирую семантику вопроса, но полностью игнорирую его суть.
— Не могли бы вы привести пример, пациент?
— Мог бы.

Меняет в корне.

Если для тебя "ввести" = "передать", а "механизм передачи" = "тело запроса", то пожалуй говорить не о чем. (хрен тебя знает что ты там подразумевал, а ещё страшнее что ты по факту пишешь)

Когда поймёшь, что правильная терминология наше всё - приходи, поговорим.

Именно это и есть один из вариантов изменённого механизма. Шифруется не всё подряд, а только необходимые данные.