Готовимся к запрету сайта?

[09h 504]

Дайте пожалуйста сылку на торент или прокси или как там его. и если можно объясните-многие прочитают и будут вам благодарны.

 

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

 

в случае с баном сайта, провайдером картина такова:

ты ломишся на blablabla.ru

твой браузер шлет запрос "дай страницу blablabla.ru" на сервер где располагается сайт

этот запрос разумеется не сразу попадает на веб-сервер с сайтом, а проходит через множество серверов "по пути" (твой комп -> провайдер -> ............ -> веб-сервер с сайтом blablabla.ru )

запрос "дай страницу blablabla.ru" тупо убивается провайдером и не идет дальше если blablabla.ru в черном списке

 

когда ты юзаешь прокси то картинка чуть другая

твой комп подключается к прокси (твой комп -> провайдер -> ............ -> прокси сервер)

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

дальше от твоего компа идет запрос этому прокси серверу "дай страницу blablabla.ru"

и потом уже независимо от подключения между твоим компом и прокси сервером .. этот сервер ломица на blablabla.ru и берет код страницы )

после чего отдает его (код страницы) твоему компу

 

ф-ция работы через прокси сервер есть в любом браузере. найти список прокси в инете можно тупо в поисковике вбив "список HTTP прокси серверов" или "список SOCKS прокси серверов" (в этих списках только айпи адрес:порт или доменное_имя:порт) бывают разные типы прокси HTTP, SOCK4, SOCK5....... (это те 3 типа что нам нужны) они немного по разному организованы и с разными возможностями, но в случае с хождением по сайтам для пользователя это не заметно и разницы никакой нет, нужно только знать что они бывают разных типов и скорей всего в настройках браузера будет выбираться тип прокси.. его надо просто выбрать соответствующий найденному прокси-серверу. если же вдруг(давно такого не видел) в вашем браузере нету выбора типа прокси значит скорей всего он умеет работать только через http прокси

 

печалька в том что и эти запросы к прокси серверам можно запросто прослушивать и также убивать имхо эти протоколы прокси стандартные. к счастью провайдеры пока таким не страдают

но даже если так начнут делать людям западло, всегда можно будет юзать разнообразные аналоги использующие свои протоколы или попросту реализованы не стандартно (например http://translate.google.com/translate?sl=r...%2Fwww.weedy.be их переводчик загружает к себе код сраницы .. переводит и выводит на экран.. но сервер гугла явно не на ростелекоме сидит :) ЗЫ разве что придеца язык менять ... но подобных вещей много и скрипт сделать который тупо выдает код другой страницы это 5 мин времени )

 

PS прокси нужно искать у которого провайдер не банит нужные нам сайты .. как вариант забугорный прокси серв

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

Изменено 15 ноября, 2012 пользователем 09h

[hassisin 1,895]

печалька в том что и эти запросы к прокси серверам можно запросто прослушивать и также убивать имхо эти протоколы прокси стандартные.

 

чем http от https отличается знаешь?

Конечно расшифровать можно все, но не на лету.

[VaCuUm 1,458]

для https по умолчанию используется TCP-порт 443

[hassisin 1,895]

для https по умолчанию используется TCP-порт 443

 

Дело то не в порте а в протоколе. Данные передаются в зашифрованом виде. Все запросы в том числе и dns идут в зашифрованом виде. На лету не расшифровать куда ты ломишся, как запрещать то?

[bury 32]

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

[Marik666 8]

Че то даже незнаю че делать пониковать или изучять всякие торенты анимайзеры п***ец так в лом

[pepsy-coca 275]

Че то даже незнаю че делать пониковать или изучять

 

...бро, пониковать,) только пониковать, поники не жалеть...)))

 

 

 

...и изучать, шпаргалку.

[09h 504]

чем http от https отличается знаешь?

Конечно расшифровать можно все, но не на лету.

ssl протокол знаю на 5+ .. на лету расшифровать задача совсем не трудная.. не раз реализовывал это в своих скриптах B)

