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
ты знаешь сами принципы асимметричного шифрования? на сервере шифруется приватным ключом, на клиенте расшифровывается публичным. это плюс сертификат сервера и защищает от такой атаки. то что ты описал возможно (в другом виде) когда пользователь не образщает внимание на отсутвие серта, или админ его винде подсовывает фальшивый trusting authority, или возможно это была как раз та ошибка в ssl 1.0
хм, а википедия говорит обратное и я с ней согласен:
