![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Jun. 26th, 2016 03:51 amПросто мысля, чтоб не потерялась:
Сегодня подавляющее количество траффика из типичной внутренней сети в Интернет выходит по шифрованному HTTPS. Современный файерволл предоставляет две опции для его обработки:
- либо отказаться от инспекции, разве что попытавшись проверить destination IP против заранее заданного списка (скажем, на файерволле заранее указано, какие адреса соответствуют *.windowsupdate.com),
- либо устраивать SSL inspection, то есть "узаконенный" man-in-the-middle attack: подсовывать юзеру фальшивый сертификат, расшифровывать и проверять траффик.
Обе опции проблематичны: первая - потому что поток данных полностью непрозрачен, плюс адреса служб имеют обыкновение меняться, а значит, внезапно будет накрываться связь. Вторая несёт в себе этические проблемы - если юзер заходит на сайт своего банка или больничной кассы, а сисадмин устраивает ему MitM, имея возможность совать нос в его данные - хорошо ли это, товарищи? Кроме того, вероятно, куча небраузерных программ, типа Дропбокса, перестанут работать, получив от файерволла левый сертификат.
Возможна третья опция - неидеальная, но предоставляющая какой-то компромисс. Файерволл может проактивно тестировать заранее заданные HTTPS-сервисы, подключаясь на них самостоятельно. Это позволит задавать в правила, наряду с стандартными "source & destination IP, source & destination port" также: Subject сертификата, имя выдавшего его CA, его уровень (DV/OV/EV), валидность по времени, длину ключа и так далее. Если файерволл подключился к сервису и получил сертификат, отличающийся от ожидаемого - соединения из внутренней сети туды не допускаются и конец делу.
(Можно, конечно, не открывать соединение, а просто пассивно инспектировать сертификаты, посланные сервером - но это не даст файерволлу криптографического подтверждения, что сервер и впрямь обладает законным ключом).
Как вариант, тестирование может проводить не сам файерволл, а служба егойного производителя, от которой файерволл будет получать регулярные апдейты (см., например, FortiCloud).
Кроме того, файерволл может проверять поле SNI в пакетах "Client Hello" исходящих SSL-соединений, чтобы убедиться, что клиенты пытаются подключиться к законному и проверенному сервису.
Таким образом, и клиентская приватность сохраняется, и сисадмину больше уверенности, что траффик наружу легальный ходит (а не какой пакостный бот изнутри на свой C&C коннектится).
К тому же, юзер уберегается от MitM-атак снаружи - он, допустим, не заметит, если mail.google.com внезапно предоставит сертификат от какого-нибудь странного ГУЦ, зато файерволл - таки да.
Интересно, изобретён ли уже этот велосипед?
Сегодня подавляющее количество траффика из типичной внутренней сети в Интернет выходит по шифрованному HTTPS. Современный файерволл предоставляет две опции для его обработки:
- либо отказаться от инспекции, разве что попытавшись проверить destination IP против заранее заданного списка (скажем, на файерволле заранее указано, какие адреса соответствуют *.windowsupdate.com),
- либо устраивать SSL inspection, то есть "узаконенный" man-in-the-middle attack: подсовывать юзеру фальшивый сертификат, расшифровывать и проверять траффик.
Обе опции проблематичны: первая - потому что поток данных полностью непрозрачен, плюс адреса служб имеют обыкновение меняться, а значит, внезапно будет накрываться связь. Вторая несёт в себе этические проблемы - если юзер заходит на сайт своего банка или больничной кассы, а сисадмин устраивает ему MitM, имея возможность совать нос в его данные - хорошо ли это, товарищи? Кроме того, вероятно, куча небраузерных программ, типа Дропбокса, перестанут работать, получив от файерволла левый сертификат.
Возможна третья опция - неидеальная, но предоставляющая какой-то компромисс. Файерволл может проактивно тестировать заранее заданные HTTPS-сервисы, подключаясь на них самостоятельно. Это позволит задавать в правила, наряду с стандартными "source & destination IP, source & destination port" также: Subject сертификата, имя выдавшего его CA, его уровень (DV/OV/EV), валидность по времени, длину ключа и так далее. Если файерволл подключился к сервису и получил сертификат, отличающийся от ожидаемого - соединения из внутренней сети туды не допускаются и конец делу.
(Можно, конечно, не открывать соединение, а просто пассивно инспектировать сертификаты, посланные сервером - но это не даст файерволлу криптографического подтверждения, что сервер и впрямь обладает законным ключом).
Как вариант, тестирование может проводить не сам файерволл, а служба егойного производителя, от которой файерволл будет получать регулярные апдейты (см., например, FortiCloud).
Кроме того, файерволл может проверять поле SNI в пакетах "Client Hello" исходящих SSL-соединений, чтобы убедиться, что клиенты пытаются подключиться к законному и проверенному сервису.
Таким образом, и клиентская приватность сохраняется, и сисадмину больше уверенности, что траффик наружу легальный ходит (а не какой пакостный бот изнутри на свой C&C коннектится).
К тому же, юзер уберегается от MitM-атак снаружи - он, допустим, не заметит, если mail.google.com внезапно предоставит сертификат от какого-нибудь странного ГУЦ, зато файерволл - таки да.
Интересно, изобретён ли уже этот велосипед?
