(proxy-sniffer)>(ssl-webmail) вопрос

В случае https-web-proxy проверку сертификата целевого сайта (mail-сервера) делает web-proxy, а не ваш браузер. Ваш браузер вообще видит только https-web-proxy.

Считайте, что web-proxy — это как удалённая ОС, причём не под вашим контролем, а под чужим, и вы всё делаете из-под неё. Сами вы можете контролирвать только канал между вами и web-прокси, но не канал между web-proxy и целевым сайтом.

Вбиваете руками или выбирайте адрес мышкой — не важно. Потенциально система имеет доступ ко всем данным. Может хоть скриншоты делать того, что вы там выбираете. Можно надеяться, что что-то технически имплеменчено на стороне web-прокси, а что-то нет, но на концептуальном уровне доверять этому никак нельзя. На http сам сайт или на https — не играет роли, если web-proxy допускается быть злонамеренной.

Web-proxy — половинчатое решение только для двух проблем:

1. Не светится совсем внаглую перед своим же провом (ISP).
2. Не светить свой IP перед mail-сервером (или произвольным целевым сайтом, который посещаете).

Впрочем, и 1 и 2 ненадёжны, если web-proxy злонамеренна:

1. Ваш IP она может не только сливать целевому сайту по первому его запросу, но и вставлять во всякие X-Forwarded-for-поля http-запросов ваш IP.
2. Web-proxy может использовать общедоступный приватный сертфиикат (или хотя бы доступный вашему противнику), что позволит ISP видеть куда вы ходите.

Так или иначе, web-proxy — не решение ни для какого серьёзного дела. Если раскрытие анонимности вам грозит чем-то серьёзным, никогда не пользуетсь web-проксями.

Спасибо за ответ, но Вы не совсем поняли исходные данные, уточню:
Прокси – обычный, вида ip:port, ну, например socks.
Почта – именно об её веб-интерфейсе идёт речь, то есть, подразумевается использование почты по HTTP/HTTPS, а не POP/SMTP.

Тогда

1. Нет. Прокси работет как транспорт вашего полностью зашифрованного трафика. На уровне абстракций считайте, что если между вами и сайтом доверенный^* https, то вам абсолютно всё равно, кто и как маршрутизирует ваш трафик.
2. Да. В этом случае прокси имеет на mail-сервере ровно те же права, что и вы сами: всё видит, а если что-то и не видит, всегда может осуществить имперсонацию и посмотреть.

^*Теоретически это так, но в практическом смысле тут всё тухло: смотрите /comment53596 и /biblioteka/statji/certifiedlies.

Спасибо за информацию, теперь я более-менее спокоен, буду использовать только HTTPS-WebMail.

Если и получатель и отправитель пользуются PGP, то я бы предложил следующую схему:

1. Отправитель анонимно регистрирует анонимный ящик для себя.
2. Отправитель пищет файл-письмо получателю, к которому прикладывает свой новый, специально сделанный для общения с этим абонентом, PGP-ключ. Данный PGP-ключ не должен быть засвечен на серверах ключей или ещё где-то. Все это вместе пакуется в файл-архив.
3. Отправитель подписывает файл-архив со всеми данными (письмо и ключи) тем ключом, который известен получателю, после чего шифрует его ключом получателя (можно даже не раскрывая key-id ключа) и отправляет ему.
4. Получатель расшифровывает приложенный файл своим ключом, внутри видит подписанный архив. Сверяет подписи и удостоверяется в личности отправителя.
5. Получатель теперь имеет возможность отправить ответ-письмо по обратному адресу, зашифровав его новым ключом отправителя.

С точки зрения внешнего наблюдателя выглядит так:

1. Какой-то аноним отправил шифрованное сообщение получателю такому-то.
2. Получатель такой-то ответил анониму зашифрованным сообщением.
3. Кто был аноним — не известно, поскольку основной ключ он нигде не засветил. Можно использовать и неанонимные ключи, всюду указывая hidden-recipient, но с анонимными ключами это более надёжно — меньше вероятность случайно ошибиться в опциях.

Спасибо за информацию

Тут всегда рады помочь в ответах на грамотно поставленные вопросы по теме сайта. Обращайтесь, если что.

В вышеописанном методе уже не так важно, есть https на mail-сервере или нет: противник (гипотетический, всемогущий) знает адрес получателя, но не видит (неанонимный) адрес отправителя (видит только анонимный). Все сообщения зашифрованы. Обычно этого достаточно для решения практической задачи.

Естественно, отправитель сообщений должен все действия производить анонимно, т.е. через Tor.

буду использовать только HTTPS-WebMail

может попробовать mailclient+gpg+tor? а вдруг понравится?

файл-письмо получателю

назначение этого письма?

специально сделанный для общения с этим абонентом

в чем специальность? и наверно открытый?

тем ключом, который известен получателю

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

Отправитель пищет файл-письмо получателю

назначение этого письма?

Имелось в виду, что это текстовый файл, который дальше пойдёт в архив, который и будет отослан (приложением к письму) целевому получателю, с которым автор топика хочет связаться.

в чем специальность? и наверно открытый?

Специальность в том, что ключ (сгенерённая ключевая пара) не используется для иных целей и не светится нигде. Естественно, отсылается только открытый ключ. Если вы уже используете PGP-ключ, где указано ваше ФИО в key id, то, подписав сообщение таким ключом, вы раскрываете своё ФИО. И анонимность ящика не поможет. Чтобы это обойти я и предложил сначала только подписать архив, а потом его ещё и зашифровать (будет вероятность подмены письма, но сейчас не о том речь).

откуда он его берет?

Предполагается, что уже знает:

Если и получатель и отправитель пользуются PGP

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

может закрыть архив паролем и на этом остановится? вот его как то еще можно сообщить.

Ну это лучше, чем ничего. Если можно сообщить пароль по доверенному каналу, то можно просто договориться о том, какой пароль использовать для всех будущих писем/архивов, и PGP ставновится не нужен (разве что для подписи... и то не уверен).