Да, так выше и написано, что именно в этом случае ключ естественно на период сессии попадает на компьютер. Так что здесь нет обмана. А вот, что польшинство текенов используется как кранилище для ключей и сертификатов, т.е. как флэшка это плохо.
Вообще-то закрытый ключ доступен тому процессору, где с помощью него проводятся криптографические операции
Так в чем противоречие?
У вас как у свободного человека есть право выбора ставить не только МЭ, NAT, Shield в конце концов, но и отразных производителей.
Точно также как у вас выбор покупать Мерседес или Вец, колбасу вареную или копченую. Используйте свое право. Экспериментируйте и т.д
Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
Он отправляет не пакете IP, а данные. И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,
FireWire это всего лишь еще один физический уровень.
В него все равно нужно инкапсулировать тот же TCP
В физический уровень FireWire TCP не инапсулируется. Но вы уловили главное.
Хоть немного, но надо говорить о реализации.
На внутреннем сервере Si с IP-адресом IPi работает программный модуль client_sms, принимающий запросы от пользователей/браузеров защищенной ЛВС, например, на tcp порт 312. Полученные запросы изымаются из TCP-пакета и передаются модулю server_sms на Se. Модуль server-sms инкапсулирует полученные двнные в TCP и передвет дальше в squid.
Адрес программного модуля (IP_порт) client_sms прописываются в браузерах как прокси.
При этом можно устанавливать различные ограничения, например, по времени доступа и т.д.
На внешнем сервере Se работает программный модуль server_sms, который обращается к прокси-серверу squid, установленному также на внешнем сервере и принимающему соединения по умолчанию на tcp порт 3128. Прокси-сервер squid уже в свою очередь перенаправляет запрос на удаленный сервис в публичной сети (сети Интернет). Отметим, что для корректной работы прокси-сервера squid на внешнем сервере, естественно, должен быть прописан DNS-сервер.
При получении ответа из публичной сети прокси-сервер на внешнем сервере отправляет полученные данные модулю server_sms, который передает их на внутренний сервер через драйвер шины IEEE1394. На внутреннем сервере данные (ответ на запрос) принимаются модулем client_sms, он их упаковывает в TCP/IP и передаются клиенту/браузеру в защищенной сети.
Вообще-то закрытый ключ доступен тому процессору, где с помощью него проводятся криптографические операции
Защищается все как написано
Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.
У вас как у свободного человека есть право выбора ставить не только МЭ, NAT, Shield в конце концов, но и отразных производителей.
Точно также как у вас выбор покупать Мерседес или Вец, колбасу вареную или копченую. Используйте свое право. Экспериментируйте и т.д
Т.Е. защищает машины локальной сети. Вы ответили.
Он отправляет не пакете IP, а данные. И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,
В физический уровень FireWire TCP не инапсулируется. Но вы уловили главное.
Хоть немного, но надо говорить о реализации.
На внутреннем сервере Si с IP-адресом IPi работает программный модуль client_sms, принимающий запросы от пользователей/браузеров защищенной ЛВС, например, на tcp порт 312. Полученные запросы изымаются из TCP-пакета и передаются модулю server_sms на Se. Модуль server-sms инкапсулирует полученные двнные в TCP и передвет дальше в squid.
Адрес программного модуля (IP_порт) client_sms прописываются в браузерах как прокси.
При этом можно устанавливать различные ограничения, например, по времени доступа и т.д.
На внешнем сервере Se работает программный модуль server_sms, который обращается к прокси-серверу squid, установленному также на внешнем сервере и принимающему соединения по умолчанию на tcp порт 3128. Прокси-сервер squid уже в свою очередь перенаправляет запрос на удаленный сервис в публичной сети (сети Интернет). Отметим, что для корректной работы прокси-сервера squid на внешнем сервере, естественно, должен быть прописан DNS-сервер.
При получении ответа из публичной сети прокси-сервер на внешнем сервере отправляет полученные данные модулю server_sms, который передает их на внутренний сервер через драйвер шины IEEE1394. На внутреннем сервере данные (ответ на запрос) принимаются модулем client_sms, он их упаковывает в TCP/IP и передаются клиенту/браузеру в защищенной сети.