Реплика: использование VPN и HTTP-прокси
Сейчас, в связи с очередными “блокировками”, опять популярна тема использования VPN и прокси-серверов. Думаю, полезным будет ещё раз предупредить о том, что при выборе подобного внешнего сервиса нужно проявлять большую осторожность. Ваш интернет-трафик будет идти через чужие серверы, которые могут его перехватывать. (Да, естественно, трафик всегда ходит через узлы, которые могут его перехватывать, но это не отменяет того факта, что изменять проторенные пути нужно с большой осторожностью.) HTTP-прокси – самый небезопасный вариант. Предложение VPN – тоже ничего не гарантирует само по себе.
То, что заявлена поддержка VPN, не означает, что трафик защищён от перехвата провайдером этого VPN. Соответственно, если вы заходите через некий “бесплатный VPN-анонимайзер” на livejournal.com (или в другой веб-сервис, например, в веб-почту), то кто-то может утащить ваш пароль. Более того, вероятен перехват HTTPS – проверено на практике: многие не утруждают себя чтением и пониманием предупреждений систем безопасности браузеров, а сразу нажимают “Всё равно продолжить”. Хуже того, злонамеренные узлы могут проводить инъекцию кода в веб-страницы, что также ведёт к утечкам важных данных. По факту, риски здесь более опасные, чем некая “блокировка доступа” к той или иной страничке. (TOR-клиенты я бы тоже не рекомендовал – это не VPN, а лишь средство анонимизации; TOR-трафик тоже подвержен перехвату на выходных узлах.)
Если нужно использовать VPN, то либо настройте свой (это не так сложно; например, вот описание настройки VPN c использованием Amazon EC2), либо приобретите подписку у более или менее проверенного провайдера VPN. Сейчас VPN штатно поддерживается всеми распространёнными операционными системами.
Адрес записки: https://dxdt.ru/2014/02/01/6599/
Похожие записки:
- "Почти что коллизия" и хеш-функции
- Открытые "исходники" и "бинарный" код с точки зрения ИБ
- Экспериментальный сервер TLS 1.3: замена сертификатов
- "Авторизованный трафик" и будущее Интернета
- Один сценарий интернет-измерений и поле SNI HTTPS/TLS
- Ретроспектива заметок: деанонимизация по географии
- Влияние систем ИИ на процессы в мире
- Различительная способность "обезличенных" данных
- CVE-2024-3094 про бэкдор в liblzma и теория ИБ
- Ссылка: bluetooth-атака на iOS
- Kyber768 и TLS-серверы Google
Комментарии читателей блога: 4
1. 3rd February 2014, 15:21 // Читатель sarin написал:
прошу прощения за дерзость, но пользуясь случаем тоже хотел бы предостеречь людей от использования некоторых подобных сервисов. вот EC2, например. но не его конкретно.
если рассматривать анонимизацию как средство обеспечения безопасности (а иного я и придумать не могу), то выбор конкретного решения должен начинаться с построения модели противника, или угрозы. для кого-то EC2 может оказаться существенно опаснее безымянного неизвестного “нигерийского” узла, созданного с целью кражи паролей от фэйсбука и номеров кредитных карт. например, если он идёт стопами Асанжа. надо понимать, с какой вероятностью условный противник может контролировать тот или иной конкретный сервис. но сначала надо понимать, кто такой твой условный противник. иначе все эти тунели превращаются в техноананизм ради процесса.
во многих случаях использование нескольких сервисов (например тор через VPN) повысит безопасность, но не всегда. тут тоже всё зависит от нюансов: кто противник, куда необходимо попасть анонимизированно и т.д. и .т.п.
у меня была небольшая история, когда обеспечение безопасного туннеля в Интернет стало вполне конкретной, насущной задачей со вполне определённой моделью противника. вай-фай сеть одного из отелей Марселя обладала тем свойством, что переподписывала весь https. вероятно реализуя человека посередине. попытки объяснить спутнице, что пользоваться сайтами когда они выкидывают такие предупреждения нельзя были абсолютно бесполезны, но ни фэйсбук, ни яндекспочта всё равно не смогли работать в таких условиях. видимо не подгрузились какие-то скрипты…
TOR благополучно решил все проблемы. Интернет стал “работать” как ему и положено… не считая того, что фэйсбуку снесло башню уже от тора, но почта работала исправно ))) так что всё зависит от угрозы. порой тора за глаза, порой приходится выделывать как никогда…
кстати можно взять на заметку способ сделать сайт неработоспособным при компрометации ключа, чтобы кликанье по Ok в браузере не помогало.
2. 3rd February 2014, 18:12 // Читатель jno написал:
напомню в юбилейный 101-й раз про простейшее решение в виде ssh-туннеля с использованием SOCKS5 (ssh -D) на *дешёвом* VPS/VDS (ресурсов почти не жрёт) или даже на домашнем, скажем, NAS’е – для очень многих случаев его более чем достаточно.
в случае VPS/VDS можно вывести открытый (или закрытый https’ом – пофиг) трафик из местной юрисдикции.
в случае домашний железки – сделать вид для вашего текущего окружения, что трафик идёт “куда можно”.
и в любом случае – прикрыть “ближний конец” всего трафика шифрованием.
3. 3rd February 2014, 18:37 // Читатель sarin написал:
проблема всех этих промежуточных узлов одна у всех: лицо, имеющее физичский доступ к этому узлу может перехватывать любой выходящий с него трафик. хотя нынче даже не обязательно физический…
4. 7th February 2014, 20:50 // Читатель jno написал:
угу. но возможность выбора лица, которое “может перехватывать любой выходящий с него трафик” выглядит лучше, чем “на кого Бог пошлёт”.