Ну вот представь, что можно принудительно задать размер окна извне.
Далее возникает вопрос: а кто телеге будет сообщать, что надо в окне оставить только поле ввода сообщения, а другие элементы убрать?
О скрытии отдельных элементов при таком-то размере окна приложение не знает, если в нём это не прописано, бесконечно уменьшать не может, а возможность прокрутки внутри окна тоже определяется самим приложением. В такой ситуации как можно принудительно задавать размер окна извне?
VasyaID, нет, у него просто напросто вход через аккаунт microsoft, и смена материнки, очевидно, вышибла его систему из авторизованных, что повлекло неработоспособность и пинкода, который можно установить для входа вместо пароля. А сети нет, потому что дров нет.
VasyaID,
>Я в курсе как работает mitm-proxy. Я его даже юзаю изредка для анализа траффика.
был бы в курсе - не писал бы того, что пишешь, и не удивлялся бы банальным вещам.
>Пожалуй на этом можно и закончить :)
Ну, если тебя смущает слово "самоподписанный" - так это всего лишь от непонимания того, как это работает. Любой корневой сертификат CA подписан закрытым ключом от своей собственной пары. Это просто задаёт первое звено в цепочке доверия, не более (случаи с перекрёстной подписью не рассматриваем, это за рамками обсуждения). Любой сертификат, который ты обнаружишь в хранилище корневых сертификатов винды при чистой установке - самоподписанный. Да-да, и все эти VeriSign, и Microsoft Root, и прочее.
Ты всё, очевидно, цепляешься за коннотации, сопутствующие словам "корневой", "самоподписанный", и т.д., но не стоит этого делать. Это всё сугубо технические термины.
И то, что каспер может влезть своими лапами куда угодно, как и потенциально любой софт с привилегиями администратора в системе - тоже ничего особо удивительного. Тем более, что KIS как таковой специально затачивается на отлов всех возможных внешних доступов с машины. Понятно, что он и хранилище portable фаерфокса найдёт, и влезет в него. Ну, как бы, что мешает то? Впрочем, особо хитрые (шифрованный образ+vm) portable-образы действительно могут этого избежать, но кто-то такими заморачивался?
Да и то, что любой софт, подобный KIS, создаёт дополнительные векторы атаки - тоже дааааавно не секрет. Они не могут работать по-другому. Вопрос лишь в балансе безопасности и функционала - как всегда.
Drawn, вот как раз про 1с ничего не скажу, там какие-то сложности были с как таковой установкой через gpo, это могу только в гугл конкретно по этой теме отослать
Например так:
Правда, это ethernet-адаптер, но в этом смысле разница небольшая.
Но ни вкладки, ни параметров может и не быть, тогда увы. Впрочем, ещё можно таки попробовать драйвер на адаптер с сайта производителя (ноутбука, в данном случае) установить, если этого почему-то не сделано. Тогда, быть может, проблема уйдёт и без шаманств...
R O, а вот не "хоть". Если ты оперируешь соединениями, то на исходящие с 80 и 443 закрывать нет вообще никакого смысла, поскольку на входящие соединения и ответы на них это никак не повлияет. Кроме того, для http и https соединений исходящие порты, как правило, из динамического диапазона, а не 80 и 443. Надо закрывать на входящие соединения, причём со стороны только WAN, если не хочешь лишиться доступа к роутеру из локалки.
53 на исходящие соединения трогать не просто бесполезно, а при стандартной конфигурации - выстрел себе в ногу, ибо сам себе блокируешь днс-запросы на внешку.
И не надо ничего никуда менять, надо просто закрыть фаерволом входящие соединения со стороны WAN. И не будет проблем.
Drawn, ну, это именно так и работает, и никак по-другому это не работает. Не считая ручного пинка через gpupdate, разумеется. Но это именно что ручной пинок, и нужен он либо для целей тестирования, либо для целей отладки, а не для штатной работы.
VasyaID, и кто ж ему запретит, можно узнать?
Ну, скажем, уточним понятие "корневой": не тот, который microsoft, или mozilla, или google считают доверенными, а тот, который в Key Usage имеет расширение keyCertSign. То есть сертификат Certification Authority (CA, Центр Сертификации, ЦС). Слово "корневой" тут фигурирует только потому, что CA могут быть корневые или подчинённые (промежуточные) - выстраивая цепочку доверия от корневого. Корневые - всегда самоподписанные (таким образом первые в цепочке), промежуточные - подписанные другим (вышестоящим) CA.
То есть, если коротко, корневой сертификат - это ЛЮБОЙ самоподписанный сертификат CA.
Таким вот нехитрым образом это может быть сертификат, выпущенный кем угодно. Даже мной, прямо сейчас. И подписать я им смогу всё, что мне заблагорассудится. Вопрос лишь в том, кто этой подписи будет доверять. А для установления отношений доверия такой сертификат просто надо добавить в хранилище "Доверенные корневые центры сертификации" на конкретной виндовой машине (про линупсы, фряхи и маки не в курсе, сорян), либо в хранилище браузера в аналогичный раздел.
В случае каспера почти наверняка поднимается локальный прокси, браузер заворачивается на него, прокси подменяет сертификаты целевых сайтов на тут же на лету выпускаемые и подписываемые сертификатом каспера, добавленным в корневые на конкретной машине. Причём этот сертификат каспера совершенно необязательно как-либо централизовано распространяем, а вполне может быть сгенерирован при установке самого каспера на конкретную машину и добавлен в доверенные (и даже может перегенерироваться периодически для вящей безопасности, ха-ха). Это позволяет конкретной инстанции каспера на конкретной машине совершать митм-атаку на все попытки доступа к внешним ресурсам с этой машины. И, таким образом, в том числе произвольно блокировать всё, что угодно, по любым мыслимым критериям.
foxyhunt, не нужен ему меш, ему нужен в крайнем случае бесшовный вифи роуминг; микротики такое умеют вполне себе, кинетики не знаю, но думаю, что умеют
>Однако я сииильно сомневаюсь что так и есть, как ты говоришь - браузер должен спрашивать на каждом сайте о приёме левого сертификата VasyaID, если браузеру дать корневой сертификат, и сказать "доверяй ему" - он будет доверять ему, и всем подписанным им сертификатам без каких-либо вопросов.
rPman, даже в случае акб для провайдерского свича, который не будет стоить дорого, я думаю, нереально, потому что это ж внутренняя бюрократия, в случае крупного прова. Если пров мелкий местный - то да, договориться, вероятно, можно.
Владимир, а чего невероятного? У меня есть n-ое количество единиц оборудования с вебмордой, вебморда которых не работает в современных браузерах или без плясок с бубном.
Но, собственно, да, переделав адресацию - можно добавить интерфейсы вланов в бридж в качестве порта (лучше не в родительский, а таки ж в отдельный), и они будут работать как обычные физические интерфейсы, объединённые в обычный мост.
nApoBo3, интерфейсы, конечно, никуда не делись, только они не добавляются в бридж в качестве порта. Не смешивать, как грится... Richard Querman, фильтрация и тегирование происходят до выхода трафика из программного интерфейса влана и после входа в него, так что с прочими системами в этом смысле он взаимодействует, как обычный физический интерфейс.
DHCP-сервер/ы же не будет/ут работать на VLAN-интерфейсах, если VLAN-интерфейсы будут добавлены в бридж в качестве порта. Не может DHCP-сервер работать на slave интерфейсах. Ну и автору в любом случае придётся переделывать адресацию в сети, т.к. он ещё и IP-адресов самих интерфейсов лишится, это тянет за собой маршрутизацию, и т.д.
