Столкнулся с ситуацией когда нужно GoogleDrive for Desktop нужно запустить, но при этом, по корпоративным стандартам, включен SSL decryption. И просто запущенный пакет дает ошибку синхронизации.
На профильных сайтах все советуют ставить в исключения из SSL decryption список хостов, куда обращается GoogleDrive. Это тоже решение, но его скорее всего зарежет информационная безопасность. И будет права со своей точки зрения.
Для старой версии было решение запускать программу с ключом --unsafe_network но в более новой версии (у меня Version: 54.0.2.0 ) такое не работает.
Изменение двух ключей реестра решает вопрос. Причем прошу обратить внимание - это не хак, это описано в недрах https://support.google.com/a/answer/7644837?hl=en
[HKEY_LOCAL_MACHINE\SOFTWARE\Google\DriveFS]
"DisableCRLCheck"=dword:00000001
"DisableSSLValidation"=dword:00000001.
И перезапустить GoogleDrive.
P.S.: вопросы моральности чтения SSL в корпоративной среде мы не обсуждаем. Хочешь пользовать личные секреты - не неси их в рабочую сеть.
Комментарии (13)
ded_Pihto Автор
06.01.2022 09:46Нашел официальное решение в глубинах https://support.google.com/ поэтому внес измения в текст статьи. никаких лайф-хаков. все по документации!
AlexeyK77
Спасибо вам большое за рецепт.
Но проблема шире, большинство ходят на гугл-сервисы из броузера, а там SSL-pinning и даже внесение корпоративного MITM-сертификата в доверенные через групповые политики не помогает.
Ситуация в целом критическая, т.к. все больше и больше хостов, даже тех, где это не нужно по большому счету не поддается декрипту, что сильно снижает уровень ИБ и напрямую нарушает требования некторых отраслевых стандартов ИБ.
Как по мне, броузер должен иметь т.н. "корпоративный" режим, когда контроль на сертификат снимается, и проверка идет через доверенные сертифкаты в ОС.
Кто как решает эту проблему? Может есть сборки броузера с отклченным SSL-pinning?
ded_Pihto Автор
Ну ssl pinning для того и создавался чтоб его нельзя было ( читай не так просто ) можно было обойти.
Для GooleDrive, Google Table, Google Word точно пининг не используется. Ни в броузере ни в приложениях. По другим приложениям или сервисам не скажу.
AlexeyK77
Это хорошая и правильная штука для личного испольвоания, что бы правительства не могли перехватывать рпиватную почту например. Но в корпоративной среде совсем другой подход и требуется полный контроль за всем что происходит, ка кна ендпоинте, так и на периметре. Поэтому по моему мнению у броузеров должын быть "корпоративный режим". Вернее он и так уже есть, многие вещи через групповые политики можно настраивать, ограничивать но вот ssl-pinningом управлять пока невозможно.
KislyFan
Слово "злоумышленники" не? Зачем опять приплетать политоту, всетаки мы технический ресурс, а не политический.
shifttstas
Не должен, в будущем же нас ждет
eSNIECH который положит конец таким корпоративным исторям (в особенности в связки с DOH).То что работадатель использует SSL decryption вообщем то показывает его отсталость. т.к сейчас в моде вообще то ZeroTrustNetworks.
Если работадатель хочет все делать по старинке - есть VDI c любыми фильтрами и белым списком ПО, но вообщем то эта практика для 3,5 компаний (например - банки) и то не для всех сред, а только обычно для тех кто работает с продом.
ky0
Особенно прикольно, когда желание всё расшифровывать соседствует с BYOD.
vp7
Особая красота наступает в тот момент, когда "для сохранения безопасности" на VDI начинают пересаживать разработчиков.
Обязательным бонусом на VDI будет подмена SSL сертификатов (часть софта после этого просто перестаёт работать сообщая о повреждённом интернет-соединении) и блокировка "сомнительных сайтов-помоек" типа докерхаба и гитхаба (некоторые языки там хранят свои библиотеки). И вдруг оказывается, что половина разработчиков уже ищет новое место работы (где за те же деньги не будет такого ужаса), четверть готова работать в таком режиме и самостоятельно переписывать все библиотеки и даже полезные для работы инструменты (задача вместо рабочего дня будет занимать рабочий месяц, но, как говорится, "любой каприз за деньги работодателя"), а оставшиеся ищут способы обойти ограничения ИБ и в большинстве случаев - успешно их обходят, иногда по незнанию создавая ещё больше уязвимостей, чем было до внедрения "супер-безопасных VDI".
shifttstas
Ну да это из книги вредных советов, чаще всего что можно пересадить на VDI: фронт офис, и (в крайнем случае) отвечающих за настройки CI/CD на проде. (devops) Все остальное конечно лучше не ограничивать никаким VDI а то будет как@vp7написал
AlexeyK77
разработку вообще лучше выносить в отдельную зону с пониженными ограничениями, ибо нормально работать будет сложно. Диверсифицированное управление рисками никто не отменял.
shifttstas
Отдельная зона - это макбуки с доступным sudo. Никакие другие зоны - не удобны.
Busla
Сильно снижает уровень ИБ как раз подмена сертификата: шлюз/proxy становится точкой через которую проходят все пароли и прочая конфиденциальная информация проходят в открытом виде. Сам пользователь не в состоянии проверить достоверность целевого сайта. И вообще конечный пользователь перестаёт нести какую-либо отвественность, т.к. в итоге его данные может читать и подменять неопределённый круг лиц обслуживающий эти proxy подменяющие сертификаты.
Что касается удобства разработчиков на макбуках с sudo, упомянутого @shifttstas - вся эта свобода более-менее работает при разработке web-, облачных, всяких saas-сервисов, т.к. лицензии на код много чего позволяют для конечного использования. Если писать ПО для продажи - начинается ад учёта совместимости даже открытых лицензий.