Комментарии 66
А что на счет HTTPS cертификата? Вы его для 127.0.0.1 поставляете вместе с ключом?
А в чём проблема сделать домен localhost.mydomainname.com с A записью = 127.0.0.1, и получить сертификат на этот самый localhost.mydomainname.com?
А так можно?
Всмысле, не разу не пробовал делать A запись на 127.0.0.1
Всмысле, не разу не пробовал делать A запись на 127.0.0.1
Да, можно. И таких вагон уже в интернете, например http://readme.localtest.me/ — даже с сертификатом.
вопрос в другом — что мешает вирусу запустить сервис на другом локальном порту, и продолжать выглядеть как белый и пушистый, проксируя, например, запросы реальному локалхостовому?
Порта в SSL сертификате нет, браузеры его не проверяют…
вопрос в другом — что мешает вирусу запустить сервис на другом локальном порту, и продолжать выглядеть как белый и пушистый, проксируя, например, запросы реальному локалхостовому?
Порта в SSL сертификате нет, браузеры его не проверяют…
А толку-то. Приложение-то обращается к конкретному порту, забинденному легитимным сервером. Никто вручную не переходит на localhost:xxx, оно вызывается js-приложением. Теоретически можно и его подменить, но так теоретически можно вовсе троян полноценный поставить или ещё что похуже. Сертификаты тут уже не помогут, если враг уже имеет доступ к устройству.
Когда вирус в системе, ему уже ничего не мешает. Даже выпускать сертификаты) Правда только не для лисы. У нее свое хранилище сертификатов.
Элементарно. Выдаете самозаверенный и авторизирующего центра, помещаете в хранилища, биньдите на порт локалхоста, все шито крыто. Правда первый раз хорошенько нужно повозюкаться, чтобы разобраться как все это работает.
А не означает ли это, что скомпрометированный компьютер в корпоративной сети потенциально будет иметь доступ к локальному веб-серверу на других компьютерах сети? Есть ли в локальном веб-сервере проверки на то, откуда пришел запрос?
Или ответственность за это перекладывается на админов?
Или ответственность за это перекладывается на админов?
У корейских интернет-банков похожая система используется. На компьютер ставится софтина, несущая с собой локальный приватный сертификат и работающая как локальный веб/прокси-сервер для определённого набора реквестов.
При открытии банка html-страничка приходит в браузере напрямую через обычный SSL, а вот запросы на операции идут через запущенное приложение, которое занимается криптованным общением с сервером.
В подробности не вникал, но выглядит очень похоже :)
При открытии банка html-страничка приходит в браузере напрямую через обычный SSL, а вот запросы на операции идут через запущенное приложение, которое занимается криптованным общением с сервером.
В подробности не вникал, но выглядит очень похоже :)
Интересно, а нативного стандартизированного доступа браузеры не предоставляют? Я видел (как минимум в винде) штатную поддержку смарт-карт.
Во, я погуглил, нашёл ссылку: https://github.com/ubinity/webpcsc-firebreath
(весь топик: http://stackoverflow.com/questions/15807038/architectures-to-access-smart-card-from-a-generic-browser-or-how-to-bridge-the)
Во, я погуглил, нашёл ссылку: https://github.com/ubinity/webpcsc-firebreath
(весь топик: http://stackoverflow.com/questions/15807038/architectures-to-access-smart-card-from-a-generic-browser-or-how-to-bridge-the)
Видел аналогичное решение при запуске Lineage II с сайта наших прекрасных дистрибьюторов в РФ.
Т.е. натурально, — заходим на сайт, нажимаем «играть» — запускается игра на компьютере. Там только с тем лишь отличием, что использовался для этого WebSocket (что выглядит более логичным, нежели ajax). Разумеется там тоже был TLS.
Самое интересное там было, что подключиться к серверу можно было только с определенного сайта. Т.е. открываю консоль разработчика и ввожу команду открытия соединения — если открыт «правильный» сайт — подключается, неправильный — не подключается. Я подумал что это работает через SNI и не стал разбираться.
Т.е. натурально, — заходим на сайт, нажимаем «играть» — запускается игра на компьютере. Там только с тем лишь отличием, что использовался для этого WebSocket (что выглядит более логичным, нежели ajax). Разумеется там тоже был TLS.
Самое интересное там было, что подключиться к серверу можно было только с определенного сайта. Т.е. открываю консоль разработчика и ввожу команду открытия соединения — если открыт «правильный» сайт — подключается, неправильный — не подключается. Я подумал что это работает через SNI и не стал разбираться.
А что насчет брандмауэра Windows и всяких фаерволов?
Они же по умолчанию могут блокировать такие подключения.
Будете писать инструкции под зоопарк антивирусов?
Они же по умолчанию могут блокировать такие подключения.
Будете писать инструкции под зоопарк антивирусов?
Не наю, локалхост на локалхост ниче не блокируется, вроде как) Китайщина 360 total secutiry, NOD Security ничего не замечают.
1) не понял, почему localhost на localhost? Я где буду работать с вашим WebClient?
Наверняка ведь на сайте https://www.my-site.ru?
И тут возникает ряд проблем:
— с https на http некоторые браузеры (например, IE) не дают сходу заходить (а если и дают — то теряют referrer)
— некоторые браузеры (например, IE и Opera) могут блокировать localhost, т.к. он не в зоне Интернета, а Интранета
— фаерволы типа Касперского и DrWeb тоже будут блокировать (видимо, вы так настроили свой ESET NOD32)
— если же купить свой https сертификат на localhost, то еще одна проблема — антивирусы по умолчанию сканируют https, подменяя сертификат — и я не уверен, что тут они корректно подменят
2) учитывая первый пункт, как вы отличаете хороших от плохих?
Например, я сделаю свой http://www.cool-jc-web-site.ru, на котором буду у всех посетителей пытаться дергать WebClient и воровать все по-максимуму
Как вы понимаете, кто к вам пришел? Если по Referrer, то перечитайте 1 пункт + Referrer несложно подделать в Ajax-запросах
Наверняка ведь на сайте https://www.my-site.ru?
И тут возникает ряд проблем:
— с https на http некоторые браузеры (например, IE) не дают сходу заходить (а если и дают — то теряют referrer)
— некоторые браузеры (например, IE и Opera) могут блокировать localhost, т.к. он не в зоне Интернета, а Интранета
— фаерволы типа Касперского и DrWeb тоже будут блокировать (видимо, вы так настроили свой ESET NOD32)
— если же купить свой https сертификат на localhost, то еще одна проблема — антивирусы по умолчанию сканируют https, подменяя сертификат — и я не уверен, что тут они корректно подменят
2) учитывая первый пункт, как вы отличаете хороших от плохих?
Например, я сделаю свой http://www.cool-jc-web-site.ru, на котором буду у всех посетителей пытаться дергать WebClient и воровать все по-максимуму
Как вы понимаете, кто к вам пришел? Если по Referrer, то перечитайте 1 пункт + Referrer несложно подделать в Ajax-запросах
Наверняка ведь на сайте https://www.my-site.ru?
не важно какой сайт, если вы предполагаете работу с локальным сервером у пользователя все аякс запросы с сайта https://www.my-site.ru будут направлены локалхост.
— с https на http некоторые браузеры (например, IE) не дают сходу заходить (а если и дают — то теряют referrer)
Да, с https нельзя делать запрос на http из за смешанного содержимого. Решается сертификатами самоподписными.
— фаерволы типа Касперского и DrWeb тоже будут блокировать (видимо, вы так настроили свой ESET NOD32)
может мы про разное говорим.
если же купить свой https сертификат на localhost, то еще одна проблема — антивирусы по умолчанию сканируют https, подменяя сертификат — и я не уверен, что тут они корректно подменяткупить на локалхост невозможно. Только самоподписный. То что они там подменяют, меня не интересует потому что либо они ломают все https сайты вместе с локальным сервером, либо ничего не ломают.
Например, я сделаю свой http://www.cool-jc-web-site.ru, на котором буду у всех посетителей пытаться дергать WebClient и воровать все по-максимуму
Проверять сертификат на сервере при рукопожатии?
Да, с https нельзя делать запрос на http из за смешанного содержимого. Решается сертификатами самоподписными.«Решается»? Браузер же будет дико ругаться на такой сертификат… И если в IE проблему еще можно обойти через msxml2.ServerXMLHTTP ( у него есть метод setOption(), позволяющий игнорировать разные ошибки сертификата), то в других браузерах — нет.
А если делать простой http:// — то это откровенная дыра — существует куча вирусов-сниферов на основе HTTP-Analyzer и Fiddler (если кто-то не верит — могу показать ответ Касперского на вопрос «почему вы считаете HTTP-Analyzer „not-a-virus“ и что это такое?)
купить на локалхост невозможно. Только самоподписныйМожно, и выше было описано, как именно — сделать https://localhost.my-site.ru, только вот нужно его в hosts прописать, а есть такие антивирусы — DrWeb и Avira — которые любят блочить и/или возвращать старый hosts
То что они там подменяют, меня не интересует потому что либо они ломают все https сайты вместе с локальным сервером, либо ничего не ломают.Нет, опять не согласен. Мы (с вами) живем в стране на букву Р (если я не ошибся), в которой широко распространен в узких кругах алгоритм ГОСТ — и вот он точно не будет работать, т.к. антивирусы не могут поддержать ГОСТ опять же из-за законов (и не могут его не сканировать, т.к. криворукие).
Это я только один пример бага антивирусов привел. Нет гарантии, что это будет работать.
Получается, что ваше решение протестировано только на http://?
И это в эру, когда крупные компании начинают переходить на HTTP/2?
Браузер же будет дико ругаться на такой сертификат…
Сделайте сертификат удостоверяющего центра, положите его в хранилище корневых центров, подпишите им самозаверенный и ничего нигде не ругается и не должно.
Можно, и выше было описано, как именно — сделать https://localhost.my-site.ru,
Домен https://localhost.my-site.ru не имеет к домену localhost никого отношения. Купить сертификат на localhost нельзя, раньше было можно. С самозаверенными сертификатами нет никаких проблем в работе. Игры с hosts не нужны.
антивирусы не могут поддержать ГОСТ опять же из-за законов
Это проблема вашего антивируса, что он вам не показывает сайты каким то там гостовым сертификатом потому что он не может подменить сертификат.
Получается, что ваше решение протестировано только на http://?
Что значит протестировано?) Вы используете рабочее решение никем не запрещаемое. И какая разница какой протокол, делайте на каком угодно.
Сделайте сертификат удостоверяющего центра, положите его в хранилище корневых центров, подпишите им самозаверенный и ничего нигде не ругается и не должно.Получается примерно так:
— сделать самоподписанный корневой
— сделать для него инсталлятор (абоненты ведь не руками будут это ставить, на дворе 21 век)
— сделать инструкцию для доменных админов, которые запрещают абы как менять хранилище корневых
— разгребать тонну звонков и писем по этому поводу
Чем это проще, чем плагины для браузеров?
Домен https://localhost.my-site.ru не имеет к домену localhost никого отношенияМожет иметь, и это было описано в комментариях выше.
Но почему-то вы упускаете из виду очевидное решение этой проблемы:
— на DNS-сервере для домена my-site.ru делаем запись localhost.my-site.ru = 127.0.0.1
— тогда и файл hosts менять не придется
Это проблема вашего антивируса, что он вам не показывает сайты каким то там гостовым сертификатом потому что он не может подменить сертификат.Это проблема Касперского, DrWeb, ESET NOD32, Avast, Outpost, ZoneAlarm. Короче, где-то 40% рынка.
Что значит протестировано?)Коммерческое решение должно быть проверено на разных ОС и браузерах, с разными (популярными) антивирусами и программами, а не только с ESET NOD32.
Пока что вся статья выглядит скорее как гипотеза, работающая с ограниченном числе сценариев.
И какая разница какой протокол, делайте на каком угодноРазница, наверное, в том, что вы — производитель защищенных носителей с конфиденциальной информацией на борту. Странно слышать от вас такие слова. Телохранитель должен проважать босса до квартиры, а не до подъезда, ибо даже в подъезде (localhost) может всякое случиться (кейлоггеры, снифферы и т.д.)
Получается примерно так:
— сделать самоподписанный корневой
— сделать для него инсталлятор (абоненты ведь не руками будут это ставить, на дворе 21 век)
— сделать инструкцию для доменных админов, которые запрещают абы как менять хранилище корневых
— разгребать тонну звонков и писем по этому поводу
Сертификаты делаются один раз производителем дома. Ставятся незаметно для пользователя при первом запуске приложения за 1 сек копированием и привязкой к ip.
Чем это проще, чем плагины для браузеров?
Что проще, поддерживать зоопарк браузеров кроссплатформенно, или одну кроссплатформенную утилиту?
Ответ для любого разработчика очевиден.
Но почему-то вы упускаете из виду очевидное решение этой проблемы:
— на DNS-сервере для домена my-site.ru делаем запись localhost.my-site.ru = 127.0.0.1
— тогда и файл hosts менять не придется
Как я вам и писал
Сообщество безопасности Интернета прекращает действие имен интранета и IP-адресов в качестве основных доменных имен или альтернативных имен субъектов (SAN) в сертификатах SSL. Это решение распространяется на всю отрасль, а не только на нашу компанию.
https://ru.godaddy.com/help/prekrashenie-dejstviya-imen-intraneta-i-ip-adresov-v-ssl-6935
Можно подумать кто-то бы говорил о проблеме расширений для браузеров если бы они работали как надо. Разговор с того и начался что они везде постоянно глючат из за своих велосипедов, у кого с activeX (маки и убунты плачут) у кого долбанные ява аплеты.
Это проблема Касперского, DrWeb, ESET NOD32, Avast, Outpost, ZoneAlarm. Короче, где-то 40% рынка.
Стоит нод и вебер. первый раз слышу о проблеме что они насильно ломают какие-то сайты потому что в россии такие законы а они насильно мстят пользоваелю.
Разница, наверное, в том, что вы — производитель защищенных носителей с конфиденциальной информацией на борту.
Я не имею к производителю отношения. К тому же, не понимаю в чем проблема обвинений, когда весь интернет построен на http где всякое может случиться даже в подъезде
с 1 октября 2016 г. центры сертификации (ЦС) должны отзывать сертификаты SSL, в которых используются имена интранета или IP-адреса.
это для любителей привязывать локальные ip к поддоменам.
это для любителей привязывать локальные ip к поддоменам.
Сертификаты делаются один раз производителем дома. Ставятся незаметно для пользователя при первом запуске приложения за 1 сек копированием и привязкой к ipЕсли делать публичный сервис, то все равно столкнешься с доменными администраторами абонентов, которые запретили установку корневых сертификатов своим абонентам.
Но ладно, проблему, видимо, можно решить за счет поддомена localhost.my-site.ru
Что проще, поддерживать зоопарк браузеров кроссплатформенно, или одну кроссплатформенную утилиту?Нет, не очевиден.
Ответ для любого разработчика очевиден
Какая любимая фраза тех.поддержки? «Не работает? Попробуйте в другом браузере!»
С плагинами это работает безотказно. С вашим локальным сервером, видимо, если и не работает, то сразу везде.
А потом начальник тех.поддержки начинает капать на мозги тимлиду команды разработки.
Или еще того хуже — идет в финансовому директору и показывает отчет о расходах на ТП.
Я не имею к производителю отношенияПост в блоге компании «Алладин Р.Д.»
В начале и в конце статьи я не вижу предупреждений, что статья написана человеком, не имеющим отношения к компании.
Видимо, поэтому и подумал.
К тому же, не понимаю в чем проблема обвинений, когда весь интернет построен на http где всякое может случиться даже в подъездеНаверное, потому, что далеко не весь Интернет пользуется продуктами компании Алладин Р.Д.
Если я правильно понимаю, если речь идет о JC WebClient — значит автоматически и о токенах.
Очень надеюсь, что почти 100% сайтов, работающих с токенами, работают по https://
Стоит нод и вебер. первый раз слышу о проблеме что они насильно ломают какие-то сайты потому что в россии такие законы а они насильно мстят пользоваелю.Я общался с DrWeb лично, и с Аваст по почте.
Первые сказали, что о проблеме знают, но не хотят лезть туда, где правит ФСБ (тем более, что у них есть сертификация своего антивируса в России, которой они дорожат)
Вторые полгода что-то пытались делать, потом сказали, что у них есть более приоритетные задачи, чем починить пару десятков сайтов у пары сотен своих пользователей
Если делать публичный сервис, то все равно столкнешься с доменными администраторами абонентов, которые запретили установку корневых сертификатов своим абонентам.
Но каким-то образом умудрившихся установить дрова на токены без прав админисратора. А в сертификате значит вся засада будет. Сертификат по факту нафиг не нужен, просто с https сайта не сделать http запрос. В хроме можно но каждый раз нужно кнопку жать на «разрешить», вобще не удобно. А сами запросы делайте обшифрованные какие угодно если так хочется без этих сертификатов.
Какая любимая фраза тех.поддержки? «Не работает? Попробуйте в другом браузере!»
Ну так потому что рабочая фраза. Только в случае с плагинами этого сделать невозможно.
С плагинами это работает безотказно
особенно когда он только для IE, а для лисы, хрома, и столько же для мака и линукса. Итого ~ 9 зверей каждый со своими причудами.
Ни один браузер кроме IE не позволяет удобно соединять железо с сайтом через расширения. Все это костыльное, непроизводительное и не приятное постоянно текучее в разработке и поддержке дело. В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницу. Причем так мало инфы, если бы не стаковерфлоу уй бы сделали. И все равно тупило. В хроме хуже всего даже не брались. Еще ява апплеты живы в инетбанкинге. Жесть просто. Если бы взяли только js-ctypes и только лису для банкинга, по мне было бы куда лучше, чем все это явааплетные дырищи и игнорируемые мако и убунтоводы.
Или еще того хуже — идет в финансовому директору и показывает отчет о расходах на ТП.
Я не работаю в такой компании и продукт у нас для своих. Но то что за два дня человек сделал основу на шарпе того, что делал месяц в разработке расширения для листы говорит о многом. О скорости отладки раширений вообще отдельная песня. Сайт просто общается аяксом с железом, что еще нужно ?))
Сейчас же не важно чем пользуется пользователь, хоть хромом, хоть амиро браузером. Вообще не важно и это очень удобно.
у пары сотен своих пользователей
а говорили о слезах 40% рынка.
Но каким-то образом умудрившихся установить дрова на токены без прав админисратора. А в сертификате значит вся засада будет.Я сам встречался с такими админами — их ответ: «мы права не урезаем, нам просто самим так удобнее распространять свои корневые сертификаты по домену, ну а то что они при этом перестают ставиться у самих абонентов — мы не в курсе»
Ну так потому что рабочая фраза. Только в случае с плагинами этого сделать невозможно.Возможно. У одного абонента с ломаной виндой плагин работает в одном браузере, у другого с пиратской сборкой — в другом.
В каком-то смысле оба абонента довольны.
В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницуА я правильно понял, что код для сканера одинаковый для всех ОС? Windows, Linux, MacOS? Серьезно? Там же под Windows только 2 разных варианта…
В лисе есть js-ctypes через него подключали сканер отпечатков прямо на веб страницу. Причем так мало инфы, если бы не стаковерфлоу уй бы сделали. И все равно тупилоТам весь затык в MFC и ATL. Если писать на чистом Си — все работает относительно быстро.
Хотя где теперь найдешь таких программистов…
а говорили о слезах 40% рынкаУ меня и у авторов антивируса разное понятие рынка… и разные масштабы…
Админы разные бывают. Да, в расширении можно избежать админских прав. Но цену этого не знаю… все равно накатывают дрова на железо требующее админские права.
Ну конечно с плагином для связи сканера нужно писать кросплатформенно если такая есть задача. Нет, у нас винда была. Пихали поток картинок в браузер с SDK чтобы оператор на сайте сделал стоп в нужном прижиме пальца. И все время не покидало чувство а нафига тут расширение)) все равно dll ка пишется для связи. И просадок FPS был в два раза. На чистом си… ха… мы не те специалисты)) А когда узнали что поток интерфейса лисы работает в том что что и плагин… и когда лиса висит пока сканер не отдаст… это был бы капец без стаковерфлоу. Причем хрен где это написано с примерами.
У одного абонента с ломаной виндой плагин работает в одном браузере, у другого с пиратской сборкой — в другом. В каком-то смысле оба абонента довольны.А как для разработчика, он один раз пишет js для обмена с токеном код. Один раз на все платформы. И только сервер точится под платформу.
Ну конечно с плагином для связи сканера нужно писать кросплатформенно если такая есть задача. Нет, у нас винда была. Пихали поток картинок в браузер с SDK чтобы оператор на сайте сделал стоп в нужном прижиме пальца. И все время не покидало чувство а нафига тут расширение)) все равно dll ка пишется для связи. И просадок FPS был в два раза. На чистом си… ха… мы не те специалисты)) А когда узнали что поток интерфейса лисы работает в том что что и плагин… и когда лиса висит пока сканер не отдаст… это был бы капец без стаковерфлоу. Причем хрен где это написано с примерами.
Как вы понимаете, кто к вам пришел?
origin подделать незя через js. А он всегда при кроссдомене передается.
https://habrahabr.ru/company/aladdinrd/blog/306920/?reply_to=9734538#comment_9731340
Есть гипотеза, что в IE можно подделать то ли через msxml2.XMLHTTP.6.0, то ли через msxml2.ServerXMLHTTP.6.0
Есть гиптоеза что Referer при аяксе можно было подделать только 00-ые.
Дак Referrer или Origin?
Referrer — да, нельзя подменить, но при запросах с https:// на http:// он пропадает, что накладывает ограничение на использование вашего API
Origin — поменять можно, работает хоть в IE6, хоть в IE11, через объект Msxml2.ServerXMLHTTP можно выставить любой origin и скачать файл с любого стороннего веб-сайта. Таким образом, пользователи IE потенциально уязвимы в вашем случае.
Что могу порекомендовать — для IE оставить вариант с ActiveX, а для остальных браузеров сделать вариант с locahost
Раньше ведь вы поддерживали 2 варианта — ActiveX и NPAPI.
Referrer — да, нельзя подменить, но при запросах с https:// на http:// он пропадает, что накладывает ограничение на использование вашего API
Origin — поменять можно, работает хоть в IE6, хоть в IE11, через объект Msxml2.ServerXMLHTTP можно выставить любой origin и скачать файл с любого стороннего веб-сайта. Таким образом, пользователи IE потенциально уязвимы в вашем случае.
Что могу порекомендовать — для IE оставить вариант с ActiveX, а для остальных браузеров сделать вариант с locahost
Раньше ведь вы поддерживали 2 варианта — ActiveX и NPAPI.
По стандрату Origin невозможно изменить программно.
1) если бы все работало по стандарту — я бы, наверное, тут не писал :-)
2) думаю, что хакера, который будет использовать эту уязвимость, такой ответ не остановит :-)
2) думаю, что хакера, который будет использовать эту уязвимость, такой ответ не остановит :-)
хакера должны пруфы приводить.
Накидал по-быстренькому:
http://andrew-ch.narod.ru/cors.htm
Походу M$ таки движется к закрытию своих дырок — на последней сборке IE11 уже по умолчанию не работает — приходится сайт добавлять в надежные узлы.
Но почему-то мне кажется, что в прошлом году я проверял — и работало без этого.
http://andrew-ch.narod.ru/cors.htm
Походу M$ таки движется к закрытию своих дырок — на последней сборке IE11 уже по умолчанию не работает — приходится сайт добавлять в надежные узлы.
Но почему-то мне кажется, что в прошлом году я проверял — и работало без этого.
у меня и в надежные не добавляет. Говорит не https(
статься 10 года. Вроде бы как… должно было работать как CORS появился нормальный
https://blogs.msdn.microsoft.com/ieinternals/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds/
статься 10 года. Вроде бы как… должно было работать как CORS появился нормальный
https://blogs.msdn.microsoft.com/ieinternals/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds/
У нас утилита — локальный сервер на https://localhost:5000. Общение аяксом. Отдает в браузер сканы со сканера, как получает новые в папке, так и посылает с браузера на термопринтер этикетки.
Только в Лисе нужно подтвердить сертификат, так как у нее свое хранилище. В остальных браузерах все на ура сразу.
Только в Лисе нужно подтвердить сертификат, так как у нее свое хранилище. В остальных браузерах все на ура сразу.
На самом деле для всех кто мучался с токенами инет банков пришло большое благо, отлаживать локальные вебсервера на ошибку разработчикам КУДА проще чем все эти недоплагины к браузерам. Плюс независимость от браузера, наконец-то. Плюс кроссплатформенность на фронтэнде. Куча проблем, помоему, решается.
Вместо некоторого, но всё же ограниченного круга браузеров теперь вам нужно поддерживать 9000 разных операционных систем и архитектур. Отличное решение, что же тут скажешь.
Поставить всю эту байду с ключами и ПО на сервер. Сотрудникам пробросить локальный прокси на нужный порт (через интернет в том числе). Если такая схема работает, то shut up and take my money
Вебмани Кипер абсолютно аналогичным образом подписывает запросы при платежах и авторизациях.
Может с десяток лет, может даже больше.
Может с десяток лет, может даже больше.
Github Desktop тоже использует подобный метод.
при работе через локальный прокси-сервер пользователь видит в адресной строке браузера не реальный URL веб-страницы на удалённом сервере, а что-то наподобие 127.0.0.1:12345
Локальный прокси на то и прокси, чтоб физически находиться на локальном адресе, который прописывается в настройках, а для доступа использовать оригинальный адрес удаленного сервера, но никак не адрес локалхоста. Поведение, указанное в цитате, относится к локальному веб-серверу.
Заявленные минусы решения на основе прокси сервера 1 и 3 — глупость, вы, видимо, в принципе с технологией не разобрались.
В целом, согласен, что решение на базе локального веб-сервера адекватнее.
В целом, согласен, что решение на базе локального веб-сервера адекватнее.
Поздравляю, вы изобрели велосипед: https://habrahabr.ru/company/skbkontur/blog/131552/
P.S. насколько мне известно, СКБ Контур отказался от этой технологии несколько лет назад и перешел на плагины под каждый браузер
https://help.kontur.ru/plugin/
P.S. насколько мне известно, СКБ Контур отказался от этой технологии несколько лет назад и перешел на плагины под каждый браузер
https://help.kontur.ru/plugin/
Первый раз слышу про уязвимости NPAPI. Можно дать пруфов?
Вот, например: http://www.pcworld.com/article/2049309/chrome-will-block-npapi-plugins-over-stability-security-concerns.html
А вообще — поиск по словам «NPAPI vulnerabilinies»…
А вообще — поиск по словам «NPAPI vulnerabilinies»…
Ну во-первых, гугл — сраные рекламщики и лапшу вешают на уши профессионально. Во-вторых, прочитал статью, про уязвимости пруфов нет. Что и требовалось доказать. Прикрываются заботой о пользователях и их безопасности, чтобы проталкивать свой вендорлок.
Так что всё ещё жду от автора пруфов на конкретные уязвимости, упомянутые им.
Так что всё ещё жду от автора пруфов на конкретные уязвимости, упомянутые им.
Ну, если это, судя по всему, вопрос веры, то я — пас. :)
Мне кажется, будь у Вас действительно желание найти эту информация — давно бы уже нашли самостоятельно, как это сделал я по указанным выше ключевым словам. Ссылок выдаёт достаточно много, есть что почитать. Было бы желание…
Мне кажется, будь у Вас действительно желание найти эту информация — давно бы уже нашли самостоятельно, как это сделал я по указанным выше ключевым словам. Ссылок выдаёт достаточно много, есть что почитать. Было бы желание…
Кто предоставляет информацию, тот предоставляет и пруфы. Опять же, неужели так сложно поделиться ссылкой, если вы и в самом деле нашли информацию. Я прошёл по первым семи ссылкам выдачи гугла и кроме означенного пресс-релиза никакой информации не нашёл. А пресс-релиз от разработчиков хрома постулирует наличие уязвимостей, но не предоставляет ни одной для ознакомления.
.
Для локального веб сервера HTTPS нужен не только сертификат, но и еще и приватный ключ от этого сертификата.
Вы его открыто храните в системе и не паритесь?
Вы его открыто храните в системе и не паритесь?
Вы открыто храните бинарник браузера в системе и не паритесь? А ведь подменив браузер, можно добиться ещё большего, чем просто подменив сертификат.
Подмененный бинарник опасен только для этой системы. А украденный сертификат, позволяет атаковать удаленную систему.
1. Спуфим DNS и подменяем localhost.server.com с 127.0.0.1, на IP нашего сервера.
2. Приватный ключ к сертификату у нас уже есть, поднимаем свой сервер и может пытаться атаковать браузер клиента.
1. Спуфим DNS и подменяем localhost.server.com с 127.0.0.1, на IP нашего сервера.
2. Приватный ключ к сертификату у нас уже есть, поднимаем свой сервер и может пытаться атаковать браузер клиента.
Это локальный прокси. Применяется к своему компу. Чужой комп не будет иметь ваших корневых сертификатов в списке доверенных
1. Это не прокси, это веб сервер.
2. Корневой сертификат будет на любом компьютере на котором используется данное ПО. Т.е. если это банк клиент, то у всех клиентов банка.
Разработчики скромно умолчали, что надо будет делать клиентам которые используют данный ключ, чтобы добавить сертификат. И откуда возьмется сам веб сервер, как будет запускаться и т.д…
2. Корневой сертификат будет на любом компьютере на котором используется данное ПО. Т.е. если это банк клиент, то у всех клиентов банка.
Разработчики скромно умолчали, что надо будет делать клиентам которые используют данный ключ, чтобы добавить сертификат. И откуда возьмется сам веб сервер, как будет запускаться и т.д…
Если по уму делать, то корневой сертификат на каждом компе — свой (генерируется при установке).
Это костыли.
По уму, получается сертификат на server.com с правом подписи на поддомены. Генерируются ключ+сертификат на localhost.server.com и загружается на токен (лучше на каждый токен свой, но можно и один на все, тогда право подписи не нужно). Сам токен реализует вебвервер. Никаких левых сертификатов в truststore, ключ никак не извлечь из системы.
По уму, получается сертификат на server.com с правом подписи на поддомены. Генерируются ключ+сертификат на localhost.server.com и загружается на токен (лучше на каждый токен свой, но можно и один на все, тогда право подписи не нужно). Сам токен реализует вебвервер. Никаких левых сертификатов в truststore, ключ никак не извлечь из системы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть ли жизнь после отказа популярных браузеров от поддержки архитектуры NPAPI