Есть ли способ получить данные сертификата SSL с помощью JavaScript?

Я хотел бы получить некоторые сведения о SSL-сертификате на определенном веб-сайте. Я знаю, что это просто с помощью инструмента openssl в Linux/MacOSX. Однако возможно ли то же самое или подобное в JavaScript?

Я понимаю, что браузер обрабатывает соединения через сокеты и что рукопожатие SSL происходит до того, как какая-либо сторона отправит данные. Однако в XMLHTTPRequest я хотел бы знать, возможно ли получить эти данные как какой-то код ответа и т. д.?


person shaond    schedule 09.04.2010    source источник
comment
Я не думаю, что это возможно.   -  person SLaks    schedule 09.04.2010
comment
Я искал API Javascript для проверки проверенных учетных данных межсайтовых запросов для повышения безопасности сайта. К сожалению, браузер отбрасывает эту информацию, что затем заставляет скрипты слепо доверять тому, что стороннему содержимому теперь можно доверять, потому что ему доверяли в прошлом. Это печальное положение дел. :-(   -  person Wil    schedule 25.11.2017
comment
Некоторые люди добавляют сведения о сертификате в заголовки ответа. В этой настройке вы можете сделать запрос xhr и прочитать req.getAllResponseHeaders()   -  person Spikolynn    schedule 02.12.2017
comment
Это лучше, чем ничего, но не обеспечивает реальной безопасности. В основном меня интересует получение данных от рекламодателей. Когда я пишу рекламный код для монетизации для клиента, я не хочу возвращаться и проверять, что рекламодатель все еще работает каждые несколько месяцев, чтобы предотвратить взлом его сайта, потому что я извлекаю ресурсы скрипта с сайта, которого нет. больше не принадлежит рекламодателю, и я не хочу говорить клиенту, что теперь это безопасно, но теперь, когда я закончил, вы предоставлены сами себе. Удачи!   -  person Wil    schedule 20.03.2018


Ответы (4)


Эта информация просто недоступна для javascript, она так редко используется (ну, никогда, поскольку она недоступна, но будет использоваться редко), что она не считается достаточно важной, чтобы добавить ее в я полагаю, что объектная модель javascript ... одинакова для любой очень редко используемой функции, оставленной без внимания.

Конечно, это также могло быть опущено из соображений безопасности... В данный момент я недостаточно изобретателен, чтобы придумать что-то подобное, но я уверен, что там тоже есть эксплойт.

person Nick Craver    schedule 09.04.2010
comment
@GregS - я тоже не могу придумать ни одного ... но я уже говорил это 100 раз, и кто-то найдет уязвимость, о которой я никогда не подумал, я полагаю, другое мышление ... .so я просто выбрасывал этот вариант. Если бы вы размещали рассматриваемый javascript ... разве вы не были бы тем, у кого уже есть сертификат? Вот что наводит меня на мысль, что каким-то образом для этого может быть еще какое-то гнусное использование. Однако, как я уже сказал, это определенно не моя область знаний, я оставлю это вам и другим, кто специализируется в этой области, подробно рассказать о том, что может быть возможно. - person Nick Craver; 09.04.2010
comment
Спасибо, Ник, думаю, мне придется подумать о том, как получить данные SSL на стороне клиента кросс-платформенным способом, без JS или установки альтернативных двоичных файлов (таких как openssl, curl/wget). - person shaond; 09.04.2010
comment
Безопасность моих страниц повысилась бы, если бы я мог использовать Javascript для проверки того, что сторонний сайт, с которого я встраиваю контент, остается тем же объектом, которому я доверял при создании страницы. В настоящее время браузер пытается подтвердить эту информацию, а затем отбрасывает ее, заставляя мои страницы предполагать, что доверительные отношения все еще существуют сегодня, потому что они были в прошлом. Я чуть не поставил минус1 твоему посту за то, что он извергал слепой FUD. Нет никаких подвигов, чтобы знать, с кем вы разговариваете. Пожалуйста, переосмыслите свой ответ. - person Wil; 25.11.2017
comment
@JamesKPolk на самом деле это проблема безопасности, поскольку веб-сайты не могут определить, был ли взломан SSL и используется поддельный сертификат. - person aaa90210; 12.10.2018
comment
@ aaa90210: Хорошо, что вы ответили 8,5 лет спустя, но сертификаты являются общедоступными ценностями, и их нетрудно получить любым из множества способов. Тот факт, что движок javascript браузера не может легко это сделать, не является проблемой безопасности. - person President James K. Polk; 12.10.2018
comment
@JamesKPolk да, но если вы не можете сравнить сертификат текущей веб-страницы с сертификатом, вы думаете, что должно возникнуть проблема. - person aaa90210; 12.10.2018
comment
@ ааа90210: Неверно. Это то, что делает браузер, а не ваш javascript. - person President James K. Polk; 12.10.2018

Сертификат не является частью DOM, поэтому нет, это невозможно. Прости!

person John Feminella    schedule 09.04.2010
comment
Да, грустно, но факт. Поэтому нам нужно, чтобы некоторые заинтересованные стороны на самом деле подняли шум по этому поводу в W3C, Mozilla, Chromium (а Safari и Edge последуют их примеру, как только против их платформ появятся CVE за то, что они не следуют). - person Wil; 30.03.2018

Нет, невозможно.

С помощью javascript можно определить, находится ли текущая просматриваемая страница через SSL-соединение (document.location.protocol=="https:"), но это все.

person Sean    schedule 09.04.2010
comment
а затем вы можете передать это значение document.location службе REST, чтобы получить информацию о сертификате. - person Saber; 12.09.2018
comment
@Saber, человек в середине атаки, все равно будет проблемой ... Я хочу проверить подпись открытого ключа сертификата, чтобы убедиться, что браузер напрямую общается с моим сервером. Но да, интересная идея... стоит изучить... - person AlexV; 19.01.2019

Текущий стандарт языка JS не предоставляет информацию о сертификате; кроме того, это, вероятно, зависит от того, как вы используете JavaScript, если вы ожидаете, что браузер конечного пользователя предоставит информацию о сертификате, тогда это будет действительно проблематично, потому что вам нужно будет получить как минимум FF, Chrome, Safari, IE , Край, ... чтобы выставить его.

Однако, как упоминалось в этом публикации по информационной безопасности, на самом деле это нежелательный вариант для этих браузеров, так как это может привести к ситуации, когда разработчик веб-сайта может написать код, чтобы ошибочно доверять учетным данным пользователя.

Это не столько угроза безопасности видимости, которая не позволяет javascript получить доступ к текущей информации о SSL-сертификате браузера, а скорее угроза безопасности барьера четвертой стены, когда разработчик JS должен знать, что «принятый пользователем» сертификат не обязательно тот, который предоставленный веб-сайт. HTML-страница действительно не должна решать проблемы безопасности с кодом на стороне клиента, но вместо этого она должна зависеть от уровня безопасности, чтобы правильно выполнять свою работу. (Я вполне понимаю желание проверить уровень безопасности, но любая управленческая работа, которую вы выполняете на верхнем уровне, будет либо поверхностной, либо переработкой всей биосферы)

Поскольку давайте на мгновение предположим, что javascript действительно предоставляет способ работы с сертификатом, тогда, когда Боб уже доверяет Мэллори, потому что его безопасность нарушена, невозможно остановить следующий обмен:

Офисный работник Боб находится по одну сторону большого брандмауэра Mega Corp., ИТ-специалист Мэллори отвечает за брандмауэр, пропускающий входящий и исходящий трафик компании локально, а замечательный веб-сайт веб-хостинга Алисы находится в Интернете.

  1. Согласно политике компании Mega Corp., Боб настроен просто принять то, что говорит Мэллори, за чистую монету.
  2. Боб, который хотел бы посетить сайт Алисы, но не имеет прямого доступа извне, пытается установить безопасное соединение через брандмауэр, подняв свой сертификат (например: «Настоящим я заявляю, что я Боб») и очень запутанно спрашивает Алису , "какой сертификат я вам отправил?"
  3. Мэллори получает просьбу Боба, но вместо этого передает ее самостоятельно (например: «Э-э, Боб говорит, что я могу читать его веб-почту»), и хотя Мэллори не понимает запутанный вопрос Боба, она все равно повторяет его Алисе: «akdvyfenwythnwerhy ?».
  4. Алиса занимается математикой и выясняет, что «akdvyfenwythnwerhy?» спрашивает "какой сертификат я вам отправил?" и отвечает Мэллори тем, что видит («Привет, Боб, это Алиса, ты сказал: Э-э, Боб говорит, что я могу читать его веб-почту»).
  5. Мэллори занимается математикой, ахает: "akdvyfenwythnwerhy?=какой сертификат я вам отправил?", и отвечает на вопрос Боба от имени Алисы ("Привет, Боб, это Алиса(Мэллори) ты сказал: настоящим заявляю, что я Боб»).
  6. Боб считает, что жизнь хороша, и продолжает читать свою электронную почту, потому что, согласно политике компании, Мэллори никогда не станет ему лгать.
  7. Мэллори теперь может читать обе стороны переписки по просьбе Боба прочитать его веб-письмо Алисе.
  8. Алиса получает запрос Боба и говорит: «Эй, подожди минутку, Боб, мне нужно, чтобы ты запустил этот JS-код, чтобы доказать, что ты знаешь, что разговариваешь с Алисой».
  9. Мэллори получает код, запускает его и отправляет результаты, заявляя, что она знает, что разговаривает с Алисой, обратно Алисе.
  10. Алиса говорит, достаточно для меня, вот ваша электронная почта.
  11. Мэллори читает электронную почту Боба, прежде чем передать ее Бобу, и все счастливы.

(Примечание: я не рассматривал случай, когда вы используете 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
comment
Ваш ответ не касается вопроса. Вопрос заключался в том, может ли Javascript получить доступ к данным в сертификате, что уже подтверждено транспортным уровнем браузера. К сожалению, браузер отбрасывает его. Ничто в его вопросе не подразумевало реализацию транспорта в Javascript или обход безопасности транспорта. -1 - person Wil; 25.11.2017
comment
@Wil, глядя на ваши комментарии, разбросанные по ветке, я полагаю, что вы пытаетесь использовать JS, когда вам следует искать решение PHP или ASP. JS - это клиентская сторона, и если вы пытаетесь проверить информацию о сертификате на компьютере пользователя, это уже слишком поздно. - person Gregor y; 08.12.2017
comment
Я думаю, вы недооцениваете тот факт, что настоящие приложения пишутся для работы в браузере — приложения, которые должны уметь делать простую вещь, например, доказывать, что они разговаривают с партнером, с которым намеревались общаться. PHP не работает в браузере. ASP не работает в браузере. Будущее не за серверными приложениями. Запрещение приложению подтверждать личность однорангового узла снижает безопасность передачи от SSL-EV к сертификату со сломанным SSL. - person Wil; 20.03.2018
comment
@Wil, написать функцию проверки на JS, а затем передать эту функцию хакеру и вежливо попросить его убедиться и беспрепятственно использовать его код для проверки, немного оптимистично. - person Gregor y; 21.03.2018
comment
Более того, если клиентское JS-приложение не поверит в свое самооправданное доказательство достоверности скомпрометированного токена, это не позволит ему совершить очень большую ошибку; уровень приложения JS получает свои данные, включая собственный код приложения, из уровня безопасности ниже, поэтому, когда токен безопасности скомпрометирован, можно довольно безопасно предположить, что то же самое относится и к коду JS, и нет никакого волшебного доказательства действительности, которое при замене с function check_valid(){return true;} посредником не всегда будет просто штамповать сломанный токен, как показано в чрезмерно упрощенном примере из реальной жизни выше. - person Gregor y; 21.03.2018
comment
Когда я создавал код, у меня были доверительные отношения с организацией Example.Com Ltd. Я хотел бы убедиться, что ответившая организация не изменилась, т.е. response.certificate.peer.o==Example.Com Ltd. Был ли мой скрипт загружен в безопасном контексте, это отвлекающий маневр. Сам браузер мог быть загружен в небезопасном контексте. Никто (кроме вас) не предлагал проводить проверки SSL/TLS на Javascript, и я уже разубедил вас в этой нелепой идее. Сам браузер уже проверил ДОМЕН и ПУНКТ. Я хочу проверить PEER. - person Wil; 21.03.2018
comment
@Wil, это похоже только на рыжий харинг, потому что использование вашего конкретного случая далеко не по теме. Уровень безопасности имеет две обязанности: во-первых, убедиться, что никто не подслушивает и/или что-то изменить, а во-вторых, убедиться, что клиент не разговаривает с самозванцем. - person Gregor y; 22.03.2018
comment
В вашем случае response.certificate.peer.o=="Example.Com Ltd" не будет работать, потому что: response.certificate.peer.o будет для текущего документа и должен иметь MyOwnSite.com LLC, посредник может поменять местами if(response.certificate.peer.o=="Example.Com Ltd"){DoCode();} с if(true){DoCode();}, аналогичным образом посредник может просто создать свой собственный сертификат с полем o, установленным на значение, которое ищет код для т.е. "Example.Com Ltd"... - person Gregor y; 22.03.2018
comment
Я считаю, что в вашей ситуации вы действительно хотите использовать PHP/ASP для пересылки стороннего JS-приложения. Ваше JS-приложение будет использовать AJAX для запроса и загрузки стороннего кода из формы PHP/ASP в вашем домене. Затем форма PHP: запрашивает код у третьей стороны, выполняет проверку, если проверка проходит, сохраняет копию на вашем сервере и пересылает ее клиенту, но если проверка не удалась, тогда форма PHP может пройти последнюю хорошая копия стороннего кода для вашего приложения, работающего на стороне клиента. - person Gregor y; 22.03.2018
comment
Это будет зависеть от уровня безопасности, чтобы исключить любого посредника между вашим доменом и клиентом, и при ручном сохранении учетных данных третьей стороны в вашем домене будет полагаться на ваш PHP для устранения любого посредника между вашим доменом и третьей стороной. изображения (что при правильном кодировании было бы математически доказуемо). - person Gregor y; 22.03.2018
comment
Что касается вашего предложения о том, почему это не сработает, это всего лишь пример вашего невежества в программировании XHR и Javascript. Каждый XHR является объектом ответа, и я бы тестировал объект ответа от стороннего партнера. Теперь вы доказали, что ваш ответ не по теме, потому что вы даже не понимаете тему. - person Wil; 30.03.2018
comment
Спасибо, что признали необходимость проверки узла. Теперь признайте, что необходимость обратного вызова на сервер моего приложения является взломом и не решает проблему. Если клиент загружается на сервер со скомпрометированным DNS-сервером и направляется на совершенно другой хост, чем сервер моего приложения, то результаты сервера моего приложения бессмысленны. Нет никакой причины скрывать проверенные браузером сведения о сертификате запроса к Javascript через объект запроса. Кроме параноидальных разглагольствований нескольких человек, которые понятия не имеют, о чем говорят. - person Wil; 30.03.2018
comment
И пока я на этом, весь аргумент 4-й стены - это FUD. В настоящее время приложения вынуждены полагать, что пользователь НЕ принял недействительный сертификат со стороннего сайта. Разрешение сценарию проверять части сертификата, идентифицирующие одноранговые узлы, в качестве второй линии защиты никак не снижает безопасность приложения или пользователя. Это позволяет приложению отказываться работать, если пользователь делает что-то глупое, или если есть MITM или Spoof с успешно подделанным сертификатом (за последние пару лет таких было десятки тысяч). Ваш пример также демонстрирует ваше непонимание того, как ПКИ работает. - person Wil; 30.03.2018
comment
1) Это не имеет ничего общего с DNS, но действительный https позаботится о проблеме перенаправления, 2) Мне жаль, что вы не видите дыры в вашей модели безопасности, но PKI работает, потому что на сервере есть доверенное хранилище сертификатов. клиентский компьютер. Когда это хранилище не нарушено, 2-й слой излишен; и когда он взломан, вы не можете передать код сценария через эту брешь, чтобы исправить ее. Потому что это повлечет за собой повторную реализацию нового уровня хранилища сертификатов в скомпрометированной среде. - person Gregor y; 03.04.2018
comment
3) Лишние или нет, вопреки почти всем рекомендациям, которые я видел, такие люди, как вы, все еще используют XSS; поэтому, вероятно, в XHR должен быть встроен механизм, позволяющий хосту «одобрять» и/или делегировать «утверждение» сторонних ресурсов. Похоже, что на developer.mozilla.org/ может быть некоторый прогресс. en-US/docs/Web/HTTP/CORS - person Gregor y; 03.04.2018
comment
Проблема в том, что CORS позволяет только хосту библиотеки одобрять использование своих ресурсов хостом франшизы, но по-прежнему отсутствует часть, где франшиза утверждает код, проверенный клиентом из библиотеки до того, как клиент его запустит. Пока это не будет реализовано, вы застряли на своем хосте, проверяя код, одобряющий его и передающий клиенту. То, как вы проверяете и утверждаете его, зависит от того, как вы хотите реализовать его на стороне сервера, но, по крайней мере, тогда команда разработчиков JS не подвергла остальных из нас ложной надежде на проверку ошибочных учетных данных с использованием скомпрометированного кода. - person Gregor y; 03.04.2018
comment
Кроме того, в качестве побочного примечания вы захотите исправить свой скрипт проверки, чтобы он шел вверх по цепочке сертификатов, пока он не дойдет до сертификата EV, прежде чем он будет полагаться на юридическое лицо, представленное .certificate.peer.o, поскольку это единственное, что ушло через процесс проверки. - person Gregor y; 03.04.2018
comment
1) клиент может принять неверный сертификат MITM при захвате DNS. Например, Firefox и Chrome предлагают это пользователю клиента. В этот момент да, все ставки сняты, но, по крайней мере, мы можем усложнить успех MITM, отклонив данные, которые плохо подделаны. Некоторые усилия лучше, чем отсутствие усилий. - person Wil; 10.05.2018
comment
3) Да, это XSS. Почти все сторонние рекламные приложения используют XSS, который по своей сути небезопасен, потому что мы передаем управление скриптовым движком браузера третьей стороне, которой мы доверяли В ПРОШЛОМ, но понятия не имеем, стоит ли нам доверять им сейчас. Следовательно, необходимо убедиться, что они по-прежнему являются той сущностью, которой мы доверяли при написании кода. Я согласен, что тестирование на стороне сервера имеет потенциал, но оно не будет иметь дело с MITM и требует дополнительных запросов, что повышает стоимость обслуживания. Выполнение этого на стороне клиента будет буквально ничего не стоить и будет более эффективным. - person Wil; 10.05.2018
comment
CORS не по теме. Это не имеет к этому никакого отношения. Это ослабление ограничений безопасности XSS, а не подтверждение подлинности однорангового узла. Если CORS позволит вам указать, что XYZ.COM является допустимым сторонним источником сценариев, только если его организация EV также является такой же доверенной организацией, тогда да, она будет соответствовать требованиям. Но это не часть спецификации. CORS позволяет вам использовать O_AUTH, файлы cookie и т. д. для проверки третьей стороны. Опять же, это подразумевает дополнительные накладные расходы, на этот раз требующие динамического контента от того, что в противном случае было бы статическим CDN. - person Wil; 10.05.2018
comment
Опять же, я хотел бы повторить, что речь идет не о недоверии к безопасности транспортного уровня, хотя он не заслуживает полного доверия, как упоминалось ранее. Речь идет об обеспечении соблюдения требований к организационным отношениям, которые реализует PKI и которые браузер представляет пользователю клиента через зеленую полосу. Однако уровень сценария затем действует как агент пользователя от его имени под видом доверительных отношений, демонстрируемых этой зеленой полосой, в то время как браузер препятствует тому, чтобы уровень сценария вел себя заслуживающим доверия образом, предотвращая требуемые доказательства доверия. - person Wil; 10.05.2018
comment
Ваше утверждение о том, что сценарий должен слепо доверять транспортному уровню на основе валидности сертификата, равносильно тому, что Боб слепо доверяет тому, что у него есть номер телефона Шэрон, потому что он разговаривал с ней по этому номеру однажды в прошлом. Затем Шэрон заменяется Ширли, у которой нет прав доступа, звонит Боб и вслепую раскрывает жизненно важные данные Ширли, потому что он не выполняет простого приветствия, это Шэрон? рукопожатие после набора номера. Но я ценю, что вы отредактировали свой текст, чтобы отразить ваше растущее понимание этих проблем. Надеюсь, теперь вы понимаете еще больше. - person Wil; 10.05.2018
comment
Вот почему я предположил, что добавление Шэрон к URL-адресу или, в вашем случае, к номеру телефона позволит уровню безопасности отображать зеленую полосу пользователя или «страница содержит незащищенный контент» JS с возможностью отклонить вызов, когда телефонная компания переназначит номер телефона Ширли. Однако это по-прежнему оставляет вас в беде, поскольку на самом деле это не позволит JS остановить неизвестное рекламное ПО от прохождения, если пользователь одобрит это; в этот момент XMLHTTPRequest все равно нужно будет предоставить статус проверки безопасности обратно на уровень JS. возможно: {NON_SECURE, VALID_ENDPONT, VALID_EV} - person Gregor y; 11.05.2018
comment
хотя с целевым набором сертификатов добавление статуса безопасности может привести к утечке XMLHTTPRequest того, кто входит в круг доверия конечного пользователя. потому что тогда злонамеренный контроллер сайта может написать JS, чтобы иметь XMLHTTPRequest ping https://badguy.com/mixed-content-of-targeted-certificates?cert1_accepted=yes&cert2_accepted=no&cert3_accepted=yes - person Gregor y; 11.05.2018
comment
Много шума из ничего пост. ОП спрашивает, как получить ››сертификат сервера‹‹, не имея ничего общего с доверием к клиенту. Если вы собираетесь сказать «нет», просто слепо доверяйте браузеру и не позволяйте клиентам проверять подпись сервера в некоторых сообщениях с данными, по крайней мере, дайте подходящий ответ. - person theAnonymous; 27.07.2018
comment
@ user3635998 Я говорю, что у JS нет лучшего выбора, чем слепо доверять браузеру в обеспечении уровня безопасности. Поскольку JS — это не программа, которую пользователь купил в магазине, принес домой и установил на свой ПК, это был просто фрагмент текста, отправленный через тот же уровень безопасности. Вы не можете доверять ему, чтобы он сканировал себя после того, как он прибыл, если вы уже слепо не доверяли безопасности браузера, чтобы доставить его безопасно; вот почему по той же причине антивирусное программное обеспечение компилируется в чистой комнате. - person Gregor y; 01.08.2018
comment
Как я уже сказал, много шума из ничего. В будущем, 1000000 лет в будущем может не использовать серт, бла-бла-бла херпит сумасшедший. Нет никакого оправдания тому, чтобы не дать JS доступ к сертификату сервера, как видно из браузера. Наличие window.getCert() — это плохо, потому что пользователь не купил такую ​​функцию. Точно так же, как пользователь не покупал браузер. ммм, верно. пффф. - person theAnonymous; 01.08.2018
comment
Кстати, если сайт больше не использует сертификат, а JS полагается на наличие сертификата, будет эта волшебная вещь, называемая ошибкой. - person theAnonymous; 01.08.2018
comment
@user3635998 да через 1000000 лет в будущем ваш сайт все еще обслуживает какой-то архаичный текстовый файл с window.getCert() ... и тогда что? о да, компьютер клиента интерпретирует это как код и запускает window.getCert=function(){return function(){return 'valid cert'}}();, потому что он был безопасно доставлен в браузер. Но эй, если у вас есть ссылки, по которым современные браузеры реализуют getCert(), потому что это такой новая идея, до которой никто не додумался, пожалуйста, поделитесь. - person Gregor y; 02.08.2018
comment
Сарказм теряется на ____. Такие люди, как вы, совершенно не способны объяснить, почему сообщать JS о сертификате сервера — это плохо. - person theAnonymous; 02.08.2018