>[оверквотинг удален]
> Во вторых, SSL решает иные задачи. Он обеспечивает явную защиту канала до
> ремоты с возможностью авторизации сертификатом и прочая и приложения явно в
> курсе успеха/неуспеха авторизации, параметров шифрования и прочая. А ipsec вообще так,
> "защита локалки". Ну или кто гарантирует что "вот отсюда до вон
> того сервера" ipsec пролезет и будет использовать стойкое шифрование? И как
> приложению проверить что оно натурально есть и стойкое? Ну мало ли,
> не хотим мы допустим в банке процессить транзакцию например если клиент
> не смог доказать сертификатом что он - именно он, а не
> некто левый. SSL это обеспечивает. IPSec ... а он для совсем
> других целей.кто сказал что для других?
> Он по идее прозрачен для приложений, но нам в
> данном случае надо наоборот явно знать успех авторизации, что клиент и
> сервер - именно те за кого себя выдают, шифрование - надежное,
> сертификат клиента - правильный. И вот тогда...
отсутствие соединения чем не показатель того что _защищенное_ соединение не установлено?
> То что там натупили с механикой подписывания сертификатов - отдельный вопрос, однако
> SSL можно использовать и например когда всего 1 CA которой мы
> натурально доверяем. В таком виде это даже вполне секурно, если что.
не нужно вообще использовать сертификаты, это порочная практика удостоверяющих центhов во всей красе показала свою несостоятельность, сертификаты зло -> на свалку. уже давно есть протjколы защищающие установку соединения обеспечивающие не тjлько защиту от MITM но и других векторов атак -> внимательно см. SRP или PAKE2