вся инфа запросто вытаскивается если прослушивается вся сессия целиком... для провайдера это элементарно.. простейший фаервол по сути

ЗЫ если захотят сделают без проблем.. вопрос ток в том а нужно ли им это )) в раше часто для галочки делают что то. да и основная задача уже выполнена.. минимум 90% отрезано от забаненых сайтов, а с остальными 10 смысла заморачиваться нету имхо 100% защиты не бывает и прошареные всегда найдут лазейку.. это все на большинство ведь расчитано...

Изменено 18 ноября, 2012 пользователем 09h

[С.Хотабыч 46,413]

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

Кабутта от пользователей это не зависит? Как начнут просить -топы публиковать со спросом, в личку, друг дружке слать "предложения от которых трудно отказаться"..

 

А где гарантия что это не тот, за кого мы его все принимаем. Ну ладно мы, куда нам с этой подводной лодки, а серые крысы если не бегут с тонущего корабля, то могут дырок в трюме понаделать. Смотреть в оба всем необходимо, за собой прежде всего, а модеры так себе.. курят тихонько, пока за жабры не прихватили.. :lol:

[hassisin 1,895]

ssl протокол знаю на 5+ .. на лету расшифровать задача совсем не трудная.. не раз реализовывал это в своих скриптах B)

вся инфа запросто вытаскивается если прослушивается вся сессия целиком... для провайдера это элементарно.. простейший фаервол по сути

ЗЫ если захотят сделают без проблем.. вопрос ток в том а нужно ли им это )) в раше часто для галочки делают что то. да и основная задача уже выполнена.. минимум 90% отрезано от забаненых сайтов, а с остальными 10 смысла заморачиваться нету имхо 100% защиты не бывает и прошареные всегда найдут лазейку.. это все на большинство ведь расчитано...

 

скрипт в студию. Я хочу это видеть !!!

Изменено 19 ноября, 2012 пользователем hassisin

[villagefreak 10]

не . не то. нехай поднимет сервак и под впн произведет связь по хттп и хттпс и сам с обеих сторон снимет показания как чо где вскрывает консервным ножом. то будя разговор по-наглядному. плюсы ему мы сами ставить будям.

[hassisin 1,895]

не . не то. нехай поднимет сервак и под впн произведет связь по хттп и хттпс и сам с обеих сторон снимет показания как чо где вскрывает консервным ножом. то будя разговор по-наглядному. плюсы ему мы сами ставить будям.

 

В SSL 1.0/TLS 3.0 используются либо блочные, либо потоковые шифры. И если, блочный шифр из-за фиксированой длинны блока в принципе поддается дешифровке ( опять же не на лету, насколько я помню на харбаре говорили о цифрах порядка 100 секунд), то расшифровка потокового - значительно более трудная задача.

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

Изменено 19 ноября, 2012 пользователем hassisin

[VaCuUm 1,458]

а модеры так себе.. курят тихонько, пока за жабры не прихватили.. :lol:

:brows: жжош

[Гость boombam1]

В SSL 1.0/TLS 3.0 используются либо блочные, либо потоковые шифры. И если, блочный шифр из-за фиксированой длинны блока в принципе поддается дешифровке ( опять же не на лету, насколько я помню на харбаре говорили о цифрах порядка 100 секунд), то расшифровка потокового - значительно более трудная задача.

Вот я и хочу посмотреть\поюзать скрипт, который на лету будет расшифровывать

:kva2::biglach:

Изменено 20 ноября, 2012 пользователем boombam1

[09h 504]

скрипт в студию. Я хочу это видеть !!!

чел да это миллион лет уже как реализовано в любом прокси сервере ) и никаких 100 сек не требуется! твой браузер разве думает 100 сек когда заходит на https://dzagi.club/forum? )) сервер провайдера является посредником и через него проходят все пакеты идущие с твоего компа и на него .. все что требуется это тупо повторять действия твоего браузера на сервере прова

т.е. на сервере провайдера расценивать:

1) трафик прокси->твой_комп - как трафик адресованый провайдеру

2) трафик твой_комп->прокси - как трафик от провайдера до прокси

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

качай http://www.eserv.ru/Eproxy507 юзай и смотри логи с адресами посещенных сайтов ) по сути абсолютно такой же "посредник" без труда может стоять и на сервере провайдера

 

ЗЫ если нужно конкретное решение.. не вопрос. освобожусь к середине декабря. на работу уйдет примерно 2 недели. стоимость обговорим

Изменено 20 ноября, 2012 пользователем 09h

[hassisin 1,895]

чел да это миллион лет уже как реализовано в любом прокси сервере ) и никаких 100 сек не требуется! твой браузер разве думает 100 сек когда заходит на https://dzagi.club/forum? )) сервер провайдера является посредником и через него проходят все пакеты идущие с твоего компа и на него .. все что требуется это тупо повторять действия твоего браузера на сервере прова

т.е. на сервере провайдера расценивать:

1) трафик прокси->твой_комп - как трафик адресованый провайдеру

2) трафик твой_комп->прокси - как трафик от провайдера до прокси

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

качай http://www.eserv.ru/Eproxy507 юзай и смотри логи с адресами посещенных сайтов ) по сути абсолютно такой же "посредник" без труда может стоять и на сервере провайдера

 

Как он будет видеть, что я хочу от прокси если все запросы к прокси идут в зашифрованом виде?

Ну ка нука расскажи мне что мой комп и прокся сообщают провайдеру? Мне кажется что у тебя пробелы в понимании алгоритмов шифрования.

 

ЗЫ если нужно конкретное решение.. не вопрос. освобожусь к середине декабря. на работу уйдет примерно 2 недели. стоимость обговорим

 

Чел, не съезжай. Ты выше писал: "на лету расшифровать задача совсем не трудная.. не раз реализовывал это в своих скриптах"

Вот и покажи нам готовое решение.

[09h 504]

Как он будет видеть, что я хочу от прокси если все запросы к прокси идут в зашифрованом виде?

во первых не все запросы! при создании сессии где идет обмен ключами и т.п. все в открытом виде. и только после этого идет передача зашифрованных данных

Ну ка нука расскажи мне что мой комп и прокся сообщают провайдеру?

что твой комп и прокся сообщают провайдеру? да обсалютно всё чем они обмениваются! имхо физически весь трафик идет через сервер провайдера

Мне кажется что у тебя пробелы в понимании алгоритмов шифрования.

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

Чел, не съезжай. Ты выше писал: "на лету расшифровать задача совсем не трудная.. не раз реализовывал это в своих скриптах"

Вот и покажи нам готовое решение.

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

 

ЗЫ че ты вообще ко мне пристал то.. покажи да расскажи.. если время девать некуда почитай http://rfc2.ru/2246.rfc спецификацию протокола на русском. найдешь пункт который считаешь невыполнимым в сей задаче пиши, отвечу, помогу если реально интересно! а если тупо есть желание поймать меня на [3.141592]здабольстве, доказывай это сам, успехов тебе в этом не легком деле.

 

вот из спецификации протокола:

7.3. Обзор протокола диалога

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

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

- Обмен сертификатами и криптографической информацией, чтобы позволить клиенту и серверу аутентифицировать друг друга.

- Генерация мастерного секретного кода из предмастерного и обмен случайными кодами.

- Предоставление параметров безопасности уровню записей.

- Разрешение клиенту и серверу проверить, что их партнер вычислил те же самые параметры безопасности и что диалог прошел без вмешательства хакера.

вся нужная для расшифровки инфа как видишь передается первым делом и в открытом виде, а далее уже пойдет подобное "GET /forum/index.php HTTP/1.1\n" "Host: dzagi.ru\n\n" только уже в зашифрованном виде.. расшифровываем при помощи перехваченной инфы.. сверяем хост с списком забаненых и убиваем запрос если нужно

 

