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