Size: a a a

2020 November 20

MS

Max Syabro in ctodailychat
python3 -V? @abespalov
источник

AB

Alex Bespalov in ctodailychat
Python 3.7.3
источник

MS

Max Syabro in ctodailychat
спасибо
источник

ES

Egor Suvorov in ctodailychat
Красивая проблема с красивым предложенным решением: https://habr.com/ru/company/vdsina/blog/528990/

Кратко:

1. DKIM позволяет проверить, что конкретное электронное письмо с заголовками действительно ушло с сервера отправителя.
2. В частности, так можно подтверждать любые утечки писем, если они подписаны DKIM и мы из каких-то кэшей DNS помним публичный ключ сервера.
3. Потенциальная проблема: пользователи на такое не подписывались. А сейчас если утекло письмо из 2015 с Gmail, то можно доказать его подлинность. Если не верить в то, что сам гугл подделал.
4. Предлагаемое решение: устроить ротацию ключей DKIM длиной в, скажем, пару недель. А чтобы нельзя было подтверждать старые письма даже если помним публичный ключ — через какое-то время после ротации публиковать старый приватный. Тогда с момента публикации утечкам доверия нет.
источник

MS

Max Syabro in ctodailychat
источник

С

Слава in ctodailychat
Egor Suvorov
Красивая проблема с красивым предложенным решением: https://habr.com/ru/company/vdsina/blog/528990/

Кратко:

1. DKIM позволяет проверить, что конкретное электронное письмо с заголовками действительно ушло с сервера отправителя.
2. В частности, так можно подтверждать любые утечки писем, если они подписаны DKIM и мы из каких-то кэшей DNS помним публичный ключ сервера.
3. Потенциальная проблема: пользователи на такое не подписывались. А сейчас если утекло письмо из 2015 с Gmail, то можно доказать его подлинность. Если не верить в то, что сам гугл подделал.
4. Предлагаемое решение: устроить ротацию ключей DKIM длиной в, скажем, пару недель. А чтобы нельзя было подтверждать старые письма даже если помним публичный ключ — через какое-то время после ротации публиковать старый приватный. Тогда с момента публикации утечкам доверия нет.
Экая пропаганда в статье. Ах, это даёт возможности шантажистам и журналистам. Как оно лихо в один ряд встало. А если мне как раз надо доказать, что некий жулик вася мне именно писал и именно емейлы с его адреса? Это ведь очень полезный сценарий.
источник

С

Слава in ctodailychat
И персонажа выбрали очень удачно. Подесту обидели злые хакеры, а он всего лишь хотел любить и быть любимым.
источник

ES

Egor Suvorov in ctodailychat
Слава
Экая пропаганда в статье. Ах, это даёт возможности шантажистам и журналистам. Как оно лихо в один ряд встало. А если мне как раз надо доказать, что некий жулик вася мне именно писал и именно емейлы с его адреса? Это ведь очень полезный сценарий.
Конечно , это же политические вопросы:

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

Мне вот было вообще неочевидно, что бывает криптографическое решение (не техническое поле expire), делающее криптографические же доказательства аутентичности бесполезными в определенный момент.
источник

S

Stas in ctodailychat
Egor Suvorov
Красивая проблема с красивым предложенным решением: https://habr.com/ru/company/vdsina/blog/528990/

Кратко:

1. DKIM позволяет проверить, что конкретное электронное письмо с заголовками действительно ушло с сервера отправителя.
2. В частности, так можно подтверждать любые утечки писем, если они подписаны DKIM и мы из каких-то кэшей DNS помним публичный ключ сервера.
3. Потенциальная проблема: пользователи на такое не подписывались. А сейчас если утекло письмо из 2015 с Gmail, то можно доказать его подлинность. Если не верить в то, что сам гугл подделал.
4. Предлагаемое решение: устроить ротацию ключей DKIM длиной в, скажем, пару недель. А чтобы нельзя было подтверждать старые письма даже если помним публичный ключ — через какое-то время после ротации публиковать старый приватный. Тогда с момента публикации утечкам доверия нет.
а чем им шифрование почты не угодило?
источник

ES

Egor Suvorov in ctodailychat
Stas
а чем им шифрование почты не угодило?
Они там грустят не из-за шифрования, а из-за форсированной криптографической подписи вообще всех исходящих писем, причём пользователи и не знают, и не могут отказаться
источник

С

Слава in ctodailychat
Stas
а чем им шифрование почты не угодило?
Им не угодило, что от содержимого писем стало сложно отпираться
источник

S

Stas in ctodailychat
Egor Suvorov
Они там грустят не из-за шифрования, а из-за форсированной криптографической подписи вообще всех исходящих писем, причём пользователи и не знают, и не могут отказаться
ну пользователи, которых это волнует - что они делают на почте гугла? :-)
источник

ES

Egor Suvorov in ctodailychat
Stas
ну пользователи, которых это волнует - что они делают на почте гугла? :-)
Например, используют Google for Business или как там
источник

ES

Egor Suvorov in ctodailychat
На своём домене
источник

S

Stas in ctodailychat
Egor Suvorov
Например, используют Google for Business или как там
то есть они уже дают гуглу доступ к своей почте, если не используют шифрование на своей стороне
источник

ES

Egor Suvorov in ctodailychat
Да и это не вопрос к гуглу, это вопрос к DKIM и как оно вообще используется
источник

ES

Egor Suvorov in ctodailychat
Stas
то есть они уже дают гуглу доступ к своей почте, если не используют шифрование на своей стороне
Это не про доверие к гуглу
источник

ES

Egor Suvorov in ctodailychat
Egor Suvorov
Да и это не вопрос к гуглу, это вопрос к DKIM и как оно вообще используется
Свой сервер с DKIM — ровно те же проблемы. Без DKIM наверняка все письма перестанут доходить
источник

S

Stas in ctodailychat
Egor Suvorov
Это не про доверие к гуглу
я понимаю про что статья, мне кажется способ решения из серии «стрельнуть себе в ногу"
источник

ES

Egor Suvorov in ctodailychat
Stas
я понимаю про что статья, мне кажется способ решения из серии «стрельнуть себе в ногу"
Почему? Администратору сервера в целом пофиг, публиковать или не публиковать ротированные ключи. Аккуратно надо, конечно — чтобы они нигде не использовались для шифрования, например. Только для подписи.
источник