вот тебе и алгоритм! а на блюдечке подносить готовый код никто бесплатно не будет имхо это уже работа

Изменено 20 ноября, 2012 пользователем 09h

[Гость DrC]

В соседней теме подобный персонаж систему алексовскую собирает.

[hassisin 1,895]

во первых не все запросы! при создании сессии где идет обмен ключами и т.п. все в открытом виде. и только после этого идет передача зашифрованных данных

а если тупо есть желание поймать меня на [3.141592]здабольстве, доказывай это сам, успехов тебе в этом не легком деле.

 

вот из спецификации протокола:вся нужная для расшифровки инфа как видишь передается первым делом и в открытом виде, а далее уже пойдет подобное "GET /forum/index.php HTTP/1.1\n" "Host: dzagi.ru\n\n" только уже в зашифрованном виде.. расшифровываем при помощи перехваченной инфы.. сверяем хост с списком забаненых и убиваем запрос если нужно

 

вот тебе и алгоритм! а на блюдечке подносить готовый код никто бесплатно не будет имхо это уже работа

 

вот я и говорю - пробелы в понимании алгоритма шифрования. Обмениваются то открытыми ключами, а расшифровывают закрытым

Ну и как ты получишь закрытый ключ из открытого?

Пока что вижу кучу копипаста, понтов и попыток съехать. Скрипт в студию !!!

 

В соседней теме подобный персонаж систему алексовскую собирает.

 

алексовскую? эт что такое? где в соседней теме?

Изменено 20 ноября, 2012 пользователем hassisin

[09h 504]

Пока что вижу кучу копипаста, понтов и попыток съехать. Скрипт в студию !!!

неадекват детектед!

где куча? где понты? нахрен мне съезжать с чего то, когда ты даже сообщения мои не читаешь.. тыб лучше над своими утверждениями подумал! покажи в описании протокола где используется ключ который не передается перед этим? ты хоть сам то понял что предъявы кидаешь, а по факту ни одного слова подтвержденного чем либо не сказал? убейся ап стену троль.. пробелы ему мои видятся в понимании.. дык ткни пальцем в доки гдеж не стыковка в моих словах то?! я тебе даже ссылку для не умеющих гуглить дал на русское описание протокола! ткни пальцем! или нехрен больше флудить пустыми словами! тебе не ясно что то.. ты и разбирайся.. это твоя личная трабла если знаний не хватает

[hassisin 1,895]

неадекват детектед!

где куча? где понты? нахрен мне съезжать с чего то, когда ты даже сообщения мои не читаешь.. тыб лучше над своими утверждениями подумал! покажи в описании протокола где используется ключ который не передается перед этим? ты хоть сам то понял что предъявы кидаешь, а по факту ни одного слова подтвержденного чем либо не сказал? убейся ап стену троль.. пробелы ему мои видятся в понимании.. дык ткни пальцем в доки гдеж не стыковка в моих словах то?! я тебе даже ссылку для не умеющих гуглить дал на русское описание протокола! ткни пальцем! или нехрен больше флудить пустыми словами! тебе не ясно что то.. ты и разбирайся.. это твоя личная трабла если знаний не хватает

 

Так ткнул уже: не понимаешь алгоритм ассиметричного шифрования.

для расшифровки сообщения используеться закрытый ключ (private) Каким образом ты его получаешь если происходит обмен открытыми (public) ключами?

Не люблю копипастить но вот онли фо ю, показываю где живет непередаваемый ключ:

Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret)

Если бы все шифровалось с предварительной передачей ключей то любой снифер перехвативший сессию целиком действительно расшифровывал бы все сообщения. Но ssl изначально разрабатывалось для проведения электронных платежей, поэтому об ее безопасности побеспокоились. На момент ее создания 256 битный ключ обеспечивал достаточную безопасность. С тех пор компы выросли, мощность умножилась неоднократно и 256 бит не представляют особой сложности для вскрытия перебором. НО НЕ НА ЛЕТУ!!!

Короче, читай Шнайера он хорошо пишет про криптографию. Или хоть на вике посмотри ассиметричное шифрование.

Изменено 20 ноября, 2012 пользователем hassisin

[09h 504]

вот теперь смотри почему я так упорно бодаюсь за свою правоту...

 

Полностью анонимная сессия может быть установлена - первое заблуждение (в данной ситуации это невозможно если прослушивается все полностью). объясняю почему

 

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

 

Результат посылается .. от клиента. (а вот теперь провал) Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). - ключ 2 предложения назад был открытым, а теперь стал закрытым и я ведь не путаю ключи .. pre_master_secret был зашифрован именно клиентом и именно открытым ключем полученным от сервера.. верно?

 

вот просто пойми фишку .. физически не возможно по такому маршруту "A <-> B <-> C" передать от А до С через В скрыв инфу не договорившись заранее о каком либо потайном шифре. тупо потому что начнется разговор по любому в открытую и в этом открытом разговоре обговаривается как дальше разговаривать.. и как бы они не договорились это будет знать и использовать сниффер!

 

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

но при этом есть 1 условие .. в мозг участкового загружены те же самые знания языков, шифровок, ребусов и т.п. и при этом вы с другом не обговаривали шифр никогда ранее )))

 

все просто и логично:

1) до того как данные начали идти в зашифрованном виде и идут в открытом.......... все ключи полученные клиентом от сервера будут и у сниффера по любому.. согласен?

2) и пока не обговорен тип шифрования, нереально шифровать данные.. и выбранный тип тоже передается в открытом виде.. согласен?

3) идем дальше.. сниффер на данный момент знает все тоже самое что и клиент .. согласен?

и вот подумай теперь, как в этой ситуации дальше что либо может стать известно серверу от клиента или наоборот клиенту от сервера, так что бы сниффер не узнал? ведь ключ который еще не знает сниффер может быть только у одной стороны! при первой же попытке его передать его слопает сниффер. использовать переданные ключи и шифровать? ну так ведь облом.. сниффер знает и тип шифрования данных и все ключи у него есть.. расшифрует и не за 100 сек а за миллисекунды т.к. это будет не тупой перебор а обычная расшифровка стандартной функцией с наличием ключа

 

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

 

вот с какими моими "согласен?" или "верно?" ты не согласен?) без обид, я просто не люблю когда на меня смотрят как на 3.14здабола.... тем более эт для мну профессиональная обида .. 15 лет программирую и именно с сетями работаю на низком уровне .. мир

вот такой вот спорный офтоп вышел ( админы сорь за мусор в топике

Изменено 20 ноября, 2012 пользователем 09h

[hassisin 1,895]

вот теперь смотри почему я так упорно бодаюсь за свою правоту...

 

 

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

 

Результат посылается .. от клиента. (а вот теперь провал этой сомнительной статьи! и это просто статья а не доки) Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). - ключ 2 предложения назад был открытым, а теперь стал закрытым и я ведь не путаю ключи .. pre_master_secret был зашифрован именно клиентом и именно открытым ключем полученным от сервера.. верно?

 

Ещё раз говорю: не понимаешь алгоритм ассиметричного шифрования.

Это разные ключи, открытый и закрытый. Открытый можно быстро получить из закрытого, а наоборот требует ебически долгих вычислений по разложению на сомножители.

Вновь копипастю:

Криптографическая система с открытым ключом (или асимметричное шифрование, асимметричный шифр) — система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифровки сообщения используется секретный ключ.

Идея криптографии с открытым ключом очень тесно связана с идеей односторонних функций, то есть таких функций , что по известному f от х довольно просто найти значение у , тогда как определение х из f от у невозможно за разумный срок.

