Алгоритм по обработке персональных данных

вам наверное таки не алгоритм а требования к ПО производящему обработку и передачу персональных данных.

POST, WSS

хорошо-бы (в идеале конечно), когда система имеет следующие возможности:

• «важные данные» криптуются на клиенте (не всегда возможно)
• исключаются «MITM-состояния» (иногда и довольно часто создается иллюзия защищенности)
• deny all :)
• доступ к «важным данным» не возможен без явного личного разрешения владельца (например подпись приватным ключом управляющего сообщения на проведение данной операции с разрешающим mode=rwx соответственно). Сюда же можно отнести, что сервер «не знает пароля» пользователя
• доступ например к файлу возможен, если ты входишь в группу,которой разрешен доступ к данному объекту

«важные данные» криптуются на клиенте (не всегда возможно)

Зачем, если есть SSL?

Зачем, если есть SSL?

Не всегда возможно, доступно...

УЦ бывают «палятся», self-signed сертификаты. Опять же, возможности для MITM.

не панацея ведь, Heartbleed вас ни чему не научил?

POST?

Или в чем вопрос-то?

Пароли не забывай по https отправлять. А остальное — по http можно.

не панацея ведь, Heartbleed вас ни чему не научил?

Здравствуйте, на этом форуме ищут панацею?

Не всегда возможно, доступно...

УЦ бывают «палятся», self-signed сертификаты.

И из-за ССЗБ с self-signed сертификатами ты предлагаешь сделать велосипед, делающий точно то же самое и так же подверженный MITM, не говоря о прочих ошибках, которые возникнут в процессе. Ок.

self-signed неудобно проверять и невозможно подтверждать, а так то-же самое.

Эмм. Можно юзкейс self-signed сертификатов в условиях веба для сторонних лиц (т.е. не внутрикорпоративных)?

Любой может прослушивать/подменять что угодно самоподписанное. Ничерта не отличается от нешифрованного кроме тривиальной работы по подмене сертификата. С нормальным сертификатом всё намного сложнее.

Эмм. Можно юзкейс self-signed сертификатов в условиях веба для сторонних лиц (т.е. не внутрикорпоративных)?

персонального клиентского сертификата не достаточно разве?

Любой может прослушивать/подменять что угодно самоподписанное.

это можно заметить для self-signed: в первую очередь ip

персонального клиентского сертификата не достаточно разве?

Нет, конечно. Как ты можешь гарантировать, что твой клиентский сертификат дойдёт до клиента, а не до MiTM и этот самый MiTM не выдаст новый клиентский твоему клиенту?

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

это можно заметить для self-signed: в первую очередь ip

Как будто это надёжно. Любой, получивший контроль над физическим соединением где угодно от тебя до клиента, может рисовать любые ip.

Если бы всё так просто было, электронные подписи были бы малополезны.

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

локальные? да, наверное можно. Теоретически: подделка пакетов «на ходу» - но это реализовать не просто и тем более что все меняется.

Или речь про то, что 8.8.8.8 например это полный фейк? Ну это уже атака по isp-каналам и все равно это обнаруживается и палится.

Могу ошибаться, но мне кажется подмена ip если и возможна, то чисто теоретически. Практические схемы работают по своим адресам, на которые нужно еще и «загнать», чем и занимаются рыбачки.

Для начала надо вклиниться в ssl-сессию. Незаметно это не прокатит.

Для начала надо вклиниться в ssl-сессию. Незаметно это не прокатит.

Если есть возможность вклиниться в установление самой первой ssl-сессии — прокатывает.

локальные? да, наверное можно. Теоретически: подделка пакетов «на ходу» - но это реализовать не просто и тем более что все меняется.

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

Прямо сейчас эр-телеком спокойно вклинивается в сессии к «запрещённым» ресурсам и выдаёт свой ответ вместо запрошенного. В том числе и к https (выдаёт с сертификатом, валидным для ertelecom.ru). Сейчас ты объяснишь мне, как это обнаруживается. Да, это стоит им денег, но только из-за высокой нагрузки: для одного офиса можно то же самое провернуть софтово.

атака по isp-каналам

Есть же много мест для вклинивания между юзером и сервером.

tl;dr: SSL именно от этого и защищает. С самоподписанным сертификатом он защищать не может, следовательно, самоподписанный сертификат годен разве что для тестирования софта либо при возможности предустановить что-либо на клиентские машины по надёжным каналам.

А вообще как его правильно защищенным формировать. Я именно это и хотел узнать.
Как безопасно на сервер передать пароль?
Https?

Какой общий принцип отправки персональных данных

шифрование и подпись НА КЛИЕНТЕ. Дальше не важно, хоть голубиной почтой.

Однако обрати внимание на риск подмены. Скажем клиент Алиса хочет отправить данные на сервер Боба. Всё будет работать, если Алиса знает публичный ключ Боба. Однако, если НЕ знает, то всё хуже, и Алиса может случайно отправить данные НЕ Бобу, зашифровав их не тем ключом.

Решается например путём TLS/SSL, когда Боб подписывает свой ключ в некой третьей стороне которой доверяет Алиса. Лучше НЕ использовать этот вариант, если Алиса имеет возможность достоверно узнать ключ либо дайджест ключа Боба(а в 95% случаев так оно и есть)

«важные данные» криптуются на клиенте (не всегда возможно)

Зачем, если есть SSL?

SSL это оно и есть. Только ключ для шифрования на стороне клиента для сервера заверен подписью центра сертификации. Или не заверен, если речь про «самоподлписанный» сертификат(в этом случае ключ заверяется как-то иначе, например честным пионерским словом).