G>это если он ключи не перехватит.
Педевикия... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Здравствуйте, VGn, Вы писали:
VGn>При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может.
Ну конечно же сможет. Ведь настоящий сервер может всё расшифровать? Вот и подменный тоже сможет. Сертификаты, которые тебе так не нравятся, придумали не зря.
... << RSDN@Home 1.2.0 alpha rev. 677>>
VGn>>При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может.
S>Ну конечно же сможет. Ведь настоящий сервер может всё расшифровать? Вот и подменный тоже сможет. Сертификаты, которые тебе так не нравятся, придумали не зря.
Только если он до этого послал пользователю свой открытый ключ, выдав его за ключ сервера. А это уже простой прослушкой трудно назвать. Собственно для проверки ключей и создана сертификация.
Это вы, думаю, знаете.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138>>
Здравствуйте, VGn, Вы писали:
G>>это если он ключи не перехватит.
VGn>Педевикия
И что? Учим матчасть:
Боб выбирает пару (e, d) и отправляет e Алисе.
Но Джек, который сидит посредине открытого канала, выбирает свою пару ключей (e1, d1) и отправляет алисе e1.
Теперь Алиса шифрует сообщение m ключом Джека и отправляет ему с. Джек при помощи d1 дешфирует его, подменяет на m1, шифрует ключом e и отправляет Бобу. В итоге Алиса уверена, что отправляет тексты Бобу, а Боб ни в чём не уверен, потому что он опубликовал ключ для кого угодно.
Это называется атакой типа man-in-the-middle, и именно от нее защищают сертификаты, которые тебе так не нравятся.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Здравствуйте, VGn, Вы писали:
VGn>Только если он до этого послал пользователю свой открытый ключ, выдав его за ключ сервера. А это уже простой прослушкой трудно назвать.
Еще раз: глупо надеяться, что злоумышленник получит read-only доступ к каналу. Как правило, если есть доступ к каналу, то есть и возможность вклиниться.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.
При прямом либо косвенном формировании http-заголовков к этому тоже стремиться уже не стоит хотя бы из-за
http-response-splitting'а