Ну теперь понятно? то есть передаеться ключ которым ты будешь зашифровывать, но он не дает возможности расшифровки. А дающий эту возможность ключ никуда не передается, так и лежит, один на сервере а второй на клиенте. Из него вычисляется открытый который и пересылается.

ну, вот здесь посмотри:http://www.secuteck.ru/wiki/index.php?title=%D0%90%D1%81%D1%81%D0%B8%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%BD%D0%BE%D0%B5_%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Изменено 20 ноября, 2012 пользователем hassisin

[09h 504]

так и лежит, один на сервере а второй на клиенте.

не вижу смысла продолжать спор если ты не читаешь мои сообщения полностью.. но при этом утверждаешь что мне чтото не понятно.

 

я уже писал что исключить возможность прослушки можно только передав ключ заранее, до прослушки или в обход ее.

без этого от прослушки спастись не возможно. а ты мне снова про мое не понимание и про этот закрытый ключ который не передается.. он передается в любом случае раз он вообще попал на 2 машины согласованный! и варианта тут 2 или при подключении передавать (тогда прослушка будет работать) или заранее (но и с этим можно бороться если передача через того же прова)! например при регистрации на прокси сервере пришлют на мыло файл сертификата

 

ЗЫ стараешься похвастаться знаниями и из за этого даже не видишь что другие пишут.. со стороны это выглядит уныло .. повторяешь одно и тоже в упор не видя что диалог продвинулся дальше

 

я говорю о том же о чем и ты если не заметил! но при этом еще и про другие методы шифрования, охватывая весь протокол целиком.

а ты как будто спецально игнорируешь мною написаное про одну часть и напором давишь на другую приплетая всё что я пишу, туда

и я нигде и ни разу не сказал про тупой подбор ключей! а именно только метод перехвата

Изменено 20 ноября, 2012 пользователем 09h

[hassisin 1,895]

не вижу смысла продолжать спор если ты не читаешь мои сообщения полностью.. но при этом утверждаешь что мне чтото не понятно.

 

я уже писал что исключить возможность прослушки можно только передав ключ заранее, до прослушки или в обход ее.

без этого от прослушки спастись не возможно. а ты мне снова про мое не понимание и про этот закрытый ключ который не передается.. он передается в любом случае раз он вообще попал на 2 машины согласованный! и варианта тут 2 или при подключении передавать (тогда прослушка будет работать) или заранее (но и с этим можно бороться если передача через того же прова)! например при регистрации на прокси сервере пришлют на мыло файл сертификата

 

ЗЫ стараешься похвастаться знаниями и из за этого даже не видишь что другие пишут.. со стороны это выглядит уныло .. повторяешь одно и тоже в упор не видя что диалог продвинулся дальше

 

я говорю о том же о чем и ты если не заметил! но при этом еще и про другие методы шифрования, охватывая весь протокол целиком.

а ты как будто спецально игнорируешь мною написаное про одну часть и напором давишь другую приплетая всё что я пишу туда

 

В том то и дело, что не передается он НИКУДА. Я ж пишу: ОДНОСТОРОННЯЯ ФУНКЦИЯ, в одну сторону вычисляется легко в другую очень сложно. Ну вот еще раз:

комп А генерирует закрытый ключ (позволяющий РАСШИФРОВЫВАТЬ). На основе этого же ключа вычисляется открытый (позволяющий ЗАШИФРОВАТЬ но не РАСШИФРОВАТЬ)который пересылается на комп Б. Комп Б в свою очередь генерит свой закрытый ключ, на основе его вычисляет открытый, который пересылает на комп А. ТО есть от А к Б и от Б к А сообщения зашифрованы РАЗНЫМИ ключами. И ключ позволяющий РАСШИФРОВАТЬ сообщение НИКУДА НЕ ПЕРЕДАЕТСЯ. ну , а следовательно не перехватывается. Ну а раз не перехватывается значит остается подбор.Теперь понял? Я ж тебе даже сцылку на вику положил, там вроде доходчиво объяснено.

