«Субьективно, к примеру я пользуюсь исключительно поиском Google последние лет 15, и не припомню ситуации когда меня поиск не устраивал и мне приходилось пользоваться другими движками»
— Очень, очень впечатлен. Не уже ли вы за все 15 лет ни разу не столкнулись с ситуацией, что в поисковой выдаче нет нужной информации?
Я обычно, ищу в яндексе, если то, что нужно не нашел, пробую в гугле… иногда он дает лучше иногда хуже выдачу.
А причем тут конкретно iOS? Вы говорите, что «Плагины никто ради сайта ставить не будет». Я же отвечаю — говорите конкретно за себя, не надо делать обобщения. А для Ios можно при желании и приложение написать.
Да, оказывается и ru есть, но для меня разницы нет, помойка и то и то. Зато прям хорошо совпало, что на ru еще и проблема с https сертификатом, похоже либо просроченный бесплатный, либо самоподписанный.
«Бесплатные хостинги шлак безотносительно поддержки https, а на платных можно выбрать с поддержкой LetsEncrypt. „
— Для SSL в любом случае тарифы дороже чем без него.
.
:) И вот что бывает, когда юзаешь бесплатные сертификаты, только что попробовал зайти на rutracker
Итог:
Владелец rutracker.ru неправильно настроил свой веб-сайт. Чтобы защитить вашу информацию от кражи, Tor Browser не соединился с этим веб-сайтом.
Подробнее…
rutracker.ru uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
Error code: SEC_ERROR_UNKNOWN_ISSUER
Хотя через оперу по https://rutracker.ru соединяется, но пишет что соединение не защищено.
x-----x
«Тем самым вы признаёте, что плагин- сложный вариант для большинства.»
— Конечно, это сложнее чем обычная регистрация так как длиннее на 1 шаг, но для тех кто хочет большую безопасность — он совсем не сложный.
«И для них же делаете свой сайт не защищённым»
— Если пользователи не хотят, он будет для них не защищенный, если хотят — то могут потратить чуть больше времени на регистрацию.
Поймите, я просто рассматриваю вариант, как дать максимальную защититу пользователям, если им это требуется, без затрат на https. Если бы https был бесплатен (хостинг/сертификат) то и смысла заморачиваться бы не было.
Да, а чуть ниже я предложил вариант с js+плагином, который решает эти проблемы, т.к. без плагина юзер в ЛК не зайдет. Плагин знает сертификат сервера, поэтому на mitm — выдаст сообщение, что юзера перенаправили на фальшивый сайт. И все это — беспланто, без необходимости покупки сертификатов и хостинга https. Если юзер выберет вариант регистрации через плагин — то он будет всегда защищен не хуже чем по https. Единственное оставшееся слабое звено — это сама регистрация, но это тоже обходится, если логин и пароль юзер будет вводить, только после установки плагина.
«Не возможно, а точно так, как я сказал»
— Даже не знаю что на такое ответить :) Обычно так говорят люди, которое плохо подумали над тем что сказали… Ведь даже на вскидку за 10 секунд можно придумать рабочий вариант. Например, при регистрации предложить 2 варианта: обычная регистрация и регистрация с дополнительной защитой от кражи пароля, которая позволяет заходить в ЛК только через плагин. Установка плагина не такая уж сложная операция, в FF есть вариант даже для установки подписанного плагина-расширения прямо с web-страницы. Кто не хочет заморачиваться, выберет 1й вариант, кто захочет большей защиты — выберет второй. Все довольны.
«И да, если так сильно нужна защита, можно и купить, это в общем то не так дорого.»
— В том-то и дело, что для небольших форумов и торреннтов, не так уж сильно она и нужна, чтобы тратить на нее деньги. Тот же rutracker юзает http
Так фишка в том, чтобы не использовать https встроенный в браузер, требующий платных сертификатов либо пугающий юзеров страшными предупреждениями. А использовать свою реализацию на js, которая уже будет знать — что сертификат этого сайта надежный.
Но зачем деньги, когда есть бесплатные сертификаты?
— Тут ниже уже было по этому поводу написано: «Первая доза всегда бесплатно». Я склонен с этим мнением согласиться.
И на два порядка- простым людям, которых на подобном сайте просто не будет.
— Возможно и так, а возможно и нет. Тут надо более подробно продумывать детали…
При неправильных настройках — да и такое возможно.
Но, как я писал ранее — mitm подвержен и https, Злоумышленник может «вынудить» пользователя принять самоподписанный сертификат, если тот никак не может достучаться до своего любимого сайта без выполнения этого действия. Единственное отличие тут будет в том, что пользователь увидит предупреждение. А если будет использован валидный скомпрометированный сертификат, то разницы вообще не будет.
Тут весь вопрос в соотношении цена / требуемое качество защиты:
https — незаменим при денежных операциях, т.к. здесь защита должна быть максимально возможной.
https — для торрентов, форумов где требуется логин… было бы не плохо, но совсем не обязательно. Тут все зависит от доходности самого форума. Если есть деньги на поддержку https — замечательно. А если доходности нет, то создателю и смысла нет дополнительно увеличивать свои расходы. Есть вариант с установкой самодписного https, но это как раз из-за грозных предупреждений может отпугнуть аудиторию первый раз заходящую из поисковика.
https — для новостных сайтов и каталогов статей вообще не имеет смысла и даже вреден из-за увеличения трафика. Если юзер не хочет, что бы следили за тем куда он лазит, всегда можно использовать Tor.
Таким образом «бесплатный» http — должен применяться там, где нет серьезных опасностей от взлома. При этом, если использовать шифрованное соединение реализованное в js клиента, можно приподнять планку защищенности, оградив себя от риска перехвата паролей и секретных данных (без mitm)
Вывод — http нужен, и блокировать/дискредитировать его в браузерах ни при каких условиях нельзя.
P.S. На самом деле, метод реализации защиты на js клиента, достаточно интересен ввиду своей «бесплатности» и теоретической надежности сравнимой с https. Да, без помощи браузера при mitm хакер может подменить js, но как вариант, это можно исправить используя для подключения плагин, установленный в браузер через его «надежный» репозиторий. Плагин будет выполнять ф-ции проверки сертификата сервера. В таком случае, на секретные страницы сайта можно будет попасть, только используя этот плагин, о чем будет сообщаться при регистрации. Т.е. по сути мы полностью повторяем https, только с более широкими возможностями выбора алгоритмов шифрования, собственных форматов сертификатов и т.д… что на порядок усложнит жизнь злоумышленникам.
Полноценный mitm, требующий от хакера взлома провайдера этим методом не решается. Но защита от сниферов слушающих локальный трафик и собирающих пароли, хэши и «секретный» контент обеспечивается полностью. В отличии от стандартного и digest протоколов зашитых в браузер.
Да согласен, в таком виде это равносильно, просто заходу на фишинговый сайт где юзер отдает свои данные злоумышленнику в поддельной форме, а потом уже тот с помощью них может делать что хочет.
Если вы не знакомы с принципом асимметричного шифрования, то можете почитать подробнее об этом в инете.
В кратце выглядит так:
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот.
1. На сервере храним закрытый ключ.
2. К нам подключается клиент (js) — отправляем ему открытый ключ.
3. Клиент шифрует параметры авторизации введеные юзером этим открытым ключем и отправляет на сервер (кроме сервера их расшифровать никто не может).
4. Сервер проверяет параметры авторизации и если они принимаются — создает временный симметричный ключ сессии, который отправляет клиенту.
5. Клиент запоминает этот ключ и далее все секретные данные (запросы) при передаче на сервер шифрует им. На сервере все секретные данные для ответа клиента шифруются этим же временным ключем. В js клиента мы расшифровываем данные и выводим контент.
Злоумышленник посередине этого временного симметричного ключа не знает, поэтому подглядеть и изменить данные не может.
Все это на стороне клиента легко реализуется в js через обычные XMLHttpRequest, ну и ответная часть понятно должна быть на сервере.
Слишком большой по объёму вычислений для выполнения человеком — берем 10 человек и выполняем :)
Если построить большой автоматический театр, то его тоже 10 человек выкатить не смогут. Но что это доказывает?
Как я и писал выше, вы просто не понимаете смысловой сути понятия «программа» и «программист».
Я вас посвящу. Программист — это тот, кто создает программы для устройств, способных эти программы выполнять. Герон делал такие устройства и создавал для них программы — поэтому он программист. Не берусь говорить что он первый, но по крайней мере родился он почти на 2000 лет раньше А. Лавлейс.
Да, если он попадет на фишинговый сайт.
При этом организовать фишинговый сайт с https используя тот же Let’s Encrypt, задача не сверх сложная (хотя и сложнее чем просто подмена js), в этом случае юзер тоже не сможет ничего заметить.
Так использование https отсутствие MITM тоже не гарантирует, если пользователь примет самоподписанный или скомпрометированный сертификат человека по середине.
Я не против использования https — я против необоснованной дискриминации http.
А что касается js, то на клиенте вполне можно сделать поддержку любого протокола шифрования поверх http, и в обход протоколов зашитых в браузере.
У меня очень маленькая надежда на то, что здравый смысл возобладает и затея с «крещением всего инета в https» улетучится из голов боссов корпораций благодетелей…
Ведь, что происходит с точки зрения здравого смысла:
На основании того, что протокол HTTP не использует шифрование — подключение браузера к вашему сайту могут назвать «ненадежным» или «незащищенным» или даже блокировать.
Теоретически, за такое можно и в суд подать за клевету.
Ведь на сайте может использоваться альтернативная реализация шифрования секретных данных поверх HTTP, реализованная, например на клиенте через jscript (я такое делал в нескольких своих проектах).
Браузер ничего не знает о сайте, и методах защиты используемых на нем для передачи секретных данных между браузером и сервером, соответственно он не имеет права вводить пользователя в заблуждение устанавливая статус подключения «ненадежное/небезопасное» или даже «надежное». Ибо это может не соответствовать реальности.
Всё что входит в компетенцию браузера, и что он может делать уверенно — это пометить сайт как «использует HTTPS» или «не использует HTTPS» и исходя из своих предпочтений подкрасить в нужный цвет.
В любом случае, думаю, что неравнодушное сообщество начнет оказывать сопротивление навязыванию из вне каких либо правил. А самое лучшее воздействие на корпорации — это лишение их прибыли отказом от использования их продукции.
— Очень, очень впечатлен. Не уже ли вы за все 15 лет ни разу не столкнулись с ситуацией, что в поисковой выдаче нет нужной информации?
Я обычно, ищу в яндексе, если то, что нужно не нашел, пробую в гугле… иногда он дает лучше иногда хуже выдачу.
«Бесплатные хостинги шлак безотносительно поддержки https, а на платных можно выбрать с поддержкой LetsEncrypt. „
— Для SSL в любом случае тарифы дороже чем без него.
.
Итог:
Владелец rutracker.ru неправильно настроил свой веб-сайт. Чтобы защитить вашу информацию от кражи, Tor Browser не соединился с этим веб-сайтом.
Подробнее…
rutracker.ru uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
Error code: SEC_ERROR_UNKNOWN_ISSUER
Хотя через оперу по https://rutracker.ru соединяется, но пишет что соединение не защищено.
x-----x
«Тем самым вы признаёте, что плагин- сложный вариант для большинства.»
— Конечно, это сложнее чем обычная регистрация так как длиннее на 1 шаг, но для тех кто хочет большую безопасность — он совсем не сложный.
«И для них же делаете свой сайт не защищённым»
— Если пользователи не хотят, он будет для них не защищенный, если хотят — то могут потратить чуть больше времени на регистрацию.
Поймите, я просто рассматриваю вариант, как дать максимальную защититу пользователям, если им это требуется, без затрат на https. Если бы https был бесплатен (хостинг/сертификат) то и смысла заморачиваться бы не было.
— Даже не знаю что на такое ответить :) Обычно так говорят люди, которое плохо подумали над тем что сказали… Ведь даже на вскидку за 10 секунд можно придумать рабочий вариант. Например, при регистрации предложить 2 варианта: обычная регистрация и регистрация с дополнительной защитой от кражи пароля, которая позволяет заходить в ЛК только через плагин. Установка плагина не такая уж сложная операция, в FF есть вариант даже для установки подписанного плагина-расширения прямо с web-страницы. Кто не хочет заморачиваться, выберет 1й вариант, кто захочет большей защиты — выберет второй. Все довольны.
«И да, если так сильно нужна защита, можно и купить, это в общем то не так дорого.»
— В том-то и дело, что для небольших форумов и торреннтов, не так уж сильно она и нужна, чтобы тратить на нее деньги. Тот же rutracker юзает http
— Тут ниже уже было по этому поводу написано: «Первая доза всегда бесплатно». Я склонен с этим мнением согласиться.
И на два порядка- простым людям, которых на подобном сайте просто не будет.
— Возможно и так, а возможно и нет. Тут надо более подробно продумывать детали…
Но, как я писал ранее — mitm подвержен и https, Злоумышленник может «вынудить» пользователя принять самоподписанный сертификат, если тот никак не может достучаться до своего любимого сайта без выполнения этого действия. Единственное отличие тут будет в том, что пользователь увидит предупреждение. А если будет использован валидный скомпрометированный сертификат, то разницы вообще не будет.
Тут весь вопрос в соотношении цена / требуемое качество защиты:
https — незаменим при денежных операциях, т.к. здесь защита должна быть максимально возможной.
https — для торрентов, форумов где требуется логин… было бы не плохо, но совсем не обязательно. Тут все зависит от доходности самого форума. Если есть деньги на поддержку https — замечательно. А если доходности нет, то создателю и смысла нет дополнительно увеличивать свои расходы. Есть вариант с установкой самодписного https, но это как раз из-за грозных предупреждений может отпугнуть аудиторию первый раз заходящую из поисковика.
https — для новостных сайтов и каталогов статей вообще не имеет смысла и даже вреден из-за увеличения трафика. Если юзер не хочет, что бы следили за тем куда он лазит, всегда можно использовать Tor.
Таким образом «бесплатный» http — должен применяться там, где нет серьезных опасностей от взлома. При этом, если использовать шифрованное соединение реализованное в js клиента, можно приподнять планку защищенности, оградив себя от риска перехвата паролей и секретных данных (без mitm)
Вывод — http нужен, и блокировать/дискредитировать его в браузерах ни при каких условиях нельзя.
P.S. На самом деле, метод реализации защиты на js клиента, достаточно интересен ввиду своей «бесплатности» и теоретической надежности сравнимой с https. Да, без помощи браузера при mitm хакер может подменить js, но как вариант, это можно исправить используя для подключения плагин, установленный в браузер через его «надежный» репозиторий. Плагин будет выполнять ф-ции проверки сертификата сервера. В таком случае, на секретные страницы сайта можно будет попасть, только используя этот плагин, о чем будет сообщаться при регистрации. Т.е. по сути мы полностью повторяем https, только с более широкими возможностями выбора алгоритмов шифрования, собственных форматов сертификатов и т.д… что на порядок усложнит жизнь злоумышленникам.
Поэтому mitm действительно сработает.
В кратце выглядит так:
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот.
1. На сервере храним закрытый ключ.
2. К нам подключается клиент (js) — отправляем ему открытый ключ.
3. Клиент шифрует параметры авторизации введеные юзером этим открытым ключем и отправляет на сервер (кроме сервера их расшифровать никто не может).
4. Сервер проверяет параметры авторизации и если они принимаются — создает временный симметричный ключ сессии, который отправляет клиенту.
5. Клиент запоминает этот ключ и далее все секретные данные (запросы) при передаче на сервер шифрует им. На сервере все секретные данные для ответа клиента шифруются этим же временным ключем. В js клиента мы расшифровываем данные и выводим контент.
Злоумышленник посередине этого временного симметричного ключа не знает, поэтому подглядеть и изменить данные не может.
Все это на стороне клиента легко реализуется в js через обычные XMLHttpRequest, ну и ответная часть понятно должна быть на сервере.
Если построить большой автоматический театр, то его тоже 10 человек выкатить не смогут. Но что это доказывает?
Как я и писал выше, вы просто не понимаете смысловой сути понятия «программа» и «программист».
Я вас посвящу. Программист — это тот, кто создает программы для устройств, способных эти программы выполнять. Герон делал такие устройства и создавал для них программы — поэтому он программист. Не берусь говорить что он первый, но по крайней мере родился он почти на 2000 лет раньше А. Лавлейс.
При этом организовать фишинговый сайт с https используя тот же Let’s Encrypt, задача не сверх сложная (хотя и сложнее чем просто подмена js), в этом случае юзер тоже не сможет ничего заметить.
Я не против использования https — я против необоснованной дискриминации http.
А что касается js, то на клиенте вполне можно сделать поддержку любого протокола шифрования поверх http, и в обход протоколов зашитых в браузере.
Ведь, что происходит с точки зрения здравого смысла:
На основании того, что протокол HTTP не использует шифрование — подключение браузера к вашему сайту могут назвать «ненадежным» или «незащищенным» или даже блокировать.
Теоретически, за такое можно и в суд подать за клевету.
Ведь на сайте может использоваться альтернативная реализация шифрования секретных данных поверх HTTP, реализованная, например на клиенте через jscript (я такое делал в нескольких своих проектах).
Браузер ничего не знает о сайте, и методах защиты используемых на нем для передачи секретных данных между браузером и сервером, соответственно он не имеет права вводить пользователя в заблуждение устанавливая статус подключения «ненадежное/небезопасное» или даже «надежное». Ибо это может не соответствовать реальности.
Всё что входит в компетенцию браузера, и что он может делать уверенно — это пометить сайт как «использует HTTPS» или «не использует HTTPS» и исходя из своих предпочтений подкрасить в нужный цвет.
В любом случае, думаю, что неравнодушное сообщество начнет оказывать сопротивление навязыванию из вне каких либо правил. А самое лучшее воздействие на корпорации — это лишение их прибыли отказом от использования их продукции.