Comments 13
Не понял в чем смысл такого громоздкого решения? Разве не проще было обойти через socks/vpn/ssh? Ясно же, что система безопасности в сети — решето.
Не проще. В условиях решаемой задачи мы имеем сильно урезанные возможности на клиентской машине. Доступ в сеть исключительно через корпоративную прокси, поэтому socks, vpn, ssh исключаются.
Если прокси разрешает CONNECT, а он конечно же разрешает, то минимум ssh повешенный на 443 сработает.
Вы правы, так действительно будет проще. Однако способом описанном в статье можно централизованно помочь всей команде разом. Или расшарить инстанс своим друзьям, которые не смогут самостоятельно это сделать. Уверен, что несмотря на громоздкость, решение найдёт хоть какой нибудь отклик и возможно будет полезным.
Вы же понимаете, что рано или поздно такая активность будет замечена и повлечет какие-то санкции? Плюс насколько безопасно пользоваться таким вот прокси?
В контексте расшарить друзьям… Я бы не доверил друзьям контроль за своей перепиской.
В контексте расшарить друзьям… Я бы не доверил друзьям контроль за своей перепиской.
Любая подобная активность может повлечь за собой какие-нибудь санкции.
Про безопасность такого подхода могу утверждать только, что он определенно безопаснее любого неофициально зеркала в паблике.
Но не могу утверждать, что безопасно на 100%. Уверен, что в комментариях найдутся специалисты, которые поделятся с нами своей экспертизой.
Про безопасность такого подхода могу утверждать только, что он определенно безопаснее любого неофициально зеркала в паблике.
Но не могу утверждать, что безопасно на 100%. Уверен, что в комментариях найдутся специалисты, которые поделятся с нами своей экспертизой.
Навскидку. Автор прокси может модифицировать свой код на github, приложение тянет пакеты из npm, куда не раз загружали вредоносный код, имеющий доступ к серверу может читать всю переписку пользователей не сильно утруждаясь. Секретные чаты не подерживаются. Если у вас еще windows в домене и любой из браузеров пользующихся системным хранилищем сертификатов, то вы даже не заметите как корпоративные админы включат MITM на ssl… Не говоря уже о том, что эффективные корпоративные менеджеры любят включать всякие системы удаленного наблюдения за рабочим местом.
Ну если рассуждать на уровне безопасности самого решения Webogram и его компонентов — не думаю, что небезопасное приложение позиционировалось бы как официальная веб-версия на сайте мессенджера.
К тому же, весь исходный код и подключаемые зависимости не скрыты в черном ящике — все доступно к изучению.
К тому же, весь исходный код и подключаемые зависимости не скрыты в черном ящике — все доступно к изучению.
Не в каждой компании разрешено использовать что-то помимо http/https для внешних ресурсов.
Тут вопрос в том детектится https или нет. Если безопасность на уровне разрешили только 80,443 без проксирования трафика, то как я уже говорил это вобще не безопасность, а ее видимость. Если поставили прокси и разрешили метод CONNECT куда угодно на разрешенные порты, то опять же и openvpn и putty спокойно пройдут через такую лазейку. Если параллельно проксированию еще и анализируется трафик, то отвалится putty, но openvpn поверх tls будет работать. Если же прокси организует полноценный MITM, то отвалится и Webogram, потому как url у api весьма характерные их ни с чем не спутаешь, да и все содержимое запросов открыто.
Можно сделать то же самое средствами простого nginx + sub_filter. (пример)
Это позволит не держать node.js на сервере и не обновлять клиент самостоятельно.
Но стоит понимать, что могут сломаться директивы замены ответа бекенда, в случае изменения функции определения сервера.
Это позволит не держать node.js на сервере и не обновлять клиент самостоятельно.
Но стоит понимать, что могут сломаться директивы замены ответа бекенда, в случае изменения функции определения сервера.
Sign up to leave a comment.
Поднимаем свой инстанс Webogram с проксированием через nginx