Изменено 20 ноября, 2012 пользователем hassisin

[09h 504]

забей.. ты в корне не понял про что я

пост №75 .. развилка понимания произошла там.. хоть и не разжевал там все

Изменено 20 ноября, 2012 пользователем 09h

[hassisin 1,895]

забей.. ты в корне не понял про что я

 

Что тут понимать, тоже мне бином Ньютона.

Ты пишешь о том что провайдер способен перехватить весь трафик. Это так , но это ничего не дает. Даже перехваченый трафик не расшифровывается на лету, следовательно запросы на прокси к запрещенным сайтам не получится отфильтровать от запросов к разрешенным.

Ты ж кричал что у тебя это реализовано. Как можно реализовать то, что не понимаешь?

просто признайся что сп**днул.

[09h 504]

Что тут понимать, тоже мне бином Ньютона.

Ты пишешь о том что провайдер способен перехватить весь трафик. Это так , но это ничего не дает. Даже перехваченый трафик не расшифровывается на лету, следовательно запросы на прокси к запрещенным сайтам не получится отфильтровать от запросов к разрешенным.

Ты ж кричал что у тебя это реализовано. Как можно реализовать то, что не понимаешь?

просто признайся что сп**днул.

я устал объяснять тебе как это реализовано .. ты не понимаешь тупо

последняя попытка и иди оно все лесом..

ты мне про малые круги а я тебе про большой

без связи А с С выходит жопа и хоть как ты хитро не шифруй.. B как бы и не существует для А и С но общаются они именно с ним и долбит он их обоих. всю шифровку беря на себя, получая данные расшифровывает и снова упаковывает и пинает дальше

ферштейн?

Изменено 20 ноября, 2012 пользователем 09h

[hassisin 1,895]

я устал объяснять тебе как это реализовано .. ты не понимаешь тупо

последняя попытка и иди оно все лесом..

ты мне про малые круги а я тебе про большой

ферштейн?

 

А клиент, Б прокси сервер, С вебсервер? Или А клиент Б провайдер С прокси сервер?

Впрочем не важно.

Давай попробуем по пунктам.

1. Закрытый то есть дешифрующий ключ никуда не передается, следовательно не перехватываться это ты не оспариваешь?

2. Без ключа дешифровка на лету невозможна. Это не оспариваешь?

3. без быстрой дешифровки запроса на проксю невозможно понять какой адрес ты запрашиваешь. Это не оспариваешь?

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

Изменено 20 ноября, 2012 пользователем hassisin

[09h 504]

А клиент, Б прокси сервер, С вебсервер? Или А клиент Б провайдер С прокси сервер?

Впрочем не важно.

Давай попробуем по пунктам.

1. Закрытый то есть дешифрующий ключ никуда не передается, следовательно не перехватываться это ты не оспариваешь?

2. Без ключа дешифровка на лету невозможна. Это не оспариваешь?

3. без быстрой дешифровки запроса на проксю невозможно понять какой адрес ты запрашиваешь. Это не оспариваешь?

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

не ну я все же налил еще кофейку и добью этот спор ) не зряж так топик мемуарами заговняли )))))

 

выкинь на секунду В .. А клиент С прокси (допустим прокся стоит на dzagi.ru)

все норм работает и инфа как шифруется так и дешифруется на лету клиентом и проксей. ну нельзя не согласиться ведь

 

идем дальше ... добавляем между ними В(провайдер) который для А выступает в роли dzagi.ru и также как обычный прокси без труда получает и дешифрует инфу

и в тоже время для С имитирует обычного клиента и также нормально общается с ним как обычный клиент и прокси

 

А сообщает В что хочет получить страницу яндекса ... В сообщает С что хочет страницу яндекса ... С дает В страницу ... В отдает страницу А

А абсолютно уверен что общается с С ... в то время как С уверен что общается с А

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

Изменено 20 ноября, 2012 пользователем 09h