Comments 525
Just use LetsEncrypt ffs
https://letsencrypt.org/getting-started/
И у HTTPS через LetsEncrypt есть фатальный недостаток — превратится в тыкву вместе с LetsEncrypt. Нужно децентрализованное решение. Все эти списки доверенных сертификатов, загружающихся в ОС или браузер — порочны. Особенно, в случае хромоподобных, берущих списки из хранилища ОС, в которое новые сертификаты можно добавить только через пляски с бубном.
Как-то я открыл список доверенных корневых центров сертификации, почитал немножко, пошевелил волосами на голове, закрыл.
К примеру поставить перед старым сервером, раздающим HTTP, некий прокси, который сам будет чего-то добавлять (хеши, цифровую подпись и т.п.) в контент (заголовки, куки) анализируя которые некое браузерное расширение (которому все доверяют) выдавало бы предупреждение если контент был изменен.
Ну или какое-то подобное решение, которое позволит не особо напрягаясь и не влезая в дебри настроек этого старого сервера хоть как-то защитить от подмены HTTP контент, который он раздает, без использования услуг третьих лиц (центров сертификации и т.п.).
Множество HTTP-сайтов, которые имеют низкую посещаемость, несут ценные идеи и заслуживают сохранения.
P.S. Если честно я сильно-сильно сомневаются что «ценные идеи» на таких сайтах существуют в единственном экземпляре. Все ценное давно уже растащено по сотням других сайтов (с https в том числе)
Но даже если откажет LE и в CF никто не переедет, значит произойдёт массовый откат к HTTP и как следствие — массовый отказ от Google Chrome как от браузера, поддерживающего только и исключительно HTTPS. Гугл в этом случае спешно выпустит обновление, возвращающее HTTP к жизни, либо сделает новый Let's Encrypt.
В любом случае, оба варианта развития ситуации мне не кажутся хоть сколько-нибудь реальными. Ваш вопрос можно перефразировать как «Давайте представим, что DNS сервера перестанут резолвить домены. У вас есть бесплатные альтернативы?»
LE позиционируется как важная часть интернет инфраструктуры, поэтому и усилия по его поддержке будут соответствующие. Он не умрёт вот так вот запросто.
Но тотальный и обязательный переход на https по указке Google мне не нравится.
PS Нужно дочитывать ветку перед тем, как отвечать
Юзайте яндекс-браузер тогда
— Кстати, яндекс-браузер — этот тот-же chromium (речь — о ядре).
Это как ОСАГО (ужас какой) — в самой идее нет ничего плохого. Но в отличие от ОСАГО внедрение HTTPS не стоит 20к в год, не нужно стоять в очередях и все такое.
Автоматически вычленять контактные телефоны и, используя встроенную SIP-звонилку и акаунт какого-нибудь SIP-повайдера, просто по несколько раз в час делать в фоновом режиме дозвон и тут же сбрасывать, а каждый двадцатый звонок, например, не сбрасывать, а зачитывать сообщение «Ваша фирма получает эти звонки, так как Вы купили рекламу, вторгающуюся в трафик пользователей интернета, мешающую нормальному отображению сайтов и нарушающую принципы сетевого нейтралитета. Отмените заказ своей рекламы либо обратитесь к провайдеру, чтобы он прекратил модифицировать трафик». Понятно, что это требует аккуратной многогранной настройки, чтобы не страдали невиновные, и придётся периодически регить новый SIP-акаунт, т.к. старый, думаю, будут вскоре банить. Но рекламодатели включат голову, и эта гадость со вмешательством в трафик закончится.
А пытаться такое сделать самостоятельно — думаю с высокой вероятностью огрести проблем, т.к. наверняка тут можно подвести какую-то статью за неправомерное использование средств связи (вам никто не давал права забивать чужой канал своими звонками).
Единственный минус — пользователю, чтобы наказать рекламодателей за такие действия, придётся периодически регить новые акаунты и, возможно, кидать на их счёт какие-то деньги, что далеко не каждый согласится делать.
Для проверки целостности нужно не шифрование, а проверочные суммы и подписи к ним.
Если при обнаружении подмены, страница не откроется, то вмешательство станет бесполезным. Шифрование выполняет другую задачу – сокрытие данных.
При отдаче статики (картинки, скрипты, стили, да просто заглавная страница без логина) — подпись может формироваться один раз для всех получателей.
На стороне сервера, вы вроде правы. Но только для статики. Которой сейчас не очень много. А динамику ваше предложение просто убьёт. Например, как подписать прямую трансляцию? Да и клиент всё равно должен проверять подпись. А если для заргузки странички необходимо сделать X запросов, то и проверок нужно X (в вашем сценарии, где каждый статический ресурс подписан отдельно). А еще это значит, что и показать ресурс нельзя по мере загрузки, даже статический — ведь подписываются не чанки :)
Во-вторых, я не говорю про то, что всё надо делать через подписи. Я даже не говорю, что подписи должны быть основным механизмом защиты целостности. Я говорю, что шифрование на транспортном уровне не должна быть единственным механизмом контроля целостности.
В-третьих. Только в этом посте 1.5Мб картинок с hsto.org (которые явно статичные) и столько же js (из которых вряд ли много динамически генерируемых).
Это всё контент, который можно было бы один раз подписать, а не шифровать для каждого запроса.(я попытался отбросить рекламу, но да)
В-четвёртых для прямой трансляции, которую смотрит несколько человек можно разработать контейнер с подписываемыми чанками. И при этом задействовать мультикаст, сэкономив не только на подписании, но и на доставке.
Вы считаете случаи нереалистичными? Вы считаете, что они не значимы статистически?
Или вам на самом деле неинтересно зачем это нужно?
Я считаю эти случаи реалистичными и статистически значимыми, но не подтверждающими вашу точку зрения. Я не считаю хорошей идеей реализацию подписей на уровень приложения для обеспечения работы HTTP. Я не ситаю хорошей идеей, проверку подписей на стороне клиента, вместо тупого симметричного дешифрования. Но не вижу потребности, кого-то убеждать в этом.
В конце-концов вы же моете руки перед едой, хотя это защищает только лишь от холеры, но не от СПИДа.
Речь о том, что гугл выдаёт относительную безопасность на сетевом уровне за безопасность как таковую.Согласен. Но это делает не только Google, но и Mozilla и MS IE…
Это не так.И, соответственно, с этой проблемой Google и борется. Вместо того, чтобы писать на https-сайтах «безопасно», а на http-сайтах ничего не писать (как это делается сейчас), в новой версии будет делаться наоборот — на http-сайтах будет писаться «небезопасно», а на https-сайтах не будет писаться ничего… Это, несомненно, более точное описание ситуации… но именно против этого действия протестует автор статьи…
гугл выдаёт относительную безопасность на сетевом уровне за безопасность как таковую
Очень жаль если Гугл так делает. Однако замечу, что надпись «Not Secure» у http-сайта не является «выдаванием относительной безопасности» за что-бы то ни было. Это предупреждение о небезопасном соединении.
А чтобы заставить его замолчать надо сделать действия, которые не защитят от других видов угроз, создав ложное чувство защищённости.
Это предупреждение об угрозе, появляющееся вне зависимости от того есть угроза или нет.
Это предупреждение о незащищённом соединении, появляющееся при наличии незащищённого соединения. Это мальчик, который кричит «Нет ружья для защиты от волков».
И кричит не про то, что дома нет ружья, а что с собой не взял…
У мальчика нет собственного ружья. Ружьё выдаёт веб-сайт. Если веб-сайт не выдал ружьё — мальчик предупредит об этом пастухов, дабы те знали что ружья нет и надо быть осмотрительней.
Вот проблема в том, что это мальчик, который кричит «Нет ружья для защиты от волков» даже при походе через двор в туалет.
В данной модели угроз единственное место, в котором не может быть волков — это
единственное место, в котором не может быть волков — этолокалхостдом.
Локальная проводная сеть; сеть предприятия, к которой установлено VPN подключение; данные, валидность которых проверяется хэшем из HTTPS-страницы… не говоря о том, что требуется совершенно разный уровень безопасности для передаваемых персональных данных (включая данные кредитки) и для получения картинок. А предупреждение одинаковое и при открытии видео с домашнего сервера и при вводе пароля к он-лайн банку.
Может быть вы живёте в глухой Сибири, где поход через двор в сортир требует ружья, но бога ради, можно не ПГУАААААТЬ меня этими волками в субурбии…
В итоге люди либо начинают таскать с собой ружьё всегда, превращаясь в параноиков. Даже когда оно мешает — лишь бы заткнуть назойливое предупреждение.(ходить на сайт производителя роутера для того, чтобы управлять роутером «безопаснее» чем на сам роутер)
Либо начинают предупреждение игнорировать. Даже когда это уже банк.
Не каждое соединение требует безопасности TLS. И напоминать об отсутствии TLS при каждом соединении — неправильно.
Если бы нынешняя ситуация рассматривалась, как временное решение до того, как будут введены механизмы позволяющие отличить безопасные подсети и безопасные данные от требующих внедрения дополнительной безопасности — я бы не возражал ни секунды. Но сейчас речь идёт о том, что HTTP должен вообще со временем умирать в пользу HTTPS.
Как будто пустить «умную» лампочку на сайт производителя и подключиться к этому сайту по HTTPS безопаснее, чем вообще запретить лампочке доступ в интернет и подключаться к ней по HTTP.
Когда я прикидывался обычным пользователем, все было нормально.
Let's Encrypt не является панацеей, а лишь костылем, который нужные компании в нужны момент легко выпилят
Если вам нужен wildcard сертификат, то конечно будет дороже, но далеко не 6-10к в год.
Либо, если совсем плохо с деньгами, подключите Cloudflare — это бесплатно. Разве что в IE6 не будет у вас сайт работать из-за SNI, но мы вроде уже вышли из пещер.
В среднем у всех центров обычная валидация домена ~5к, wildcard ~20-30к.
Но если вам, как мне нужен самый простой сертификат (но не Let's Encrypt), то какой-нибудь COMODO POSITIVE самое то.
Не сочтите за рекламу.
Покупал здесь: firstssl.ru/ssl
И здесь: ruweb.net/ssl
Полет нормальный уже не один год.
И там и там Wildcard 6-7к в год, обычный DV 500-700 руб.
UPD: В предыдущем комментарии ошибся со стоимостью Wildcard. Но обычным бложикам он и не нужен.
Реселлят comodo.
Они всего то лишь будут помечать красным, когда ваш сайт будет открываться через ИХ браузер и понижать в выдаче ИХ поискового сервиса. Разве они не имеют права определять поведение своего собственного продукта?
Право выбора у вас никто не забирает. Вы можете выбирать хотите ли вы, чтобы ваш сайт открывался в хроме или нет. Хром не ваш, — вы не можете забрать у гугла право выбора, что им делать с их браузером.
Я хочу чтобы мне оставляли право выбора что МНЕ делать с МОИМ вебсайтом на МОЕМ хостинге.Вы по прежнему имеете делать что угодно со своим веб-сайтом. И люди, использующие не Chrome, а, скажем, Lynx, по прежнему смогут туда заходить…
Ну, там проверить все ли запросы приходят куда надо и с нужными параметрами, найти повторяющийся шаблон в ддос-запросах и настроить блеклистинг (mitmproxy тут не поможет, увы), проблемы у клиента, незнакомого с отладочными панелями в браузере, всякое…
Я через ngrep могу быстро собрать стат по тысячам запросов и выявить аномалии, запустив shell-однострочник, составленный за минуту. Лишние движения по расшифровке трафика (а серверов может быть гораздо больше одного) заберут время и ресурсы сервера (а, следовательно, на хайлоаде и не всегда возможны), или приведут к тому, что что-то будет упущено.
В любом случае, с HTTP анализ трафика гораздо, гораздо проще чем с HTTPS.
Вот например, случай из рабочего чата произошедший несколько дней назад. Для тестовой версии сайта создается поддомен без https, ссылка отправляется заказчику:
Угадаете в чем дело? И это не какой-то выдуманный теоретический случай, а реальная жизнь. В реальной жизни все подряд суют свое говно в HTTP сайты и единственный способ доставить клиенту контент в неизменном виде это HTTPS.
Проблема в том, что HTTPS не единственный способ, но Гугл навязывает его и выдает за панацею, не смотря на то, что у HTTPS есть свои слабые стороны (например возможность цензуры).
И это не какой-то выдуманный теоретический случай, а реальная жизнь.
Назвали бы провайдера-то.
Вы можете его подсунуть в wireshark и так же удобно расшифровывать трафик.
Нет! Это было возможно до повсеместного введения обмена ключами на основе протокола Диффи-Хеллмана. Сейчас же, если вы не делаете активный MITM прямо в момент соединения, расшифровать пассивно записанную сессию при наличии ключей не получится.
зато несколько уменьшает вероятность инъекций, например.
Для интернет-магазина, скажем, смысл есть.
А для хомяка с пачкой страниц — ну смысл? Ноль.
Скрипт, майнящий биткоины. Meltdown/Spectre. Rowhammer. Да кучу всего можно придумать
Откуда он возьмется на хостинге типа chat.ru — я еще могу понять.
А если это это shared-хостинг? Подмена провайдером контента?
Но что мешает провайдеру подменять контент на уровне еще веб-сервера, еще на уровне генерации страницы? Ровным счетом ничего и я не понимаю, чем тут может помочь сертификат или https.
откуда он возьмется на хомяке
MitM же
что мешает провайдеру подменять контент на уровне еще веб-сервера
Контролировать провайдера, контролирующего веб-сервер, намного проще, чем MitM. В случае обнаружения проблем можно просто к другому не столь обнаглевшему провайдеру переехать, например
Понимаете, практическое руководство о том, как это сделать + объяснения, какие инструменты и механизмы этому препятствуют.
2. Открываешь не запароленую вайфай точку с именем типа McDonalds wifi(или что там сейчас похожее)
3. Ждешь пользователей и делаешь с их http трафиком что хочешь :)
С https не прокатит.
Мне кажется стоит это вставить в статью, т.к. Как автор не в курсе как это работает, как и многие читатели.
При этом для этого мне не потребовались какие-либо знания в этой области. Скачал сниффер, две кнопки тыкнул и все…
Я не «хакер» и даже в сети не разбираюсь
В универе так же я проверял работу сниффера и словил несколько сеансов OK и ВК. Зашёл через один сеанс на «Моя страница» и всё. Чужие данные я не стал изучать, ибо мне это не нужно было.
Я просто убедился в том, что открытые сети и соединение по http — не безопасно!
Я просто убедился в том, что открытые сети и соединение по http — не безопасно!
это понятно, но, как видите в этом топике собралась и оппозиция =)
А если по теме, заходить в чужии сеансы конечно же можно и это решается с помощью https, но, это еще не финиш, т.к. пара логин-пароль все равно не похищена. Да, вы сможете таким образом например угнать акк, но полное фиаско если вы сможете завладеть текущей парой логин-пароль. Тогда, например, вы сможете попробовать их на другом ресурсе, а как известно, пользователи частенько применяют одни и те же креденшиалы на нескольких ресурсах
а магазины даже вкуснее макдака
Можно (было!) украсть куку, и зайти с этой кукой во вконтактик.
Но если в архиве с котиками нет авторизации, то и логиниться некуда.
Смотрите изначальный посыл:
Для интернет-магазина, скажем, смысл есть.
А для хомяка с пачкой страниц — ну смысл?
Вот заходит наш пользователь-жертва на сайт с картой Воронежского Метрополитена, который без https. Просто карта, просто картинка и абзац текста.
Вот рядом сидит C00L}{ATZKEP и сниффит его траффик. И вот насниффил кулхацкер траффик к нашей жертве с сайта Воронежского метрополитена. И что он с ним дальше будет делать?
провайдет забирает «что-то» от веб сервера
Не вижу никаких сложностей в изменении генерации кода на уровне веб-сервера. Еще до https-wrapper'а
Не вижу никаких сложностей в изменении генерации кода на уровне веб-сервера. Еще до https-wrapper'а
А я вижу =) для этого нужно довольно глубоко вмешиваться во внутренние механизмы конкретного веб-сервера и\или view генератора, если таковой имеется. А это все попахивает как минимум нетривиальным реверс-инженерингом, если не брать вариант с override-ом конфигов сервера (но это уже читерство если хостер подменяет ваши же конфиги)
какая-либо вечгая литература(корн корн, анатомический атлас, конституция древнего года и почее куда ходит дофига молодежи)
подшивки мукулатуры, банальные архивы школ.
да куча интересных мест куда часто заглядывют
Используя HTTP, хостер по-сути помогает злоумышленникам / рекламщикам / провайдерам отслеживать интересы пользователя и в некоторых случаях напрямую получать информацию о пользователе.
Если сайт, работающий на HTTP, не запрашивает ввод какой-либо информации напрямую, это еще не значит, что пользователь имеет ту же степень сохранности данных, что и на HTTPS
Какой-нибудь сферический билайн может подменить любой текст «ничего не запрашивающего блога», и хорошо, если это будет баннер, который просто сломает вёрстку. А если это заведомо ложная информация?
Это блог. Я не запрашиваю никакие данные у пользователей.
Пометка «ненадёжный» от Google обозначает:
Это блин означает, что буквально «информация, которую вы читаете на этом блоге, могла быть изменена провайдером, администратором, датацентом, хостером, соседом. Если Вы, следуя этой информации, принимаете критически важное решение, то мы должны предупредить — возможно, информацию предоставил не автор сайта». А это, извините, и есть «ненадёжный». И неважно, блог это или нет, запрашивает он что-то или нет.
В конце концов, пароль от админки «блога» мог перехватить любой в той же локалке и просто войти в систему через месяц. И сделав «ненадёжной» каждую букву в информации этого «блога».
Интернет бы не стал таким, какой есть, без HTTPS. Не было бы оплат, доверия, надежности. Был бы один бесконечный двач.
Не, пусть лучше гугл показывает мне релевантную рекламу, чем вот такое.
Какой-нибудь сферический билайн может подменить любой текст «ничего не запрашивающего блога», и хорошо, если это будет баннер, который просто сломает вёрстку. А если это заведомо ложная информация?
Мб за это стоит бить по рукам "сферического билайна", а не пытаться решить проблему лишней финансовой нагрузкой на простые сайты?
Сколько людей сидит на всяких шаредах с конструкторами и делают или делали шикарный контент? Я любитель старых игр и ОЧЕНЬ много всего нахожу на мелких сайтах, которые стоят на неизвестных хостингах и сверстаны чуть-ли не в ворде. Им как вставить сертификат?
На нормальных шаредах уже давно завезли HTTPS. Как раз сегодня днём обновлял два Let's Encrypt сертификата на шаредах SpaceWeb. Да, немножко неудобно, потому что простой «sudo certbot renew» на шареде не написать, но всё ж переход на HTTPS стоил ноль рублей ноль копеек
Им как вставить сертификат?Старые сайты это проблема, да. Но уж новые можно было потрудиться перевезти на нормальные шареды и без всяких HTTPS
«Ещё раз напишу: в моёй Windows 95 меня ВСЕ устраивает. Меня не устраивает политика Mozilla, которая перестала выпускать обновления Firefox для Windows 95. Было и работало же.»
Примерно так выглядит ваш комментарий.
Пару предупредительных в виде штрафа
… злоумышленнику-анониму, сидящему за соседним столиком в макдональдсе и раздающему поддельный вайфай? Ну-ну, попробуйте.
А про операторов — вот когда в законах всех стран, подключенных к интернету, будут прописаны такие штрафы, тогда и поговорим. А сейчас без HTTPS высовываться нельзя даже не находясь в макдональдсе.
«Ещё раз напишу: в моёй Windows 95 меня ВСЕ устраивает. Меня не устраивает политика Mozilla, которая перестала выпускать обновления Firefox для Windows 95. Было и работало же.»Нет, просто вы не понимаете смысла комментария да и всей статьи в целом, вот и всё.
Примерно так выглядит ваш комментарий.
А смысл такой — для сайта на HTTP вместо лживого ярлыка «Небезопасный» нужно писать правду «Не использующий HTTPS», и бороться не с HTTP блокируя такие сайты, а бороться с теми кто нарушает закон. В данном случае google со своим 'Not secure' — откровенно врет пользователям. Если хотят быть честными, пусть тогда в инсталяторе своего хрома тоже пишут 'Not secure'.
P.S.: HTTP нисколько не устарел, никто в здравом уме его из браузеров выпиливать не собирается, он вполне себе работает и поверх SSL и т.п. протоколов.
Полностью согласен.
Есть и обратная проблема: для фишинговых сайтов, получивших HTTPS, хром пишет, что они безопасные.
Но это никак не отменяет того, что daggert'у нужно менять шаред на более современный, а не продолжать сидеть на условном Windows 95.
а бороться с теми кто нарушает закон
Зачем бороться с нарушениями, когда можно устранить саму техническую возможность нарушения?
за 0 рублей в месяц
я думаю в этой ситуации глупо что-то требовать, кроме того, что уже есть. Можно лишь скромно попросить, абсолютно не рассчитывая на результат. Человеку дали на халяву хостинг, он им пользуется.
У меня тоже было и не раз такое, что мне давали ресурсы на халяву, но они были «as is». Да-да, в том числе сертификат от чужого домена со временем появился (что даже хуже, чем его отсутствие, потому что вместо not secure все мои пользователи видят заглушку в хроме и неочевидные действия надо предпринять, чтобы пройти на сайт. Зато стало «типо безопаснее»).
В данном случае google со своим 'Not secure' — откровенно врет пользователям.
Нет. HTTP — HyperText Transfer Protocol. HTTPS — HyperText Transfer Protocol Secure. Соответственно, HTTP — HTTPS без S, Secure, или Not Secure HTTPS.
Если хотят быть честными, пусть тогда в инсталяторе своего хрома тоже пишут 'Not secure'.
Инсталлятор Хрома подписан. Он вполне себе «Secure»
Нет. HTTP — HyperText Transfer Protocol. HTTPS — HyperText Transfer Protocol Secure. Соответственно, HTTP — HTTPS без S, Secure, или Not Secure HTTPSУ вас такая же порочная логика как и у гугла.
Вы действительно думаете, что фраза «Secure / Not secure» имеет такой же смысл как «Использует HTTPS / Не использует HTTPS»?
Фраза «Безопасный / Не безопасный» по отношению к сайту — вводит пользователей в опасное заблуждение и является откровенной ложью, которую гугл использует в своих целях.
Если хотят быть честными, пусть тогда в инсталяторе своего хрома тоже пишут 'Not secure'.Вы никогда не слышали про «множественные уязвимости в хроме»? Если программа имеет цифровую подпись — это не говорит о том, что ей можно безопасно пользоваться.
Инсталлятор Хрома подписан. Он вполне себе «Secure»
С точки зрения гугла:
Использовать протокол HTTP — не безопасно, так как из-за его уязвимостей имеется теоретическая/практическая возможность для третьего лица перехватить/изменить данные.
С точки зрения пользователя хрома:
Использовать хром — не безопасно, так как из-за уязвимостей в его коде имеется теоретическая/практическая возможность для третьего лица перехватить/изменить данные.
Но гугл использует двойные стандарты, вешает ярлык для HTTP — не безопасен, а для своего хрома «почему-то» не вешает. Последнее время всё больше разочаровываюсь в «корпорации добра».
А сейчас без HTTPS высовываться нельзя даже не находясь в макдональдсе
Если Вы такой специалист в плане ИБ, как пытаетесь показать в других ветках, то какого черта Вы сидите в общественных местах задницей наружу с голым HTTPS? Если Вас так заботит Ваша приватность, как минимум нужен tor+obfs, или на худой конец ,VPN (неважно, поднятый вручную где-то там, или доверенный провайдер).
Тут скорее уместна аналогия с дверьми — не смотря на то, что общество борется со злоумышленниками, вход в своё жилище вы всё равно защищаете. Пока не придумали системного способа борьбы со злом, который бы устранил проблему навсегда (и вряд ли придумают), будет иметь смысл защищаться.
Даже в условиях, когда злоумышенников нет, HTTPS может помочь. Если кто-то неправильно (без всякого злого умысла) настроит прокси-сервер, сетевую маршрутизацию или DNS, что приведёт к обработке трафика не на том узле, использование HTTPS в большинстве случаев поможет сразу же обнаружить проблему — браузер покажет ошибку, и пользователи пожалуются.
Дополнительно приписываю в HTML комментарии после закрывающего тега html цифровую подпись ко всему предыдущему. Чтобы кто попало по дороге не думал, что сможет произвольно и незаметно подправить контент.
Когда 100500сайтов фактически обяжут сидеть на HTTPS, то это либо single point of failure в лице того же LetsEncrypt (сдохнет доступ к его CA — что будем делать?), либо купленный у кого-то сертификат.
Так что нет, пока что не убедили, что HTTPS — единственный путь к безопасности.
шифрую тем же открытым ключом
А откуда вы открытый ключ возьмёте?
цифровую подпись ко всему предыдущему
А как именно получатель проверит цифровую подпись?
Можно использовать OpenPGP
Можно-то можно, но на вопрос вы не ответили — откуда открытый ключ для OpenPGP возьмёте? Email это тоже касается, да.
Вручную или с помощью расширения к браузеру. Например, вот это
И откуда в нём появятся открытые ключи, необходимые для проверки?
Техническая реализация проверки — расширение для браузера.
в тех же HTTP заголовках
… которые подменены человеком посередине на открытые ключи злоумышленника. Как мне доверять открытым ключам, переданным в HTTP заголовках?
… которые подменены человеком посередине на открытые ключи злоумышленника. Как мне доверять открытым ключам, переданным в HTTP заголовках?Прочитать про дифи и хеллмана, обогатив себя знаниями как передавать открыто информацию и не боятся подмены.
И да, переформулирую по-другому: если бы вы заглянули в в википедию, то узнали бы, что протокол Диффи-Хеллмана используется для получения общего секретного ключа. Чтобы получить общий секретный ключ, нужно заранее знать открытые ключи. Вот я и спрашиваю — откуда взять открытые ключи и как им доверять?
В той же википедии написано, что «чистый» протокол Диффи-Хеллмана уязвим к MitM-атакам.
Я прекрасно знаю и про Диффи, и про Хеллмана. Вот я обменялся ключами по протоколу Диффи-Хеллмана, без подмен — но как мне понять, что я обменялся с настоящим получателем, а не со злоумышленником? Как Диффи и Хеллман помогут отличить получателя от злоумышленника, если «некоторые два числа g и p» (цитата из википедии) заранее неизвестны?Это прекрасно.
Одним абзацем показать, что протокол ДХ не понят от слова совсем.
В той же википедии написано, что «чистый» протокол Диффи-Хеллмана уязвим к MitM-атакам.Ваши заявления подразумевают уровень знаний в ИБ заметно больше чем википедия.
Я исхожу из реальности, где лучшее что могло случится это ДХ и даже является головной болью многих спец.служб.
Итого мы имеем теоретическую митм уязвимость и тлс и дх.
Разница лишь в том, что у ДХ это единственная проблема безопасности. А вот у тлс есть еще несколько проблем. При чём гарантированное теоретическое решение митм проблемы обещает только квантовая передача данных. Которой нет в серии и пока не предвидится, да я прозрачно намекаю, что гарантированного решения митм ещё нет, ни для одного протокола, есть только
Потому считаю отсылку на митм либо недостатком знаний в данном направлении, либо намеренным уходом от конструктива.
Я допускаю, что я мог чего-нибудь не понять — ну так расскажите, что именно я не понял и как ДХ обеспечивает безопасность при заранее неизвестных открытых ключах? Вы тоже не уходи́те от конструктива.
гарантированного решения митм ещё нет
Это прекрасно. Ещё один комментарий назад вы говорили, что ДХ позволяет не бояться подмены.
А вот у тлс есть еще несколько проблем.
Например? Не считая человеческий фактор — он будет всегда и везде.
Потому считаю отсылку на митм либо недостатком знаний в данном направлении, либо намеренным уходом от конструктива.
Основное назначение тлс и ДХ — это как раз защита от mitm. По отдельности они уязвимы, а вместе — то, на чём держится вся безопасность веба.
Напомню, с чего началась ветка: Temmokan предлагает не использовать HTTPS, то есть оказаться от тлс. Остаётся ДХ. И как же тогда решать эту «единственную проблему безопасности» ДХ? Расскажите, я действительно мог чего-нибудь не понять.
Я допускаю, что я мог чего-нибудь не понять — ну так расскажите, что именно я не понял и как ДХ обеспечивает безопасность при заранее неизвестных открытых ключах? Вы тоже не уходи́те от конструктива.Что именно рассказать?
Это прекрасно. Ещё один комментарий назад вы говорили, что ДХ позволяет не бояться подмены.Прошу процитировать когда и где это было обозначено.
Напомню, с чего началась ветка: Temmokan предлагает не использовать HTTPSПоиск показал только 3 совпадения по слову Temmokan. Причем два сообщение, и одно в вашем сообщении(после моего поста будет 4).
Я не вижу где он предлагает «не использовать HTTPS», вижу только предложенную им альтернативу. Которую он считает более легкой и более применимой в многих случаях получения информации. Далее вижу ваше возражение о невозможности безопасно передать ключи, и моё замечание о том, что такая возможность есть(это протокол ДХ).
Предполагая, что вы не знаете про ДХ о нём и рассказано выше.
Что именно рассказать?
Входные данные для алгоритма, например. И откуда они возьмутся. И почему этим входным данным можно доверять.
Прошу процитировать когда и где это было обозначено.
«Прочитать про дифи и хеллмана, обогатив себя знаниями как передавать открыто информацию и не боятся подмены.» Не бояться подмены — значит быть защищённым от mitm. Или упомянутые здесь слова внезапно приобрели новый смысл?
Третья сторона.
Как я уже не один десяток раз повторил ниже — можно работать с TLS и без третьей стороны, было бы желание. Доверять центрам сертификации никто не заставляет, как минимум в Firefox их можно отключить, сегодня проверял.
вижу только предложенную им альтернативу
Какую? Он пишет про «шифрую тем же открытым ключом», а откуда он возьмёт этот открытый ключ, которому можно доверять, он не упоминает (заголовкам HTTP доверять изначально нельзя). Чем он создаст цифровую подпись, он тоже не упоминает. Где он предложил альтернативу — непонятно.
моё замечание о том, что такая возможность есть(это протокол ДХ).
Опять же, я не исключаю, что я чего-то не понимаю в ДХ, но я не вижу, как результату ДХ можно доверять, когда нет изначально доверенных открытых ключей или что-то типа того. Пожалуйста, расскажите, как с помощью ДХ и без TLS (мы же здесь обсуждаем альтернативу TLS?) можно получить открытые ключи, которым можно доверять, когда изначально собеседники не знают друг о друге вообще ничего (кроме установленного TCP-соединения, например).
А вот как будет обеспечиваться безопасность ДХ без заранее известного доверенного ключа — я так и не понимаюВы либо невнимательно читали мой 2й ответ. Либо не уловили, что подошли к т.н. проблеме курицы и яйца.
Но я теперь понимаю, что не понятно. Как и было сказано проблема митм является больше теоретической. Потому как:
Скачивая браузер, в котором и зашиты сертификаты, которым вы считаете, что можете доверять, ничего не помешает мэну из мидла подменить и сертификаты или добавить свой. (хотя на самом деле он просто будет от давать сразу пропаченый инсталлер). На возражения типа я же могу проверить хеш с сайта, придётся сначала убедить себя в том, что вам не подменили хеш для сверки.
А текущий браузер которым смотрите хеш тоже откуда-то взялся и тоже мог быть подменен… уходим в долгую рекурсию (а кто-то в параною).
Итого даже если вы старательно доверяете гуглу, но именно они и лично вам не присылали CD или DVD с доверенным браузером(самые доступные носители защищенные от перезаписи), то заранее известный ключ можно подвергать сомнению.
Насколько я знаю, гарантированной защиты от этого неприятного мэна ещё нет. Покрайней мере для массового применения гражданскими лицами.
подошли к т.н. проблеме курицы и яйца
Я с этой проблемы и начал всю эту ветку, спросив «А откуда вы открытый ключ возьмёте» без HTTPS — странно, что вы это только сейчас осознали.
уходим в долгую рекурсию
Именно. Разорвать рекурсию можно обменом ключей при личной встрече с собеседником убедившись, что это на самом деле он, а не клон-агент спецслужб. Но так как встречаться с условным админом условного гугла — идея так себе, то придётся снижать безопасность, доверяя кому-то ещё. Например, общим с админом гугла друзьям (сеть доверия в PGP), или кому-то, кто берёт на себя ответственность быть честным (центры сертификации в TLS). Так что как минимум от той части HTTPS, которая возится с ключами, мы особо никуда не уехали.
Temmokan ругает Let's Encrypt, так что, похоже, доверие по TLS его не устраивает, а альтернатив от него я всё же не увидел. Сеть доверия в PGP развивать разве что
Я с этой проблемы и начал всю эту ветку, спросив «А откуда вы открытый ключ возьмёте» без HTTPS — странно, что вы это только сейчас осознали.Странно, что вы не знаете разницу между «открытый ключ» и «доверенный ключ/сертификат». Под первым обычно подразумевается часть протокола РСА
то придётся снижать безопасностьИ наконец-то переходим от теории к практике. ИРЛ применяется адекватный уровень безопасности. Тот кто сможет митм, сможет и описанную ранее рекурсию.
Сеть доверия в PGP развивать разве чтоНедавно была новость о том как спец.службы в даркнете около года
Входные данные для алгоритма, например. И откуда они возьмутся. И почему этим входным данным можно доверять.Потому что имеется математическое обоснование этого. Любой кто дружит с математикой может это проверить.
Или упомянутые здесь слова внезапно приобрели новый смысл?Они его имели изначально. Задача лишь послать
Про защиту от митм начал… andreymal знаете такого? Ну тот самый который любит себе же и перечить.
Как я уже не один десяток раз повторил ниже — можно работать с TLS и без третьей стороны, было бы желание. Доверять центрам сертификации никто не заставляет, как минимум в Firefox их можно отключить, сегодня проверял.Разве уже общались ниже? Не помню.
Не вижу ни какого практического применения в удалении сертификатов, из протоколов построенных на сертификатах.
Какую?Шифровать только часть документа, там где это действительно нужно. Остальное же просто подписывать одноразовыми ключами ака одноразовыми хешами для защиты от подмены.
Опять же, я не исключаю, что я чего-то не понимаю в ДХ, но я не вижу, как результату ДХ можно доверять, когда нет изначально доверенных открытых ключей или что-то типа того.В шифровании не может быть и заготовленных и открытых и доверенных ключей. Так это же "Треугольник проекта", выбрать можно только 2 из 3х.
Опять же, я не исключаю, что я чего-то не понимаю в ДХ
Пожалуйста, расскажите, как с помощью ДХ и без TLS (мы же здесь обсуждаем альтернативу TLS?)
А что если я вам скажу, что ДХ это один из протоколов инициализации TLS?
Причём лучший, остальные
Попробую всё же ещё разок.
Вас, предположим, сбивает с толку одинаковое слово «протокол».
На самом деле ДХ это конкретный протокол, а TLS это сборник протоколов, среди которых каждая из сторон выбирает из наличия. Т.е.
Из полного набора, сначала отбрасывается, то что не поддерживает клиент, потом то что не поддерживает сервер.
И вот прям сейчас читая хабру, у меня может быть значительно более высокий уровень защищенности соединения, чем у других, а посещая форум своего знакомого у меня будет ничтожный уровень защищенности(стоит минимальный набор крипто либ), при этом всё время это TLS и «зеленый замочек».
Кстати практическую возможность взломать уже демонстрировали, и защищеной можно считать только последнюю версию.
PS:
Почитав вашу переписку ниже, не могу не засуммонить nagibat0r
Потому что имеется математическое обоснование этого.
А ещё имеется математическое обоснование абсолютной криптостойности шифра Вернама. Только это абсолютно никак не спасёт от утечки одноразовых ключей, если таковая случится, без отзыва их доверия. И одноразовые ключи сами по себе из ниоткуда тоже не возьмутся — собеседники должны передать их друг другу, что опять же требует чего-то заслуживающего доверия. Так что давайте вернёмся в реальность и не будем забывать, что без TLS собеседники никак не могут доверять друг другу — независимо от того, насколько там математически обоснован этот ваш ДХ.
Они его имели изначально.
Они — собеседники, его — открытый ключ? Если так, то это «изначально» вообще-то обеспечивают TLS и центры сертификации. Если нет ни TLS, ни центров сертификации — откуда это «изначально» возьмётся?
Шифровать только часть документа, там где это действительно нужно.
Это будет работать, если существует вышеупомянутое «изначально». А это «изначально» нужно ещё откуда-то получить.
В шифровании не может быть и заготовленных и открытых и доверенных ключей.
Упс, кажется, вы только что объявили PGP невозможным. Там ключи (1) заготавливаются заранее один раз на долгий срок (иногда даже бессрочно), (2) открытый ключ публично заливается на серверы ключей и (3) становится доверенным после личной встречи с собеседником.
А что если я вам скажу, что ДХ это один из протоколов инициализации TLS?
Я это прекрасно знаю и наблюдал его в wireshark всего час назад. TLS с помощью центров сертификации (или ручного доверия) предоставляет ключи, которые позволяют подписать ДХ и тем самым защитить его от mitm. Но, ещё раз, Temmokan предлагает, как вы говорите, какую-то альтернативу TLS. Так что ДХ в контексте данной ветки остаётся сам по себе, без TLS. И уязвимый перед mitm как следствие.
Упс, кажется, вы только что объявили PGP невозможным.Не стоит выдавать желаемое за действительное.
PGP был прорывом для своего времени. там используется обмена рса или дх.
Что именно в PGP защищает от вашего любимого митм?
На остальное ответ в параллельном сообщении и 2м.
Я это прекрасно знаю и наблюдал его в wireshark всего час назад.Так «прекрасно», что запускается срочно wireshark?
Вот это квалификация! А не подскажете как наблюдением отличаете ДХ от иных протоколов?
Уговорили, повторяю. Я там вижу предложение шифровать выборочно, с подписью всей страницы. Что выглядит достаточно разумно, покрайней мере для меня т.к. знаю сколько и какого трафика проходит.
Так «прекрасно», что запускается срочно wireshark?
И что? Мне уже wireshark ни в коем случае нельзя запускать почему-то?
как наблюдением отличаете ДХ от иных протоколов?
Вы wireshark вообще хоть раз открывали? Он всё парсит и подписывает.
Я там вижу предложение шифровать выборочно, с подписью всей страницы.
Да, это там есть. Но ещё там есть «не убедили, что HTTPS — единственный путь к безопасности», недовольство тем, что «фактически обяжут сидеть на HTTPS» и переживания за «сдохнет доступ к его CA» — то есть всё то, что обеспечивает доверие к ключу, которым Temmokan собирается «шифровать выборочно, с подписью всей страницы». Если его не устраивает, что «сдохнет доступ к его CA», то остаётся вопрос, как тогда доверять открытым ключам перед подписью — я и спросил «А откуда вы открытый ключ возьмёте»? если не из CA, к которому сдохнет доступ.
Да, это там есть. Но ещё там есть «не убедили, что HTTPS — единственный путь к безопасности», недовольство тем, что «фактически обяжут сидеть на HTTPS» и переживания за «сдохнет доступ к его CA» — то есть всё то, что обеспечивает доверие к ключу, которым Temmokan собирается «шифровать выборочно, с подписью всей страницы». Если его не устраивает, что «сдохнет доступ к его CA», то остаётся вопрос, как тогда доверять открытым ключам перед подписью — я и спросил «А откуда вы открытый ключ возьмёте»? если не из CA, к которому сдохнет доступ.А Скрипач не нужен, родной ©
Если я правильно понял начальные две записи Temmokan, он намекал о ненужности сертификационных центров.
По причине того, что у кого хватит ресурсов стать посередине, хватит и обойти костыль сертификатов.
Как именно тоже описано в одном из сообщений выше про «рекурсию».
И я всё еще не понимаю, что вам не понятно? Если только… вера в независимость и неподкупность СЦ?
Но даже это уже опровергнуто практикой, пример уже был выше. Значит сильно не внимательны.
он намекал о ненужности сертификационных центров
Ну так вопрос-то всё равно остаётся — «А откуда вы открытый ключ возьмёте», если не от сертификационных центров?
«Рекурсия» это проблема, да. Но, думаю, можно попытаться смягчить её, например, скачиванием браузера через разных провайдеров — хэш должен быть одинаковым у всех скачанных файлов (а если хэши отличаются, значит кто-то подменил браузер). Ну а если уж подменять станут абсолютно все провайдеры (по приказу государства, например) или же если врубить теорию заговора и считать, что все браузеры сотрудничают со всеми государствами, то я как простой смертный уже ничего не смогу сделать и остаётся только шапочку из фольги надевать да на митинги ходить. (Ну или вручную решать доверие к каждому сертификату. Но откуда мне знать, что в RSA нет каких-нибудь уязвимостей? Где там моя шапочка?)
вера в независимость и неподкупность СЦ?
Ага.
Но даже это уже опровергнуто практикой, пример уже был выше. Значит сильно не внимательны.
Видимо, в этом посте я что-то проглядел. Из подобных примеров знаю только WoSign да StartCom, но их-то уже выпнули отовсюду. А тут ещё нижеупомянутый Certificate transparency завозят, затрудняющий левые манипуляции с сертификатами
«Рекурсия» это проблема, да. Но, думаю, можно попытаться смягчить её, например, скачиванием браузера через разных провайдеров — хэш должен быть одинаковым у всех скачанных файлов (а если хэши отличаются, значит кто-то подменил браузер). Ну а если уж подменять станут абсолютно все провайдеры (по приказу государства, например)Простите, только из лесу?
Тогда советую просмотреть жаркую эпопею под названием «заблокирую телеграмм».
Если бы у вас была хоть капля аналитики вы б увидели там очень быстрое исполнение приказа РКН, даже несмотря на то, что он мог оказаться нелегитимен. При чём делало это очень оперативно. Иногда даже слишком, без времени для подумать.
А по доверию СЦ процитирую написанное ранее:
Третья сторона. При чём это угроза вполне реальная. Особенно если вспомнить, что могут быть и решения специального суда, например, постановление суда FISC от 25 апреля 2013 года.
Чисто для понимания этот сайт заверен тем же комодом.
Логическую цепочку продолжить дальше самостоятельно получится?
эпопею под названием «заблокирую телеграмм»
Это вы про что-то там с треском провалившееся?
При чём это угроза вполне реальная
Это ужасно, но не имеет отношения к безопасности HTTPS. Даже если абсолютно все центры сертификации откажутся выдавать сертификаты Sci-Hub'у, всегда остаётся вариант получить его у Александры Элбакян каким-либо путём (может, даже при личной встрече — всё-таки она не админ гугла; если она не прячется от всех подряд, хз где она сейчас) и вручную добавить сертификат в доверенные.
Мой доверие к цетрам сертификации строится не на том, что они выдают сертификаты любому домену (как продемонстрировал Sci-Hub, не любому), а на том, что они не выдают поддельные сертификаты кому попало. WoSign и StartCom, которые немножко засветились в подобном, уже выпнуты.
Логическую цепочку продолжить дальше самостоятельно получится?
Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более. Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.
на том, что они не выдают поддельные сертификаты кому попалоВы проверили все выданные сертификаты?
А все ответы соответсвующих серверов комода?
Вопросы очевидно риторические. А потому утверждение не имеет никаких обоснований кроме «я о таком не знаю».
Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.Тогда говорить будет поздно.
Просто потому, что об этом ни кто не узнает.
А очередной Сноуден, который всем сможет это рассказать — появится не скоро.
Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более.Вы видите только то что хочется.
А я вот ещё паралельно вижу, что комодо исполнил решение суда.
И исполнит ещё одно решение в котором будет сказано «дать положительные ответы на запросы от… того на кого агент джон доу покажет пальцем», хотя почему исполнит — уже исполнил.
Ну тут остаётся только шапочку из фольги надеть.
Там просто не существует слова «доверие», только слово «проанализировал(а)» и «проверил(а)».
О, вы уже второй раз объявили невозможным PGP, в котором есть «сеть доверия».
О, вы уже второй раз объявили невозможным PGP, в котором есть «сеть доверия».Я и в третий раз могу вам напомнить как в даркнете работали спец.агенты втёрлись в доверие и работали в течении года.
Вы лично можете гарантировать, что в «сети доверия пгп» нет десятков точек от спец.служб лидирующих стран в разведке?
А что там не прописались мошенники или ещё кто-то?
Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более. Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.
Symantec поддельных сертификатов выпустил тридцать тысяч за несколько лет.
А раз мы говорим Symantec то мы говорим и GeoTrust, VeriSign, Equifax, Thawte и RapidSSL. Впечатляет?
И это были не просто сертификаты вроде ЛетсЕнкрипт, это были дорогие суперсертификаты EV используемый банками и корпорациями, ну знаете это когда не просто зелёный замочек а ещё название компании.
Да их наказали, спустя несколько лет. А до этого? До этого HTTPS годами «защищал» вас.
Вот это уже более серьёзно.
Осталось предложить альтернативу.
Вот это уже более серьёзно.Всмысле серьёзно?
Осталось предложить альтернативу.
Вы рассуждаете о доверии Сц, при этом не знаете важных событий ИБ?
То, что вы вспомнили зачем-то телеграм вместо Symantec, говорит о том, что вы тоже не знаете. Но всё же, если СЦ доверять нельзя — предложите альтернативу?
То, что вы вспомнили зачем-то телеграм вместо SymantecДействительно, зачем?
Может там всё прозрачно и очевидно, но надо было вдуматься?
говорит о том, что вы тоже не знаете.Говорит лишь о том, что у andreymal серьёзные проблемы с логикой.
При наличии достаточно надёжного способа передачи открытого ключа от HTTP-сервера вся последовательность предложенных мной действий предотвращает MITM.
Сервиса обмена ключами можно организовать и на HTTPS, суть моего утверждения — что нет необходимости во всеобщем переходе на HTTPS. Который без всеобщего внедрения того же DANE создаёт только иллюзию безопасной передачи.
И ещё раз попрошу не приписывать мне то, что я не утверждал.
Вам не понравился «single point of failure» в виде Let's Encrypt, то есть вы усомнились в центрах сертификации, с помощью которых работает HTTPS. Так как центры сертификации — основная фишка HTTPS, то я счёл допустимым сделать вывод, что вы предлагаете не использовать HTTPS. Если я ошибся, значит вы комментарий так коряво сформулировали)
Если не центры сертификации, то значит предложите какой-то другой «достаточно надёжный способ передачи открытого ключа в HTTP»
Сервиса обмена ключами можно организовать и на HTTPS
У которых HTTPS-сертификат от Let's Encrypt, который single point of failure, из-за которого всё плохо? Тогда останутся все те проблемы HTTPS, которые вы упомянули в своём комментарии («сдохнет доступ к его CA — что будем делать?»)
> У которых HTTPS-сертификат от Let's Encrypt,
Необязательно на Let's Encrypt. Опять вы сочиняете что-то, что я якобы подразумеваю, чтобы потом с довольным видом вести полемику с вашей же выдумкой?
Ляжет упомянутый мной канал — что уже представляет собой глобальную проблему — задействуйте другие каналы, где криптография работает (той же электронной почтой), и так далее, вплоть до личной передачи ключа на носителе (напоминаю ещё раз, чтобы вы мне ничего нового не приписывали, что альтернативные способы — для чрезвычайной ситуации, когда HTTPS для данного конкретного сервиса не работает).
Если вы не предлагаете не использовать HTTPS и если Let's Encrypt вас всё-таки устраивает, то тогда я совершенно перестал понимать, о чём был ваш комментарий
вплоть до личной передачи ключа на носителе
Это всё можно сделать в рамках HTTPS (в любом браузере есть ручное добавление «лично переданного на носителе» ключа в доверенные), так что я продолжаю вас не понимать
И опять вы приписываете мне то, что я не подразумеваю. А ведь я уже всё сказал выше. Цитирую себя:
«суть моего утверждения — что нет необходимости во всеобщем переходе на HTTPS»
Выделил жирным то, что именно утверждаю.
Если всё равно не понимаете — что ж, продолжайте не понимать.
Так или иначе приходится кому-то (чем-то) доверять — тому, что ответ DNS никто не подменит, что сертификаты в хранилище компьютера не подменные, и так далее. По мне — чем меньше сущностей, которым придётся доверять «на слово», тем меньше головной боли.
HTTPS в том виде, в котором он есть, является лишь иллюзией безопасности
HTTPS в том виде, в котором он есть — безопасность на базе доверия неподкупным центрам сертификации. Сомневаетесь в том, что они неподкупные — убираете «третью сторону», удалив корневые сертификаты из браузера, решаете вопрос доверия к каждому ключу самостоятельно и получаете end-to-end.
удалив (!) все сертификаты и все центры из доверенных, он получает end-to-end
А вы настолько весь такой компетентный, что до сих пор не смогли доказать обратное. Вы присылали определение end-to-end — я вам расписал, что HTTPS полностью под него подходит.
Так что нет, пока что не убедили, что HTTPS — единственный путь к безопасности.
Кто же Вас убеждает в этом? Безопасность должна быть комплексной. HTTPS — один из простых способов повысить безопасность
Даже в общем-то и не убеждает, а ставит перед фактом — или обеспечь HTTP, или сайт будет помечен как небезопасный.
2 года назад похожее произошло, но не припоминаю чтобы кто-то был сильно против, как сейчас. Напомню: старые SSL стали считаться небезопасными и все браузеры на них ругаются, что они «not secure»
Да, когда самоподписанные сертификаты безоговорочно стали признавать небезопасными, народ особо не возмущался.
Осталось «внезапно» сделать LE платным, пусть даже дешёвым.
Если говорить о HTTP и HTTPS, то альтернатив HTTPS со стороны Google не предлагается.А почему они должны предлагаться «со стороны Google», я не понял? Вы хотите альтернативы — вы её и внедряйте.
Если она окажется достаточно популярной — может и Google её поддержит.
Но пока, извините, при всех ваших воплях ответа на пару простых вопросов нету:
1. Где взять и как поставить сервер, которой будет осуществлять все эти хитрые манипуляции с заголовками?
2. Где взять и как использовать браузер, который будет совместим с вышеописанным сервером?
Пока ответы на эти вопросы «нету ни браузера, ни сервера» — поведение Google выглядит разумным.
Заставить Google и другие конторы обратить на всё это внимание можно по сути единственным образом — внедрить действующий образец. По-другому никак.
И 1. и 2. решаются написанием модулей/плагинов. Не нужно быть семи пядей во лбу, чтобы это понять.
А поведение Google «выглядит разумным» не потому, что нет ответов на 1 и 2 — задайся Google альтернативой, это всё давно бы уже решилось — а просто потому, что повсеместное внедрение HTTPS выгоднее — при наличии простого способа давления на всех владельцев сайтов сразу другие варианты нет смысла рассматривать.
Корпорации в первую очередь всё делают ради своих доходов и и иных видов выгоды.
Где вы увидали, простите, «вопли»?Первое предложение первого абзаца обсуждаемой статьи. Да собственно почти вся статья, которая вокруг простого технического решения возводит кучу пафоса.
А поведение Google «выглядит разумным» не потому, что нет ответов на 1 и 2 — задайся Google альтернативойЕщё раз — почему вы считаете, что Google должен это делать?
HTTPS выгоднее — при наличии простого способа давления на всех владельцев сайтов сразу другие варианты нет смысла рассматриватьHTTPS просто уже существует, как вам уже указали. А ваши «гениальные» технологии — нет. Вот и всё.
Корпорации в первую очередь всё делают ради своих доходов и и иных видов выгоды.Не только копрорации. Человек вообще склонен минимизировать усилия.
В настоящее время существует две технологии: безопасная и небезопасная. На одну из них браузер ругается (не показывая зелёненькой надписи «Secure»), на другую — нет. Замена надписи «Secure» на пустоту, и пустоты на «Unsecure» — чистая косметика.
Но вам это не нравится и вы говорите, что вторую технологию тоже можно сделать безопасной… ну так вперёд — делайте! Как сделаете и добъётесь того, чтобы не только вы её использовали, а какой-нибудь ощутимый процент пользователей… можно будет поставить вопрос, чтобы и для неё надписи «Unsecure» не было.
Но только так и только в этом порядке: вы обеспечиваете технологию, Google меняет браузер, чтобы для неё шилдик был другой.
Сам Google разрабатывать ничего подобного не собирается, потому как одна, достаточно безопасная, технология уже у него есть — и логично дорабатывать и развивать именно её, а не заниматься переизобретением велосипеда.
И 1. и 2. решаются написанием модулей/плагинов. Не нужно быть семи пядей во лбу, чтобы это понять.Но, похоже, нужно очень много пядей, чтобы понять, что принцип: «утром деньги, вечером стулья или вечером деньги, утром стулья — но делньги вперёд» незыблем. Пока этих модулей/плагинов нет (а насколько я знаю, их таки нет) — обсуждать нечего.
> Ещё раз — почему вы считаете, что Google должен это делать?
Вам нужны ответы даже на риторические вопросы?
Google уже сделал всё, что захотел — кому не нравится, просто не пользуйтесь его браузером.
Остальные ваши реплики — белый шум; там, действительно, нечего обсуждать.
Вы пишете «при всех ваших воплях» — потрудитесь продемонстрировать мои «вопли», в таком случае.Ох уж эта неоднозначность русского языка и вежливость. В данном случае, поедставьте себе, слово «вы» обозначало-таки слово «вы»… а не вежливую форму слова «ты». Подразумевалось поведение (почти истерической) всей группу «свидетелей HTTP» — конкретно у вас (в смысле у «у вас» == «у Temmokan»), пожалуй, истерики действительно нет.
Остальные ваши реплики — белый шум; там, действительно, нечего обсуждать.Ну это как хотите. Далеко не все стандарты, которые поддерживает Chrome разработаны в Гугле, и, кроме того, Chrome — далеко не единственный браузер.
Я попытался описать как практически можно было бы решить проблему «хотим безобасность не на основе HTTPS, а на какой-нибудь другой основе».
Если этого вам реально не нужно, а нужно, чтобы вас по головке погладили и посуствовали, покивав при этом на «бездушную корпорацию» — то да, в этом разрезе действительно мои предложения бессмысленны.
Ну так и не обобщайте. Эмоциональные эпитеты в адрес собеседника обычно означают, что дискуссия из предметной перешла в «спор на темпераменте».
У исходной статьи действительно эмоциональный посыл. А по-хорошему надо было, хотя бы вкратце, упомянуть о состоянии дел в этой области.
Я вот ждал, когда хоть кто-нибудь упомянет тот же HTTP 1.1 Upgrade — уже достаточно давно существующий механизм использования стандартного HTTP порта, при этом позволяющий в т.ч. перевести передачу данных на TLS. И даже свой пример, построенный прямо тут же «на коленке», но уже вполне годный как замена HTTPS прямо поверх стандартного HTTP привёл в надежде, что мне укажут на тот же Upgrade.
Спорить о мотивациях Google можно долго, но в данных комментариях нет их официального представителя, а, значит, нет возможности обсуждать предметно — только строить гипотезы и спорить на темпераменте.
По мне, всё просто. Вокруг HTTPS уже развёрнута огромная инфраструктура, на этом всём кормятся десятки крупных корпораций, получающих деньги за воздух (ну да, они якобы страхуют риски использования HTTPS и типа ручаются за покупателей супер-дорогих сертификатов).
Ежу понятно, что любая альтернатива, которая не использует эту инфраструктуру, будет подавляться упомянутыми выгодоприобретателями. Им на кой копать себе не то что бы могилу, но огромные потенциальные вложения во что-то новое? Туда же — изготовители браузеров и так далее.
Так что можно не гадать, куда направили бы все альтернативные HTTPS варианты. Потерянные деньги — это серьёзнее всего остального в нашем капиталистическом настоящем.
Где-то так. А то, что лично вам не докладывают, кто какими альтернативами пользуется — ну не докладывают, что поделать. А вот сделать детальное исследование этой области — вот это было бы действительно и предметно, и осмысленно.
Спорить о мотивациях Google можно долго, но в данных комментариях нет их официального представителя, а, значит, нет возможности обсуждать предметно — только строить гипотезы и спорить на темпераменте.Если вы будете ждать появляения «официального представителя», то будете ждать вечность, так как такового в природе не существует.
И даже свой пример, построенный прямо тут же «на коленке», но уже вполне годный как замена HTTPS прямо поверх стандартного HTTP привёл в надежде, что мне укажут на тот же Upgrade.Ваш пример принципиально отличается от HTTP Upgrade тем, что, в принципе, позволяет решить одну из проблем, о которых плачет топикстартер и многие другие в этой ветке: как-то сохранить те установки, за которыми никто не следит и где изменить настройки сервера нельзя.
HTTP Upgrade так сделать не позволит и потому, по большому счёту, бессмысленен. Годится разве что для попуток обхода блокировок, но и то — легко отлавливается DPI.
Обойти центры сертификации — он тоже не позволит, кстати, так что тут — тоже мимо.
Туда же — изготовители браузеров и так далее.Нет, не «туда же». Google на HTTPS ничего не зарабатывает, скорее теряет. Долгое время HTTPS было невозможно внедрять просто потому, что всякие у YouTube и Hulu не хватало мощностей для «сквозного» шифрования.
Но появление новых процессоров с аппаратным AES — эту проблему решило.
Так что можно не гадать, куда направили бы все альтернативные HTTPS варианты.Ну вот, наконец, и вы лично скатываетесь в истерику: «мы ничего не делали, ничего не делаем и ничего делать не будем, потому что злые корпорации всё равно всё уничтожат… ааа… пожалейте нас, убогих».
Раскрою вам маленькую тайну: крупные копрорации состоят из отдельных людей. И люди, разрабатывающие Chromium на Хабре тоже есть. Вы, в частности, можете стать одним из них, если захотите. А вот людей, которым можно поплакаться и сделать так, чтобы кто-то другой потратил время и силы, чтобы что-то реализовать — таких нету. Вообще нету, нигде, не только на Хабре.
Об остальном я сказал чуть выше.
Внедрение HTTPS вместо «голого» HTTP реально решает кучу проблем, а поскольку другие альтернативы обсуждаются не в рамках WHATWG, а, в лучшем случае, в виде никем не реализованных RFC (а по большей части и вообще в виде «стонов» на неспециализированных форумах), то неудивительно, что на них никто внимание не обращает.
Однако пока что я не вижу никаких практических движений и никакого кода. Только нытьё в блогах и на форумах.
Google ведёт себя в этом вопросе ровно так, как советовал Linus много лет назад — и это, в сущности, единственный разумный вариант.
Зачем, кто-нибудь может объяснить? Чтобы скрыть от провайдера факт загрузки библиотеки?
И да, проблема не в Гугле. Проблема шире: всё сообщество целиком (в том числе с подачи Гугла) согласилось везде должен быть HTTPS. Это не очень хорошая тенденция, поэтому хотелось бы её переломить. Хотя бы для некоторых читателей этой статьи.
С одной стороны — автор вроде как прав и считать такое "принуждение к HTTPS" принуждением — корректно, ведь само письмо построено как "условие".
С другой стороны — даже если сайт никак не принимает и не обрабатывает данные пользователей — он отдаёт данные, почему автор никак не задумался о целостности данных, которые "отдал" сайт и которые "получил" пользователь? Способов использовать то, что "летит" к пользователю масса: аналитика, реклама, фишинговые кнопки с джаваскриптовыми подарками от провайдера.
Было бы логично, например, жёстко запретить приём данных без HTTPS, а для контента просто выводить уведомление, а не "страшный" заголовок про "No secure", будто бы сайт фишинговый.
P.S.: не пользуюсь Chrome и не собираюсь до тех пор, пока Firefox не является его клоном — там хотя бы информацию о сертификате по клику в адресной панели не засунули в такое место, что приходится гуглить или выдумывать, как вернуть такую простейшую функцию обратно.
P.S.: не пользуюсь Chrome и не собираюсь до тех пор, пока Firefox не является его клоном — там хотя бы информацию о сертификате по клику в адресной панели не засунули в такое место, что приходится гуглить или выдумывать, как вернуть такую простейшую функцию обратно.
Не знаю, чё там в Chrome, но в последних Chromium информация о сертификате стала даже на один клик ближе, чем в Firefox
Какой-то глупый пост.
Они [архивы] просто работают.
И обрабатываются человеком посередине. И совсем не факт, что обрабатываются в мирных целях.
Я хочу, чтобы людям было всё проще и проще запускать собственные веб-серверы.
nginx запускается с пол-пинка даже на винде. Сертификаты Let's Encrypt прикручиваются ещё с пол-пинка. А если разрабатывать собственный веб-сервер — зачем?
мы потеряем множество сайтов, созданных на коленке за 25 лет существования Сети
Множество HTTP-сайтов, которые имеют низкую посещаемость, несут ценные идеи и заслуживают сохранения.
Возможно, это единственное что-то не совсем глупое в этом посте
не запрашивают у пользователя никакой информации
Зато отдают её пользователю, и человек посередине может подмешать туда что-нибудь нехорошее.
не упоминают, что [Google?] сами могут делать это в браузере
Никто не запрещает использовать, например, Firefox. И вообще что угодно другое — HTTPS вроде бы поддерживается всеми адекватными программами.
Если HTTPS — это так круто… Тогда зачем заставлять людей?
Затем, что люди нихрена не понимают в компьютерной безопасности. Даже те, кто делает сайты.
Мы не хотим, чтобы всё было безопасным.
Я хочу.
Столько всего небезопасно. Пересечение улицы.
Автор поста переходит дорогу не по переходу и/или на красный свет? Рад за него, а остальные-то тут при чём?
Жизнь вообще небезопасна.
Ну давайте теперь уберём светофоры и разметку и отменим правила дорожного движения, ага.
Но архив моего блога за 2001 год? Серьёзно, здесь нет нужды в особых требованиях.
Откуда я могу знать, что я вижу именно архив блога за 2001 год? Может, мой провайдер испытывает ненависть к автору поста и подменяет содержимое блога чем-нибудь нехорошим?
Google попытался взять под контроль открытый Интернет
Google попытался сделать интернет чуточку безопаснее, исключив MitM-атаки. Автор — белка-истеричка.
Пожалуй, единственное мало-мальски серьёзное беспокойство по поводу HTTPS — это Let's Encrypt. Сейчас он весь такой бесплатный и удобный — а вдруг в будущем испортится? Или, к примеру, тот же StartSSL прикрыли — вдруг и Let's Encrypt однажды прикроют? Не о том автор беспокоится, ох не о том.
Затем, что люди нихрена не понимают в компьютерной безопасности. Даже те, кто делает сайты.
Ну да раньше ктото делал фишерский сайт на HTTP и както не внушало доверия, а на HTTPS бац и уже зеленй красивый замочек а сертификаты всем дают.
— Я так понимаю, что ваша альтернатива — это всё забором обнести и посадить всех в клетку?!?!?
Как почитаешь некоторые «аргументы», так сразу отношение к некоторым драконовским законам сразу смягчается.
Как HTTPS это вопрос решает? гугл-аналитика, яндекс метрика и т.д. и т.п.
А без HTTPS — гугл-аналитика, яндекс метрика, билайн, мегафон, теле2, вася пупкин за соседним столиком в макдональдсе… Вот видите, HTTPS сразу отсекает кучу левака и оставляет только то, что подключено на сайте на самом деле :) А то, что там подключено — это уже проблемы сайта, я могу не посещать сайт с аналитиками и метриками, если не захочу.
example.dev, то хром меня будет посылать пока я не повешу на этот домен сертификат.
Полностью согласен с наличием проблемы, но это немного не по теме поста, и вам никто не мешает взять любой другой домен
То есть, от недоверия к гуглу и провайдерам мы переходим до недоверия к браузерам.
Да. Браузеру (да и гуглу тоже) я доверяю во много раз больше, чем провайдеру.
Как часто во времена голого HTML+CSS вы чувствовали себя не в безопасности?
Постоянно. Помогает только принцип Неуловимого Джо.
ваша альтернатива — это связать руки/ноги всем людям на земле
Моя альтернатива — заставить вас переходить дорогу на зелёный свет. Да, так тоже иногда убивают (вот буквально недалеко от моего дома месяц или два назад так сбили человека, переходившего на зелёный; не задержись я на десять минут — на том перекрёстке мог оказаться я), но что же теперь — нарушать правила и ходить на красный? Что так собьют, что этак собьют — какая разница? Давайте не доводить до абсурда.
Если вы раньше читали статью
А если не читал?
одна корпорация решает за всех
Как минимум две — ещё Mozilla. И решают они в целом правильно.
Вы бы лучше беспокоились за фактическую монополию Let's Encrypt (который теоретически может превратиться в тыкву) и за то, что на локалхост и на 192.168.1.1 (и на домены dev) тоже заставляют ставить HTTPS — вот это настоящие проблемы, а не то, про что ноет автор поста.
Я себе так и сделал (не потому что заставляют, а потому что хочу HTTPS на локалхосте тестировать), но всё ж в целом это довольно бессмысленно (какой нафиг MitM в локальной сети — электромагнитный фон из витой пары соседи подслушивать будут что ли лол?)
На практике именно с MitM такого типа не сталкивался, но со вторым DHCP в локалке — было дело с одной китайской железкой.
Я бы не хотел сдавать любопытному соседскому пареньку пароль от админки роутера или проекта, который тестирую у себя в локалке. Хорошо, если пароли везде уникальные, а если этот пароль идентичен или похож на пароль от беспроводной сети? (ну кто там будет слушать в моей локалке...) Или от ещё какого-то сервиса? Или в продакшен пойдёт с тем же паролем?
И ведь избежать этого так просто.
Моя альтернатива — заставить вас переходить дорогу на зелёный свет. Да, так тоже иногда убивают (вот буквально недалеко от моего дома месяц или два назад так сбили человека, переходившего на зелёный; не задержись я на десять минут — на том перекрёстке мог оказаться я), но что же теперь — нарушать правила и ходить на красный? Что так собьют, что этак собьют — какая разница? Давайте не доводить до абсурда.
Тут скорее уместнее провести аналогию, ну например с альпинизмом. Или каким-нибудь экстремальным видом спорта. Вообще небезопасные же вещи. Но это не означает что их надо запретить, а то там люди могут же шею себе свернуть. Если я имею желание зайти на потенциально вредоносный, небезопасный сайт, то с чего вдруг кто-то имеет право мне это запретить?
nginx запускается с пол-пинка даже на винде. Сертификаты Let's Encrypt прикручиваются ещё с пол-пинка.
это если есть ngnix. А если там, прости господи, древний Lotus? Ставить перед ним reverse proxy? Можно, конечно, но за чей счёт банкет? И вообще, HTTP — это не только сайты в интернете. Устройства промавоматики часто имеют веб-морду. Да, по HTTP. А среди энтузиастов сейчас популярны микроконтроллеры ESP8266 за 1,5 доллара — это полноценный IoT с WiFi и там можно воткнуть веб-морду. Но только HTTP. На SSL в нём тупо не хватит памяти.
Да, это реальная проблема (которую я уже упоминал в своих комментах)
Ругань — дело времени. Например, Firefox уже сопротивляется сохранению паролей на не-https сайтах даже на локалке. Стало менее удобно в настройки роутера заходить. Chromium вроде бы ещё не сопротивляется, но нет уверенности, что не станет сопротивляться в будущем
Firefox уже сопротивляется сохранению паролей на не-https сайтах
В firefox это хотя бы можно отключить через about:config. А вообще идея сделать исключения для локальных ip адресов выглядит здраво, в локальных и корпоративных vpn сетях https попросту не нужен.
У нас на работе во внутренней, не причастной к интернету сети, есть много web сервисов, и все вот эти вот предупреждения о небезопасности и невозможность сохранения паролей иногда здорово портят мне нервы, а пользователи задалбывают вопросами. Поэтому сейчас при установке firefox esr я в обязательном порядке правлю так же еще и целую кучу параметров из about:config.
А если там, прости господи, древний Lotus?
И из-за этого нужно снижать безопасность посетителей? Это уже безответственность и халатное отношение админа к посетителям. (Если админ есть, конечно)
Устройства промавоматики часто имеют веб-морду. Да, по HTTP.
Ну уж им-то точно нечего делать в интернете.
микроконтроллеры ESP8266 за 1,5 доллара
Им — тоже.
P.S. на самом деле одну жесть в этом роде мы уже пережили. Межсетевые экраны Cisco ASA массово поставлялись в Россию с выключенным сильным шифрованием. Их можно перепрошить, чтобы включить 3DES, но это незаконно без разрешения ФСБ. А так как это устройство безопасности, вендор заложил возможность управления только через HTTPS и SSH. Да, при единственном доступном протоколе шифрования 56-битном DES. Который выпилен из всех браузеров. Ага.
Ну уж им-то точно нечего делать в интернете.
Вы правда уверены, что можете решать кто и что должен делать в интернете и кому там место?
Ведь может оказаться, что-то другой решит и вам там не место?
nginx бесплатен, а настройкой его в режиме прокси справится даже ребенок.
При этом, если у вас, прости господи, Lotus, то это как бы автоматически говорит следующее: «Йо, мы жирный и богатый интерпрайз, мы можем позволить себе закупать софт hi-end класса».
И да. У платформы Lotus/Domino просто охренительно продуманная архитектура в плане безопасности. И прикрутить туда сертификат LE, который в общем-то совершенно обычный сертификат, нормальному админу Lotus не должно составить труда.
Раньше ведь сами прописывали провайдерские прокси ради роста скорости.
И да, большая часть «атак» о которых вы пишете решается не шифрованием, а подписанием.
Потому что мой трафик — моё личное дело. И я хочу, чтобы его не только не подменяли, но ещё и не читали. Поэтому просто подпись меня не устраивает.
Вот когда я буду не против, чтобы мой трафик прослушивал кто-то сторонний, тогда я своими собственными руками и пропишу «провайдерский прокси». А делать это без моего ведома не надо.
Для этого, во-первых есть VPN. Во-вторых есть возможность предоставлять к одному и тому же сайту как HTTP, так и HTTPS доступ.
Проблема-то собственно в том, что сегодня даже прописав руками провайдерский прокси от этого нельзя получить выгоду: десять одинаковых котиков по HTTPS будут переданы в виде десяти разных наборов байт зашифрованные для десяти разных получателей. Любой человек посередине считается злым, кроме ситуации, когда сайт передал ему свой сертификат (CDN). Включая все сервисы и службы, которые получатель хотел бы настроить сам.
во-первых есть VPN.
При наличии VPN ничего приниципиально не меняется, просто вопрос доверия провайдеру меняется на вопрос доверия держателю VPN-сервера
как HTTP, так и HTTPS доступ
С этим, пожалуй, соглашусь
Любой человек посередине считается злым
Да, я не хочу, чтобы человек посередине знал, какие именно котики меня умиляют)
Думаю, в браузерах нужно что-то вроде галочки типа «Я умный, разбираюсь в безопасности и хочу, чтобы мне не запрещали HTTP», отключенной по умолчанию
Да, я не хочу, чтобы человек посередине знал, какие именно котики меня умиляют)
Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет. В другом большом числе случаев единственное для чего будет использована эта информация — для ускорения доставки вам котиков.
Более того, правильный прокси-сервер позволит вам скрыть вопрос «какие котики мне нравятся» уже от поставщика котиков. Чего в HTTPS сделать нельзя никак: каждый котик отправляется персонально для вас и значит можно определять кого ещё вы запрашивали и пытаться угадать кто вы есть.
В какой-то мере решение проблемы безопасности через HTTPS играет сильно на руку Гугла, как поставщика контента. Он оказывается монополистом на данные о структуре спроса на контент: вы не можете их скрыть, никто другой не может их получить… вы согласны с такой монополией?
Кстати, при отсутствии монополии таких данных не будет в едином целом вообще ни у кого: часть данных будет у Гугла, часть у оператора кэша, а их ещё может быть не один… так что опциональный HTTPS на само деле безопаснее(с точки зрения возможности скрытия данных), чем жёсткий.
что-то вроде галочки типа «Я умный, разбираюсь в безопасности и хочу, чтобы мне не запрещали HTTP», отключенной по умолчанию
Во-первых не забывайте про домашние устройства вне DNS, которые как минимум не смогут получить корректные сертификаты.
Во-вторых суть проблемы с HTTPS не только в давлении на пользователей, но и в давлении на сайты. Сайты с изображениями на HTTP обозначаются в заголовках значками, призванными символизировать проблемы и ошибки.
Я не хочу сказать, что это всё вина Гугла… нет, это скорее выглядит так, как будто столкнувшись с потенциальными проблемами всё сообщество web кидается прятать голову в песок TLS вместо того, чтобы разбираться с каждой проблемой соответственно.
Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет.
«Тут дело вот в чём: в достаточно большом числе случаев никакого водителя, мчащегося на переход с превышением скорости, не будет...»)
скрыть вопрос «какие котики мне нравятся» уже от поставщика котиков
Ну, может быть, но лично я поставщику котиков доверяю больше)
Сайты с изображениями на HTTP обозначаются в заголовках значками, призванными символизировать проблемы и ошибки.
При отключенной условной галочке «Я умный...» HTTP это действительно проблема и ошибка, потому что данные прослушиваются непонятно где непонятно кем без предварительного согласия пользователя. Хотя отсутствие у вас возможности согласиться на использование HTTP-прокси это тоже проблема и ошибка современного веба, это я не отрицаю
всё сообщество web кидается прятать голову в песок TLS вместо того, чтобы разбираться с каждой проблемой соответственно
Хорошо сказано
данные прослушиваются непонятно где непонятно кем без предварительного согласия пользователя.
Не прослушиваются! Могут прослушиваться!
В рамках метафоры с водителем: водитель может мчаться с превышением… это не повод, например, запрещать наземные переходы.
Вообще конечно, кто-то может и у вас по местной улочке нестись 90, а кто-то может ваш вай-фай слушать… но давайте соизмерять?
лично я поставщику котиков доверяю больше)
Ну, это ваше право. Проблема в том, что сейчас под сомнение ставится право других людей НЕдоверять ему, а доверять больше своему провайдеру (или вообще собственноручно настроенной проксе).
Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет.
Говоря конкретно про россию, а именно тут мы с вами живем, на сегодня абсолютно каждый провайдер прослушивает http трафик, перенаправляя его на свои прокси-сервера. Именно так работает блокировка полных url адресов.
И если раньше открытость трафика не была проблемой, то в сегоднящних условиях это проблема, что не оправдывает конечно такое агрессивное запугивание пользователя плашками с предупреждением о «небезопасности».
Я вообще считаю, что браузер не должен пугать пользователя подобными сообщениями и как-то ограничивать функциональность сайта в зависимости от того, с шифрованием он или нет. Браузер должен просто отображать контент, все. Это дело конкретного сайта по какому протоколу ему работать. А меня, как продвинутого пользователя, такое поведение браузера, который считает себя умнее меня и вовсе бесит.
Я про то, что там где мы боимся перехвата — да, надо шифровать.
Но там, где боимся только подмены — подписывать. И не подменять защиту от одной угрозы — защитой от другой угрозы. А не внедрять HTTPS на каждый чих, полагая, что он всё делает безопасным «автоматически».
Думаю что у многих найдутся такие дедули, которые, увидя что-то непонятное на «неаншенском», быстренько ретируются из этого вашего интернета. Так что вот, жду звонка с содержанием наподобие — «сломался интернет».
Let's Encrypt. Сейчас он весь такой бесплатный и удобный — а вдруг в будущем испортится? Или, к примеру, тот же StartSSL прикрыли — вдруг и Let's Encrypt однажды прикроют?
Это единственная проблема с Let's Encrypt'ом? А то в комментариях к этой статье о нём много нелестных отзывов, но никакой конкретики
Не, новый IE — это сафари. Встроенный в ось браузер с альтернативным пониманием стандартов и такими невороятными глюками, что ие6 вспоминается с теплотой.
Проблема IE была в кривости поддержки стандартов И широкой распространённости. У Сафари второго пункта нет.
Ну и в итоге очень удобно подмять под себя контроль кто куда ходит и что читает, при HTTP это может делать любой по пути следования трафика, а тут как не странно по сути только Google/Mozilla/M$ и доля гугла на рынке браузеров почти 60%.
Если убрать привязку к доверенным центрам, то кому тогда доверять?
Владельцу сайта же. Т.е. «доверенные центры» ну совершенно ничего не меняют — кроме, разве что, EV сертификатов (когда проводится проверка наличия компании). Для сертификатов типа DV они всего лишь проверяют тот факт что купивший его владеет доменом (или имеет доступ к его управлению) — а это стоит не больше чем уже упомянутый DANE, поскольку любой фишер может купить домен и сертификат к нему, заплатив анонимной кредиткой за то и другое — т.е. совершенно не привязывая себя (как физическое лицо или компанию) к ним.
Если бы доверенный центр гарантировал хотя бы тот факт что владельца сайта можно найти как физическое лицо (или компанию) — да, другое дело, но это уже будут совсем другие расходы на валидацию.
А центры доверия за какие деньги должны работать и обслуживать миллионы клиентов?
Они вообще не нужны кроме случаев EV — для этого хватит DANE. Цель «массовой» сертификации — защитить траффик от клинта к серверу, не более, с этим справится любой владелец сайта, достаточно выложить нужные данные в DNS (разумеется, речь про DNSSEC, а не простой DNS).
Если же говорить про EV, то банки и прочие компании которым это важно, вполне могут заплатить за сертификаты, которые действительно удостоверяют их существование — вот с этого CA и будут кормится.
PS: Наверное, вы в курсе про то что не все доверенные центры заслуживают доверия? Даже Symantec оказался не таким уж доверенным, несмотря на всю помпу.
За всё нужно платить, за безопасность в том числе. Если убрать привязку к доверенным центрам, то кому тогда доверять?
Да, а вот центрам сертификации мы доверяем, правда?
Google will distrust all existing Symantec SSL certificates starting with October 2018, and Symantec will have to rebuild its entire certificate issuance infrastructure from scratch if it wants to remain in the CA (Certificate Authority) business.
Symantec punished for misissuing 30,000 SSL certs
In March 2017, Google and Mozilla engineers found that Symantec misissued 127 SSL certificates, but as the investigation progressed this initial estimation grew to a whopping figure of over 30,000 certs.
The number shocked industry experts. Because Symantec was the one of the largest CA on the market, few dared to react. The first one to show its displeasure with Symantec's SSL issuance procedures was Google, who a few days later after the discovery announced an intention to gradually remove support for Symantec certificates in Chrome.
Ещё одна сторона той же проблемы. Раньше сайты могли сохраняться многими годами без вмешательства админов. В новой же реальности они будут жить только пока жив сертификат. С пресловутым LetsEncrypt — месяцы.
Есть сайты, которые 10-15 лет не обновлялись. И работают. Google хочет положить этому конец.
Есть 2 типа зависимости:
— которые можно игнорить (как вы правильно сказали — обновление ОС);
— которые ломают сайт/etc.
Тема статьи про 2.
Я сам так и делаю. Но даже с такой простой автоматикой на своих паре десятков доменов за год пару раз уже получал просроченные сертификаты. А без внимания админа это произойдёт намного быстрее.
И это ещё без учёта возможных проблем со стороны самого LetsEncrypt.
Пока — нет. Но Гугл обещает, что будет с этим бороться. И общий тренд к тому ведёт. Через несколько лет, вполне возможно, неквалифицированный пользователь с попасть на сайт с кривым сертификатом не сможет.
А что до встраиваемого контента — это проблема уже сейчас. Вот прямо в тему, вчера пользователи стали жаловаться, что на форуме перестали показываться картинки. Я потыкался, с виду работает. Сегодня жалоб стало больше, пошёл разбираться. Оказывается, на одном из серверов, выбираемом через round-robin DNS как раз протух сертификат Let's Encrypt. Его автоматическое обновление с round robin, вообще, дополнительная головная боль, вот у меня глюк и вылез.
Так что картинка на сайте с протухшим сертификатом не работает уже сейчас… А что будет завтра?
Доступность информации
По мне так — я согласен с тем, что нельзя искоренять http. Это прямо влияет на доступность информации.
С http не нужны никакие центры сертификации, ничего. Любой с калькулятора сможет получить доступ к сайту, при отсутствии фильтрации траффика со стороны провайдера.
Текущий уровень внедрения HTTPS
А он никакой. Просто никакой. Let's encrypt это конечно весело и по пацански, но DANE'то где?
Доверять свою безопасность стороннему регистратору сертификатов ИЛИ своему DNS серверу?
Ни один паблик DNS сервер в инете сие не поддерживает, потому, что не будет нужны в этих сертификатах от комоды, летса и иже с ними.
В итоге: HTTPS не допилен, доступность инфы зависит от третьих рыл, и они собрались искоренить HTTP, загнав всех в рамки недоHTTPS.
DNS over HTTPS
Это не оверхед?)
Прозрачный ответ от DNS с подписью и ее проверка на основе паблик ключа это быстрее чем поднять сессию (https) с проверкой сертификатов и отправить запрос, следом получить ответ.
DNS очень быстро работает. А когда кеширует, то локальный кеш вообще бомба (путин-террористы). У меня везде используется google dns через dnsmasq с включенным dnssec. Дома на лаптопе и на серверах. Время ответа на серверах очень быстрое, гугл очень шустрый как и связь с ним. Дома, конечно, медленнее чем с ДНС провайдера, но последний слоупочный.
На счет DANE — не готова полная поддержка всех RFC для паблик сервисов (=днс хостингов), так как им просто не выгодно отнимать этот пирог у центров сертификации. Другое дело, что все DNS сервера, которые массово доступны (bind, nsd) поддерживают нужные нам записи. И ничего не мешает запустить свой DNS и прописать там записи для DANE.
А вот браузеры… тут я хз. Раньше были плагины, на свежие версии они не пашут (для firefox по крайней мере). Сайтов с самодельными сертификатами не нашел. Все "CA signed".
А если, допустим, древний никем не поддерживаемый сайт использует куки? Он же не сможет удолбать пользователя предупреждением про куки. Т.е. имеем нарушение Закона. Заперетить такие сайты и заблокировать на всегда. Тех, кто их создал, найти и оштрафовать. Тех, кто умер — посмертно.
Идея поста хорошая, но все аргументы сведены к "Гугл плохой" и "Почему мне указывают что делать".
А как же осветить техническую сторону вопроса?
Ведь https это не только зелёная плашечка в браузеое, это нехилая нагрузка на CPU условного CDN или любого другого контент поставщика чей RPS начинается от 1000 и выше.
А есть точная инфа про нагрузку от какого-нибудь такого контент-поставщика? А то я когда-то давно читал, что всё почти наоборот — мол, почти весь HTTPS уже реализован аппаратно в процессорах и HTTPS на производительность якобы почти не влияет (хотя лично я не изменял, у меня нету 1000 RPS)
Самый простой вариант — запустите openssl speed rsa и посмотрите sign/s — это и будет вашим лимитом на RPS (умножте на количество ядер) в случае HTTPS. Keep alive и session cache увеличивают RPS (для одного клиента), но если клиентов очень много — это мало помогает, нужно больше CPU со всеми вытекающими.
Впрочем, это всё имеет значение только для тех у кого действительно RPS выше 1000/s — остальные этого, скорее всего, не заметят (если у них не старинное железо, разумеется).
В процессоре реализовано только симметричное шифрование. А ассиметрия, необходимая для установки соединения, делается чисто софтово. Тут, правда, помогает криптография на эллиптических кривых в которой математика в разы проще по нагрузке чем в RSA.
На 6 ядрах было 10K rps по SSL на nginx с
return 200 "OK";И сравнения на виртулке в которую не пробросились флаги с проца что он умеет AES.
SSL на такой выжимает ~1-2K.
Без SSL — ~8K.
Все значения округлены в до тысяч в большую сторону и итоговая суммарная нагрузка на сервера предполагалась больше указанных выше значений.
Вообще конечно тут много интересного и сразу. Для меня вот встаёт делема «никто ничего не знает о безопасности, поэтому давайте обезопасим всех сами». У неё есть одна проблема — как ты не защищай всё это бейджиками, количеством кликов, двусторонним подтверждением подлинности на техническом уровне — за компом всё равно будет сидеть обезьяна, которой пофиг, какие войны устраивают айтишники на счёт безопасности. Обезьяне главное смотреть котиков. Ей пофиг какие технологии защищают её от «неправильных котиков», если ей захочется посмотреть на неправильных, она найдёт их.
Для меня вопрос заключается не в том, что юзеры будут убегать с сайта с криками «там не безопасно», для меня страшным является то, что пользователи будут спокойно вводить свои пароли в окошках рекламных баннеров, не думая, а полагаясь на зелёненький значёк в строке браузера.
Нет смысла бороться за безопасность пользователя, нужно бороться за грамотность в этой области.
1. Почему когда вы посищаете сайт по https подписаный неизвестным для вас CA вам должно выкидывать ALERT на весь екран о том что ваш сайт на который вы заходите «непойми на что», а чем http лучше? Вы по факту реально заходите не пойми на что, никакой гарантии что вы на том ресурсе о котором думатете, это еще хуже: с самоподписным SSL (или выданым недовереным СА) между вами MITM хоть не зделают если вы всетаки знаете что это за СА, а вот с http — за нефиг. Я еще удивлен что Google не добралось до «наказаний» за отсутвие авторедиректа с http-to-https или у себя не реализовало проверку приоритета — сначала https, а потом http в самом негативе.
2. Если раньше у вас не было выбора и вы обязаны были покупать дорогие сертификаты wildcard, или накупать кучу single сертификатов (и то он был — китайты с StartSSL), то сейчас любой желающий может спокойно сделать себе LetsEcnrypt — проще чем настроить даже сам nginx\apache\iis\haproxy\squid etc. И что самое главное: даже мелкие хостеры каких то статических или php cPanel уже тоже интегрировали себе такие функции (вплоть до wildcard over dns api), и вам вообще ничего не нужно делать кроме как нажать на кнопку «я согласен с лиц соглашением LetsEncrypt»
3. То что пишут в коментариях по поводу пониженой производительности по сравнению с plaintext: чушь собачая. Шифрование AES-NI сейчас в соцпроцессоре реализовано даже на в некоторых soho роутерах, а это значит что сам ваш процессор непосредственно на прямую не почти тратит свои силы на шифрование\дешифрование, этим занимается отдельный модуль. Страницы рендертся на слабейшем сервере (с поддержкой AES-NI)и скачиваются с обратной стороны даже самым забитым китайским смартфоном что по http что по https с одинаковой скоростью (с разницой на уровне погрешности)! Мало того есть такая прелесть HTTP\2 и хоть он в теории может работать без TLS, но на практике он без него в природе не фурычит, так вот HTTP\2 с https реально быстрее чем даже обычный http с plaintext за сщет мультипоточности и бинарной, а не текстовой структуры запросов. Плюс если кто не знал в https самое долгое это handshake — как только вы первый раз обмениваетесь dhparam, а потом все летит как по маслу, и протокол придуман так что даже если вы оборвали соединение — вам не нужно делать новый handshack — сервер всеравно хранит определенное время вашу с ним сессию и востановит ее при повтороном подключении если не исчерпается timeout.
4. Ну и на последок, припустим у вас в нутри корпоративной сети есть сайт не смотрящий наружу и вы не хотите выбрасывать его наружу — создаете свой локальный CA, раздаете всем сотрудникам публичный СА ключ и инструкцию как его установить на их ОС (если есть AD то еще проще — просто через GPO) и вуаля — все верят вашему CA, после чего вы берете и генерете себе такие SSL какие пожелаете для любых целей и любых локальных ресурсов.
Сложно? Не думаю.
сейчас любой желающий может спокойно сделать себе LetsEcnrypt
А потом? Letsencrypt, будучи бесплатным сервисом, не даёт никаких гарантий — и (теоретически) может превратиться в тыкву в любой момент. Или стать платным.
Я не хочу сказать что им не стоит пользоваться (наоборот — очень нужно), просто подобного рода сервис стоило бы гарантировать — раз уж он очень нужен. Но гугль почему-то не спешит раздавать сертификаты гарантированно бесплатно, и в то же время требует HTTPS «во избежание» — это несколько настораживает.
Плюс если кто не знал в https самое долгое это handshake — как только вы первый раз обмениваетесь dhparam, а потом все летит как по маслу
А ничего что это нужно делать заново как минимум для каждого нового клиента? Т.е. RPS уже заведомо ограничен процессором (и количеством ядер). Другое дело что для слабых нагрузок (а-ля домашний блог) это несущественно, но вот для нагруженных сайтов — уже нужны системы помощнее.
Не поймите меня неправильно, в целом я всеми щупальцами вас поддерживаю — просто не стоит забывать о рисках и затратах.
Другое дело что для слабых нагрузок (а-ля домашний блог) это несущественно, но вот для нагруженных сайтов — уже нужны системы помощнее.Ну так чем больше пользователей, тем нужнее SSL/TLS. Ведь пользователи будут там авторизовываться, обмениваться информацией и так далее, ведь сейчас же Web 2.0 как-никак.
А потом? Letsencrypt, будучи бесплатным сервисом, не даёт никаких гарантий — и (теоретически) может превратиться в тыкву в любой момент. Или стать платным.
До LetsEncrypt был StartSSL (китайцы) которые давали бесплатно сертификаты на 3 года.
А сейчас за местно них LetsEncrypt который никогда не станет платным потому что он создан из фонда инвесторов таких как Cisco, Mozilla, Chrome, и сатус у организации закреплен как «не комерческая», они в принцыпи не имеют требовать с кого либо деньги за свои услуги, читайте letsencrypt.org/become-a-sponsor а потом пишите свои не обоснованые догадки.
А ничего что это нужно делать заново как минимум для каждого нового клиента? Т.е. RPS уже заведомо ограничен процессором (и количеством ядер). Другое дело что для слабых нагрузок (а-ля домашний блог) это несущественно, но вот для нагруженных сайтов — уже нужны системы помощнее.
По поводу нагрузок HTTPS — у меня на опыте администрирования сайтов с достаточно большой нагрузкой, и фронтенд за одним nginx в роли reverse proxy который делает https, вы не представляете на каком корыте он может стоять (1 CPU 1,8Ghz, 2Gb RAM, Ubuntu) и загрузка CPU никогда не привышает 40%, поэтому давайте не придумывать.
До LetsEncrypt был StartSSL (китайцы)
До китайцев это были евреи, которые затем продали китайцам, которые и загадили сей проект.
сейчас за местно них LetsEncrypt который никогда не станет платным
Неважно кто их спонсирует — ни вы, ни кто-то другой сейчас не может утверждать, что с этим станет через 2-3-4 года. Может оказаться так что их затраты со временем превысят спонсорские и донатные поступления — и выбора у них не окажется. Тот же упомянутый вами StartSSL вроде выглядел надежно — но их не стало в итоге.
«Некоммерческая организация» значит только то что они созданы не с целью получения прибыли, но никто им не запретит брать деньги для поддержания своего существования, и никто не запретит им самораспуститься.
вы не представляете на каком корыте он может стоять (1 CPU 1,8Ghz, 2Gb RAM, Ubuntu) и загрузка CPU никогда не привышает 40%
Я не говорил что «нагрузка невыносима», я говорил что она ощутимо выше при очень большом количестве запросов (по сравнение с обычным HTTP).
Ради эксперимента проведите benchmark на static file нулевого размера — посмотрите на RPS с HTTPS и без него (без session cache и keepalive), и посмотрите на загрузку процессора с и без него.
И наконец, не стоит забывать про overhead — если у нас есть сервис с которого мы забираем каждую минуту по 100 байт, на каждый запрос будет приходится несколько килобайт траффика в случае HTTPS — вроде как немного, а если это мобильный клиент с тарификацией по килобайтам (да, есть ещё такое, и ещё много лет будет)?
Подводя итоги — HTTPS/TLS это не «ужас-ужас», это нужно и полезно — но не стоит всё же лепить его бездумно куда попало, нужно учитывать массу факторов. К примеру, в моей домашней сети, гарантированно недоступной извне, имеющей с два десятка IoT и других устройств (не подключенных к облаку) и всего двух пользователей, совсем не нужно шифрование.
Letsencrypt, будучи бесплатным сервисом, не даёт никаких гарантий — и (теоретически) может превратиться в тыкву в любой момент.
Да в общем-то так может сделать и платный сервис. Цена, большая чем 0 — никоим образом вам ничего не гарантирует сама по себе.
Цена, большая чем 0 — никоим образом вам ничего не гарантирует сама по себе.
Согласен, но обычно те кто берет за что-то деньги имеют T&C в которых хоть что-то гарантируют, к тому же они имеют источник средств для поддержания сервиса.
Основная разница в том что платящий за сервис вправе требовать оказания услуг, в то время как «халявщик» вообще не имеет прав. На платный сервис можно подать в суд, с него можно стребовать компенсацию etc — с бесплатным этот номер не пройдёт.
к тому же они имеют источник средств для поддержания сервиса.
взгляните на список спонсоров летсэнкрипта на главной, я думаю денег на саппорт они найдут легко
взгляните на список спонсоров летсэнкрипта на главной, я думаю денег на саппорт они найдут легко
Спонсоры приходят и уходят, а затраты растут. Вы можете гарантировать что текущая ситуация не изменится ещё лет 5-10? А кто-то из спонсоров может гарантировать? Соберется совет акционеров Cisco и скажет «хватит, только бабло тратим» — и всё, нет крупного спонсора.
А теперь представьте что все (без исключения) станут пользоваться Letsencrypt, включая все IoT — представляете как возрастут их затраты на инфраструктуру?
Ещё раз повторю — нужно не верить в то что так будет всегда, нужен commitment — т.е. компании должны вместе собраться и подписать договор в духе — «да, мы гарантируем бесплатные сертификаты всем желающим до своего последнего вздоха под страхом утопления» — вот это будет другое дело, а сейчас они просто спонсоры, без обязательств, захотел — заплатил, не захотел — ушел.
да, мы гарантируем бесплатные сертификаты всем желающим до своего последнего вздоха под страхом утопления
такое вам никто никогда не гарантирует, даже если вы им будете заносить по миллиону в месяц. Это утопия, будет круто если так будет, но так не будет.
Вы можете гарантировать что текущая ситуация не изменится ещё лет 5-10?
Платный сервис вам так же не будет гарантировать работу «до гроба» только лиш потому что вы ему 10 баксов закинули. Да и способов монетизации бесплатных сервисов вагон (вон у гугла все кругом бесплатное для пользователей, но что-то все никак не свернется).
Платный сервис вам так же не будет гарантировать работу «до гроба» только лиш потому что вы ему 10 баксов закинули.
Скажите, у вас будет больше уверенности в сервисе который берет деньги и существует лет 20 или в сервисе который денег не берет и существует 5 лет?
Ясный пень, никто никому ничего никогда не гарантирует на 100%, но я предпочту платить $$ кому-то в обмен на контрактные обязательства, чем не платить и в любой момент потерять сервис — не потому что он исчезнет, а потому что я им не просто не понравился, или какой-то админ не разобрался и решил что я враг народа.
Простой пример — бесплатные почтовые ящики на гугле, mail.ru и хз где ещё — его могут просто банально прикрыть потому что кто-то пожаловался на спам (даже если его не было). Или какие-то письма на него будут отшивать как спам без возможности это настроить (так делает gmail), и никакие обращения в службу поддержки ничего не изменят (если они вообще ответят) — потому что у меня нет прав, никаких (а у них есть). Если ящик не будет работать сутки или неделю — я не получу компенсации, у них нет SLA. Если у меня будет проблема — нет гарантированного времени рекации службы поддержки и т.д.
У Letsencrypt есть такой пункт в соглашении (3.3):
ISRG may, in its sole discretion, refuse to grant Your request for a Let’s Encrypt Certificate, including for any lawful reason stated or not stated in this Agreement.
Это значит буквально «верчу как хочу» — в отличие от любого платного CA, которые чётко прописывают в каких случаях это возможно.
Да, если мне нужно что-то что жизненно важное для сервиса (типа сертификата) — я хочу иметь гарантии прописанные в T&C и чётко прописанные условия при которых в услугах могут быть отказано, и я хочу защиты этого контракта со стороны закона. Letsenctypt этого не предоставляет — но, с другой стороны, я и не зависим от него, хотя и пользуюсь для удобства. Не дадут сертификат — это будет неприятно, но я переживу, а вот какой-нибудь Facebook или банк потеряют очень много денег и репутацию.
А теперь основная проблема — нас заставляют использовать «правильный» (с зелеными сертификатами) HTTPS, но при этом не хотят дать гарантий что это всегда можно будет делать без дополнительных затрат — это вас не беспокоит?
Как бы вы не верили в спонсоров Letsencrypt — если с ними что-то случится когда HTTP уже не останется — то многие сразу побегут покупать сертификаты за любые деньги у платных CA, иначе всё — нет продаж, посетителей и прочих плюшек, это будет просто хаос.
Было бы более логично брать дополнительную плату за каждый зарегистрированный домен и вкладывать это в сервис типа Letsencrypt — тогда гарантированно у них будут средства на развитие инфраструктуры по мере её роста, независимо от спонсоров. Можно было бы даже сделать тендер — и любая адекватная фирма могла бы предложить свои услуги для выполнения этих обязательств.
В конце концов, если регистратор имен становится банкротом, домены-то никуда не деваются — предусмотрены процедуры, передача управления и данных другому регистратору (всё бесплатно для владельцев доменов) — почему с сертификатами должно быть иначе?
ISRG may, in its sole discretion, refuse to grant Your request for a Let’s Encrypt Certificate, including for any lawful reason stated or not stated in this Agreement.
платный может прописать у себя ровно то же самое, вам решать — соглашаться или нет.
Скажите, у вас будет больше уверенности в сервисе который берет деньги и существует лет 20 или в сервисе который денег не берет и существует 5 лет?
если вопрос лишь в том сколько времени существует сервис, то LE остается только подождать — не так и сложно
И лично мне «платность» не добавляет уверенности ни в чем. Мой личный пример — xbox live. Не очень давно я там поменял геймертаг, там это делается за деньги (примерно 10 баксов, мало им что я плачу за подписку и игры они еще и за смену ника деньги дерут), так вот где-то через недельку, какому-то типу видимо этот геймертаг не понравился и он кинул жалобу. мне вынесли предупреждение и сменили ник на рандомный, на мой вопрос: ало, я же заплатил и ник прошел валидацию у вас на сайте, верните хотя бы деньги! мне сказали — нифига, у нас такие правила, если хочешь поменять — плати еще раз. вот и все гарантии платности. Да, разумеется, я мог бы не соглашаться с T&C на этапе регистрации и не пользоваться сервисом, теоретически, но в реале — я не имею альтернатив если я хочу играть в xbox. Так что я вынужден и платить и при этом так же не имею никаких прав.
2. Да всё клёво вот вам на халяву дают, берите радуйтесь. Но почему то не хочется думать а что будет если завтра перестанут давать халяву?
AES NI не помогает при установке соединения, т.е. на rps он не влияет.
Насчёт самоподписанных сертификатов, gpg же как то работает без абсолютно доверенных серверов. Если мне действительно нужно подтвердить сертификат, то можно просто можно спросить сервера которым Вы лично доверяете, какой хеш ключа у данного сервера. Маловероятно, что и Вы и он окажетесь под одним MITM.
То, что HTTP/2 и WebSocket не работают без TLS это тоже «заслуга» гугла из за его стремления навязать HTTPS повсюду. Из за этого на ровном месте создаются проблемы с созданием отладочного сервера, на своей машине за парой натов. С HTTP сервер разворачивается парой кликов, с HTTPS придётся создавать собственную инфраструктуру сертификации, что даже не близко к паре кликов. А с кешем SSL-сессий есть проблема, в мире довольно сильно распространены CDN и при каждом новом соединении там будет новый сервер, даже если IP-адрес один и тот же и сессионные ключи они обычно не делят между собой.
Ну и напоследок скажу, мой процессор Intel E5700 ничего не знает об AES, зажрались владельцы топовых Core i7.
Но в переходе на HTTPS есть другая проблема, которую почему-то редко упоминают. Сейчас, чтобы создать страницу, мне не надо ничьего разрешения, кроме наличия самого интернета. Хоститься можно дома, а DNS-ов бесплатных полно. Для простейшей странички с полезными людям текстовыми архивами вполне достаточно.
Переход же на HTTPS — это уже интернет по паспорту. Ибо Ктото Гдетович должен будет этот сертификат, то есть «паспорт», мне выдать, чтобы страница работала. Да, сегодня выдача очень легка и проста (тот же LetsEncrypt). Но само введение этого обязательного элемента в процесс создания любой страницы — это закладка барьера потенциально произвольной высоты в будущем.
Интернет, вообще, по всему миру становится всё менее свободным. Чувствую, ещё придётся внукам рассказывать легенды про IT-фронтир рубежа 1990/2000-х. Сейчас такое осталось только в децентрализованных сетях, типа ZeroNet. И, вопрос, останется ли оно таким хотя бы при внуках :-/
Многие это не понимают, потому что вода в котле греется очень медленно. А многим просто сравнивать не с чем. И этот тред тому подтверждение...
Да. И вспоминается недавняя история когда CA принудили по суду отозвать сертификат SciHub'а. На минуточку — процедура отзыва же предусмотрена для компроментации сертификата а НЕ для других целей.
Принципиально это не отличается от блокировки доменного имени — в случае чего, регистратор имен может устроить не менее веселую жизнь по запросу властей, и наличие сертификата тут не поможет.
Стать CA — сложнее. При этом чтобы создать CA большие проблемы — достаточно надавить на одного из производителей браузеров.
Существует страновые домены и если у меня на сайте в .ru будет контент, который не понравится американскому суду но к которому у российского суда претензий нет… американский суд пойдет лесом.
С CA так нельзя, сейчас нет CA 'только для .ru',(насколько я помню — технически сделать чтобы этот CA мог только для .ru выписывать — тоже нельзя), попытка же сделать Российский CA сразу приведет к скандалу в том числе и тут на тему того что ФСБ принудит его к выдаче сертификатов для прослушки всего. И этим обвинениям — противопоставить нечего будет.
Сейчас, чтобы создать страницу, мне не надо ничьего разрешения, кроме наличия самого интернета. Хоститься можно дома, а DNS-ов бесплатных полно. Для простейшей странички с полезными людям текстовыми архивами вполне достаточно.
Если очень хочется, то создаётся самоподписанный сертификат. Причём как я понимаю, опасность MitM будет только при первом подключении, а потом браузер запоминает сертификат и имеется такая же защита, как при «правильном» HTTPS.
Теоретически это решается выдачей вместо ошибки простого вопроса типа «Опечаток такой-то, доверять? Да/Нет» (или можно даже из отпечатка сгенерировать няшную картинку, чтоб совсем юзерфрендли) — так же, как делают в SSH, PGP, OMEMO и прочих. Но, похоже, браузеры слишком любят центры сертификации и делать подобное не будут( Ну и никудышная грамотность населения мешает ещё
И да, хром станет новой монополией и это нужно учитывать.
В условиях крайне, крайне дрянной связи, в которых я сижу едва ли не пол-дня, мой телефон "прыгает" по базовым станциям до нескольких раз в минуту. Иногда связь пропадает на десятки секунд вообще.
Сайты на HTTPS очень болезненно реагируют на подобное поведение. Или рушится сеанс, или сервер даётся отлуп, или выпадают совсем странные ошибки типа "SSL INTERFERENCE". Сайты на HTTP же вполне спокойно открываются и догружаются.
И как же невероятно бесит, когда я по 10 минут обновляю страницу, не в силах зайти на сайт нужного справочника или прочитать искомую статью только потому, что кто-то решил, что доступ к сайту будет только через HTTPS!
Прикол в том, что договориться с этой «третьей стороной» или «подписать при этом subordinate CA у рутов» намного, НАМНОГО сложнее, чем просто раздать поддельный вайфай в макдональдсе. Поэтому при наличии HTTPS меня будут прослушивать только какие-нибудь спецслужбы. А без HTTPS меня ещё и будет прослушивать какой-нибудь анонимный вася пупкин из соседнего подъезда. Поэтому HTTPS нужен. Не для защиты от спецслужб, а для защиты от васей пупкиных. А также от админов провайдера, у которых руки зачешутся трафик послушать.
Нужны только деньги.
Которых у васи пупкина не хватит. Так что HTTPS всё-таки добавляет безопасности :)
Если нужна анонимность, для этого есть действительно хорошие инструменты
Все они работают на тех же самых алгоритмах, на которых работает HTTPS
Все они работают на тех же самых алгоритмах, на которых работает HTTPS
Да ну? Вот это новости!!! То есть, в Вашем понимании, все инструменты базируются на TLS? Извините, но Вы в корне неправы.
всё-таки добавляет безопасности
Я к чему разговор — то веду… HTTPS всего лишь создает иллюзию безопасности. Не более. И это вводит в заблуждение других, в результате чего страдает безопасность. А кто-нибудь говорит людям, что такое HTTPS? Что такое TLS? Нет, не говорит.
(Если я что-то проспал и появилось что-то более крутое, чем RSA и AES — просветите, пожалуйста.)
что-то более крутое
А я и не говорил, эти алгоритмы чем-то плохи. Я сказал про HTTPS. Что то лучше HTTPS? Да пожалуйста. Обфускация трафика. Использование end-to-end. Больше ничего и не нужно.
и я не хочу принимать эту глупость как довод
Что Вы назвали глупостью?
Если технология может защитить от 99% проблем
На чем основано данное утверждение?
Надо кроме знаний иметь и возможность
Не думайте, что у Вашего Интернет-провайдера недостаточно знаний, возможностей и денег, чтобы организовать такой MITM, о котором Вы и не узнаете. Речь именно о провайдерах, а не о Васях, Петях и прочих «хакерятах»
Может в TLS дыра лежит,
Конечно лежит. Это третья сторона. И это самая большая дыра в TLS.
Третья сторона не означает, что не безопасно.
Всё понятно.
Я с провайдером разберусь
Да ну? Каким образом? Предотвратите MITM, который даже не увидите?
Я уверен, что провайдер последний человек, который будет этим заниматься.
Уверяю, что скоро это будет первый человек. Про закон Яровой слышали? А Вы подумайте, зачем провайдерам хранить кучу нечитаемых данных? Конечно же, незачем.
А без ТЛС у меня таких точек будет больше одной.
Так используйте, кто не дает?
Что ТЛС небезопасен априори
Еще раз. Что может быть безопасного в технологии, которая ломается напрочь прозрачным прокси с подменой сертификатов? Это самый большой недостаток TLS.
Я написал вроде четко «ЕСЛИ». Я предположил.
Ок. HTTPS не только не решает проблемы, он еще их добавляет.
И еще раз. Вася пупкин не сможет получить красивый сертификат.
И нет ничего абсолютно безопасного на практике, кстати. (Есть теоретически безопасные одноразовые блокноты, но на практике их особо не попользуешь)
Обфускация трафика.
Ни от чего не поможет.
Использование end-to-end.
HTTPS — это и есть один из вариантов end-to-end! Один end — клиент, другой end — сервер, между ними всё зашифровано доверенным сертификатом. Доверенным, потому что у васи пупкина не хватит денег, чтобы подкупить центр сертификации и получить поддельный красивый сертификат.
Если вы боитесь, что вася пупкин слишком богат, и не хотите доверять центрам сертификации — удаляйте всё предустановленное и добавляйте только те сертификаты, которым доверяете лично вы. Во всех основных браузерах такая возможность присутствует.
Больше ничего и не нужно.
Да, HTTPS вполне достаточно :)
Это и есть один из вариантов end-to-end
в каком он, извините, месте end-to-end'ом стал, если принимает участие третья сторона?
Обфускация трафика ни от чего не поможет
Да ну? Расшифруйте OBFS4.
потому что у васи пупкина не хватит денег
Да что Вы своим Васей? Он уже икотой заболел (юмор). А если серьезно, что да, при чем здесь Василий? Беспокоиться надо совсем не о Васе из соседнего подъезда, а о том, что Ваши личные данные будут складироваться сами знаете, где. А уж на это, я Вас уверяю, у нужных компаний достаточно денег.
Да, HTTPS вполне достаточно :)
Я понял Вас. Предлагаю закончить диалог, раз Вам HTTPS кажется end-to-end и безопасным.
в каком он, извините, месте end-to-end'ом стал, если принимает участие третья сторона?
Никто вас не заставляет пользоваться центрами сертификации. Встречаетесь с админом сайта, получаете от него сертификат, добавляете его в доверенные — всё, полноценный end-to-end на базе HTTPS готов.
Беспокоиться надо совсем не о Васе из соседнего подъезда
«Сам знаю где» не будет воровать у меня деньги из киви-кошелька (у «них» есть способы хитрее вроде манипуляций с пенсионным возрастом). Если предположить, что «мне нечего скрывать»©, то на «сам знаю где» мне плевать. А вот вася будет очень рад перехватить логин и пароль от моего киви-кошелька. Ну или написать о том, как я очень люблю чью-нибудь маму, на стене ВК, перехватив куки. (Между прочим в мой ВК и правда писали, когда я по неосторожности попользовал публичный Wi-Fi без HTTPS. А могли бы и все личные сообщения по-тихому слить, чтобы я не заметил.) (Впрочем, наверняка и так слили, чего это я)
И вообще в RSA и AES наверняка есть уязвимости, известные американским спецслужбам. А в ГОСТовском шифровании наверняка есть уязвимости, известные российским спецслужбам. А чтобы изобрести своё шифрование, нужно быть гением. Так что АБСОЛЮТНО ЛЮБОЕ шифрование небезопасно. Надевайте шапочку из фольги :)
(Про OBFS4 я ещё матчасть не изучил)
полноценный end-to-end
Вы меня рассмешили. Какой это еще end-to-end? Вы хотя бы прочитайте, что это такое, а потом делайте утверждение, что это полноценный end-to-end (который ваш провайдер одной левой поломает). Не вводите в заблуждение других. HTTPS (TLS) — это ни разу не end-to-end и никогда им не был и не будет.
И поверьте. Даже HTTPS Вас не спасет от того же Васи Пупкина. Что спасет? Обфускация. Это спасёт. Но поведение в паблик вайфаях требует бОльшего. Это уже другая история.
Про OBFS4 я ещё матчасть не изучил
советую как можно скорее заняться этим вопросом.
который ваш провайдер одной левой поломает
Как именно, если отказаться от центров сертификации? Раз вы такой умный, расскажите нам всем, не стесняйтесь. (Про OBFS4 тоже было бы неплохо, если бы вы рассказали. Уверен, я на хабре не один такой, который не знает матчасть.)
Про OBFS4
А зачем мне перепечатывать то, что уже итак в Гугле ищется? Начинайте с Tor.
если отказаться от центров сертификации
А можно подробнее, аж интересно стало :)
Как именно
Если коротко, то
ssl_bump bump all
ssl_bump bump all
Ничего не понял. В документации про bump сказано, что оно «establishes a secure connection with the client». Но чтобы установить соединение с клиентом, нужно передать сертификат, которому клиент доверяет. Но если клиент не доверяет центрам сертификации, то откуда у этого вашего bump'а возьмётся сертификат, которому клиент станет доверять?
Да господи, Вы читаете то, что я выше написал? Рассматриваемый мной клиент-параноик не доверяет рутам!
Удалите из вашего браузера все рутовые сертификаты, и вы получите end-to-end HTTPS. Как в таком случае подписанный у рутов сертификат поможет провайдеру?
И вы по-прежнему увиливаете от ответов на вопросы, как именно провайдер перехватит и как именно ломается безопасность без центров сертификации. Видимо, ветку действительно стоит закончить, раз вы не умеете конструктивно беседовать.
И вы по-прежнему увиливаете от ответо
Вам еще раз скинуть строку из конфига Squid?)
как именно провайдер перехватит и как именно ломается безопасность
Заворачивается 443 порт на порт Squid. Всё. Весь трафик на этом порту летит через прозрачный прокси. Так и ломается.
Вам еще раз скинуть строку из конфига Squid?)
Эта строчка требует владеть сертификатом, которому клиент будет доверять. Если клиент не доверяет рутам, то как в таком случае подписанный у рутов сертификат поможет провайдеру?
трафик на этом порту летит через прозрачный прокси
И браузер отклоняет все соединения через него, потому что не доверяет подсунутому сертификату. Безопасность не сломана.
Будем продолжать демагогию и хождение по кругу до бесконечности?
Ну вроде всё хорошо, рутовым сертификатам не доверяю, безопасность не нарушена.
Вы хотя бы знаете суть работы ssl bump?Бремя доказательства лежит на утверждающем. Раз вы говорите, что он позволяет обойти безопасность HTTPS — расскажите, как, объясните его суть.
Выше я показал скриншот, как без доверия рутам браузер отказывается брать какой попало сертификат и безопасность не нарушается. Ваш ход.
И Вы проиграли! Внимательно прочитайте то, что написал мне мой браузер:
The certificate is not trusted because the issuer certificate is unknown.
Перевожу на кухонно-бытовой: браузер отказался открывать сайт, потому что он не знает, кто выпустил сертификат, и не доверяет ему.
Произошло ровно то, что и должно было произойти. Браузер не доверяет рутам.
Безопасность HTTPS по-прежнему не нарушена.
Как вы соединитесь с Гуглом? А верно, никак, пока не добавите его рут в доверенные. А раз добавите его рут, то и провайдер спокойненько произведет MITM. Так что, проиграли Вы!
Безопасность есть, потому что соединения нет и никакие личные данные провайдер не смог подслушать из-за отсутствия соединения.
Как вы соединитесь с Гуглом?
Если делать по всем канонам безопасности — схожу к администратору гугла, получу сертификат с открытым ключом лично из его рук и добавлю его в доверенные. (Не в исключения, в которые добавить невозможно, как написано на скриншоте, а сразу в доверенные.) Это будет настоящее честное end-to-end HTTPS шифрование, в которое провайдер никак не сможет вмешаться.
Как вы предлагаете устанавливать end-to-end шифрование при соединении с гуглом? Если не получать открытый ключ лично из рук админа гугла, то как? Расскажите во всех подробностях.
Вы не указали, что исключение браузер добавить не сможет!
В исключения добавлять не надо. Надо добавлять в доверенные. Это разные вещи, не путайте.
настоящее честное end-to-end HTTPS
Сходите в Википедию, прочитайте, что такое end-to-end.
хожу к администратору гугла, получу сертификат с открытым ключом лично из его рук и добавлю его в доверенные
Это бред, мсье
Как вы предлагаете устанавливать end-to-end шифрование
Речь не о Гугле, а обо всём. Использовать тот же ssh. Вот там наичистейший end-to-end. Никто не вмешается в трафик. Никак. А если вдруг что-то случится, то вы не соединитесь, так как отпечаток будет другим. Всё.
Обфусцируйте свой трафик.
Допустим, я (клиент) обфусцирую. Но на другом конце кто-то (сервер) кто-то должен его, эм, деобфусцировать, чтобы прочитать мой запрос. Пожалуйста, объясните на пальцах, как мне убедиться, что этот кто-то, кто деобфусцировал мой запрос — на самом деле гугл, а не кто-то выдающий себя за гугл?
Это бред, мсье
Ваше утверждение про бред — это бред, мсье. Обмен ключами при личной встрече — самый надёжный способ обеспечения безопасности. Именно с этого предлагается начинать, например, в PGP.
Сходите в Википедию, прочитайте, что такое end-to-end.
Вы тоже сходите и убедитесь, что TLS без рутов подходит под определение end-to-end.
TLS без рутов
Это уже не TLS, так как TLS предусматривает третью сторону априори.
Обмен ключами при личной встрече — самый надёжный способ обеспечения безопасности
я уже написал про SSH.
кто деобфусцировал мой запрос
obfs4 — вполне себе хорошая идея для этого. Если вам важна приватность, используйте Tor+obfs4. Всё. Прочитайте подробнее об этих вещах, всё станет понятно.
Вы тоже сходите и убедитесь, что TLS без рутов подходит под определение end-to-end
ничего похожего в TLS с end-to-end НЕТ. Абсолютно. Это совершенно разные вещи.
Это уже не TLS, так как TLS предусматривает третью сторону априори.
Но на практике я вот взял и отказался от третьей стороны в Firefox. Осталось лишь добавить сертификат, которому я доверяю, в доверенные, и можно использовать TLS без третьей стороны. Что я делаю не так?
SSH
SSH при первом подключении к серверу не пускает вас, а спрашивает «Вы довереяете этому ключу? y/n» При согласии ключ сервера добавляется в доверенные. При несогласии никакого соединения не устанавливается. Прямо как с гуглом в моём Firefox! Всё абсолютно то же самое, что и в TLS без третьей стороны.
Прочитайте подробнее об этих вещах, всё станет понятно.
Вы так старательно увиливаете от ответа, что создаётся впечатление, будто вы сами не понимаете, как работает obfs4.
ничего похожего в TLS с end-to-end НЕТ. Абсолютно. Это совершенно разные вещи.
Выше я продемонстрировал, что TLS без третьей стороны удивительно похож на SSH.
Вы так старательно увиливаете от ответа, что создаётся впечатление, будто вы сами не понимаете, как работает obfs4.
Вас в Гугле забанили? Ах да, Вы же отказались от рут… Ах да, я имею прекрасное представление о технологии обфускации, о Tor.
Выше я продемонстрировал, что TLS без третьей стороны удивительно похож на SSH
Чем!? END-to-END предусматривает сравнение своих отпечатков открытых ключей. При end-to-end ВСЯ информация пользователя недоступна даже серверам, передающим данные. Где Вы увидели это в TLS?
Прямо как с гуглом в моём Firefox
Кто Вам даст сертификат Гугла? Вы предлагаете палить из базуки по блошкам. Не так обеспечивается безопасность и приватность, как Вы себе представляете, о чем я уже выше сказал. А вот теперь я предлагаю закончить диалог. Окончательно. Вы в корне не понимаете, как работает end-to-end и как работает TLS, хотя даже в Википедии об этом исчерпывающе написано. Всего доброго.
Ах да, я имею прекрасное представление о технологии обфускации, о Tor.
Расскажите, не стесняйтесь, а то я забанил гугл)
Кто Вам даст сертификат Гугла?
А кто вам даёт ключ SSH-сервера при первом подключении?
Где Вы увидели это в TLS?
Когда я получу сертификат гугла из рук админа гугла, я прочитаю его отпечаток и буду сравнивать при подключении, очевидно.
Вы в корне не понимаете, как работает end-to-end и как работает TLS, и почему-то считаете, что TLS и SSH работают по-разному, хотя даже в Википедии об этом исчерпывающе написано.
А кто вам даёт ключ SSH-сервера при первом подключении?
А Вы пробовали подключаться-то хоть разок? Видимо нет, раз такие вопросы.
Расскажите, не стесняйтесь, а то я забанил гугл)
Толсто, сэр.
Когда я получу сертификат гугла из рук админа гугла
Вперед. Жду подробный отчет с фотографиями.
Вы в корне не понимаете, как работает end-to-end и как работает TLS, и почему-то считаете, что TLS и SSH работают по-разному
Куда уж мне, действительно.
До свидания.
А Вы пробовали подключаться-то хоть разок?
А вы? SSH-клиент показывает вам отпечаток при первом подключении к серверу. Как вы проверяете, что отпечаток правильный?
Вперед.
Мне это не нужно, я доверяю рутам, в отличие от вас. А вот как вы собираетесь доверять гуглу с этим вашим obfs4, вы так и не рассказали, как будто не понимаете, как он работает, и пытаетесь скрыть это отправками в гугл.
До свидания.
До свидания.
я доверяю рутам
Вы троллить не умеете. Пока Вы там доверяете рутам, провайдер у этих рутов подпишет сертификат и будет производить MITM, это скоро будет, поверьте.
Мне это не нужно
Ну вот и отлично)
как будто не понимаете, как он работает
Вот понимаете, я могу рассказать о том, чего явно не написано в Интернете. А рассказывать о такой вещи, как обфускация — потратьте своё личное время для своих личных целей и читайте.
Вопрос про проверку отпечатка SSH тактично проигнорировали. И опять гуглить отправили, максируя собственное незнание. Что ж, до свидания.
Как вы проверяете, что отпечаток правильный?
для каких целей используется SSH в плане безопасности и приватности? Вы поднимаете\покупаете в определенном доверенном месте сервер с SSH, который будет Вас маскировать. Вам ЛИЧНО дадут отпечаток для проверки.
максируя собственное незнание
Толсто. Очень.
я доверяю рутам, в отличие от вас
Я где-то выше сказал, что не доверяю рутам? Это Вы уже потом покрылись и доказывали тут, что вы убираете доверие к рут сертификатам и получаете супер шифрование. Я ни слова о недоверии рутам не сказал. Я лишь сказал, что TLS предусматривает третью сторону, и это проблема, так как провайдер легко за деньги подпишет свой сертификат у рута и произведет MITM.
Не надо переиначивать все и переворачивать!
Вам ЛИЧНО дадут отпечаток для проверки.
И чем это принципиально отличается от получения HTTPS-сертификата из рук админа гугла? (Кроме того, что встретиться с админом гугла немножко труднее, конечно, но мы ведём речь о технической стороне вопроса.)
TLS предусматривает третью сторону
Доверять которой вас никто не заставляет.
провайдер легко за деньги подпишет свой сертификат у рута
Я всю ветку игнорирую, что у провайдера не найдётся столько денег, чтоб рута подкупить. Если мы говорим про техническую возможность — идите берите сертификат из рук админа гугла и тем самым защитите себя от прослушки провайдером. Если мы говорим про реальность — ну не сможет провайдер этого сделать, денег не хватит. (Ну или продемонстрируйте обратное на практике.)
Толсто. Очень.
Но всё же уклоняться от конструктивного ответа вы продолжаете.
И чем это принципиально отличается от получения HTTPS-сертификата из рук админа гугла?
Я Вам повторяю, что TLS и end-to-end — это разные вещи в корне! Изучите матчасть, прежде чем делать заявление, что TLS без доверия к рутам = end-to-end.
у провайдера не найдётся столько денег, чтоб рута подкупить
Да ну!? На реализацию пакета Яровой находят. А оно стоит намного дороже сертификата.
идите берите сертификат из рук админа гугла и тем самым защитите себя от прослушки провайдером
Не смешите, пожалуйста.
Я Вам повторяю, что TLS и end-to-end — это разные вещи в корне!
Я вам повторяю, что TLS и end-to-end — это очень похожие вещи в корне! Что в TLS, что в SSH вы можете получить отпечаток на руки и сравнивать его при подключении. Что в TLS, что в SSH используется RSA для ключей. И ещё в PGP всё то же самое, кстати.
А оно стоит намного дороже сертификата.
Намного дороже поддельного сертификата, выпущенного в обход всех правил? Озвучьте тогда точную стоимость поддельного сертификата — видимо, вы её знаете, раз пишете такие утверждения, нам всем на хабре это будет очень интересно. (Может, вы ещё и сами выпуском поддельных сертификатов занимаетесь и случайно проболтались? Тогда это всё объясняет!)
Не смешите, пожалуйста.
То же самое в SSH и PGP вас почему-то не смешит.
Я вам повторяю, что TLS и end-to-end — это очень похожие вещи в корне!
Эх. Ну что ж, раз Вы не знаете матчасть, мне очень жаль. Любите факты? Да пожалуйста.
end-to-end:
Шифрование происходит на конечных устройствах, данные остаются зашифрованными, пока не будут доставлены к месту назначения. Ключи шифрования известны только двум сторонам. Всё. Никому более. Никогда. Кроме того, обе стороны сравнивают свои отпечатки открытых ключей.
tls: нет никаких «своих отпечатков открытых ключей» здесь нет. Вся безопасность сводится лишь к проверке валидности сертификата у root'a. Вы предлагаете отказаться от корневых центров? Вы ломаете эту Вашу безопасность. Без корневых центров вообще никак не проверить подлинность сертификатов. Брать у админа ресурса? Вы шутите? Конечно же шутите. Ведь никто Вам не даст сертификат. Кому это надо? Только Вам, и никому более, никто о Вас и думать не будет. А если добавляете корневые центры, то это ничего не добавит, кроме иллюзии безопасности. Никто не отменял ssl_bump и sslstrip. В end-to-end в принципе невозможна такая атака. Никак.
Озвучьте тогда точную стоимость
А Вы сами спросите у центра сертификации. С чего мне рассказывать Вам подробности получения сертификата?
Может, вы ещё и сами выпуском поддельных сертификатов занимаетесь
Вы меня раскрыли. Какой ужас.
То же самое в SSH и PGP вас почему-то не смешит.
Потому что принцип действия SSH совсем отличается от HTTPS. В корне. Поэтому меня это нисколько не смущает.
Шифрование происходит на конечных устройствах
Как в HTTPS.
данные остаются зашифрованными, пока не будут доставлены к месту назначения
Как в HTTPS.
Ключи шифрования известны только двум сторонам. Всё. Никому более. Никогда.
Как и в HTTPS. Центрам сертификации известны только открытые ключи, закрытых они не знают.
Кроме того, обе стороны сравнивают свои отпечатки открытых ключей.
Браузр обязательно занимается этим для каждого HTTPS-соединении, а если что-то не так, то сообщает о проблеме пользователю — скриншот Firefox я вам показывал.
tls: нет никаких «своих отпечатков открытых ключей» здесь нет.
Неправда. Загляните хотя бы разок в свойства сертификата в любом браузере.
Вся безопасность сводится лишь к проверке валидности сертификата у root'a.
Неправда. Вы можете оказаться от root'а и добавлять каждый раз сертификат в доверенные самостоятельно, точно как в SSH.
Ведь никто Вам не даст сертификат.
Неправда. Все спокойно пересылают сертификаты по интернету, и ничто не мешает мне точно так же попросить сертификат у админа сайта по сторонним каналам связи (например, при личной встрече) — главное, чтобы он согласился. (Согласится ли админ гугла — это не относится к технической стороне вопроса.)
А если добавляете корневые центры, то это ничего не добавит, кроме иллюзии безопасности.
Неправда. Поддельный сертификат будет стоить баснословных денег, которых ни у кого не найдётся, поэтому корневые центры обеспечивают безопасность.
В end-to-end в принципе невозможна такая атака. Никак.
Неправда. Достаточно любым образом заставить пользователя доверять ключу. С учётом того, что личные встречи всем организовывать лень — это очень легко, нужно всего лишь немножко социальной инженерии.
А Вы сами спросите у центра сертификации.
Боюсь, что он мне ответит, что выпуском поддельных сертификатов он не занимается, потому что это удар по репутации.
Потому что принцип действия SSH совсем отличается от HTTPS. В корне.
Как я вам наглядно не раз продемонстрировал в моих комментариях, HTTPS приницпиально ничем не отличается от SSH, кроме существования центров сертификации. Перечитайте их ещё раз и не поленитесь изучить матчасть хотя бы на википедии.
И ещё раз. Даже если Вы уберёте корневые центры из доверенных, да хоть что сделаете, это не мешает ни разу производить mitm. Покупка сертификата провайдером — это лишь для создания иллюзии Вашей безопасности. Провайдер может этого не делать, а дать Вам сертификат для импорта в браузер. Вы можете отказаться. Но при открытии ресурса Вы все равно не обеспечите безопасность с помощью https, так как bump будет произведён в любом случае, так как 443 порт завернут на прокси. Достаточный довод? Или мне нужно процитировать пример из той же squid wiki?
это не мешает ни разу производить mitm
И ещё раз. Как провайдер проведёт mitm без доверия купленному сертификату?
дать Вам сертификат для импорта в браузер. Вы можете отказаться.
Да, естественно я откажусь.
Но при открытии ресурса Вы все равно не обеспечите безопасность с помощью https, так как bump будет произведён в любом случае
Браузер прервёт соединение, потому что не доверяет сертификату провайдера. Безопасность будет обеспечена путём недоверия сертификату и обрыва соединения.
Достаточный довод? Или мне нужно процитировать пример из той же squid wiki?
Нет.
Давайте вы подтвердите свои слова на практике? Получите валидный сертификат на мой домен andreymal.org и поднимите веб-сервер с ним. Дайте мне IP-адрес сервера, я внесу его в файл hosts (тем самым имитировав вмешательство провайдера в трафик). Перед подключением я удалю все корневые сертификаты из моего браузера. Если браузер успешно подключится к вашему серверу и автоматически признает ваш сертификат безопасным, то я признаю свою неправоту, компенсирую вам расходы на покупку сертификата (если покажете, что они были) и ещё на сотню литров пива сверху докину.
И ещё раз. Как провайдер проведёт mitm без доверия купленному сертификату?
SSL Bump будет произведен в любом случае, как только Вы откроете ресурс, независимо от того, есть ли у Вас сертификат в списке доверенных или нет. Просто, если сертификат провайдером не куплен, а самоподписан, у вас «значок не зелененький» будет, пока не добавите провайдеровский сертификат в доверенные.
Браузер прервёт соединение, потому что не доверяет сертификату провайдера
Ну а Вам-то надо попасть на ресурс!? В чем заключается безопасность? Нет соединения-нет проблем? Прикольная у Вас логика.
автоматически признает ваш сертификат безопасным
Вы читаете, что я пишу? Мне кажется нет. При чем здесь автоматическое признание? Я что, Ваш провайдер? Уже сказал, что провайдер может купить сертификат, может дать Вам для внесения в список доверенных, и Вы можете отказаться. Но Вам нужно попасть на ресурс, не так ли? И как Вы туда попадете с помощью Вашего суперзащищенного HTTPS? Я уже устал повторять, я говорю о том, что HTTPS небезопасен, так как его можно расшифровать с помощью SSL Bump. Где здесь безопасность? А плюс к этому, третья сторона в протоколе. Это не безопасность вовсе.
пока не добавите провайдеровский сертификат в доверенные
Никогда не добавлю.
Ну а Вам-то надо попасть на ресурс!?
На небезопасный — не надо.
его можно расшифровать с помощью SSL Bump.
Хорошо, давайте по-другому. Поставьте прокси с этим вашим squid и ssl bump между мной и моим сервером. Я точно так же внесу его в hosts или в настройки браузера и попользуюсь своим сайтом (root'ы удалять не стану). Если браузер не выдаст ошибку безопасности и если вы мне покажете расшифрованный трафик, перехваченный вами — я также признаю свою неправоту и кину вам на пиво.
На небезопасный — не надо.
Ресурс — безопасный. Небезопасный протокол! Вы откажетесь от всего Интернета?
Если браузер не выдаст ошибку безопасности
Я не сказал, что он не выдаст ее! Вы либо добавляете в список доверенных мой сертификат, либо я его подписываю в корневом центре. Иначе-ошибка. Но на ресурс вы зайти сможете.
Вы либо добавляете в список доверенных мой сертификат, либо я его подписываю в корневом центре. Иначе-ошибка.
Вот именно!
Иначе — ошибка.
Иначе — данные не будут переданы.
Иначе — утечка HTTP-трафика с секретной информацией не произойдёт.
Иначе — безопасность будет обеспечена.
HTTPS безопасен.
1) Подтверждение, что установленное соединение не прослушивается.
2) Установка соединения несмотря на попытки его прослушать.
Вторая задача в общем виде вообще не решается: провайдер в этом смысле может как запретить SSL без подмены сертификата, так и вообще запретить SSL.
Если Вы не сможете доверять сертификату, как Вы попадете на ресурс!?
Никак. В том и суть. Я не попадаю на ресурс и благодаря этому не передаю секретные данные, зашифрованные левым сертификатом — безопасность обеспечена.
Ведь MITM будет в любом случае, хотите Вы этого или нет
И мне плевать, потому что браузер не доверяет сертификату и пишет ошибку, и я не попадаю на ресурс — безопасность обеспечена.
В этом и заключается Ваша безопасность — не использовать Интернет?
Спустя сутки вы наконец-то это поняли!
Только это не значит, что при MitM остаётся сидеть ничего не делать.
Можно как минимум:
сменить провайдера (в моём доме их штук пять, плюс как минимум четыре мобильных оператора в Петербурге);
осилить DNSSEC (мой провайдер осуществляет MitM для deviantart.com путём подмены DNS-ответов с подсовыванием IP-адресов серверов, имеющих поддельные сертификаты, и DNSSEC спасает от такого MitM);
подключить какой-нибудь такой VPN или SOCKS-прокси, который не будет заниматься подменой HTTPS-сертификатов.
Вот когда ВСЕ ТРИ варианта окажутся неработоспособными, тогда катастрофа. А пока я MitM моего провайдера успешно обхожу.
осилить DNSSEC
Это нужно было осилить уже давно.
сменить провайдера
Смысл?
подключить какой-нибудь такой VPN или SOCKS-прокси
VPN рубится и факт его использования на стороне провайдера очень даже отлично определяется теми же Цисками. Да куда там, даже Kerio умеет. Как и SOCKS — рубится с полпинка практически. Так что единственное, что поможет в корне — это obfs+tor. О чем я, черт возьми, в начале и сказал, но Вы развели демагогию, дназывая https безопасным и доказывая это чуть ли не со свистом, но при этом предлагая удалять доверительные отношения с рутами (на чем и в принципе основан https). И при этом в конце сказав, что Вы боретесь с MITM… Уважаемый, у меня нет слов :)
А пока я MitM моего провайдера успешно обхожу
Скоро по-другому будет)
HTTPS небезопасен
HTTPS безопасен. От государства и от АНБ не защитит ничего кроме шапочки из фольги (об этом даже нет смысла разговаривать), а от васи пупкина и от провайдера HTTPS очень даже защищает.
Смысл?
Другой провайдер может не делать MitM.
VPN рубится
Я вам больше скажу — весь интернет рубится! Было бы желание. Только оттого, что вы перерубите свою витую пару, HTTPS не станет небезопасным.
Так что единственное, что поможет в корне — это obfs+tor.
Не поможет, если, например, отрублен весь интернет. Ну или если провайдер будет рубить абсолютно весь подозрительный трафик, например по белому списку. Но опять же к безопасности или небезопасности HTTPS это не имеет никакого отношения.
а от васи пупкина и от провайдера HTTPS очень даже защищает.Не сертификат, а шифрование. Уже лет 15-20 как защищает.
И ещё очень долго будет защищать, потому как у васи пупок развяжется стать посередине и пускать через себя весь трафик. Не говоря уже о том, что б его дважды гонять через шифрование.
Техническое и финансовое ограничение единственная причина почему провайдер не становится митм, а не СЦ.
Весь трафик «дважды гонять» совсем не обязательно, достаточно лишь трафик одного конкретного неугодного пользователя прослушивать, а с этим даже дохлый андроид справится. Но для этого нужно получить доверенный сертификат у СЦ. Если государство ещё как-то может теоретически надавить на СЦ этими вашими судами и РКНами, то вася пупкин и провайдер (сам по себе, без помощи государства) уже ничего поделать не смогут.
HTTPS безопасен
Да ради Бога, думайте так дальше, я Вам не мама, чтобы воспитывать.
Другой провайдер может не делать MitM
И не факт, что Вы это узнаете ;-)
Я вам больше скажу — весь интернет рубится
Я понял уже давно, что для Вас безопасность — не пользоваться вообще ничем. Но мы говорим не об этом.
например по белому списку
Какие белые списки? Вы о чем? OBFS маскирует трафик, делает нечитабельным. Отрубить неизвестный трафик — это убийство, на это даже Китай не пошел, от чего там успешно работает OBFS.
Отрубить неизвестный трафик
… вполне технически возможно. Сегодня Китай не пошёл — а вдруг завтра пойдёт? Центрам сертификации и провайдерам вы не доверяете, а Китаю доверяете?)) И, кстати, вы так и не рассказали, как obfs4 работает, как будто не знаете, как он работает.
как будто не знаете, как он работает.Зачотный троллинг.
Малыш нашёл себе бесплатных учителей, но оно так не работает.
PS:
Даже если расскажут как, ученик имеет слишком поверхностный подход, не утруждает обдумыванием полученой информации т.е. теряет 80-90% даже кратко изложенного.
Такие «знания» только, что б «пыть в глаза» пускать.
А вы окончательно скатились в бессмысленную демагогию. Если собеседник не готов доказывать свои утверждения, значит не нужно было ничего писать. nagibat0r говорит, что с OBFS4 всё хорошо — вот пусть объяснит мне и другим читателям, почему с ним всё хорошо.
nagibat0r говорит, что с OBFS4 всё хорошоКак специалист я с ним согласен.
Правда стоит уточнить, у него намного лучше, чем у большинства других для соответствующих целей.
Для нашей ситуации эти решения избыточны чуть больше чем полностью.
вот пусть объяснит мне и другим читателям, почему с ним всё хорошо.Путин лично выписал особые полномочия, что я наблюдаю повелительный тон?
Когда решит написать статью, что б разложить особенности для неофитов, тогда и «объяснит» почему и как там лучше.
Когда решит написать статью, что б разложить особенности для неофитов, тогда и «объяснит» почему и как там лучше.
Если собеседник не готов подтверждать свои слова сейчас, значит не нужно было вообще начинать эту бессмысленную ветку.
Для нашей ситуации эти решения избыточны чуть больше чем полностью.
Именно.
Путин лично выписал особые полномочия, что я наблюдаю повелительный тон?
Да у этого персонажа, видимо, все полномочия, насколько он думает. Однако…
Когда решит написать статью, что б разложить особенности для неофитов
Возможно и стоит написать, да. Но позже. Дел по-горло. Итак одна долгожданная статья в черновиках висит уже месяц, никак не доделаю.
вполне технически возможно
Я не сказал, что это НЕВОЗМОЖНО! Я сказал, что этого никто не сделает! По понятным причинам!
вы так и не рассказали
Если Вам сложно открыть Гугл, ок, специально для Вас, коли Вы такой лентяй.
Obfs4 использует протокол, который маскирует свой трафик, чтобы он выглядел как случайные данные. Obfs4 основывается на ScrambleSuit — транспортном протоколе, который затрудняет, для DPI, идентификацию и блокировку трафика. ScrambleSuit обеспечивает защиту от атак зондированием, используемым Великим китайским файрволом. При использовании obfs4, рукопожатие всегда делает полный обмен ключами. Рукопожатие использует метод согласования ключей NTor, который запутывает открытые ключи при помощи алгоритма Elligator 2; Шифрования канального уровня использует библиотеку (NaCl) с имитовставками (Poly1305 и XSalsa20). Считается лучшим в том, что он быстрее, чем другие транспорты. Для реализации обфускации obfs4 используется obfsproxy. Obfsproxy работает по принципу клиент-сервер, на стороне клиента Tor трафик обфусцируется (маскируется) в obfsproxy и уже потом отправляется в направлении т.з. моста, где также стоит obfsproxy который снимает с трафика маскировку и шлёт его уже в Tor сеть. Таким образом скрывается факт использования Tor сети и повышается безопасность TLS/SSL трафика за счет его дополнительной модификации (обфускации). Надеюсь, внятно?
а Китаю доверяете
А при чем здесь Китай? Какая разница, доверяю я ему или нет? О чем Вы? Так, чтобы спросить и поболтать ни о чем?
Много умных терминов без конкретики, но хоть что-то.
При использовании obfs4, рукопожатие всегда делает полный обмен ключами.
Обмен ключами с кем? Как убедиться, что обмен произошёл с кем надо, а не с кем-то подконтрольным условному Китаю?
моста, где также стоит obfsproxy
Как убедиться, что мост не подконтролен условным китайским властям? Какое из перечисленных вами заумных слов обеспечивает это? Или даже так: откуда клиент вообще узнаёт адрес моста?
А при чем здесь Китай?
Это я вас спросить хотел, это вы зачем-то вспомнили Китай.
Я сказал, что этого никто не сделает! По понятным причинам!
По причинам, в правильность которых вы решили верить.
без конкретики
Я что, бесплатная Википедия? Я рассказал все довольно подробно, что еще требуется? Потратьте своё личное время и перечитайте 100 раз, может и поймете.
Обмен ключами с кем? Как убедиться, что обмен произошёл с кем надо, а не с кем-то подконтрольным условному Китаю?
Извините. но я спрошу. Вы в себе?
подконтрольным условному Китаю
Выше спросил.
Это я вас спросить хотел, это вы зачем-то вспомнили Китай.
А почитать в Гугле не судьба, как связан OBFS и Китай? Мне снова тратить личное время на ответ на глупый вопрос?
Речь о Великом Китайском Файрволе, который славится тем, что кастрировал все, что можно, но Tor работает через OBFS.
правильность которых вы решили верить
Кормитесь в другой ветке
Опять уклонились от всех ответов.
Вы в себе?
А вы в себе? Если бы вы были в себе, то спокойно ответили бы, как решается вопрос доверия серверу в OBFS4, без вот такой вот демагогии.
Я ещё раз повторяю, я Вам рассказал, как оно работает, и я прекрасно знаю, но так как Вы неспособны усвоить ничего, идите в Гугл, пожалуйста. Я не намерен отвечать на вопросы, которые ставятся в такой форме. Во первых, я не на экзамене, а Вы далеко не учитель. Во вторых, Вы все равно не согласитесь ни с чем в силу своего жирного троллинга
Ну я ещё раз напоминаю вам, что вы не доказали, что OBFS4 достаточно. Вы просто нахватали терминов из гугла и накопипастили их мне. Видимо, на этом ветку можно завершать, раз отвечать на вопросы вы не желаете.
Ещё раз. В моём сообщении указано то, о чем спрашивали. Нужны подробности? Вот спецификация https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt. Читайте.
Я её читал и не нашёл там ответа на свой вопрос. Эта спецификация или чего-то не договаривает, или всё же предполагает, что клиенту «server's Node ID and identity public key» сервера заранее известны. Но откуда клиент OBFS4 их узнает-то?
Читайте ещё раз.
Прочитал ещё раз, внимательно-превнимательно, и нашёл вот что:
The server distributes the public component of the identity key (B) and NODEID to the client via an out-of-band mechanism.
О каком именно «out-of-band mechanism» идёт речь — по вашей ссылке нигде не сказано.
Может, скажете вы?
Какой конкретно «логически независимый канал передачи» (или несколько каналов) нужно использовать для получения «the identity key (B) and NODEID» при работе c OBFS4? Какой конкретно канал будете использовать лично вы, например?
Я сказал, что HTTPS небезопасен в том виде, в котором он есть и всем рекалмируется. Пояснил, почему. Предложил альтернативу. Безоговорочную. OBFS4 сигнатуры не существует и вряд ли она появится, так что он не может быть обнаружен. Дал описание работы протокола, краткое. Дал ПОЛНУЮ спецификацию, в конце концов.
Какой конкретно канал будете использовать лично вы
Еще раз ВНИМАТЕЛЬНО прочитайте спецификацию. Зайдите в Tor WIKI, в конце концов. Там есть ВСЯ информация. Правда, на английском, но понять там все прекрасно можно.
Obfsproxy гарантирует соединение с именно тем бриджом, который указали в конфиге. Гарантирует, что пакеты будут доставлены в обфусцированном виде до бриджа и будут посланы дальше в Tor-сеть. Гарантирует, что пакеты будут приняты в обратном порядке именно Вами, а не Васей. Почему? Потому что происходит обфускация всего трафика от obfsproxy на Вашем ПК до obfsproxy на бридже. Как так происходит? Это написано в спецификации. Пожалуйста, потратьте своё личное время, в конце концов.
З.Ы.: любой протокол, у которого существует сигнатура, считается не совсем безопасным. В чем состоит безопасность? Что никто не сможет вмешаться в ваше соединение и не сможет отследить ничего касаемо вашего соединения. Есть сигнатура — можно отследить. Можно вмешаться. Всё.
И да, Вы так и не признали, что проиграли в споре про безопасность HTTPS. Что ж, в таком случае я прекращаю с Вами диалог с этой минуты. Всего доброго, и удачи в изучении матчасти.
Не увиливайте от ответа.
бриджом, который указали в конфиге
Чтобы указать бридж в конфиге, надо его откуда-то получить. Откуда? Откуда лично вы взяли (или возьмёте в будущем) бридж?
Нет уж, давайте вы продемонстрируете свою некомпетентность публично! Вы мне в личке ответили:
Слушайте, Андрей, может вы прекратите ТУПИТЬ и включите голову? Бриджи берутся с сайта Tor! Это известно всем! Нигде более их не взять! Совмеваетесь в том, что показано на сайте после капчи? Пишите разработчикам на емейл, который указан! Вам пришлют бриджи! Чего Вам нужно? Потроллить? Или Вы глупый?
Признайте, что спор Вы проиграли. А Вы его проиграли с треском.
Сайт может быть подменён провайдером с помощью поддельного сертификата, вы сами мне об этом целые сутки рассказывали.
На почту можно писать только с адресов Gmail, Riseup!, или Yahoo! — опять же все три могут быть подконтрольны каким-нибудь американцам. При этом в почте даже не предлагается использовать шифрование (а если бы предлагалось, то всё равно непонятно, как доверять ключу).
То есть все упомянутые способы заведомо небезопасны и могут подсунуть бридж злоумышленника.
Так как же получить такой бридж, которому можно доверять? Вы мне так и не рассказали. Пока не расскажете — проигравшим считаетесь вы.
проигравшим считаетесь
HTTPS небезопасен, что я доказал, Вы проиграли. Мне всё равно, что вы там считаете, но раз Вы не можете просто признать, что проиграли спор, то разговривать с Вами не о чем.
могут подсунуть бридж злоумышленника
О май гад, Вам еще рассказывать, как работает луковая маршрутизация? Если Вы читали спецификацию и Tor WIKI, то поняли бы, что после деобфускации идет Tor — трафик, который дешифровать на самом бридже нельзя. Никак.
При этом в почте даже не предлагается использовать шифрование
Можете использовать шифрование, кто не дает? Ваша безопасность — это ваша безопасность!
Сайт может быть подменён провайдером с помощью поддельного сертификата
Вы приписываете мне то, чего я никогда не говорил! Я сказал, что можно подменить сертификат и расшифровать трафик, о подменах сайта речи не было, не свистите.
вы сами мне об этом целые сутки рассказывали
Вы сутки доказывали, что HTTPS безопасен, но проиграли этот спор. Где слова: «Да, я проиграл спор»? Вы балабол и только.
З.Ы.: если Вы не доверяете своему почтовому провайдеру и не хотите получать бриджи с сайта Tor, поднимайте свой бридж там, где угодно, и подключайтесь к нему, о чем кстати тоже написано в Tor WIKI.
З.Ы2: на этот раз, я действительно прекращаю с Вами диалог:) Вы проиграли спор и не признали это. Вы откровенно глупите и троллите, демонстрируя всем свою глупость. До свидания. Нет желания общаться с троллем.
Для того, чтобы поднять свой бридж, нужен провайдер, который не будет резать тор и который вообще позволит подключаться извне. Таких провайдеров с каждым днём всё меньше. И кстати чем свой бридж принципиально будет отличаться от бриджа на локалхосте?
Чтобы получить гарантированно хороший бридж, остаётся только лично встретиться с админом бриджа и получить от него Node ID и публичный ключ. И надеяться, что провайдер не забанит его по айпишнику. То есть безопасность абсолютно такая же, как и в HTTPS при отказе от центров сертификации — только там мы пытались встретиться с админом гугла.
HTTPS безопасен ровно на столько же, насколько безопасен OBFS4 — безопасность обоих упирается в доверие заранее известному публичному ключу. Недоверенный OBFS4-сервер может даже не слушать, а просто не пускать ваш трафик.
Вы говорили, что OBFS4 трафик рубить не получится — я вам рассказал, как его обрубить.
Вы пытаетесь замаскировать свой проигрыш демагогией и манипулированием терминами, так что, наверно, разговаровать с вами действительно не о чем. До свидания.
Если идти путём последовательного скептицизма, то таких способов нет. От слова совсем. Даже если лично владелец ресурса, с которым вам нужно связаться, сам принесёт вам распечатку этого ключа (и предъявит 100500 документов и подтверждений своей личности), где гарантия, что этот владелец не агент ЦРУ (что его мозги не промыты Союзом Девяти, что он не двойник настоящего, что вам не внушили эту передачу под гипнозом… — нужное подчеркнуть, недостающее добавить)?
Любая такая передача всегда предполагает некий уровень доверия к процессу и к его участникам. Скажем, меня вполне устраивает, если мне ключ присылают в зашифрованном виде (GnuPG) средствами Fastmail, а ключик мой берут на публичных Key-серверах (хотя и Fastmail, и упомянутые серверы могут как бы что угодно кому сливать и что хотят подделывать).
Повторю вопрос: какой способ передачи вы лично считаете достаточно надёжным и безопасным?
Никакой. Как я уже писал ранее,
придётся снижать безопасность, доверяя кому-то ещё.
Вы доверяете Fastmail'у. А вот nagibat0r, судя по всему, никому не доверяет. Как он при этом собирается использовать этот свой OBFS4, я не понимаю до сих пор.
в зашифрованном виде (GnuPG)
Согласен. А мне, что касается получения бриджей, достаточно зайти на сайт Tor. Что делать, если заблокирован? Так все просто. У меня не менее 10 бриджей активны всегда, и я проверяю их доступность всегда. Так что даже в тот день, когда Tor не сможет подключаться у всех, кто не использует бриджи, у меня он подключится в любом случае, и я спокойно без всяких MITM возьму на НАСТОЯЩЕМ оф.сайте еще пачку мостов. Потому что надо заранее заботиться о приватности и безопасности, а не когда петух в одно место клюнет.
Вы, кстати, не доказали, что https безопасен. Абсолютно. Никак. Потому как есть такие вещи, как sni и splice. И я как провайдер легко даже без подмены сертификатов увижу, куда Вы заходили, и даже терминирую туннель, если нужно. Это абсолютно неоспоримо. Так что спор Вы проиграли. Можете идти в другую ветку и упорно доказывать всем всё, что угодно
Извините. но я спрошу. Вы в себе?Очень даже в себе.
Просто выуживает информацию, которую не может найти в полноценных статьях.
Хотя UDP_OBFSи в этом случае не помешает.
Это уже не TLS, так как TLS предусматривает третью сторону априори.
Вы полегче с такими обобщениями.
en.wikipedia.org/wiki/TLS-PSK
нагибатор 0:1 андреймал
Ведь если посмотреть на то, каким образом работают end to end и HTTPS, то очевидны недостатки последнего. Если есть третья сторона — это не безопасность по причинам, которые я указал выше. Удалять руты? Да ни один здравомыслящий человек это не сделает, потому что он на половину сайтов никогда не зайдет из-за HSTS.
Все CA сейчас выписывают сертификаты только с обязательной регистрацией в Certificate transparency. А это значит, что выписать за денежку рутовый сертификат, которым провайдер сможет читать весь трафик — это палево на весь мир, и ни один адекватный CA на это сейчас не пойдет. Ну а если пойдет, то будет быстро запален и вырезан из доверенных. Вмиг.
И да, пропихнул эту тему — злой гугл.
Чисто теоретически вроде бы можно выписать липовый сертификат по старинке в обход Certificate transparency. И тогда, возможно, палево случится не сразу. Впрочем, я всё равно не верю, что это возможно на практике, даже за большие деньги)
Допустим в браузеры его допустили.
И реально делают как обещал. Поддерживает и DV и EV/OV. Авторизация только через госуслуги.
Что он сможет сделать если придет ФСБ с ордером в котором:
— выдать сертификат на сайт террористы.com
— НЕ светить эту информацию нигде (в том числе в Certificate transparency)
Для упрощения задачи — против сайта террористы.com в США исков не подают только потому что свобода слова но в том что там таки террористы — даже в США очень у многих людей сомнений нет.
Также для упрощения задачи — ФСБ получила этот ордер с соблюдением всех процедур, судья не за 10 минут принял решение, у ФСБ ЕСТЬ основания считать что террористы.com реально используется для координации деятельности организации (ну и пропаганды тоже) и они хотят провести теракт в России. Суду эти доказательства были предъявлены.
CA оспорил решение.
Еще одно заседание (опять закрытое) — опять доказательства предъявлены + Роскомсвободу позвали (ну допустим они юридической защите CA помогают).
Материалы закрыты но все участники (и Роскомсвобода тоже) подтверждают что ФСБ вообщем не врет, и весьма вероятно — мониторинг трафика из России к этому сайту — поможет предотвратить теракт. Но детали публике сказать не можем. Сначала все было секретным но потом на публику утек сам факт (без указания сайта).
Что должен делать CA? С учетом что решения законное, даже оспорить дали, все кто в курсе — понимают что ну вообщем то запрос обоснован да и просят они один конкретный сайт (а не subCA). Но — это нарушение их политики (они прямо обещали что НЕ будут для .com выдавать) + CA Browser Forum может иметь определенные вопросы к ним на базе хотя бы этой утечки и могут превентивно даже выпилить (или как минимум потребуют подтверждение — но CA прямо запрещено ж разглашать эту информацию — как изначальным запросом ФСБ так и решением суда).
И что CA делать? Технически возможность сделать что просят — у них есть, законное требование — есть. Последствия даже не самого действия а слуха что они это сделали — вообщем то же очевидны.
Если они в итоге вылетят из доверенных — где гарантия что не начнется новый вой на тему антироссийских санкций и «а какие гарантии что АНБ такое не потребует у своих»…
И как быть?
Всем участникам этой истории (Считаем что ФСБ реально считает что им нужен сертификат для перехвата и что польза- будет и готова это доказать независимым экспертам и разрешить опубликовать отчет (без идентифицирующих деталей))
Во-вторых, вне зависимости от требований ФСБ, если владелец террористы.com не дурак и сделал Public Key Pinning, попытка хоть сколько-то массовой атаки всплывёт достаточно быстро.
А ещё проблемы с поиском из-за всех тех ресурсов, которые додумались сделать бесконечную прокрутку. Так что если у вас поисковик выдал ссылку на какой-нибудь ВКонтакт, вам ещё постараться придётся, чтобы по этой ссылке найти нужное.
Зато вот с появлением HTTPS перестали работать кэширующие прокси — они стали попросту бесполезными. А ведь они очень неплохо помогали экономить трафик, да и плавность работы с ними была куда как выше.
Во-вторых, я писал выше, что да, для разработчика контроль над трафиком — это удобно и выгодно. Однако пользователю выгоднее, чтобы никто не контролировал весь трафик целиком.
Я не должен был её читать, потому что они слишком старая? Возможно, мне не стоило бы читать свежие воспоминания участников событий 1993-го, 1996-го, 1998-го, 1999-го годов, потому что в них — правда, а не то, что придумывают об этих событиях в 2018-м году. Да, наверное, с точки зрения разного рода полицаев всех мастей, необходимо ограничить доступ ко всему старому, потому что интернет — это своеобразная коллективная память, и я прекрасно понимаю, что многим, наверняка и вам в том числе, выгодно, чтобы эта память была как можно короче.
>А то с такой логикой, давайте вернемся в пещеры. Будем бить себя дубинками по голове
Да, кстати, если уж говорить про «себя дубинкой по голове», то да, у меня есть неотъемлемое право бить себя дубинкой по голове — и никто у меня это право просто так не отнимет. И уже моё личное дело, буду я им пользоваться или нет, вас это абсолютно не касается.
Не нравится гугл хром? — Сделайте свой браузер. Серьёзно, форкнуть хромиум — не самая хитрая задача.
Как разработчику — мне важно, чтобы мой сайт и сайты контент которых я могу встраивать были безопасны (какая-нибудь АПИшка определения страны по IP например, через JSONP).
Как посетителю — мне важно получать именно тот контент, который мне хотел передать разработчик сайта. При этом я не желаю, чтобы мои действия отслеживал мой оператор связи или оператор VPN.
Поэтому лично для меня в переводе всего интернета на HTTPS — есть только плюсы. Перечисленные в статье минусы я назвал бы смехотворными, нет смысла их даже комментировать.
Нужно понимать, что у любого решения всегда будут защитники и противники. В том числе в интернете, однако чтобы интернет развивался, а не стоял на месте — какие-то решения должны приниматься.
Решение о переводе интернета на HTTPS большинству пользователей принесёт пользу, поэтому меньшинство, которое против, — может только принять этот факт.
Учитывать мнение меньшинства это конечно прекрасно, однако я могу быть против тегов video, против JavaScript, против ajax, против iframe. Но я не говорю гуглу, что он должен убрать всё это из хрома (но Go ему следует переименовать, ну правда, занято же было).
Зашёл прочитать о том, почему QUIC хуже HTTP, а увидел переливание из пустого в порожнее о вариациях последнего.
Boooring!
Переход на HTTPS — ещё один кирпичик к этой «не-вечности». Ладно, я до сих пор занимаюсь вебом, и могу поставить сертификаты. А есть куча компаний, которым просто сделали сайт по заказу, сайт крутится где-то на хостинге, действий никаких не требует, нужно только продлевать хостинг и домен. Будут ли они искать специалистов и заморачиваться с переходом на HTTPS? Или просто забьют? Или увидят падение трафика из-за того, что браузер стал показывать предупреждения и просто перестанут поддерживать сайт полностью?
Может быть проблемы таких «хоумпаг» — не самая большая проблема интернета, но мне лично приятно знать, что вот я зашёл на страницу, получил информацию, и смогу эту информацию потом найти на том же месте и спустя 10 лет.
Проблема номер раз: «сайты, открытые по https, не являются безопасными. Защищённость соединения означаете только защищённость соединения. Надеюсь, браузеры рано или поздно будут явно об этом информировать. Да хотя бы плашку „достоверность информации и защита от перехвата паролей не гарантируется“ на всех http-сайтах.
Два: заставлять переходить на https и скрывать „незащищённые сайты“ в результатах выдачи поисковиков — неправильно. Доступность накопленной в сети информации уменьшится — это плохо.
Три: Необходим какой-нибудь https-lite без шифрования, но с контролем целостности, и с пониженной сложностью настройки для реализации на маломощных устройствах. Понятия не имею, как сделать что-то подобное, но было бы неплохо) В своё время реализовывал „веб-сервер“ с минимальной функциональностью. Тогда поразило, насколько http-протокол прост и понятен. Если бы браузеры тогда ультимативно требовали наличие шифрования, у меня бы ничего не получилось.
Есть такая штука, как Subresource Integrity. Если расширить её на медиа-данные это был бы уже неплохой шаг вперёд по крайней мере в части mixed-content.
Я не уверен, что проблема вообще решаема без сложной криптографии.
В принципе можно пытаться решить задачу защиты основной страницы подписью в теле HTML. Но тут требуется стандартизация подписи, поскольку HTML не XML и XMLDSig не покатит… ну и опять же это по выч.ресурсам не сильно проще чем HTTPS для динамических страниц. А вот для статики (вздох ностальгии по Web 1.0) было бы неплохо.
Плодить протоколы и технологии, а зачем? Какие например устройства не справляются с https?
И пример с «сайтом, который никак не собирает информацию у пользователей» очень показателен.
Да, данный конкретный сайт (возможно) вполне себе может работать на http и никакой проблемы ни для кого никогда не создаст.
Но рядом с этим самым сайтом в интернете есть тысячи других, в которых отсутствие https буде т подвергать пользователя риску.
И, видимо, самый простой способ сделать интернет безопаснее выглядит именно так.
P.S. Про информацию, которую «кто-то давно положил в интернет, надеясь, что она сохранится» – это какая-то утопия.
Да, данный конкретный сайт (возможно) вполне себе может работать на http и никакой проблемы ни для кого никогда не создаст.
Но рядом с этим самым сайтом в интернете есть тысячи других, в которых отсутствие https будет подвергать пользователя риску.
Так проблема собственно в том, что сегодняшний подход Google и сообщества вообще в том, что различий делать не надо. И раз кто-то хочет HTTPS — значит всем нужен HTTPS. Хотя выше я отмечал сценарии, когда использование HTTPS приводит к снижению приватности и безопасности…
Минусов я четких не увидел, но плюсов то — вагон. Причём как для обоих сторон
HTTPS это хорошо там, где это надо. Но в то же время идея о том, что HTTP must die — неправильная. Так же как ipv4 вполне ещё долго может существовать в качестве протокола локальных сетей и совершенно не стоит пытаться дискредитировать устройства за то, что они работают по ipv4.
Проблемы HTTPS были приведены в комментариях. Вот одна, самая яркая: при том, подходе к HTTPS vs HTTP видео с моей домашней видеокамеры оказывается (по мнению браузера) более «безопасно» смотреть на сайте производителя или предложенного им хостинга, чем на самой камере, не выпуская его в интернет вообще. Потому что не выпуская видео в интернет я не могу подписать соединение доверенным сертификатом (а сертификат на локальный адрес мне никто не выпишет).
а сертификат на локальный адрес мне никто не выпишетЧто за глупости? Вы сами себе его можете выписать и добавить в браузер.
Точно также, как telnet перестали использовать даже в локальных сетях и http нужно перестать использовать даже для своей локальной web-камеры. Конечно процесс займёт какое-то время…
Что за глупости? Вы сами себе его можете выписать и добавить в браузер.
Сколько рядовых пользователей это осилят?
Telnet в основном использовался администраторами и разница между telnet и ssh в тривиальном случае только в положении переключателя.
HTTPS с самовыписанными сертификатам — область очень специфическая. В основном будет корпоративная или при усложнённой сети. В нормальной ситуации потребности в дополнительной безопасности внутри локальной сети нет. И не надо рассказывать про KRACK: обнаружение уязвимостей — повод закрывать уязвимости, а не добавлять ещё один слой шифрования.
В нормальной ситуации потребности в дополнительной безопасности внутри локальной сети нет.Гугл тоже так думал. Пока Сноуден про Prism миру не поведал. Оказалось, что даже внедрять своих агентов НСА не пришлось: достаточно было с роутерами немножко пошаманить.
А сколько рядовых пользователей осилят обнаружить свисток, вставленный в роутер, который у большинства стоит не в квартире, а в электрощитке, к которому доступ не такой уж скрытный?Что за глупости? Вы сами себе его можете выписать и добавить в браузер.Сколько рядовых пользователей это осилят?
По большому счёту для большинства «обычных пользователей», «не умеющих» в самовыписанные сертификаты и не «висящих на карандаше» у спецслужб доступ «через три облака» безопаснее, чем напрямую через IP без шифрования.
Эта проблема решается обычно доступом из приложений, согласитесь, что большинство пользователей не будет вводить IP (который ещё и динамический) и заходить на камеру из браузера. Сейчас используют P2P камеры, которые для подключения используют приложение
А вот приложения с вендорным (наверняка недокументированным) API — это ещё хуже, чем нешифрованное соединение внутри WPA. Не говоря о том, что вам, в сущности, никто не обещал что этот вендорный протокол зашифрован, а не просто запутан.
mDNS не позволит вам обращаться к камере из вне вашей сети, приложение — позволит, это именно тот самый простой путь для обычного пользователя, для продвинутых есть RTMP поток по IP адресу
А RTMP с точки зрения «HTTP must die» тоже должен must die и остаться только RTMPS.
mDNS не позволит вам обращаться к камере из вне вашей сети, приложение — позволит, это именно тот самый простой путь для обычного пользователя, для продвинутых есть RTMP поток по IP адресу
А так как с точки зрения локальных законов такая деятельность законна — остается лишь одно решение — перейти на https, хотя мы с минимальным уровнем безопасности.
Это по сути позволяет шпионить за пользователями и лишает интернет его движущей силы — дохода от рекламы.
Ну, логично. Сайт, который в этом заинтересован — перейдёт на HTTPS. А тем, кто не заинтересован зачем? У меня, например, на сайте рекламы нет.
Интернет меняется, и, увы, далеко не все изменения — к лучшему…
Причём возможность повторной отправки тех же (не подменённых, не «заражённых») данных провайдером как раз будет очень актуальна в тех самых развивающихся странах, где скорости интернета невелики.
… сколько раз надо повторить, что защита от внедрения может решаться иным способом ...Ну мне вот за подобную крамолу минусов наставили.
Интересно было бы более подробно узнать от вас о том ином способе, который вы упоминаете.
Тогда как минимум статика уже может защищаться от подмены методом подписания до загрузки на сервер и мощность и функционал сервера не будет иметь значения. Также при IMG-SRI страница с безопасного сервера cможет безопасно внедрять изображения со старого сервера.
Google и HTTP