К сожалею, в статье не рассмотрены некоторые фундаментальные аспекты безопасности OAuth, которые я осветил тут: habr.com/ru/post/320744
В частности, не говорится о том, что в общем случае невозможно отличать сервисы-клиенты по client_id. Соответственно в общем случае нельзя выдавать чувствителеные к client_id методы в публичный API.
ready_for_sky_team подскажите пожалуйста, что за GSL то такой? А то гугление приводит только к General Service List и GNU Scientific Library, что явно не то.
Под фразой «dns узел» имелось в виду узел, идентифицируемый при помощи системы доменных имён, сиречь — dns.
Пункт 2 вашего описания рождает множество вопросов, например: что такое tls тоннель, каким образом он реализуется, как связан с текущим положением tls в стеке tcp/ip, как он будет инкапсулироваться в текущие форматы пакетов или сообщений? Думаю, что аккуратный вариант ответов на эти вопросы (в рамках существующих технологий) очень трудоёмок, а реализация в конкретных библиотеках ещё более затратна.
Да плюс такая реализация кроме привнесения инфраструктурных проблем ещё и добавит как минимум один раундтрип при установке соединения. А текущий драфт как раз направлен в том числе на минимизацию их количества. И я считаю, что это движение в правильном направлении.
Насколько я понял предложенное в обсуждении, это установление tls тоннеля с dns узлом поверх tls тоннеля с узлом идентифицируемым ip адресом. Мне кажется что с точки зрения библиотеки tls это много работы. Плюс много работы в том, чтобы подумать соответствую архитектуру системы: сертификатов на ip адреса я не видел.
А в том, что вы предлагаете есть серьезная проблема: 0-rtt используется для восстановления уже установленной сессии. Т.е. когда доверенность узла установлена. В вашем случае, совершенно непонятно с каким узлом было установлено изначальное соединение. Если следовать вашей логике, то это будет сервер, обслуживающий виртуальные сервера возможно даже с абсолютно разными доменами. В случае провайдера виртуального хостинга это будут все сайты его клиентов находящиеся на одной машине. Мне лично абсолютно не хочется доверять всем этим сайтам.
PFS скорее относится к ключам симметричного шифрования для уже установленного соединения.
А SNI как и получение сертификата (читай публичного ключа) для соответсвующего запрашиваемого имени — в установлении шифрованного соединения.
Мне кажется, что это предложение не пройдет: слишком многое надо делать для того, чтобы защитить адрес узла для обращения. SNI введен для того, чтобы на одном IP можно было обслуживать несколько виртуальных серверов с разными доменными именами. Т.е. SNI позволяет установить шифрованное соединение не IP<->IP а IP<->DomainService, что хорошо соответсвует сегодняшней практике использования сервисов в интернете. Если нужен тоннель в стиле IP<->IP то для этого лучше подойдут решения типа VPN. Городить TLS поверх VPN мне кажется никто не будет, что косвенно подтверждается тем, что за 2,5 года с момента возникновения обсуждения Encrypted SNI в текущем драфте нет никакого намека на предложенный вариант.
Что-то не нашел в драфте RFC упоминание о шифрованном SNI. Только лишь в случае 0RTT-Data, а он работает только в случае переиспользование предыдущей уже установленной сессии. Так как SNI это часть Client Hello, то что-то я не представляю как его можно зашифровать до обмена ключами.
Да, все верно. Но мне кажется, что достаточно проблематично стать таким CA и выдавать сертификаты на любые домены, чтобы при этом сертификат такого CA не заблокировал, например, Google в своём браузере. Производитель браузера может затем и надавить на root CA подписавший такой сертификат. Думаю root CA под угрозой блокировки своего сертификата быстренько отзовет сертификат выданный для CA поставщика DPI решений.
Отдельный вопрос в том, как вообще получить такой доверенный сертификат, который позволяет выдавать сертификаты на любые веб ресурсы. Мне кажется, что производителю DPI в таком случае нужно очень тесно дружить с разработчиками ОС и браузеров.
Спасибо за интересное исследование. Но у меня осталась пара вопросов после прочтения материала:
Как вы "фрагментируете" https?
В статье вообще не освещены механизмы работы DPI с https трафиком. На сколько я понимаю без того, чтобы в DPI был установлен валидный (с точки зрения браузера) сертификат, организовать глубокую инспекцию невозможно, и значит нужно блокировать весь https по IP. Тогда опять же в каких случаях ваше ПО помогает обойти DPI для https?
Когда круг пользователей хорошо контролируется, то мы можем развернуть доверенный центр сертификации и выдавать проверяемые сертификаты либо пользователям, либо приложениям (клиентам). Так же при наличии соответствующей Enterprise инфраструктуры можно устанавливать и обновлять сертификат пользователя на нескольких пользовательских устройствах.
К сожалению, самоподписанные сертификаты сложно контролировать и врядли они будут полезны в этом случае.
А если говорить о генерации чего-либо во время регистрации, то можно просто генерировать client_id и client_secret, но это, к сожалению, не решает описанных в статье проблем.
Разумное замечание. Но это только одна из освещаемых проблем.
Насколько я понимаю, OAuth как раз и создавался «безопасным» в частности в том смысле, что завладеть вашим паролем (client_secret) было невозможно, если клиентом являлось серверное приложение (что на сколько я понимаю, отражено в OAuth 1.0 и в OAuth 2.0 Authorization code flow). Затем появилась необходимость использования не только серверных клиентов, где безопасность client_secret не может быть гарантирована (OAuth 2.0 Implicit flow). Но стандарт не дает никаких рекомендаций о том, как мы можем гарантировать, что клиент действительно серверный и соответственно, что мы можем ему позволить обращаться к какому-то чувствительному в этом смысле API.
Так же, некоторые популярные библиотеки, реализующие OAuth провайдер вообще не уделяют внимания необходимости разделения таких клиентов, например FOS OAuthServerBundle. Можно сказать, что направление пользователя по правильному пути это не задача библиотеки, но например django-oauth-toolkit делает на этом явный акцент.
Ладно, друзья, мне было приятно с вами пообщаться, но времени на это обсуждение и так потрачено слишком много.
Понимаю, вас беспокоит собственная репутация и вы в любом случае не сдадитесь.
Единственно, не очень понятно почему публикация подобного рода появилась именно на Хабре, а не на Гиктаймс, к примеру. Но пусть это останется на откуп администрации.
За сим говорю вам адьес! И до встречи на просторах рунета!
> А вот меня бы беспокоила ситуация с уязвимыми сайтами на моей работе. Хоть бывшей, хоть нынешней. Как же так?
Ну так, знаете ли можно и беспокоится о клиентах первых продавцов колеса. (:
> Я там работал и ничего не предпринял для исправления ситуации и укрепления сна клиентов?
Да? Видимо вы пропустили тот пост, где я рассказывал о том, какие фиксы были сделаны мной и моими коллегами когда мы работали на Фабрике.
> На дворе давно уже MODX2.3.3
> Естественно. Как можно не обновлять систему и дополнения на рабочем сайте?
Ну вы еще начните ругать банки, за то что они WindowsXP используют в своих банкоматах, а не супер-пупер новый, офигенный Windows 8.
> Клиент как раз жаловался на то, что даже по запросу на обновление движка сайта они обновляют в лучшем случае за две недели, ссылаясь на то, что процедура эта трудозатратная (хотя с чистым MODX это делается в пять кликов)
Да, давайте ругать еще тех людей, которые до сих пор в своих проектах используют CentOS 5 и почему-то не спешат обновляться до версии 7…
> Если что-то не понятно, спрашивайте типа «а имели ли вы тут ввиду, что...?»
К счастью, я владею неким количеством серого вещества, которое позволяет мне делать правильные в большенстве своем умозаключения.
> Посмотрите наши цены и цены Фабрики
Посмотрел. Хорошие цены. Из этого следует, что вы не бедный, обиженный иском злой Фабрики фрилансер, а достаточно преуспевающая компания, которая может себе позволить и иск в 500 т.р. получить, и потратить достаточное количество ресурсов на формирование общественного мнения о себе.
> цель не привлечь их клиентов к нам, а предупредить их потенциальных клиентов
Возможно, но в этом комменте habrahabr.ru/post/257149/#comment_8403331 складывается впечатление, что вы отвечаете на вопрос человека о том, что надо с них денег получить тем, что и так мол все в порядке, запрос у нас в топе.
Путем нехитрых умозаключений можно придти к выводу, что вы зарабатываете деньги на том, что ваша страница в топе выдачи.
> При этом покупатель не сможет её ни обновить, ни как-то заштопать, потому что это неофициальный (форк| копия|непоймичто)
На сколько мне известно, все нормально обновлялось при помощи прямых рук и инструкции MODX.
А вообще, типичный покупатель сайта на MODX не сможет его обновить самостоятельно в принципе, так как совершенно не владеет IT, ну и узнать о необходимости обновления, скорее всего тоже.
Да, вопрос на засыпку: а вы обновляете сайты всех своих клиентов?
Вобщем все это демагогия.
Да Фабрика работает на поток, да у нее бывают косяки как и у всех в принципе и исходя из специфики поточности — в особенности (где-то был пример с общественным транспортом).
Но я не защищаю Фабрику, мне по большому счету все равно что у них и как сейчас происходит. Я за адекватную оценку ситуации и за некоторую обоснованность высказываемых суждений. Лишь с этой точки зрения я и проводил свою полемику. (:
В частности, не говорится о том, что в общем случае невозможно отличать сервисы-клиенты по client_id. Соответственно в общем случае нельзя выдавать чувствителеные к client_id методы в публичный API.
ready_for_sky_team подскажите пожалуйста, что за GSL то такой? А то гугление приводит только к General Service List и GNU Scientific Library, что явно не то.
Пункт 2 вашего описания рождает множество вопросов, например: что такое tls тоннель, каким образом он реализуется, как связан с текущим положением tls в стеке tcp/ip, как он будет инкапсулироваться в текущие форматы пакетов или сообщений? Думаю, что аккуратный вариант ответов на эти вопросы (в рамках существующих технологий) очень трудоёмок, а реализация в конкретных библиотеках ещё более затратна.
Да плюс такая реализация кроме привнесения инфраструктурных проблем ещё и добавит как минимум один раундтрип при установке соединения. А текущий драфт как раз направлен в том числе на минимизацию их количества. И я считаю, что это движение в правильном направлении.
А в том, что вы предлагаете есть серьезная проблема: 0-rtt используется для восстановления уже установленной сессии. Т.е. когда доверенность узла установлена. В вашем случае, совершенно непонятно с каким узлом было установлено изначальное соединение. Если следовать вашей логике, то это будет сервер, обслуживающий виртуальные сервера возможно даже с абсолютно разными доменами. В случае провайдера виртуального хостинга это будут все сайты его клиентов находящиеся на одной машине. Мне лично абсолютно не хочется доверять всем этим сайтам.
Т.е. защитить доменное имя узла
А SNI как и получение сертификата (читай публичного ключа) для соответсвующего запрашиваемого имени — в установлении шифрованного соединения.
Что-то не нашел в драфте RFC упоминание о шифрованном SNI. Только лишь в случае 0RTT-Data, а он работает только в случае переиспользование предыдущей уже установленной сессии. Так как SNI это часть Client Hello, то что-то я не представляю как его можно зашифровать до обмена ключами.
Т.е. если я правильно понимаю, ПО фрагментирует не HTTP заголовок (которой идёт уже зашифрованным), а сообщение TLS Client Hello?
Да, все верно. Но мне кажется, что достаточно проблематично стать таким CA и выдавать сертификаты на любые домены, чтобы при этом сертификат такого CA не заблокировал, например, Google в своём браузере. Производитель браузера может затем и надавить на root CA подписавший такой сертификат. Думаю root CA под угрозой блокировки своего сертификата быстренько отзовет сертификат выданный для CA поставщика DPI решений.
Спасибо! Не думал, что SNI идёт открытым текстом. Хотя это логично было бы предположить.
Спасибо за интересное исследование. Но у меня осталась пара вопросов после прочтения материала:
К сожалению, самоподписанные сертификаты сложно контролировать и врядли они будут полезны в этом случае.
А если говорить о генерации чего-либо во время регистрации, то можно просто генерировать client_id и client_secret, но это, к сожалению, не решает описанных в статье проблем.
Насколько я понимаю, OAuth как раз и создавался «безопасным» в частности в том смысле, что завладеть вашим паролем (client_secret) было невозможно, если клиентом являлось серверное приложение (что на сколько я понимаю, отражено в OAuth 1.0 и в OAuth 2.0 Authorization code flow). Затем появилась необходимость использования не только серверных клиентов, где безопасность client_secret не может быть гарантирована (OAuth 2.0 Implicit flow). Но стандарт не дает никаких рекомендаций о том, как мы можем гарантировать, что клиент действительно серверный и соответственно, что мы можем ему позволить обращаться к какому-то чувствительному в этом смысле API.
Так же, некоторые популярные библиотеки, реализующие OAuth провайдер вообще не уделяют внимания необходимости разделения таких клиентов, например FOS OAuthServerBundle. Можно сказать, что направление пользователя по правильному пути это не задача библиотеки, но например django-oauth-toolkit делает на этом явный акцент.
Понимаю, вас беспокоит собственная репутация и вы в любом случае не сдадитесь.
Единственно, не очень понятно почему публикация подобного рода появилась именно на Хабре, а не на Гиктаймс, к примеру. Но пусть это останется на откуп администрации.
За сим говорю вам адьес! И до встречи на просторах рунета!
Ну так, знаете ли можно и беспокоится о клиентах первых продавцов колеса. (:
> Я там работал и ничего не предпринял для исправления ситуации и укрепления сна клиентов?
Да? Видимо вы пропустили тот пост, где я рассказывал о том, какие фиксы были сделаны мной и моими коллегами когда мы работали на Фабрике.
> На дворе давно уже MODX2.3.3
> Естественно. Как можно не обновлять систему и дополнения на рабочем сайте?
Ну вы еще начните ругать банки, за то что они WindowsXP используют в своих банкоматах, а не супер-пупер новый, офигенный Windows 8.
> Клиент как раз жаловался на то, что даже по запросу на обновление движка сайта они обновляют в лучшем случае за две недели, ссылаясь на то, что процедура эта трудозатратная (хотя с чистым MODX это делается в пять кликов)
Да, давайте ругать еще тех людей, которые до сих пор в своих проектах используют CentOS 5 и почему-то не спешат обновляться до версии 7…
К счастью, я владею неким количеством серого вещества, которое позволяет мне делать правильные в большенстве своем умозаключения.
> Посмотрите наши цены и цены Фабрики
Посмотрел. Хорошие цены. Из этого следует, что вы не бедный, обиженный иском злой Фабрики фрилансер, а достаточно преуспевающая компания, которая может себе позволить и иск в 500 т.р. получить, и потратить достаточное количество ресурсов на формирование общественного мнения о себе.
Возможно, но в этом комменте habrahabr.ru/post/257149/#comment_8403331 складывается впечатление, что вы отвечаете на вопрос человека о том, что надо с них денег получить тем, что и так мол все в порядке, запрос у нас в топе.
Путем нехитрых умозаключений можно придти к выводу, что вы зарабатываете деньги на том, что ваша страница в топе выдачи.
На сколько мне известно, все нормально обновлялось при помощи прямых рук и инструкции MODX.
А вообще, типичный покупатель сайта на MODX не сможет его обновить самостоятельно в принципе, так как совершенно не владеет IT, ну и узнать о необходимости обновления, скорее всего тоже.
Да, вопрос на засыпку: а вы обновляете сайты всех своих клиентов?
Вобщем все это демагогия.
Да Фабрика работает на поток, да у нее бывают косяки как и у всех в принципе и исходя из специфики поточности — в особенности (где-то был пример с общественным транспортом).
Но я не защищаю Фабрику, мне по большому счету все равно что у них и как сейчас происходит. Я за адекватную оценку ситуации и за некоторую обоснованность высказываемых суждений. Лишь с этой точки зрения я и проводил свою полемику. (: