[FaultEvent fault=[RPC Fault faultString="The type initializer for 'PPG.Security.LoginManager' threw an exception." faultCode="Server.Processing" faultDetail="The type initializer for 'PPG.Security.LoginManager' threw an exception. : at PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
at PPG.Facade.General.Login(String username, String password)
at PPG.FlexService.Users.Login(String userName, String password)"] messageId="87D0435C-8E7D-474C-9F64-987A8280EEBC" type="fault" bubbles=false cancelable=true eventPhase=2]
потом еще одна
The type initializer for 'PPG.bl.States' threw an exception.
И все, войти нельзя, кнопка Sign In запрещена.
У кого то еще такое есть? или это у меня что то жестко глючит.
Всем яростно минусующим — читать здесь. Хоть и для АСПа, но в основах верно и для Флекса и т.п.
В частности:
The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it. An error message can be of vital significance to an attacker. A default ASP.NET error message lists the specific versions of ASP.NET and the .NET framework which are being used by the Web server, as well as the type of exception that was thrown. Just knowing which Web-based applications are used (in this case ASP.NET) compromises application security by telling the attacker that the server is running a relatively recent version of Microsoft Windows and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web server.
Если смотреть на тот кусок вырванного стек-трейса, то очень интересен контракт вызванного метода:
PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
т.е. пароль передается открытым текстом, великолепно! А если предположить, что это flex веб-приложение (я не спец по нему, могу ошибаться), то открытый пароль передается уже с клиента на сервер (PPG.Security.LoginManager.Login вызывается на клиенте, который вызывает метод сервиса на сервере PPG.FlexService.Users.Login), что просто кричит "захады дарагой, гостэм будэш".
Т.е. 1) делаем проксирующий дефейс (не забывая про SSL) страницы логина 2) складываем все логин/пароли к себе 3) профит. Или и того легче: снифаем ваш трафик (ISP провайдер, инет-кафе, WiFi) + 2)+3).
И это только беглый взгляд.
зы: M.A.D — вы же тестируете приложения за деньги, причем как организация, и ваш глаз не зацепился за эту проблему! нихира себе, ребята (с) Бородач
Здравствуйте, AnonThisTime, Вы писали:
ATT>Всем яростно минусующим — читать здесь. Хоть и для АСПа, но в основах верно и для Флекса и т.п. ATT>В частности: ATT>The more information a hacker can gather about a Web site, the more likely it is that he will be able to successfully attack it. An error message can be of vital significance to an attacker. A default ASP.NET error message lists the specific versions of ASP.NET and the .NET framework which are being used by the Web server, as well as the type of exception that was thrown. Just knowing which Web-based applications are used (in this case ASP.NET) compromises application security by telling the attacker that the server is running a relatively recent version of Microsoft Windows and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web server.
ATT>Если смотреть на тот кусок вырванного стек-трейса, то очень интересен контракт вызванного метода: ATT>PPG.Security.LoginManager.Login(String user, String password, Boolean UseEmailAsKey, Guid& CredentialToken)
ATT>т.е. пароль передается открытым текстом, великолепно! А если предположить, что это flex веб-приложение (я не спец по нему, могу ошибаться), то открытый пароль передается уже с клиента на сервер (PPG.Security.LoginManager.Login вызывается на клиенте, который вызывает метод сервиса на сервере PPG.FlexService.Users.Login), что просто кричит "захады дарагой, гостэм будэш". ATT>Т.е. 1) делаем проксирующий дефейс (не забывая про SSL) страницы логина 2) складываем все логин/пароли к себе 3) профит. Или и того легче: снифаем ваш трафик (ISP провайдер, инет-кафе, WiFi) + 2)+3). ATT>И это только беглый взгляд.
ATT>зы: M.A.D — вы же тестируете приложения за деньги, причем как организация, и ваш глаз не зацепился за эту проблему! нихира себе, ребята (с) Бородач
Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
Здравствуйте, Neud, Вы писали:
N>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил?
2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной.
3. ээээ...причем здесь я?
Здравствуйте, AnonThisTime, Вы писали:
ATT>Здравствуйте, Neud, Вы писали:
N>>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
ATT>1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил? ATT>2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной. ATT>3. ээээ...причем здесь я?
Ну вы высказали теорию, о том, что стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов. Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь. Вот я и спрашиваю, вы этим занимались?
N>>>Вы перегоняете пароли в открытом виде? Думаю, что тут, что-то типа md5 от пароля — не более. Вы когда-нибудь действительно занимались похищением паролей? Настраивание проксей и прочее?
ATT>>1. причем здесь "Вы перегоняете пароли в открытом виде"? Я о себе говорил? ATT>>2. Думать можно что угодно. Юзайте md5 на здоровье, только скажите названия приложений, чтобы обходить их стороной. ATT>>3. ээээ...причем здесь я? N>Ну вы высказали теорию, о том, что стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов. Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь. Вот я и спрашиваю, вы этим занимались?
О какой теории вы говорите? Т.е. чтобы защитить какую-то часть своего приложения/сервиса, где теоретически может быть угнана ключевая информация внутренностей, я должен обязательно сначало взломать незащищенную версию? А если не взломаю, то не защищать ибо "ну не хакер я, значит и другие не сломают"? Не долго такой сервис проживет.
Я привел ссылку с очень растространенными вариантами появления дыр в защите, и тут стек-трейс — это только один из элементов вытекшей информации. И это таки "показатель плохих программистов", я бы сказал даже нубов (возможно и по неосторожности). Ибо если чел пишет веб-сервис, то знание таких ньюансов, это как отче наш. Почитайте гайды по секьюрити, а в особенности параграф "Do Not Reveal Exception Details to the Client":
When exceptions occur, return concise error messages to the client and log specific details on the server. Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names to the client. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. A malicious user could use system-level diagnostic information to learn about your application and probe for weaknesses to exploit in future attacks.......
и у вас не возникнет такого: "стэк не стоит показывать пользователю. Это и да и нет, но не как не показатель плохих программистов".
Перехват паролей, по ssl, да еще и в asp.net это довольно не простая вещь
асп.нет это всего лишь платформа, на которой также можно писать говнокод, т.е. "да еще и в asp.net" не добавляет защиты в неумелые руки. Тут тонны вариантов хака.
С SSL сложнее, но не невозможно. Вон недавно пробегало, что взломали SSL 1.0 просто подсунув червя между клиентом и сервером (в ISP или сервер интернет-кафе например)!
Это конечно неправильно, но на самом деле информация об исключении не так страшно, как использование открытых паролей или "что-то вроде md5". Я так понимаю сервис можно считать скомпрометированным? По крайней мере до тех пор пока не найдут нормальных кодеров и не перелопатят движок на предмет уязвимостей.
Здравствуйте, grosborn, Вы писали:
G>Это конечно неправильно, но на самом деле информация об исключении не так страшно, как использование открытых паролей или "что-то вроде md5".
Вы совершенно правы! Гораздо лучше чтобы пароли передавались телепатически и так же телепатически еще и принимались.
О каком открытом виде передачи пароля идет речь, если весь уходящий из браузера на сайт панели трафик шифруется публичным ключом TLS 1.0 (SSL 3.1) и расшифровываться приватным ключом на сайте этого сервиса. Обоснуйте, пожалуйста.
Может и я тогда тоже для доступа покупателей к панельке управления купленными модулями небезопасно пароли шифрую с помощью безопасного логина через TLS соединение, как в Gmail?
> Вы совершенно правы! Гораздо лучше чтобы пароли передавались телепатически и так же телепатически еще и принимались.
Не. Кажись в вавилоне пять телепаты перехватывали пароли И вообще, пример с телепатом-перехватчиком разбирается как простейший пример при рассмотрении уязвимостей. Так что лучше, если пароль никто не знает и никто не видел, ыыыы....
> О каком открытом виде передачи пароля идет речь, если весь уходящий из браузера на сайт панели трафик шифруется публичным ключом TLS 1.0 (SSL 3.1) и расшифровываться приватным ключом на сайте этого сервиса. Обоснуйте, пожалуйста. > Может и я тогда тоже для доступа покупателей к панельке управления купленными модулями небезопасно пароли шифрую с помощью безопасного логина через TLS соединение, как в Gmail?
Я не специалист по криптосистемам. Да пусть меня поправят, если что не так напишу.
Несимметричные алгоритмы используются только при генерации сеансовых ключей.
Для передачи текущего трафика используются обычные симметричный алгоритмы шифрования сенсовым ключом, соль не используется, алгоритмы замедления (антибрутфорс) не используются.
Подход: восстановление исходного кода той части, что у вас передает пароль, получение алгоритма выделяющего из исходящего трафика пакета передачи пароля. Если этот шаг удачен и если пароль внутри tsl вы передаете открытым, то брутфорс по словарю или сразу даст пароль или даст сравнительно небольшой набор, с помощью которого можно будет его подобрать.
Лучше бы конечно специалиста спросить.
Здравствуйте, grosborn, Вы писали:
G>Лучше бы конечно специалиста спросить.
Лучший способ обезопасить логин, а так же другую информацию, передаваемую на сайт, является использование современных криптографических протоколов — TLS (SSL 3.1)
Если знаете что-то лучше этого — дайте знать.
В форумах типа вобла (vBulletin) вводили механизм передачи хешированого пароля с помощью JavaScript — а смысл? На сервере сравнивался этот же хеш с сохраненным, т.е. проснифив хеш передаваемый на сервер, злоумышленник так же может и сам передать его. В этом случае паролем выступает MD5 хеш пароля.
Единственный способ безопасно передать данные на сервер — использование криптографического протокола. И ничего тогда лишнего выдумывать не надо. Весь трафик будет шифрованный. Для некоторых CMS есть модули позволяющие осуществлять безопасный логин, например — http://drupal.org/project/securelogin
Более надежный способ аутентификации — двухфакторыный. Передача вместе с тем что вы знаете (пароль) еще и чего-то что есть только у вас (железяка генерирующая токен, смс код который вы получите на свой телефон) или чего-то кем вы являетесь (скан сетчатки глаза, ваше ДНК, отпечатки пальцев)
Но это уже совсем другая история.
Действительно интересно мнение авторитетных специалистов по безопасности веб-сайтов.
Если есть какой-то более безопасный метод передачи данных на сайт, кроме как через HTTPS с использованием TLS — дайте знать.
> Если есть какой-то более безопасный метод передачи данных на сайт, кроме как через HTTPS с использованием TLS — дайте знать.
Достаточно будет зашифровать пароль с солью, с нефиксированной длиной пакета и можно передавать по https.
Хэш md5 выбросить ф топку, для целей безопасности он уже не годится.
Использовать ключ и длину пакета от 1к.
Точнее зашифровать хэш пароля. Вам же хэш передать нужно? И в общем случае не использовать md5 хэш, а как минимум SHA512++, хотя рекомендуется что-то посильнее. Ну и хэш вы правильно написали, не должен быть сформирован только из исходного пароля.
Здравствуйте, grosborn, Вы писали:
G>Точнее зашифровать хэш пароля. Вам же хэш передать нужно? И в общем случае не использовать md5 хэш, а как минимум SHA512++, хотя рекомендуется что-то посильнее. Ну и хэш вы правильно написали, не должен быть сформирован только из исходного пароля.
Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же.
Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер)
Смысла в этом нет.
Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ.
И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0.
Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS (http://ru.wikipedia.org/wiki/TLS) намного более продумано и проверенно временем чем предложенное симметричное шифрование пароля с сальтом.
Пока это предложение с шифрованием пароля на стороне клиента с помощью симметричной криптографии типа SHA-2 и salt кажется как бы не особо подходящим, особенно в плане безопасности.
> Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же. > Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер) > Смысла в этом нет. > Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ. > И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0.
Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом.
Соответственно если есть возможность перхватить трафик и позиционировать ваш открытый пароль в шифрованном трафике, то ssl ломается, если позиционируем в трафике хэш пароля известного алгоритма (msd5), то опять ломается.
> Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
SSL несколько для иных целей сделан, чем для передачи паролей.
> Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS
Опять же сертификаты. Я не специалист, но вроде бы удостоверяется только одна сторона — сервер. Мы же передаем данные с клиента, то есть с неудостоверенной сертификатами стороны. И даже если бы удостоверялся клиент, телепат-перехватчик тоже может быть удостоверен.
---
Проблема в том, что все эти заборы-огороды создают видимость защищенности, а на самом деле одна маленькая дырка все ломает.
PK>Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же. PK>Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер) PK>Смысла в этом нет.
SHA это не шифрование! Не ясно, что значит "получить salt с клиента" и в чем не смысла.
PK>Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ. PK>И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0. PK>Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?
далеко-далеко не параноидально, когда речь идет о деньгах и/в финансовых системах! Представьте, что в один прекрасный день Вася добавил код в результате чего в качестве транспорта теперь юзается обычный http.
PK>Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS (http://ru.wikipedia.org/wiki/TLS) намного более продумано и проверенно временем чем предложенное симметричное шифрование пароля с сальтом.
в данной ситуации (передача пароля) надежность у обоих одинаковая и проверенность у них обоих одинаковая. Уже SHA256 не поддается расшифровке в разумных временных рамках. У них просто назначение разное. хеширование — для первичного "рукопожатия" (логина) клиента/сервера, а дальше траф не криптованный, SSL — для шифрования трафа на всем периоде сессии пользователя.
PK>Пока это предложение с шифрованием пароля на стороне клиента с помощью симметричной криптографии типа SHA-2 и salt кажется как бы не особо подходящим, особенно в плане безопасности.
G>Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом. G>Соответственно если есть возможность перхватить трафик и позиционировать ваш открытый пароль в шифрованном трафике, то ssl ломается, если позиционируем в трафике хэш пароля известного алгоритма (msd5), то опять ломается.
эээ, вы "слегка" заблуждаетесь на счет "некриптостойкое" и "сеансовым ключом". SSL это обычное ассиметричное шифрование с приватным/публичным ключем, т.е. не сеансовый ключ (я понимаю под сеансовым ключ, создаваемый для каждого сеанса новый). SSL это некисло-стойкое шифрование (пока скомпрометировали только SSL 1.0), т.к. шифровать могут все (публичный ключ), а расшифровать только сервер, т.е. даже перехватив зашифрованные траф, расшифровать не получится.
НО, от админов с прошлой работы слышал, что (им надо было мониторить корпоративный траф, чтобы ничего не уволокли) для виндового домена есть какая-то надстройка(плагин, хз), которая мониторит исходящий траф, и на запрос публичного ключ SSL протоколом, она генерит временную пару приват/паблик + запрашивает у оригинального хоста (у кого просят паблик ключ) паблик. Затем отдает клиенту (кто запросил) свой паблик, которым потом траф клиентом шифруется. Когда такой траф приходит в этот плагин, он его расшифровывает свои приватом, логирует, шифрует пабликом от отригинального хоста и отправляет по назначению. В результате браузер/приложение сотрудника не видит подлога, но шифрованный траф мониторится. Т.е. при таких атаках типа men in the middle, даже ssl/tls траф можно смотреть. И здесь как раз и поможет хеширование пароля, ибо можно в инет-кафе/на работе засветить свои креденшиалз и, возможно, потерять все деньги и не только.
G>Опять же сертификаты. Я не специалист, но вроде бы удостоверяется только одна сторона — сервер. Мы же передаем данные с клиента, то есть с неудостоверенной сертификатами стороны. И даже если бы G>удостоверялся клиент, телепат-перехватчик тоже может быть удостоверен.
не ясно, что такое "удостоверяется", да и не важно это. Важно, что расшифровать может толька знающий приватный ключ.
Здравствуйте, AnonThisTime, Вы писали:
ATT>НО, от админов с прошлой работы слышал, что (им надо было мониторить корпоративный траф, чтобы ничего не уволокли) для виндового домена есть какая-то надстройка(плагин, хз), которая мониторит исходящий траф, и на запрос публичного ключ SSL протоколом, она генерит временную пару приват/паблик + запрашивает у оригинального хоста (у кого просят паблик ключ) паблик. Затем отдает клиенту (кто запросил) свой паблик, которым потом траф клиентом шифруется. Когда такой траф приходит в этот плагин, он его расшифровывает свои приватом, логирует, шифрует пабликом от отригинального хоста
ты знаешь сами принципы асимметричного шифрования? на сервере шифруется приватным ключом, на клиенте расшифровывается публичным. это плюс сертификат сервера и защищает от такой атаки. то что ты описал возможно (в другом виде) когда пользователь не образщает внимание на отсутвие серта, или админ его винде подсовывает фальшивый trusting authority, или возможно это была как раз та ошибка в ssl 1.0
если бы описанное тобой в чистом виде было возможно — то смысла в ssl, т.е. защите от транзитных узлов, не было бы никакого!
а в кафе можно перехватить что угодно, кто контролирует машину — тот контролирует всё
Здравствуйте, grosborn, Вы писали:
>> Если есть какой-то более безопасный метод передачи данных на сайт, кроме как через HTTPS с использованием TLS — дайте знать.
G>Достаточно будет зашифровать пароль с солью
это называется pbkdf. суть в том, что к паролю юзера добавляется случайное число (соль), от него вычисляется криптохеш (sha512) и на сервер передаётся соль и хеш. если нужно обеспечить защиту от перебора, то sha вычисляется много раз рекурсивно, скажем чтобы общее время генерации хеша было 0.1с
передавая же соль с сервера, мы защищаемся от переиспользования перехваченного в прошлый раз ответа
Здравствуйте, grosborn, Вы писали:
G>Опять же сертификаты. Я не специалист, но вроде бы удостоверяется только одна сторона — сервер. Мы же передаем данные с клиента, то есть с неудостоверенной сертификатами стороны. И даже если бы удостоверялся клиент, телепат-перехватчик тоже может быть удостоверен.
они удостоверяются по-разному. сервер удостоверяет себя сертом, клиент — паролем. если у клиента нет пароля, то конечно любой может зайти и сказать "я вася, мне никто не звонил?"
а вот удостоверить клиента так, чтобы никто не смог под него потом подделаться — это как раз детская задачка по криптографии. ssl даёт вам в руки её готовое решение, позволяющее не вникать в детали шифрования, сертов и защиты паролей
> G>Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом. > > некриптостойкое шифрование — фраза дня! и шифрование идёт алгоритмом sha512++
Ну докопался к очепятке. Хэширование. Ты по сути-то что можешь написать? Раз специалист, скажи свое мнение можно ли открытый пароль по SSL передавать? Если скажем мы знаем, что вот этот пакет идущий по SSL — это отправка пароля пользователя на серверную сторону и перехватываем трафик. И принимаем, что можем перебором взломать 512 бит ключ (это с запасом на будущее).
Далось вам это асимметричное шифрование. Сам трафик шифруется симметричным, поскольку асимметричное затратно по процессорному времени, то есть медленное.
Здравствуйте, grosborn, Вы писали:
>> G>Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом. >> >> некриптостойкое шифрование — фраза дня! и шифрование идёт алгоритмом sha512++
G>Ну докопался к очепятке. Хэширование.
ещё лучше. хеширование — это когда ты берёшь любой обхём данных и вычисляешь его хеш. оно полезно для верификации что ничего случайно не потерялось. криптостойкое хеширование позволяет подписать данные — оно отличается от обычного тем, что нет быстрого способа сгенерить данные, имеющие заданный хеш
G>Ты по сути-то что можешь написать? Раз специалист, скажи свое мнение можно ли открытый пароль по SSL передавать? Если скажем мы знаем, что вот этот пакет идущий по SSL — это отправка пароля пользователя на серверную сторону и перехватываем трафик. И принимаем, что можем перебором взломать 512 бит ключ (это с запасом на будущее).
я не специалист. я читал пару книг о шифровании вообще. как устроен ssl — не в курсе. могу только сказать, что организовать MiM-устойчивую аутенфикацию сервера и проверку пароля можно, используя соль и асимметричное шифрование — значит в современных ssl так и сделано
Здравствуйте, grosborn, Вы писали:
G>Далось вам это асимметричное шифрование. Сам трафик шифруется симметричным, поскольку асимметричное затратно по процессорному времени, то есть медленное.
трафик — да. асимметричное шифрование всегда так и делается — асимметрично шифруем сеансовый ключ, а сеансовым ключом симметрично сам трафик. по защищённости это полностью соответствует асимметричному шифрованию всего трафика
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, AnonThisTime, Вы писали:
ATT>>НО, от админов с прошлой работы слышал, что (им надо было мониторить корпоративный траф, чтобы ничего не уволокли) для виндового домена есть какая-то надстройка(плагин, хз), которая мониторит исходящий траф, и на запрос публичного ключ SSL протоколом, она генерит временную пару приват/паблик + запрашивает у оригинального хоста (у кого просят паблик ключ) паблик. Затем отдает клиенту (кто запросил) свой паблик, которым потом траф клиентом шифруется. Когда такой траф приходит в этот плагин, он его расшифровывает свои приватом, логирует, шифрует пабликом от отригинального хоста
BZ> ты знаешь сами принципы асимметричного шифрования?
надеюсь что да.
BZ>на сервере шифруется приватным ключом, на клиенте расшифровывается публичным.
даааааа? хм, а википедия говорит обратное и я с ней согласен:
при которой открытый ключ передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу, и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифровки сообщения используется секретный ключ.
Публичный ключ в принципе расшифровать не может, иначе такое шифрование не называлось бы ассиметричным (однонаправленным).
Переадресовываю "ты знаешь сами принципы": а ты?
BZ>это плюс сертификат сервера и защищает от такой атаки.
от какой именно атаки и причем здесь сертификат (SSL сертификат?).
BZ>то что ты описал возможно (в другом виде) когда пользователь не образщает внимание на отсутвие серта, или админ его винде подсовывает фальшивый trusting authority, или возможно это была как раз та ошибка в ssl 1.0
ну как тогда работает это? Это тот же принцип — проксирование трафа.
BZ>если бы описанное тобой в чистом виде было возможно — то смысла в ssl, т.е. защите от транзитных узлов, не было бы никакого!
SSL и транзитные узлы никак не связано. Последних может быть сотня или не быть вообще, но траф стырят.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, grosborn, Вы писали:
G>>Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом.
BZ>некриптостойкое шифрование — фраза дня! и шифрование идёт алгоритмом sha512++
хм, вполне себе корректное название, т.е. шифрование крякнутым алгоритмом. не?
Я не понял, что тебе не нравится в "не криптостойкое шифрование". Не криптостойкое, это подразумевается в данном случае, что шифрование идет криптостойким алгоритмом, но недостаточной длиной ключа. Поскольку SSL призван защищать сеансовые данные и в общем случае перехваченный поток данных сеанса не позволяет идентифицировать в каком пакете какого типа данные идут, то можно использовать более короткие ключи. Но я разбирал частный случай. Вот в этом случае я и написал, что он не криптостойкий, то есть для некоторых видов атак длины используемых ключей недостаточно.
Здравствуйте, AnonThisTime, Вы писали:
BZ>>на сервере шифруется приватным ключом, на клиенте расшифровывается публичным. ATT>даааааа? хм, а википедия говорит обратное и я с ней согласен:
начнём с основ. АК использует два ключа — один шифрует, другой расшифровывает. процесс генерации ключа создаёт их оба. фишка АК в том, что зная один ключ, невозможно бытсро вычислить второй. при этом то, какой ключ ты опубликуешь — твоё дело
соответственно когда ты сказал, что MiM шифрует ключом, известным только серверу, я и назвал его приватным. суть дула в том, что этот ключ никто кроме сервера не знает
BZ>>это плюс сертификат сервера и защищает от такой атаки. ATT>от какой именно атаки и причем здесь сертификат (SSL сертификат?).
MiM. при том, что серт SSL сообщает публичный пароль сервера, и MiM не может под сервер подделаться, поскольку не знает секретного ключа. повторю — я не знаю, как устроен ssl, но описанную тобой схему нейтрализовать можно. если это и работало, то только с ssl 1.0 — там была какая-то ошибка
BZ>>то что ты описал возможно (в другом виде) когда пользователь не образщает внимание на отсутвие серта, или админ его винде подсовывает фальшивый trusting authority, или возможно это была как раз та ошибка в ssl 1.0
ATT>ну как тогда работает это? Это тот же принцип — проксирование трафа.
оно позволяет обойти парольную защиту? https сессии бывают и без авторизации — https://sf.net
BZ>>если бы описанное тобой в чистом виде было возможно — то смысла в ssl, т.е. защите от транзитных узлов, не было бы никакого!
ATT>SSL и транзитные узлы никак не связано. Последних может быть сотня или не быть вообще, но траф стырят.
а кто траф стырит, как не транзитные узлы через который он идёт?
Здравствуйте, AnonThisTime, Вы писали:
BZ>>некриптостойкое шифрование — фраза дня! и шифрование идёт алгоритмом sha512++
ATT>хм, вполне себе корректное название, т.е. шифрование крякнутым алгоритмом. не?
шифрование — это и есть encryption. что такое крякнутый алгоритм — не знаю
Здравствуйте, AnonThisTime, Вы писали:
ATT>НО, от админов с прошлой работы слышал, что (им надо было мониторить корпоративный траф, чтобы ничего не уволокли) для
Здравствуйте, grosborn, Вы писали:
G>Я не понял, что тебе не нравится в "не криптостойкое шифрование". Не криптостойкое, это подразумевается в данном случае, что шифрование идет криптостойким алгоритмом, но недостаточной длиной ключа. Поскольку SSL призван защищать сеансовые данные и в общем случае перехваченный поток данных сеанса не позволяет идентифицировать в каком пакете какого типа данные идут, то можно использовать более короткие ключи.
security by oscurity, работающее "в большинстве случаев" в шифровании использовать не принято. ты с чем-то перепутал
Здравствуйте, AnonThisTime, Вы писали:
ATT>НО, от админов с прошлой работы слышал, что (им надо было мониторить корпоративный траф, чтобы ничего не уволокли) для
собтсвенно, описанная тобой схема основана именно на том, что клиент не видит разницы между сертом оригинального сервера и сертом ваших админов. вот что делается в ssl:
Для того, чтобы сгенерировать ключи сеанса, используется безопасное соединение. Клиент шифрует случайное число с помощью открытого ключа (ОК) сервера и отправляет результат на сервер. Только сервер в состоянии расшифровать его (с его закрытым ключом (ЗК)), и только этот факт делает ключи скрытыми от третьей стороны, так как только сервер и клиент имели доступ к этим данным. Клиент знает открытый ключ и случайное число, а сервер знает закрытый ключ и (после расшифровки сообщения клиента) случайное число. Третья сторона, возможно, знает только открытый ключ, если закрытый ключ не был взломан.
таким образом, после хендшейка весь траф шифруется. но при атаке MiM весь траф становится известен миму. другое дело, что браузеры вроде предупреждают, когда сайт a.com вдруг подписывается сертом от сайта b.com
и так же телепатически еще и принимались.
хм, а википедия говорит обратное и я с ней согласен:
