— Гость (10/04/2010 02:45)   

Какое более универсально при проходе через провайдера.

Я слышал про такие слухи, как то, что не всякие рутеры пропускают IPsec-трафик. За правдоподобность не ручаюсь.

Пусть после VPN-сервера соединение идёт в Tor. Tor работает через SSL. Если VPN работает через IPsec, то различие протоколов (SSL и IPsec) повышает защищённость связи. Т.е. для перехвата информации необходима уязвимость в обоих протоколах.

Не ясна схема вашей сети. Вы хотите сказать, что на всём сетевом маршруте пакеты информация идёт в "двух одёжках": вначале закрыта Ipsec'ом, а поверх протоколом Tor? Но сделать такое на всём маршруте можно только при использовании скрытых сервисов Tor. В противном случае будут участки пути, где есть только что-то одно (IPsec или SSL).

В интернете писали что-то про недоведённость до ума протокола IPsec в плане безопасности, типа он вызывал нарекания у спецов, к тому же вещь достаточно сложная (по сравнению с SSL). Впрочем, к самому SSL тоже есть нарекания, хотя это не мешает всем его активно использовать. Чисто идеологически IPsec лучше чем SSL, т.к. более универсален и ширфует не на уровне туннеля, но на уровне IP-пакетов, что приводит к меньшему оверхеду по сравнению с VPN.

— Avalon (10/04/2010 09:27)   

Не ясна схема вашей сети. Вы хотите сказать, что на всём сетевом маршруте пакеты информация идёт в "двух одёжках": вначале закрыта Ipsec'ом, а поверх протоколом Tor? Но сделать такое на всём маршруте можно только при использовании скрытых сервисов Tor. В противном случае будут участки пути, где есть только что-то одно (IPsec или SSL).

От локальной машины до VPN-сервера IPsec+SSL (наиболее критический участок маршрута), от VPN-сервера до выходного узла Tor только SSL.

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

— sentaus (10/04/2010 11:43)   

Я слышал про такие слухи, как то, что не всякие рутеры пропускают IPsec-трафик.

С NAT у IPSec проблемы будут.

— Гость (10/04/2010 16:48)   

От локальной машины до VPN-сервера IPsec+SSL

Достаточно чего-то одного, но правильно настроенного, если, конечно, вы не будут пытаться менять код программ для каких-то спеццелей типа нормализации трафика и препятствования распознаванию (см. /comment25765^[link1]) используемых протоколов.

Впрочем, к самому SSL тоже есть нарекания, хотя это не мешает всем его активно использовать.

Были^[link2] не до конца прояснённые тонкости, когда начинали рыть вглубь.

[offtop]
Уважаемый SATtva, не могли бы Вы прикрутить поддержку поиска по комментариям unknown'а? Со временм становится всё трудней и трудней находить релевантные посты :-(
[/offtop]

— unknown (11/04/2010 22:12, исправлен 11/04/2010 22:14)   

Если вы не знаете чем IPSec лучше OpenVPN, используйте OpenVPN.
У IPSec могут быть проблемы с прохождением через NAT, сложности настройки и пока он имеет преимущества для больших промышленных решений, где нужны большие масштабы и объёмы.

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

Tor и OpenVPN используют библиотеку OpenSSL, но у них неодинаковые протоколы. Фундаментальные дыры в OpenSSL (как в случае Debian-OpenSSL-PRNG) могут повлиять конечно на оба, но могут быть уязвимости и приносящие ущерб в разной мере.

— Гость (11/04/2010 23:29)   

И опять же, пока его в полном объёме не включат в ядро

В default сити unix kernel? Емнип, первой ОС где, он появился по умолчанию, была OpenBSD, причём оно там (якобы) работает искаропки и уж тем более поддердивается GENERIC-ядром. В других ОС можно включить в опциях ядра, и то, что они не включены by default означает лишь то, что большинству эти фичи не нужны, а объём ядра без необходимости не стоит увеличивать.

не примут стабильный стандарт

Намедни:

Two bugs in IPsec/HMAC-SHA2 were fixed, resulting in an incompatibility with the HMAC-SHA-256/384/512 hash algorithms with previous versions of OpenBSD and other IPsec implementations sharing the bugs.

Из аннотаций^[link3] к первомаю.

$ config -x /netbsd |grep -i ipsec options IPSEC # IP security options IPSEC_ESP # IP security (encryption part; define w/IPSEC) options IPSEC_NAT_T # IPsec NAT traversal (NAT-T) #options IPSEC_DEBUG # debug for IP security $ dmesg |grep -i ipsec IPsec: Initialized Security Association Processing. $Не так страшен... как его малюют.

— Гость (11/04/2010 23:30)   
s/ОС где, он появился по умолчанию/ОС, где он появился/

— SATtva (16/04/2010 19:23)   

Уважаемый SATtva, не могли бы Вы прикрутить поддержку поиска по комментариям unknown'а?

Поиск по постам определённого автора обязательно добавлю на днях.

— Гость (11/05/2010 00:30)   
[offtop]
Он уже реализован? Заодно хотелось бы увидеть мануал по тому, что здесь^[link4] называется "стандартным поисковым синтаксисом".
[/offtop]

— SATtva (11/05/2010 20:48)   

Он уже реализован?

Нет, пока некогда.

Заодно хотелось бы увидеть мануал по тому, что здесь называется "стандартным поисковым синтаксисом".

Там дальше сразу после двоеточия написано. Операторы примерно те же, что у Гугла и Ко.

— Гость (09/10/2010 23:57)   

Поиск по постам определённого автора обязательно добавлю на днях.

SATtva, вот Вы скажите, чем некошерен поиск по автору "Гость"? Если не указываю авторство — находит, указываю — уже нет.