Текущий стандарт языка JS не раскрывает информацию о сертификате; кроме того, вероятно, это зависит от того, как вы используете JavaScript, если вы ожидаете, что браузер конечного пользователя предоставит информацию о сертификате, то это будет действительно проблематично, потому что вам нужно получить минимальный FF, Chrome, Safari, IE Эдж, ... чтобы разоблачить это.
Однако, как упомянуто в этом сообщении по информационной безопасности , для этих браузеров это не совсем желательный вариант, так как это позволит ситуации, когда разработчик веб-сайта может написать код, по ошибке доверяющий стороне пользователя. учетные данные.
Это не столько риск безопасности видимости, который препятствует доступу javascript к текущей информации SSL-сертификата браузера, но скорее риск безопасности четвертой стены, когда разработчик JS должен знать, что «принятый пользователем» сертификат не обязательно тот, который предоставил сайт. HTML-страница на самом деле не должна обрабатывать проблемы безопасности с помощью кода на стороне клиента, но вместо этого она должна зависеть от уровня безопасности для правильного выполнения своей работы. (Я полностью понимаю желание проверить на уровне безопасности, но любая управленческая работа, которую вы выполняете на верхнем уровне, будет либо поверхностной, либо переработкой всей биосферы)
Поскольку давайте на мгновение предположим, что javascript действительно предоставил способ работы с сертификатом, то, когда Боб уже доверяет Мэллори, потому что его безопасность нарушена, невозможно остановить следующий обмен:
Офисный работник Боб находится на одной стороне огромного брандмауэра Mega Corp., IT Мэллори отвечает за брандмауэр, пропускающий трафик внутри компании и за ее пределы, а замечательный веб-сайт Алисы находится на WWW.
- В соответствии с политикой компании Mega Corp. Боб настроен просто принять то, что Мэллори говорит по номиналу.
- Боб, который хотел бы посетить сайт Алисы, но не имеет прямого доступа извне, пытается установить безопасное соединение через брандмауэр, подняв свой сертификат (например, «Я заявляю, что я Боб») и спрашивает Алису действительно запутанным образом, "какой сертификат я тебе отправил?"
- Мэллори получает запрос Боба, но вместо этого проходит самостоятельно (например, «Э-э, Боб говорит, что я могу читать его веб-почту»), и хотя Мэллори не понимает запутанный вопрос Боба, она все еще повторяет его Алисе , "akdvyfenwythnwerhy?".
- Алиса занимается математикой и выясняет, что "akdvyfenwythnwerhy?" спрашивает "какой сертификат я тебе отправил?" и отвечает обратно Мэллори с тем, что она видит («Привет, Боб, это Алиса, ты сказала:« Боб говорит, что я могу читать его веб-почту »).
- Мэллори занимается математикой, имеет ах-ха-момент «akdvyfenwythnwerhy? = Какой сертификат я тебе отправил?» И отвечает на вопрос Боба от имени Алисы («Привет, Боб, это Алиса ( Мэллори ») ) вы сказали: настоящим заявляю, что я Боб ").
- Боб верит, что жизнь прекрасна, и продолжает читать его веб-почту, потому что по правилам компании он знает, что Мэллори никогда не лжет ему.
- Мэллори теперь в состоянии прочитать обе стороны разговора, передает запрос Боба, чтобы прочитать его веб-почту Алисе.
- Алиса получает запрос Боба и говорит, эй, подожди минутку, Боб. Мне нужно, чтобы ты запустил этот код JS, чтобы доказать, что ты знаешь, что говоришь с Алисой.
- Мэллори получает код, запускает его и отправляет результаты, утверждая, что она знает, что разговаривает с Алисой, обратно к Алисе.
- Элис говорит, достаточно хорошо, вот ваша электронная почта.
- Мэллори читает электронную почту Боба, прежде чем передать ее Бобу, и все счастливы.
(Примечание: я не рассматривал случай, когда вы запускаете серверную часть JS, тогда это будет зависеть от того, какую программу вы используете для запуска кода JS.)
Edit 4/4/2018 - Хотя вышесказанное не является неправильным, это скорее с точки зрения встроенного и связанного JS, чем с объектом
XMLHTTPRequest JS; более того, вполне вероятно, что самый сильный аргумент против совместного использования деталей PKI с
XMLHTTPRequest выглядит следующим образом:
Должна оставаться сильная разделительная линия между частью HTTP и частью S протокола HTTPS. JavaScript и его XMLHTTPRequest объект находятся на стороне HTTP (уровень приложения) этой строки, тогда как весь процесс обмена сертификатами находится на стороне S (уровень trans / sec) этой строки. Чтобы сторона безопасности была атомарной (с возможностью горячей замены), ее внутренняя работа не может быть открыта через линию на стороне приложения; потому что может наступить день, когда транспортный уровень / уровень безопасности больше не использует сертификаты PKI для облегчения своей службы безопасной связи, и когда наступит этот день, никому не нужно будет переписывать любой существующий код JS, который полагался на детали, содержащиеся в этих сертификатах, для обработки с волной распространения, вызванной тем, что сообщество www постепенно принимает свой любимый вкус любого нового уровня безопасности.
При этом, по-видимому, сторона безопасности также проводит проверку юридических лиц - по крайней мере, в некоторых случаях, таких как сертификаты EV, - и это ИМО с недоумением RFC7230, раздел 2.7.2 что он не переопределяет authority https-URI для включения необязательного legalentity, который уровень безопасности будет использовать при проверке URL-адреса, с которым он связывается, является не только подходящей конечной точкой, но и в настоящее время под контролем предполагаемые деловые отношения.
authority = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ]
legalentity = *( unreserved / pct-encoded / sub-delims )