Их позиция
Сторонники отказа от HTTP в своих убеждениях в основном опираются на то, что:
- По пути от сервера к браузеру пользователя с веб-страницей может случиться что-то плохое.
- Переход на HTTPS — это несложно и недорого.
- Гугл предупреждает людей о том, что сайт «ненадёжен». Значит, если я не хочу, чтобы люди разбежались в страхе, мне нужно просто выполнить их требования.
Почему это плохо
Интернет — это открытая платформа, а не корпоративная. Он определяется его стабильностью вот уже 25 с лишним лет и по-прежнему полон сил. Google является гостем в Интернете, как и все мы. Гости не устанавливают правила.
Почему это плохо с практической точки зрения
Значительная часть Интернета представляет собой архивы. Файлы просто лежат там, где их никто не поддерживает. Они просто работают. Там нет никого, чтобы сделать работу, которую Google требует ото всех сайтов. И у кого-то есть много доменов и поддоменов, размещенных на всех видах программного обеспечения, о которых Google никогда не думал. Там, где требуемые преобразования не оправданы возможной выгодой. Причина такого широкого разнообразия в том, что Интернет всегда был открытым и никому не принадлежал.
Интернет — это чудо
Google приложил большие усилия, чтобы убедить вас в том, что HTTP — это плохо. Позвольте мне рассказать, почему HTTP — это лучшее, что когда-либо было.
Его простота — это то, что позволило Интернету работать. Это привело к бурному росту новых приложений. Сейчас трудно поверить, что когда-то не существовало Amazon, Netflix, Facebook, Gmail, Twitter и др. Это связано с тем, что сетевые стандарты до появления Интернета были сложными и плохо документированными. Взрывной рост произошёл, потому что Интернет — простой. Там, где более ранние протоколы были сложными, веб был простым.
Я не думаю, что рост остановился. Я хочу, чтобы людям было всё проще и проще запускать собственные веб-серверы. Google делает то, что всегда делают священнослужители от программирования, увеличивая входной барьер, делая вещи более сложными, отстаивая свою монополию. Это означает, что только самые прожжённые гики смогут создавать сайты. И мы потеряем множество сайтов, созданных на коленке за 25 лет существования Сети людьми, которые не совсем понимали, что они делают. Ведь они тоже часть великолепия Интернета. Блуждание в темноте на самом деле позволяет вам добиваться чего-то. Миры, созданные корпоративными программистами, зачастую устроены так, что в них невозможно найти свой путь.
Интернет — это общественный договор о неразрушении. Он служит нам 25 лет. Я не хочу отказываться от этого из-за того, что кучка гиков в Google думает, что они знают, как лучше.
Интернет — похож на Большой Каньон. Это огромная естественная сущность, потенциал, вдохновение и, как и каньон, он заслуживает нашей защиты. Это место для экспериментов и обучения. Оно так же пригодно и для больших корпоративных сайтов вроде Google. Все взгляды на Интернет важны, особенно те, которые крупные компании не понимают или не уважают. Именно так работает технологический прогресс.
Сохранение Сети, работающей просто, так же важно, как и сетевой нейтралитет.
Они считают, что у них есть власть
Google делает популярный браузер и является лидером в области технологий. Они могут, по их мнению, окружить сеть и для начала предупреждать пользователей о доступе к HTTP-контенту. Скорее всего, они не остановятся на этом, требуя от пользователя согласия на открытие таких страниц, а затем просто блокируя их.
Это нечестно
Многие из сайтов, которые они обозначают как «ненадёжные», не запрашивают у пользователя никакой информации. Конечно, пользователи этого не поймут. Многие серьезно воспримут предупреждение и нажмут кнопку «Назад», не имея понятия, почему они это делают. Разумеется, Google в курсе. Это такая грязная политическая тактика, которую мы ожидаем от коррумпированных политических лидеров, а не от ведущих технических компаний.
Ловкость рук
Они говорят нам, чтобы мы беспокоились об атаке «человек посередине», которая может изменять контент, но не упоминают, что сами могут делать это в браузере, даже если мы используем «безопасный» протокол. Они — единственная структура, которой вы должны доверять прежде всего. Без вариантов.
Они приводят неверную статистику
Когда они говорят, что HTTPS составляет определённую долю трафика, это не является показателем масштаба проблемы. Множество HTTP-сайтов, которые имеют низкую посещаемость, несут ценные идеи и заслуживают сохранения.
Это уничтожит историю Интернета
Если Google добьётся своего, это сделает недоступной большую часть истории Сети. Люди выкладывали в Интернет вещи с расчётом на то, что они будут доступны со временем. Поэтому важно, чтобы ни у кого не было власти решать, чем должен быть Интернет. Это похоже на массовое сжигание книг в невиданном доселе масштабе.
Если HTTPS — это так круто...
Тогда зачем заставлять людей? Это предполагает, что основную выгоду получит Google, а не владельцы контента.
Интернет небезопасен
В конце концов, в чём ценность безопасности?
Twitter и Facebook напоминают AOL в старые доинтернетовские времена. Они управляются компаниями — приверженцами безопасного опыта. Они предлагают компромиссы для этого. Ограничения для ссылок. Никаких стилей. Ограничения на использование символов. Блокирование, подавление, отчётность, нормы. И так далее, и так далее. Воспринимайте их, как Диснейленд.
Интернет небезопасен. Это правильно. Мы не хотим, чтобы всё было безопасным. Это позволяет людям быть дикими и экспериментировать с новыми идеями. Именно благодаря этому Интернет был испытательным полигоном для множества потрясающих вещей на протяжении его истории.
Столько всего небезопасно. Пересечение улицы. Поездка на велосипеде в Манхэттене. Влюблённость. Но мы всё равно делаем это. Вы не можете находиться в безопасности всё время. Жизнь вообще небезопасна.
Если Google преуспеет в создании безопасного и пресного Интернета, нам придётся заново построить его за пределами гуглосферы. Давайте сэкономим немного времени и просто создадим новый Интернет вне Интернета.
PS Конечно, мы хотим, чтобы отдельные части Сети были безопасными. Например, сайты банков. Но архив моего блога за 2001 год? Серьёзно, здесь нет нужды в особых требованиях.
Письмо с угрозами от Google
20 июня 2018 года я получил письмо от Google как владелец scripting.com.
Согласно письму я должен «перейти на HTTPS, чтобы избежать срабатывания предупреждений и помочь защитить данные пользователей».
Это блог. Я не запрашиваю никакие данные у пользователей.
Пометка «ненадёжный» от Google обозначает: «Google попытался взять под контроль открытый Интернет, и этот сайт сказал «нет»».
Комментарии (455)
Akuma
03.07.2018 20:34+3С одной стороны верно, с другой — на этом «просто блоге» провайдеры интернета могут встраивать рекламу без ведом владельца блога, например. И хорошо, если просто рекламу, а не вредоносный контент.
Это как ОСАГО (ужас какой) — в самой идее нет ничего плохого. Но в отличие от ОСАГО внедрение HTTPS не стоит 20к в год, не нужно стоять в очередях и все такое.Areso
03.07.2018 22:14+1Может быть проблема не в сайтах-архивах-хомяках из 2000-ых, а в таких вот провайдерах?
JediPhilosopher
04.07.2018 13:16+1Я вот как владелец такого сайта ничего не могу поделать с провайдером (да и дело тут не в одном конкретном провайдере, как я понимаю многие таким балуются). Но могу настроить хттпс чтобы хрен ему, а не доход с моего сайта. Собственно до недавноего времени тоже думал что нафиг в моем блоге https, пока не увидел аж пять рекламных блоков в своей статье при заходе через мобильный интернет от Мегафона. Сразу же перевел все на https.
CoolCmd
04.07.2018 14:21а в CSP провайдер свое дерьмо добавляет?
JediPhilosopher
04.07.2018 15:59Не смотрел. Но если у провайдера есть полный контроль над траффиком (а в случае нешифрованного http он есть) то он может добавлять что угодно куда угодно, никакие заголовки от этого не спасут, с точки зрения браузера реклама будет выглядеть точно так же, как если бы я сам ее в свой блог вставил.
stalinets
04.07.2018 18:21Сделать бы расширение для браузера, которое будет кошмарить рекламодателей, пользующихся таким мерзким способом рекламы — встраивание её в пользовательские страницы.
Автоматически вычленять контактные телефоны и, используя встроенную SIP-звонилку и акаунт какого-нибудь SIP-повайдера, просто по несколько раз в час делать в фоновом режиме дозвон и тут же сбрасывать, а каждый двадцатый звонок, например, не сбрасывать, а зачитывать сообщение «Ваша фирма получает эти звонки, так как Вы купили рекламу, вторгающуюся в трафик пользователей интернета, мешающую нормальному отображению сайтов и нарушающую принципы сетевого нейтралитета. Отмените заказ своей рекламы либо обратитесь к провайдеру, чтобы он прекратил модифицировать трафик». Понятно, что это требует аккуратной многогранной настройки, чтобы не страдали невиновные, и придётся периодически регить новый SIP-акаунт, т.к. старый, думаю, будут вскоре банить. Но рекламодатели включат голову, и эта гадость со вмешательством в трафик закончится.JediPhilosopher
04.07.2018 18:35Такие системы есть в некоторых городах для борьбы с нелегальной уличной рекламой. И то вон в Санкт-Петербурге (который весь обклеен рекламой спайсов и борделей) власти всячески саботируют ее внедрение.
А пытаться такое сделать самостоятельно — думаю с высокой вероятностью огрести проблем, т.к. наверняка тут можно подвести какую-то статью за неправомерное использование средств связи (вам никто не давал права забивать чужой канал своими звонками).
u007
05.07.2018 13:43Банить не будут, номер попадёт под защиту от назойливых звонков на некоторое время, и дозвониться через sip станет невозможно.
stalinets
05.07.2018 18:41Ну, теоретически фирма может заморочиться, узнать что за SIP-провайдер по определяющемуся номеру пула, связаться с ним и попросить забанить акаунт. Но в рунете и на ютубе есть куча пранкерских сайтов и каналов, и эти пранкеры же как-то умудряются троллить людей годами. Очевидно, регят периодически левые акаунты взамен забаненных. Значит, и расширение для браузера так может (просто выдать сообщение, что очередной акк забанен, зарегьте другой). И варианты с подменой определяемого номера точно есть, чтобы затруднить идентификацию, с симки ли это звонят через GSM-шлюз, или к SIP- или SKYPE-акаунту просто привязан федеральный номер.
Единственный минус — пользователю, чтобы наказать рекламодателей за такие действия, придётся периодически регить новые акаунты и, возможно, кидать на их счёт какие-то деньги, что далеко не каждый согласится делать.u007
05.07.2018 18:54Я имел в виду номер фирмы. Сип-провайдеры на таких шутниках собаку съели, всё схвачено)
rumkin
04.07.2018 02:25Для проверки целостности нужно не шифрование, а проверочные суммы и подписи к ним.
alexey-m-ukolov
04.07.2018 05:35Речь же не про проверку целостности, а про защиту от вмешательства.
rumkin
04.07.2018 14:43Если при обнаружении подмены, страница не откроется, то вмешательство станет бесполезным. Шифрование выполняет другую задачу – сокрытие данных.
extempl
04.07.2018 15:14Если при обнаружении подмены, страница не откроется
То пострадают все.
- Агрессивный рекламодатель (хорошо)
- Провайдер которому заплатил рекламодатель (хорошо)
- Хостер сайта (плохо)
- Посетитель (плохо).
А вот кто выиграет — непонятно. Справедливость, что-ли?
Зачем?
DistortNeo
04.07.2018 17:22Это потребует точно такой же возни с сертификатами для проверки подписей и обновлением серверной части. Шифрование же — просто приятный бонус.
Sergey_Cheban
04.07.2018 18:15Ну так это тоже криптография. Несколько другая, но тоже требующая сертификата для подписывания проверочных сумм. Набор недостатков аналогичный, но при этом без достоинств, которые даёт шифрование.
16tomatotonns
04.07.2018 06:51Обычное вредоносно-рекламное расширение браузера будет встраивать произвольное количество рекламы в абсолютно любую страничку. И даже раз в пять секунд открывать страничку с рекламным видео. Видел «вирусы на питоне», которые мониторят открытые браузеры и через аналог драйверов selenium'а подменяют контент и заставляют тыкать на нужные автору расширения кнопки и регулярно открывать рекламные вкладки, с вопящим видео. Очень выгодно. А если сидящий за компьютером — разработчик, то в процессах он просто увидит запущеный питон, и не факт что среагирует, потому что «своя софтина привычная», получается натуральная мимикрия.
WitcherGeralt
04.07.2018 08:39Защита контента на сетевом уровне это лишь часть проблемы, ибо на самой машине пользователя может быть всевозможная зловредная дрянь. В России каждый второй виндузятник устанавливает так называемый «антивирус» касперского, который встраивает в страницы свои скрипты. И HTTPS тут ничем не поможет.
khim
04.07.2018 17:31То, что защита на сетевом уровне не решает всех проблем не обозначает, что она не нужна.
В конце-концов вы же моете руки перед едой, хотя это защищает только лишь от холеры, но не от СПИДа.WitcherGeralt
04.07.2018 17:47А кто сказал, что она не нужна? Речь о том, что гугл выдаёт относительную безопасность на сетевом уровне за безопасность как таковую. Это не так.
khim
04.07.2018 18:06Речь о том, что гугл выдаёт относительную безопасность на сетевом уровне за безопасность как таковую.
Согласен. Но это делает не только Google, но и Mozilla и MS IE…
Это не так.
И, соответственно, с этой проблемой Google и борется. Вместо того, чтобы писать на https-сайтах «безопасно», а на http-сайтах ничего не писать (как это делается сейчас), в новой версии будет делаться наоборот — на http-сайтах будет писаться «небезопасно», а на https-сайтах не будет писаться ничего… Это, несомненно, более точное описание ситуации… но именно против этого действия протестует автор статьи…
AC130
04.07.2018 20:24+1гугл выдаёт относительную безопасность на сетевом уровне за безопасность как таковую
Очень жаль если Гугл так делает. Однако замечу, что надпись «Not Secure» у http-сайта не является «выдаванием относительной безопасности» за что-бы то ни было. Это предупреждение о небезопасном соединении.Scondo
04.07.2018 20:45-1Является. Это предупреждение об угрозе, появляющееся вне зависимости от того есть угроза или нет. Это мальчик, который кричит «волки».
А чтобы заставить его замолчать надо сделать действия, которые не защитят от других видов угроз, создав ложное чувство защищённости.AC130
04.07.2018 23:46+1Это предупреждение об угрозе, появляющееся вне зависимости от того есть угроза или нет.
Это предупреждение о незащищённом соединении, появляющееся при наличии незащищённого соединения. Это мальчик, который кричит «Нет ружья для защиты от волков».Scondo
05.07.2018 09:35Вот проблема в том, что это мальчик, который кричит «Нет ружья для защиты от волков» даже при походе через двор в туалет. И кричит не про то, что дома нет ружья, а что с собой не взял…
AC130
05.07.2018 10:07И кричит не про то, что дома нет ружья, а что с собой не взял…
У мальчика нет собственного ружья. Ружьё выдаёт веб-сайт. Если веб-сайт не выдал ружьё — мальчик предупредит об этом пастухов, дабы те знали что ружья нет и надо быть осмотрительней.
Вот проблема в том, что это мальчик, который кричит «Нет ружья для защиты от волков» даже при походе через двор в туалет.
В данной модели угроз единственное место, в котором не может быть волков — этолокалхостдом. Большая часть друзей мальчика видится с ним вне дома, и его предупреждения полезны. А остальные друзья обладают достаточным уровнем технических знаний дабы принять своего ближнего таким, какой он есть, и приглашать к себе домой другиемальчиковбраузеры.Scondo
05.07.2018 10:39единственное место, в котором не может быть волков — это
локалхостдом.
Локальная проводная сеть; сеть предприятия, к которой установлено VPN подключение; данные, валидность которых проверяется хэшем из HTTPS-страницы… не говоря о том, что требуется совершенно разный уровень безопасности для передаваемых персональных данных (включая данные кредитки) и для получения картинок. А предупреждение одинаковое и при открытии видео с домашнего сервера и при вводе пароля к он-лайн банку.
Может быть вы живёте в глухой Сибири, где поход через двор в сортир требует ружья, но бога ради, можно не ПГУАААААТЬ меня этими волками в субурбии…AC130
05.07.2018 11:16Вас никто ничем не пугал. В том, что предупреждения одинаковы, нет ничего ошибочного. HTTP — Not Secure HTTPS.
Scondo
05.07.2018 12:10Ну, если человек выходит из дома в туалет, а ему напоминают, что он не взял ружьё… это конечно, не совсем то же самое что «пугать» но идея примерно та же.
В итоге люди либо начинают таскать с собой ружьё всегда, превращаясь в параноиков. Даже когда оно мешает — лишь бы заткнуть назойливое предупреждение.(ходить на сайт производителя роутера для того, чтобы управлять роутером «безопаснее» чем на сам роутер)
Либо начинают предупреждение игнорировать. Даже когда это уже банк.
Не каждое соединение требует безопасности TLS. И напоминать об отсутствии TLS при каждом соединении — неправильно.
Если бы нынешняя ситуация рассматривалась, как временное решение до того, как будут введены механизмы позволяющие отличить безопасные подсети и безопасные данные от требующих внедрения дополнительной безопасности — я бы не возражал ни секунды. Но сейчас речь идёт о том, что HTTP должен вообще со временем умирать в пользу HTTPS.
Как будто пустить «умную» лампочку на сайт производителя и подключиться к этому сайту по HTTPS безопаснее, чем вообще запретить лампочке доступ в интернет и подключаться к ней по HTTP.
firedragon
04.07.2018 20:07У «Кошмарского» есть только одна проблема. Он слишком хорошо защищает.
Когда я прикидывался обычным пользователем, все было нормально.
Malsa
04.07.2018 08:39Да, это стоит не 20к, а 6-10к в год. Почти не то же самое.
Let's Encrypt не является панацеей, а лишь костылем, который нужные компании в нужны момент легко выпилятAkuma
04.07.2018 11:04Покупаю сертификат за 500 руб. в год. Плюс две с половиной строчки в конфиге nginx.
Если вам нужен wildcard сертификат, то конечно будет дороже, но далеко не 6-10к в год.
Либо, если совсем плохо с деньгами, подключите Cloudflare — это бесплатно. Разве что в IE6 не будет у вас сайт работать из-за SNI, но мы вроде уже вышли из пещер.Malsa
04.07.2018 13:23Это где такие цены на сертификаты? Даже у реселлеров не встречал.
В среднем у всех центров обычная валидация домена ~5к, wildcard ~20-30к.Akuma
04.07.2018 13:26Все зависит от типа сертификата. Если вам нужен сертификат как у Твиттера, например, то он будет стоить немеренно.
Но если вам, как мне нужен самый простой сертификат (но не Let's Encrypt), то какой-нибудь COMODO POSITIVE самое то.
Не сочтите за рекламу.
Покупал здесь: firstssl.ru/ssl
И здесь: ruweb.net/ssl
Полет нормальный уже не один год.
И там и там Wildcard 6-7к в год, обычный DV 500-700 руб.
UPD: В предыдущем комментарии ошибся со стоимостью Wildcard. Но обычным бложикам он и не нужен.Vilgelm
05.07.2018 05:25Если у вас 10 сайтов, то это уже 5000-7000 в год. LE или Cloudflare как-то приятнее.
ntfs1984
04.07.2018 15:09А если я хочу чтобы мой провайдер встраивал рекламу в мои блоги?
Если я хочу САМ разбираться с МОИМ провайдером и МОИМ (а вот это уже спорно, спасибо Гуглю) сайтом?stork_teadfort
04.07.2018 15:24Ну будьте справедливы, Гугл ваш бложик не закрывает — к вашему хостеру не приходят люди в форме гугл-полиции и не требуют сделать rm -rf для домашней директории сайта www.ntfs1984.ru.
Они всего то лишь будут помечать красным, когда ваш сайт будет открываться через ИХ браузер и понижать в выдаче ИХ поискового сервиса. Разве они не имеют права определять поведение своего собственного продукта?sumanai
04.07.2018 21:00Разве они не имеют права определять поведение своего собственного продукта?
Они фактически монополисты, так что нет.khim
05.07.2018 09:25Они фактически монополисты, так что нет.
Это с какого перепугу? Они не могут дискриминировать конкурентов — это да, но я не вижу каких конкурентов их действие в данном, конкретном, случае дискриминирует.
Tatikoma
04.07.2018 16:58Если вы действительно этого хотите, — вам достаточно передать ключи шифрования своему провайдеру.
ntfs1984
04.07.2018 19:46Этого — это чего именно?
Я хочу чтобы мне оставляли право выбора что МНЕ делать с МОИМ вебсайтом на МОЕМ хостинге.Tatikoma
04.07.2018 19:48«Этого» — того, чтобы провайдер встраивал вам рекламу. Вроде очевидно из предложения передать ключи шифрования.
Право выбора у вас никто не забирает. Вы можете выбирать хотите ли вы, чтобы ваш сайт открывался в хроме или нет. Хром не ваш, — вы не можете забрать у гугла право выбора, что им делать с их браузером.
khim
05.07.2018 09:27Я хочу чтобы мне оставляли право выбора что МНЕ делать с МОИМ вебсайтом на МОЕМ хостинге.
Вы по прежнему имеете делать что угодно со своим веб-сайтом. И люди, использующие не Chrome, а, скажем, Lynx, по прежнему смогут туда заходить…
zuborg
03.07.2018 20:36Мне, как сисадмину, открытость HTTP позволяет эффективно находить источники всяких проблем в работе сайтов (используя tcpdump, ngrep и подобное).
StallinHrusch
04.07.2018 13:15это вам позволяет находить «проблемы» только на стороне фронтенда (или я не правильно понял, какого рода косяки могут быть у сайтов, что надо аж до уровня TCP опускаться?), для чего с избытком хватает той же панели разработчика в хроме (если руками искать). Так что не такое это и большое достоинтсво открытости HTTP в с равнение с его недостатками.
zuborg
04.07.2018 13:30Сисадмины обычно бекендом занимаютя.
Ну, там проверить все ли запросы приходят куда надо и с нужными параметрами, найти повторяющийся шаблон в ддос-запросах и настроить блеклистинг (mitmproxy тут не поможет, увы), проблемы у клиента, незнакомого с отладочными панелями в браузере, всякое…StallinHrusch
04.07.2018 13:45пардон я подумал вы говорите про сторонние сайты, не про подконтрольные вам. ну тогда всякие Sentry как решение, если разрабы не накрутили собственный логгер. Так или иначе, сисадмину лезть в tcp это как-то уже моветон
zuborg
04.07.2018 14:18+2Ну как сказать, ситуации разные бывают, и иногда посмотреть живой трафик это самый простой (и надежный, что немаловажно!) способ узнать, что происходит в реальности. Логирование может что-то упустить, а в дампе трафика все на виду.
zhovner
04.07.2018 14:18У вас, как у сисадмина, должен быть приватный ключ от сервере. Вы можете его подсунуть в wireshark и так же удобно расшифровывать трафик.
zuborg
04.07.2018 14:28+2Да решение то найдется, только все ли оно будет таким эффективным?
Я через ngrep могу быстро собрать стат по тысячам запросов и выявить аномалии, запустив shell-однострочник, составленный за минуту. Лишние движения по расшифровке трафика (а серверов может быть гораздо больше одного) заберут время и ресурсы сервера (а, следовательно, на хайлоаде и не всегда возможны), или приведут к тому, что что-то будет упущено.
В любом случае, с HTTP анализ трафика гораздо, гораздо проще чем с HTTPS.zhovner
04.07.2018 14:39+2А вам неизвестно случаев, когда на вашем сайте у пользователя ломается верстка или появляется реклама просто потому, что его провайдер вставляет туда свой джаваскрипт и иногда это ломает верстку?
Вот например, случай из рабочего чата произошедший несколько дней назад. Для тестовой версии сайта создается поддомен без https, ссылка отправляется заказчику:
Угадаете в чем дело? И это не какой-то выдуманный теоретический случай, а реальная жизнь. В реальной жизни все подряд суют свое говно в HTTP сайты и единственный способ доставить клиенту контент в неизменном виде это HTTPS.zuborg
04.07.2018 16:08Известны, конечно, сам с таким сталкивался. Я не спорю, что защита контента от изменения нужная вещь. И защита от прочтения, в общем-то тоже. Просто защита от прочтения делает диагностику ошибок гораздо более сложной, только и всего.
rumkin
04.07.2018 16:59Проблема в том, что HTTPS не единственный способ, но Гугл навязывает его и выдает за панацею, не смотря на то, что у HTTPS есть свои слабые стороны (например возможность цензуры).
StallinHrusch
04.07.2018 17:06-1что за возможность цензуры такая есть у https?
DistortNeo
04.07.2018 17:23+2Потенциальный отказ центров сертификации в выдаче сертификатов.
StallinHrusch
04.07.2018 17:51-2одни откажут, к другим пойдем =) а если все откажут, то уже надо начинать плести шапочки из фольги и поднимать знамя революции
evgenWebm
05.07.2018 11:27У Гугла несколько проектов по безопасности и интернет технологиям.
HTTPS это только один из них.
Zenitchik
04.07.2018 18:31И это не какой-то выдуманный теоретический случай, а реальная жизнь.
Назвали бы провайдера-то.
KorDen32
04.07.2018 14:30Вы можете его подсунуть в wireshark и так же удобно расшифровывать трафик.
Нет! Это было возможно до повсеместного введения обмена ключами на основе протокола Диффи-Хеллмана. Сейчас же, если вы не делаете активный MITM прямо в момент соединения, расшифровать пассивно записанную сессию при наличии ключей не получится.
kalininmr
03.07.2018 20:40+2имхо — переход довольно прозрачный. все телодвижения на уровне вебсервера.
зато несколько уменьшает вероятность инъекций, например.Arris
04.07.2018 02:10Было бы куда делать инъекции.
Для интернет-магазина, скажем, смысл есть.
А для хомяка с пачкой страниц — ну смысл? Ноль.andreymal
04.07.2018 02:13Скрипт, майнящий биткоины. Meltdown/Spectre. Rowhammer. Да кучу всего можно придумать
Arris
04.07.2018 02:24Разъясните на пальцах, откуда он возьмется на хомяке, на котором даже jquery нет (или включаемых скриптов с других ресурсов), ванильный JS, ванильные гифки и табличная вёрстка конца прошлого тысячелетия?
Откуда он возьмется на хостинге типа chat.ru — я еще могу понять.
А если это это shared-хостинг? Подмена провайдером контента?
Но что мешает провайдеру подменять контент на уровне еще веб-сервера, еще на уровне генерации страницы? Ровным счетом ничего и я не понимаю, чем тут может помочь сертификат или https.andreymal
04.07.2018 02:30+1откуда он возьмется на хомяке
MitM же
что мешает провайдеру подменять контент на уровне еще веб-сервера
Контролировать провайдера, контролирующего веб-сервер, намного проще, чем MitM. В случае обнаружения проблем можно просто к другому не столь обнаглевшему провайдеру переехать, например
Arris
04.07.2018 02:40Лично мне, ламеру, не помешала бы статья с объяснением, не как работает MiTM, а как сделать MitM-атаку против сайта с HTTP в лабораторных условиях.
Понимаете, практическое руководство о том, как это сделать + объяснения, какие инструменты и механизмы этому препятствуют.Beyondtheclouds
04.07.2018 03:031. Идешь в макдак c ноутом
2. Открываешь не запароленую вайфай точку с именем типа McDonalds wifi(или что там сейчас похожее)
3. Ждешь пользователей и делаешь с их http трафиком что хочешь :)
С https не прокатит.QDeathNick
04.07.2018 10:01Мне кажется стоит это вставить в статью, т.к. Как автор не в курсе как это работает, как и многие читатели.
dev96
04.07.2018 10:58Даже ноут не обязательный. С андроид-устройства в универе как-то (в 2014-ом) заходил на чужие аккаунты сидящих в тот момент людей в ОК и ВК.
При этом для этого мне не потребовались какие-либо знания в этой области. Скачал сниффер, две кнопки тыкнул и все…
Я не «хакер» и даже в сети не разбираюсьStallinHrusch
04.07.2018 13:54а в 2014м разве авторизация вк\ок была не поверх https? как минимум форма логина должна была уже передаваться через https. да, если чел уже залогинен можно перехватить токен из заголовков (и то если там http), но это все таки токен а не креденшиалы. Кукисы так же давно умеют requireSSL Что-то не ладное творилось у вас в универе ;-)
dev96
04.07.2018 16:38не знаю, что было, а чего не было, но помню, что я на собственном опыте проверял надёжность открытых сетей. Для начала сниффер проверил дома в своей сети, и зашёл в вк в чужой сеанс. Тогда в клиенте ВК на андроид безопасное соединение (https) было по-умолчанию выключено.
В универе так же я проверял работу сниффера и словил несколько сеансов OK и ВК. Зашёл через один сеанс на «Моя страница» и всё. Чужие данные я не стал изучать, ибо мне это не нужно было.
Я просто убедился в том, что открытые сети и соединение по http — не безопасно!StallinHrusch
04.07.2018 16:44Я просто убедился в том, что открытые сети и соединение по http — не безопасно!
это понятно, но, как видите в этом топике собралась и оппозиция =)
А если по теме, заходить в чужии сеансы конечно же можно и это решается с помощью https, но, это еще не финиш, т.к. пара логин-пароль все равно не похищена. Да, вы сможете таким образом например угнать акк, но полное фиаско если вы сможете завладеть текущей парой логин-пароль. Тогда, например, вы сможете попробовать их на другом ресурсе, а как известно, пользователи частенько применяют одни и те же креденшиалы на нескольких ресурсах
kalininmr
04.07.2018 12:16кстати есть масса покруе вариантов. оффисы со слабыми точками.
а магазины даже вкуснее макдака
Stalker_RED
04.07.2018 13:51Только вот не " делаешь что хочешь" а «читаешь», да?
Можно (было!) украсть куку, и зайти с этой кукой во вконтактик.
Но если в архиве с котиками нет авторизации, то и логиниться некуда.Beyondtheclouds
05.07.2018 02:57Нет, именно «делаешь что хочешь»
Если просто слушать открытый вайфай макдака то можно только слушать(хотя незнаю может тоже есть варианты).
Если раздать свой открытый, маскирующийся под легитимный, то можно вместо страницы с котиками отдать что угодно, и встроить на нее что угодно.
Arris
04.07.2018 15:29Подождите, но причем здесь https?
Смотрите изначальный посыл:
Для интернет-магазина, скажем, смысл есть.
А для хомяка с пачкой страниц — ну смысл?
Вот заходит наш пользователь-жертва на сайт с картой Воронежского Метрополитена, который без https. Просто карта, просто картинка и абзац текста.
Вот рядом сидит C00L}{ATZKEP и сниффит его траффик. И вот насниффил кулхацкер траффик к нашей жертве с сайта Воронежского метрополитена. И что он с ним дальше будет делать?StallinHrusch
04.07.2018 15:36встроит в страницу майнер и поедет на бали
TrllServ
04.07.2018 21:19+2Через 12000 лет майнинга на смарте или нетбуке.
Вы это серьёзно?
Если уж рядом сидит C00L}{ATZKEP со среднестатистическим юзверем который не озаботился безопасностью, он быстрее на бали поедет если его девайс взломает, который запросто светит в вайфай сеть SMBv1 или прочими прелестями.
firedragon
04.07.2018 20:38Не стоит недооценивать предсказуемость тупизны(С). Щелкнут на попап и не заметят
StallinHrusch
04.07.2018 13:49провайдет не котнролирует веб сервер, провайдер не генерирует страницы. в случае с https провайдет забирает «что-то» от веб сервера и передает на клиент, это что-то он поменять не может никак. в случае http — он забирает сгенерированную страницу в чистом виде и может ей манипулировать как угодно и отправить на клиент все что ему пожелается.
Arris
04.07.2018 15:15Спасибо, кэп, за разъяснение. Я не знал (сарказм).
провайдет забирает «что-то» от веб сервера
Не вижу никаких сложностей в изменении генерации кода на уровне веб-сервера. Еще до https-wrapper'аStallinHrusch
04.07.2018 15:35Не вижу никаких сложностей в изменении генерации кода на уровне веб-сервера. Еще до https-wrapper'а
А я вижу =) для этого нужно довольно глубоко вмешиваться во внутренние механизмы конкретного веб-сервера и\или view генератора, если таковой имеется. А это все попахивает как минимум нетривиальным реверс-инженерингом, если не брать вариант с override-ом конфигов сервера (но это уже читерство если хостер подменяет ваши же конфиги)
kalininmr
04.07.2018 12:09ну отчегож.
какая-либо вечгая литература(корн корн, анатомический атлас, конституция древнего года и почее куда ходит дофига молодежи)
подшивки мукулатуры, банальные архивы школ.
да куча интересных мест куда часто заглядывют
EvilGenius18
03.07.2018 21:23+7Глупости, автор не понимает о чем говорит.
Используя HTTP, хостер по-сути помогает злоумышленникам / рекламщикам / провайдерам отслеживать интересы пользователя и в некоторых случаях напрямую получать информацию о пользователе.
Если сайт, работающий на HTTP, не запрашивает ввод какой-либо информации напрямую, это еще не значит, что пользователь имеет ту же степень сохранности данных, что и на HTTPSKlenov_s
03.07.2018 22:54+6Правильно! Ведь гугл никогда ничего не отслеживает и безумно рад конкуренции на поприще продажи рекламы ))
ainu
03.07.2018 23:22-4Лучше уж гугл отслеживает, следуя известным мне условиям соглашения, чем, на минуточку, любой желающий, не регулируемый ничем.
Какой-нибудь сферический билайн может подменить любой текст «ничего не запрашивающего блога», и хорошо, если это будет баннер, который просто сломает вёрстку. А если это заведомо ложная информация?
Это блог. Я не запрашиваю никакие данные у пользователей.
Пометка «ненадёжный» от Google обозначает:
Это блин означает, что буквально «информация, которую вы читаете на этом блоге, могла быть изменена провайдером, администратором, датацентом, хостером, соседом. Если Вы, следуя этой информации, принимаете критически важное решение, то мы должны предупредить — возможно, информацию предоставил не автор сайта». А это, извините, и есть «ненадёжный». И неважно, блог это или нет, запрашивает он что-то или нет.
В конце концов, пароль от админки «блога» мог перехватить любой в той же локалке и просто войти в систему через месяц. И сделав «ненадёжной» каждую букву в информации этого «блога».
Интернет бы не стал таким, какой есть, без HTTPS. Не было бы оплат, доверия, надежности. Был бы один бесконечный двач.
Не, пусть лучше гугл показывает мне релевантную рекламу, чем вот такое.daggert
04.07.2018 00:14+2Какой-нибудь сферический билайн может подменить любой текст «ничего не запрашивающего блога», и хорошо, если это будет баннер, который просто сломает вёрстку. А если это заведомо ложная информация?
Мб за это стоит бить по рукам "сферического билайна", а не пытаться решить проблему лишней финансовой нагрузкой на простые сайты?
andreymal
04.07.2018 00:15Позвольте поинтересоваться, где вы увидели финансовую нагрузку?
daggert
04.07.2018 01:14+2Ну вот я сижу на шареде. Он меня всем устраивает (совсем всем, вообще всем, на все 146%), но на нем нет возможности вкорячить https… Как без доп финансовой нагрузки тут обойтись? Я умею пользоваться VPS и пользуюсь по работе, но их цена, для не приносящего дохода личного бложика, меня не устраивает.
Сколько людей сидит на всяких шаредах с конструкторами и делают или делали шикарный контент? Я любитель старых игр и ОЧЕНЬ много всего нахожу на мелких сайтах, которые стоят на неизвестных хостингах и сверстаны чуть-ли не в ворде. Им как вставить сертификат?andreymal
04.07.2018 01:19-1Ну, вас, наверно, никто не заставлял выбирать такой плохой шаред ?\_(?)_/?
На нормальных шаредах уже давно завезли HTTPS. Как раз сегодня днём обновлял два Let's Encrypt сертификата на шаредах SpaceWeb. Да, немножко неудобно, потому что простой «sudo certbot renew» на шареде не написать, но всё ж переход на HTTPS стоил ноль рублей ноль копеек
Им как вставить сертификат?
Старые сайты это проблема, да. Но уж новые можно было потрудиться перевезти на нормальные шареды и без всяких HTTPSdaggert
04.07.2018 10:27Еще раз напишу: В моем хостинге меня ВСЕ устраивает, и большой ЖД и анлимиты по трафу. Меня не устраивает политика гугла, которая сейчас похожа на политику нашей страны, с ее отчетностями по токенам, континентами-АП и всем таким. Было и работало. Начали подменять — надо наказывать операторов, благо что каждое правительство каждой страны дает операторам лицензию, за которую они держаться. Пару предупредительных в виде штрафа в 10% прибили за год — никто больше не посмеет ставить плашки с платными подписками или свою рекламу.
andreymal
04.07.2018 10:38«Ещё раз напишу: в моёй Windows 95 меня ВСЕ устраивает. Меня не устраивает политика Mozilla, которая перестала выпускать обновления Firefox для Windows 95. Было и работало же.»
Примерно так выглядит ваш комментарий.
Пару предупредительных в виде штрафа
… злоумышленнику-анониму, сидящему за соседним столиком в макдональдсе и раздающему поддельный вайфай? Ну-ну, попробуйте.
А про операторов — вот когда в законах всех стран, подключенных к интернету, будут прописаны такие штрафы, тогда и поговорим. А сейчас без HTTPS высовываться нельзя даже не находясь в макдональдсе.
FreeMind2000
04.07.2018 12:05«Ещё раз напишу: в моёй Windows 95 меня ВСЕ устраивает. Меня не устраивает политика Mozilla, которая перестала выпускать обновления Firefox для Windows 95. Было и работало же.»
Нет, просто вы не понимаете смысла комментария да и всей статьи в целом, вот и всё.
Примерно так выглядит ваш комментарий.
А смысл такой — для сайта на HTTP вместо лживого ярлыка «Небезопасный» нужно писать правду «Не использующий HTTPS», и бороться не с HTTP блокируя такие сайты, а бороться с теми кто нарушает закон. В данном случае google со своим 'Not secure' — откровенно врет пользователям. Если хотят быть честными, пусть тогда в инсталяторе своего хрома тоже пишут 'Not secure'.
P.S.: HTTP нисколько не устарел, никто в здравом уме его из браузеров выпиливать не собирается, он вполне себе работает и поверх SSL и т.п. протоколов.andreymal
04.07.2018 12:11Полностью согласен.
Есть и обратная проблема: для фишинговых сайтов, получивших HTTPS, хром пишет, что они безопасные.
Но это никак не отменяет того, что daggert'у нужно менять шаред на более современный, а не продолжать сидеть на условном Windows 95.
а бороться с теми кто нарушает закон
Зачем бороться с нарушениями, когда можно устранить саму техническую возможность нарушения?
daggert
04.07.2018 12:22Дадите мне шаред на 100 гигов, с анлимитом, пингом в 5мс по городу, пыхом, апачем и муськой, за 0 рублей в месяц — я перейду с радостью.
andreymal
04.07.2018 12:25+1Позвольте поинтересоваться, что ж это за шаред такой, который даёт всё перечисленное, но при этом почему-то не даёт HTTPS? В поддержку не обращались по поводу HTTPS?
Areso
04.07.2018 13:00за 0 рублей в месяц
я думаю в этой ситуации глупо что-то требовать, кроме того, что уже есть. Можно лишь скромно попросить, абсолютно не рассчитывая на результат. Человеку дали на халяву хостинг, он им пользуется.
У меня тоже было и не раз такое, что мне давали ресурсы на халяву, но они были «as is». Да-да, в том числе сертификат от чужого домена со временем появился (что даже хуже, чем его отсутствие, потому что вместо not secure все мои пользователи видят заглушку в хроме и неочевидные действия надо предпринять, чтобы пройти на сайт. Зато стало «типо безопаснее»).
daggert
04.07.2018 13:53Один хостинг провайдер, который не взлетел, на базе местечкового интернет-провайдера. Заявки давно не принимаются, поддержка работает только над обновлением ПО, зато бесплатно и всех устраивает. Обращался — вариантов https нет, проект закрыт.
AC130
04.07.2018 20:39+1В данном случае google со своим 'Not secure' — откровенно врет пользователям.
Нет. HTTP — HyperText Transfer Protocol. HTTPS — HyperText Transfer Protocol Secure. Соответственно, HTTP — HTTPS без S, Secure, или Not Secure HTTPS.
Если хотят быть честными, пусть тогда в инсталяторе своего хрома тоже пишут 'Not secure'.
Инсталлятор Хрома подписан. Он вполне себе «Secure»FreeMind2000
05.07.2018 11:54+2Нет. 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 — не безопасен, а для своего хрома «почему-то» не вешает. Последнее время всё больше разочаровываюсь в «корпорации добра».
nagibat0r
05.07.2018 09:20А сейчас без HTTPS высовываться нельзя даже не находясь в макдональдсе
Если Вы такой специалист в плане ИБ, как пытаетесь показать в других ветках, то какого черта Вы сидите в общественных местах задницей наружу с голым HTTPS? Если Вас так заботит Ваша приватность, как минимум нужен tor+obfs, или на худой конец ,VPN (неважно, поднятый вручную где-то там, или доверенный провайдер).
sticks
04.07.2018 08:22К слову сказать, VDS для личных нужд сейчас можно найти и за $10 (меньше 700 рублей) в год. Плюсом к бложику там можно будет сделать практически всё, что душе угодно (например, поднять уютненькую приватную проксю). Другое дело, что на «администрирование» этого дела нужно какое-никакое время, а на шаред просто залил, и оно там живет
r0mik
04.07.2018 08:45зарегистрируйтесь на CloudFlare, подключите сайт по бесплатному тарифу, включите https — получите не только профит в виде бесплатного https, но еще и некоторую отказоустойчивость…
lomnev
04.07.2018 00:23Поддерживаю.
Не нужно прибегать к HTTPS как к аналогу засунуть голову в песок, вместо воздействия на реального злоумышленника. Это работает не только в интернете, но и в реальной жизни.
Всегда есть способ поизображать из себя страуса и сработать в стиле «моя хата скраю». Но это проигрышная стратегия.
В лесу волк нападает на людей? — Носите бронежилет! (HTTPS)
Но здравый смысл подсказывает, что лучше не бронировать свою задницу, а бороться со злом, которое угрожает не только конкретному индивидуму, а обществу в целом.
Придирки к деталям вроде «финансовой нагрузки» не относятся к обсуждаемой теме.kmeaw
04.07.2018 08:16Проблема этой аналогии в том, что добавить поддержку HTTPS на своём веб-сервере даже проще, чем реализовать MitM. Настройка выполняется один раз; это объективно проще, чем купить бронежилет и каждый раз надевать его перед прогулкой по лесу.
Тут скорее уместна аналогия с дверьми — не смотря на то, что общество борется со злоумышленниками, вход в своё жилище вы всё равно защищаете. Пока не придумали системного способа борьбы со злом, который бы устранил проблему навсегда (и вряд ли придумают), будет иметь смысл защищаться.
Даже в условиях, когда злоумышенников нет, HTTPS может помочь. Если кто-то неправильно (без всякого злого умысла) настроит прокси-сервер, сетевую маршрутизацию или DNS, что приведёт к обработке трафика не на том узле, использование HTTPS в большинстве случаев поможет сразу же обнаружить проблему — браузер покажет ошибку, и пользователи пожалуются.
StallinHrusch
04.07.2018 14:01здравый смысл подсказывает, что дверь в квартиру вы все же запираете, хотя правительство борется с ворами.
Temmokan
04.07.2018 09:08Ну, совсем на пальцах. Захочется мне передать что-то шибко секретное — шифрую тем же открытым ключом, вставляю шифротекст, передаю по HTTP. Браузер получает и дешифрует.
Дополнительно приписываю в HTML комментарии после закрывающего тега html цифровую подпись ко всему предыдущему. Чтобы кто попало по дороге не думал, что сможет произвольно и незаметно подправить контент.
Когда 100500сайтов фактически обяжут сидеть на HTTPS, то это либо single point of failure в лице того же LetsEncrypt (сдохнет доступ к его CA — что будем делать?), либо купленный у кого-то сертификат.
Так что нет, пока что не убедили, что HTTPS — единственный путь к безопасности.andreymal
04.07.2018 10:41шифрую тем же открытым ключом
А откуда вы открытый ключ возьмёте?
цифровую подпись ко всему предыдущему
А как именно получатель проверит цифровую подпись?
deathadmin
04.07.2018 11:49А откуда вы открытый ключ возьмёте?
Можно использовать OpenPGP для подписи текста, как в случае с email
А как именно получатель проверит цифровую подпись?
Вручную или с помощью расширения к браузеру. Например, вот это:
addons.mozilla.org/en-US/firefox/addon/signed-pages/?src=searchandreymal
04.07.2018 11:51Можно использовать OpenPGP
Можно-то можно, но на вопрос вы не ответили — откуда открытый ключ для OpenPGP возьмёте? Email это тоже касается, да.
Вручную или с помощью расширения к браузеру. Например, вот это
И откуда в нём появятся открытые ключи, необходимые для проверки?
deathadmin
04.07.2018 12:22Можно-то можно, но на вопрос вы не ответили — откуда открытый ключ для OpenPGP возьмёте? Email это тоже касается, да.
…
И откуда в нём появятся открытые ключи, необходимые для проверки?
Мне кажется, что вы рассматриваете PGP здесь, как средство шифрования. Я же говорю о цифровой подписи с открытым ключом. Конечно, здесь есть свои тонкости. Но в случае, если сервер ключей лежит, то можно через другие каналы связи попросить у автора ключ, что бы сверить цифровую подпись.StallinHrusch
04.07.2018 14:38круто, вы только что переизобрели https. вопрос только — зачем?
deathadmin
04.07.2018 16:09-1HTTPS существует с 2000 года, PGP — с 1991 года. Сколько вам лет?
StallinHrusch
04.07.2018 16:15+1не понял при чем тут «что когда появилось». я имел ввиду что вы напридумывали вагон костылей, которые почти полностью в итоге копируют существующие реализации
deathadmin
04.07.2018 16:20-1при том, что эти «костыли» существуют уже давно. То, что вы о них не знаете, заставляет меня думать что вам лет 20 и вы просто не застали этих технологий. Зато вы небрежно обвиняете меня в велосипедостроительстве.
StallinHrusch
04.07.2018 16:23старость костылей не оправдывает их применение, особенно если есть метод без костылей. а попытка задеть меня моим возрастом выглядит как детский сад с вашей стороны
Temmokan
04.07.2018 11:59Открытые ключи сторон можно передать в тех же HTTP заголовках, не проблема.
Техническая реализация проверки — расширение для браузера.andreymal
04.07.2018 12:00в тех же HTTP заголовках
… которые подменены человеком посередине на открытые ключи злоумышленника. Как мне доверять открытым ключам, переданным в HTTP заголовках?
TrllServ
04.07.2018 21:30… которые подменены человеком посередине на открытые ключи злоумышленника. Как мне доверять открытым ключам, переданным в HTTP заголовках?
Прочитать про дифи и хеллмана, обогатив себя знаниями как передавать открыто информацию и не боятся подмены.andreymal
04.07.2018 21:34-1Я прекрасно знаю и про Диффи, и про Хеллмана. Вот я обменялся ключами по протоколу Диффи-Хеллмана, без подмен — но как мне понять, что я обменялся с настоящим получателем, а не со злоумышленником? Как Диффи и Хеллман помогут отличить получателя от злоумышленника, если «некоторые два числа g и p» (цитата из википедии) заранее неизвестны?
andreymal
04.07.2018 21:44-1И да, переформулирую по-другому: если бы вы заглянули в в википедию, то узнали бы, что протокол Диффи-Хеллмана используется для получения общего секретного ключа. Чтобы получить общий секретный ключ, нужно заранее знать открытые ключи. Вот я и спрашиваю — откуда взять открытые ключи и как им доверять?
В той же википедии написано, что «чистый» протокол Диффи-Хеллмана уязвим к MitM-атакам.
TrllServ
04.07.2018 23:23+1Я прекрасно знаю и про Диффи, и про Хеллмана. Вот я обменялся ключами по протоколу Диффи-Хеллмана, без подмен — но как мне понять, что я обменялся с настоящим получателем, а не со злоумышленником? Как Диффи и Хеллман помогут отличить получателя от злоумышленника, если «некоторые два числа g и p» (цитата из википедии) заранее неизвестны?
Это прекрасно.
Одним абзацем показать, что протокол ДХ не понят от слова совсем.
В той же википедии написано, что «чистый» протокол Диффи-Хеллмана уязвим к MitM-атакам.
Ваши заявления подразумевают уровень знаний в ИБ заметно больше чем википедия.
Я исхожу из реальности, где лучшее что могло случится это ДХ и даже является головной болью многих спец.служб.
Итого мы имеем теоретическую митм уязвимость и тлс и дх.
Разница лишь в том, что у ДХ это единственная проблема безопасности. А вот у тлс есть еще несколько проблем. При чём гарантированное теоретическое решение митм проблемы обещает только квантовая передача данных. Которой нет в серии и пока не предвидится, да я прозрачно намекаю, что гарантированного решения митм ещё нет, ни для одного протокола, есть толькопротоколыпредложения как усложнить реализацию митм (напоминаю мы ведь говорим о теории).
Потому считаю отсылку на митм либо недостатком знаний в данном направлении, либо намеренным уходом от конструктива.andreymal
04.07.2018 23:30-1Я допускаю, что я мог чего-нибудь не понять — ну так расскажите, что именно я не понял и как ДХ обеспечивает безопасность при заранее неизвестных открытых ключах? Вы тоже не уходи?те от конструктива.
гарантированного решения митм ещё нет
Это прекрасно. Ещё один комментарий назад вы говорили, что ДХ позволяет не бояться подмены.
А вот у тлс есть еще несколько проблем.
Например? Не считая человеческий фактор — он будет всегда и везде.
Потому считаю отсылку на митм либо недостатком знаний в данном направлении, либо намеренным уходом от конструктива.
Основное назначение тлс и ДХ — это как раз защита от mitm. По отдельности они уязвимы, а вместе — то, на чём держится вся безопасность веба.
Напомню, с чего началась ветка: Temmokan предлагает не использовать HTTPS, то есть оказаться от тлс. Остаётся ДХ. И как же тогда решать эту «единственную проблему безопасности» ДХ? Расскажите, я действительно мог чего-нибудь не понять.
TrllServ
05.07.2018 00:25Я допускаю, что я мог чего-нибудь не понять — ну так расскажите, что именно я не понял и как ДХ обеспечивает безопасность при заранее неизвестных открытых ключах? Вы тоже не уходи?те от конструктива.
Что именно рассказать?Магическое действиеМатематическое обоснование ДХ на несколько страниц сюда скопировать?
Это прекрасно. Ещё один комментарий назад вы говорили, что ДХ позволяет не бояться подмены.
Прошу процитировать когда и где это было обозначено.
Например?Третья сторона. При чём это угроза вполне реальная. Особенно если вспомнить, что могут быть и решения специального суда, например, постановление суда FISC от 25 апреля 2013 года.
Напомню, с чего началась ветка: Temmokan предлагает не использовать HTTPS
Поиск показал только 3 совпадения по слову Temmokan. Причем два сообщение, и одно в вашем сообщении(после моего поста будет 4).
Я не вижу где он предлагает «не использовать HTTPS», вижу только предложенную им альтернативу. Которую он считает более легкой и более применимой в многих случаях получения информации. Далее вижу ваше возражение о невозможности безопасно передать ключи, и моё замечание о том, что такая возможность есть(это протокол ДХ).
Предполагая, что вы не знаете про ДХ о нём и рассказано выше.andreymal
05.07.2018 00:39-1Что именно рассказать?
Входные данные для алгоритма, например. И откуда они возьмутся. И почему этим входным данным можно доверять.
Прошу процитировать когда и где это было обозначено.
«Прочитать про дифи и хеллмана, обогатив себя знаниями как передавать открыто информацию и не боятся подмены.» Не бояться подмены — значит быть защищённым от mitm. Или упомянутые здесь слова внезапно приобрели новый смысл?
Третья сторона.
Как я уже не один десяток раз повторил ниже — можно работать с TLS и без третьей стороны, было бы желание. Доверять центрам сертификации никто не заставляет, как минимум в Firefox их можно отключить, сегодня проверял.
вижу только предложенную им альтернативу
Какую? Он пишет про «шифрую тем же открытым ключом», а откуда он возьмёт этот открытый ключ, которому можно доверять, он не упоминает (заголовкам HTTP доверять изначально нельзя). Чем он создаст цифровую подпись, он тоже не упоминает. Где он предложил альтернативу — непонятно.
моё замечание о том, что такая возможность есть(это протокол ДХ).
Опять же, я не исключаю, что я чего-то не понимаю в ДХ, но я не вижу, как результату ДХ можно доверять, когда нет изначально доверенных открытых ключей или что-то типа того. Пожалуйста, расскажите, как с помощью ДХ и без TLS (мы же здесь обсуждаем альтернативу TLS?) можно получить открытые ключи, которым можно доверять, когда изначально собеседники не знают друг о друге вообще ничего (кроме установленного TCP-соединения, например).
andreymal
05.07.2018 01:16-1Если я правильно понял матчасть и вывод wireshark, в TLS безопасность ДХ обеспечивается подписью ServerKeyExchange, внутри которого и передаются параметры ДХ. А вот как будет обеспечиваться безопасность ДХ без заранее известного доверенного ключа — я так и не понимаю
TrllServ
05.07.2018 02:20+1А вот как будет обеспечиваться безопасность ДХ без заранее известного доверенного ключа — я так и не понимаю
Вы либо невнимательно читали мой 2й ответ. Либо не уловили, что подошли к т.н. проблеме курицы и яйца.
Но я теперь понимаю, что не понятно. Как и было сказано проблема митм является больше теоретической. Потому как:
Скачивая браузер, в котором и зашиты сертификаты, которым вы считаете, что можете доверять, ничего не помешает мэну из мидла подменить и сертификаты или добавить свой. (хотя на самом деле он просто будет от давать сразу пропаченый инсталлер). На возражения типа я же могу проверить хеш с сайта, придётся сначала убедить себя в том, что вам не подменили хеш для сверки.
А текущий браузер которым смотрите хеш тоже откуда-то взялся и тоже мог быть подменен… уходим в долгую рекурсию (а кто-то в параною).
Итого даже если вы старательно доверяете гуглу, но именно они и лично вам не присылали CD или DVD с доверенным браузером(самые доступные носители защищенные от перезаписи), то заранее известный ключ можно подвергать сомнению.
Насколько я знаю, гарантированной защиты от этого неприятного мэна ещё нет. Покрайней мере для массового применения гражданскими лицами.andreymal
05.07.2018 02:35-1подошли к т.н. проблеме курицы и яйца
Я с этой проблемы и начал всю эту ветку, спросив «А откуда вы открытый ключ возьмёте» без HTTPS — странно, что вы это только сейчас осознали.
уходим в долгую рекурсию
Именно. Разорвать рекурсию можно обменом ключей при личной встрече с собеседником
убедившись, что это на самом деле он, а не клон-агент спецслужб. Но так как встречаться с условным админом условного гугла — идея так себе, то придётся снижать безопасность, доверяя кому-то ещё. Например, общим с админом гугла друзьям (сеть доверия в PGP), или кому-то, кто берёт на себя ответственность быть честным (центры сертификации в TLS). Так что как минимум от той части HTTPS, которая возится с ключами, мы особо никуда не уехали.
Temmokan ругает Let's Encrypt, так что, похоже, доверие по TLS его не устраивает, а альтернатив от него я всё же не увидел. Сеть доверия в PGP развивать разве что
TrllServ
05.07.2018 03:02+1Я с этой проблемы и начал всю эту ветку, спросив «А откуда вы открытый ключ возьмёте» без HTTPS — странно, что вы это только сейчас осознали.
Странно, что вы не знаете разницу между «открытый ключ» и «доверенный ключ/сертификат». Под первым обычно подразумевается часть протокола РСАили ДХи ничего про общедоступные сертификаты.
то придётся снижать безопасность
И наконец-то переходим от теории к практике. ИРЛ применяется адекватный уровень безопасности. Тот кто сможет митм, сможет и описанную ранее рекурсию.
Сеть доверия в PGP развивать разве что
Недавно была новость о том как спец.службы в даркнете около годанаркотой барыжилипроводили спец.операцию войдя в доверие много к кому. И потому создавать сеть доверия сейчас? Хотя тут могу согласиться, её доверия будет больше нынешних СЦ и она будет надёжнее в плане долговечности.
TrllServ
05.07.2018 02:00+1Входные данные для алгоритма, например. И откуда они возьмутся. И почему этим входным данным можно доверять.
Потому что имеется математическое обоснование этого. Любой кто дружит с математикой может это проверить.
Или упомянутые здесь слова внезапно приобрели новый смысл?
Они его имели изначально. Задача лишь послатьключчасть для ключа с открытой страницей. И шифровать общим ключом.
Про защиту от митм начал… andreymal знаете такого? Ну тот самый который любит себе же и перечить.
Как я уже не один десяток раз повторил ниже — можно работать с TLS и без третьей стороны, было бы желание. Доверять центрам сертификации никто не заставляет, как минимум в Firefox их можно отключить, сегодня проверял.
Разве уже общались ниже? Не помню.
Не вижу ни какого практического применения в удалении сертификатов, из протоколов построенных на сертификатах.
Какую?
Шифровать только часть документа, там где это действительно нужно. Остальное же просто подписывать одноразовыми ключами ака одноразовыми хешами для защиты от подмены.
Опять же, я не исключаю, что я чего-то не понимаю в ДХ, но я не вижу, как результату ДХ можно доверять, когда нет изначально доверенных открытых ключей или что-то типа того.
В шифровании не может быть и заготовленных и открытых и доверенных ключей. Так это же "Треугольник проекта", выбрать можно только 2 из 3х.
Опять же, я не исключаю, что я чего-то не понимаю в ДХ
Пожалуйста, расскажите, как с помощью ДХ и без TLS (мы же здесь обсуждаем альтернативу TLS?)
А что если я вам скажу, что ДХ это один из протоколов инициализации TLS?
Причём лучший, остальныечитай старыеаналоги не рекомендованы, но остаются в составе для совместимости. Что, кстати, тоже проблема.
Попробую всё же ещё разок.
Вас, предположим, сбивает с толку одинаковое слово «протокол».
На самом деле ДХ это конкретный протокол, а TLS это сборник протоколов, среди которых каждая из сторон выбирает из наличия. Т.е.
Из полного набора, сначала отбрасывается, то что не поддерживает клиент, потом то что не поддерживает сервер.
И вот прям сейчас читая хабру, у меня может быть значительно более высокий уровень защищенности соединения, чем у других, а посещая форум своего знакомого у меня будет ничтожный уровень защищенности(стоит минимальный набор крипто либ), при этом всё время это TLS и «зеленый замочек».
Кстати практическую возможность взломать уже демонстрировали, и защищеной можно считать только последнюю версию.
PS:
Почитав вашу переписку ниже, не могу не засуммонить nagibat0randreymal
05.07.2018 02:15-1Потому что имеется математическое обоснование этого.
А ещё имеется математическое обоснование абсолютной криптостойности шифра Вернама. Только это абсолютно никак не спасёт от утечки одноразовых ключей, если таковая случится, без отзыва их доверия. И одноразовые ключи сами по себе из ниоткуда тоже не возьмутся — собеседники должны передать их друг другу, что опять же требует чего-то заслуживающего доверия. Так что давайте вернёмся в реальность и не будем забывать, что без TLS собеседники никак не могут доверять друг другу — независимо от того, насколько там математически обоснован этот ваш ДХ.
Они его имели изначально.
Они — собеседники, его — открытый ключ? Если так, то это «изначально» вообще-то обеспечивают TLS и центры сертификации. Если нет ни TLS, ни центров сертификации — откуда это «изначально» возьмётся?
Шифровать только часть документа, там где это действительно нужно.
Это будет работать, если существует вышеупомянутое «изначально». А это «изначально» нужно ещё откуда-то получить.
В шифровании не может быть и заготовленных и открытых и доверенных ключей.
Упс, кажется, вы только что объявили PGP невозможным. Там ключи (1) заготавливаются заранее один раз на долгий срок (иногда даже бессрочно), (2) открытый ключ публично заливается на серверы ключей и (3) становится доверенным после личной встречи с собеседником.
А что если я вам скажу, что ДХ это один из протоколов инициализации TLS?
Я это прекрасно знаю и наблюдал его в wireshark всего час назад. TLS с помощью центров сертификации (или ручного доверия) предоставляет ключи, которые позволяют подписать ДХ и тем самым защитить его от mitm. Но, ещё раз, Temmokan предлагает, как вы говорите, какую-то альтернативу TLS. Так что ДХ в контексте данной ветки остаётся сам по себе, без TLS. И уязвимый перед mitm как следствие.
TrllServ
05.07.2018 02:28Упс, кажется, вы только что объявили PGP невозможным.
Не стоит выдавать желаемое за действительное.
PGP был прорывом для своего времени. там используется обмена рса или дх.
Что именно в PGP защищает от вашего любимого митм?
На остальное ответ в параллельном сообщении и 2м.andreymal
05.07.2018 02:38Что именно в PGP защищает от вашего любимого митм?
Обмен ключами при личной встрече.
Хотя если вы ведёте к тому, что личная встреча не является частью PGP и оттого не может считаться третьей точкой в «Треугольнике», то тогда ладно.
TrllServ
05.07.2018 07:46Я это прекрасно знаю и наблюдал его в wireshark всего час назад.
Так «прекрасно», что запускается срочно wireshark?
Вот это квалификация! А не подскажете как наблюдением отличаете ДХ от иных протоколов?
Но, ещё раз, Temmokan предлагает, как вы говорите, какую-то альтернативу TLS.Ещё раз?
Уговорили, повторяю. Я там вижу предложение шифровать выборочно, с подписью всей страницы. Что выглядит достаточно разумно, покрайней мере для меня т.к. знаю сколько и какого трафика проходит.andreymal
05.07.2018 10:51Так «прекрасно», что запускается срочно wireshark?
И что? Мне уже wireshark ни в коем случае нельзя запускать почему-то?
как наблюдением отличаете ДХ от иных протоколов?
Вы wireshark вообще хоть раз открывали? Он всё парсит и подписывает.
Я там вижу предложение шифровать выборочно, с подписью всей страницы.
Да, это там есть. Но ещё там есть «не убедили, что HTTPS — единственный путь к безопасности», недовольство тем, что «фактически обяжут сидеть на HTTPS» и переживания за «сдохнет доступ к его CA» — то есть всё то, что обеспечивает доверие к ключу, которым Temmokan собирается «шифровать выборочно, с подписью всей страницы». Если его не устраивает, что «сдохнет доступ к его CA», то остаётся вопрос, как тогда доверять открытым ключам перед подписью — я и спросил «А откуда вы открытый ключ возьмёте»? если не из CA, к которому сдохнет доступ.
TrllServ
05.07.2018 11:35Да, это там есть. Но ещё там есть «не убедили, что HTTPS — единственный путь к безопасности», недовольство тем, что «фактически обяжут сидеть на HTTPS» и переживания за «сдохнет доступ к его CA» — то есть всё то, что обеспечивает доверие к ключу, которым Temmokan собирается «шифровать выборочно, с подписью всей страницы». Если его не устраивает, что «сдохнет доступ к его CA», то остаётся вопрос, как тогда доверять открытым ключам перед подписью — я и спросил «А откуда вы открытый ключ возьмёте»? если не из CA, к которому сдохнет доступ.
А Скрипач не нужен, родной ©
Если я правильно понял начальные две записи Temmokan, он намекал о ненужности сертификационных центров.
По причине того, что у кого хватит ресурсов стать посередине, хватит и обойти костыль сертификатов.
Как именно тоже описано в одном из сообщений выше про «рекурсию».
И я всё еще не понимаю, что вам не понятно? Если только… вера в независимость и неподкупность СЦ?
Но даже это уже опровергнуто практикой, пример уже был выше. Значит сильно не внимательны.andreymal
05.07.2018 11:54он намекал о ненужности сертификационных центров
Ну так вопрос-то всё равно остаётся — «А откуда вы открытый ключ возьмёте», если не от сертификационных центров?
«Рекурсия» это проблема, да. Но, думаю, можно попытаться смягчить её, например, скачиванием браузера через разных провайдеров — хэш должен быть одинаковым у всех скачанных файлов (а если хэши отличаются, значит кто-то подменил браузер). Ну а если уж подменять станут абсолютно все провайдеры (по приказу государства, например) или же если врубить теорию заговора и считать, что все браузеры сотрудничают со всеми государствами, то я как простой смертный уже ничего не смогу сделать и остаётся только шапочку из фольги надевать да на митинги ходить. (Ну или вручную решать доверие к каждому сертификату. Но откуда мне знать, что в RSA нет каких-нибудь уязвимостей? Где там моя шапочка?)
вера в независимость и неподкупность СЦ?
Ага.
Но даже это уже опровергнуто практикой, пример уже был выше. Значит сильно не внимательны.
Видимо, в этом посте я что-то проглядел. Из подобных примеров знаю только WoSign да StartCom, но их-то уже выпнули отовсюду. А тут ещё нижеупомянутый Certificate transparency завозят, затрудняющий левые манипуляции с сертификатами
TrllServ
05.07.2018 12:14«Рекурсия» это проблема, да. Но, думаю, можно попытаться смягчить её, например, скачиванием браузера через разных провайдеров — хэш должен быть одинаковым у всех скачанных файлов (а если хэши отличаются, значит кто-то подменил браузер). Ну а если уж подменять станут абсолютно все провайдеры (по приказу государства, например)
Простите, только из лесу?
Тогда советую просмотреть жаркую эпопею под названием «заблокирую телеграмм».
Если бы у вас была хоть капля аналитики вы б увидели там очень быстрое исполнение приказа РКН, даже несмотря на то, что он мог оказаться нелегитимен. При чём делало это очень оперативно. Иногда даже слишком, без времени для подумать.
А по доверию СЦ процитирую написанное ранее:
Третья сторона. При чём это угроза вполне реальная. Особенно если вспомнить, что могут быть и решения специального суда, например, постановление суда FISC от 25 апреля 2013 года.
Чисто для понимания этот сайт заверен тем же комодом.
Логическую цепочку продолжить дальше самостоятельно получится?andreymal
05.07.2018 12:40эпопею под названием «заблокирую телеграмм»
Это вы про что-то там с треском провалившееся?
При чём это угроза вполне реальная
Это ужасно, но не имеет отношения к безопасности HTTPS. Даже если абсолютно все центры сертификации откажутся выдавать сертификаты Sci-Hub'у, всегда остаётся вариант получить его у Александры Элбакян каким-либо путём (может, даже при личной встрече — всё-таки она не админ гугла; если она не прячется от всех подряд, хз где она сейчас) и вручную добавить сертификат в доверенные.
Мой доверие к цетрам сертификации строится не на том, что они выдают сертификаты любому домену (как продемонстрировал Sci-Hub, не любому), а на том, что они не выдают поддельные сертификаты кому попало. WoSign и StartCom, которые немножко засветились в подобном, уже выпнуты.
Логическую цепочку продолжить дальше самостоятельно получится?
Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более. Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.
TrllServ
05.07.2018 12:59на том, что они не выдают поддельные сертификаты кому попало
Вы проверили все выданные сертификаты?
А все ответы соответсвующих серверов комода?
Вопросы очевидно риторические. А потому утверждение не имеет никаких обоснований кроме «я о таком не знаю».
Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.
Тогда говорить будет поздно.
Просто потому, что об этом ни кто не узнает.
А очередной Сноуден, который всем сможет это рассказать — появится не скоро.
Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более.
Вы видите только то что хочется.
А я вот ещё паралельно вижу, что комодо исполнил решение суда.
И исполнит ещё одно решение в котором будет сказано «дать положительные ответы на запросы от… того на кого агент джон доу покажет пальцем», хотя почему исполнит — уже исполнил.andreymal
05.07.2018 13:02Ну тут остаётся только шапочку из фольги надеть.
TrllServ
05.07.2018 13:07Да нет, вам просто не стоит в серьёзную безопасность.
Там просто не существует слова «доверие», только слово «проанализировал(а)» и «проверил(а)».andreymal
05.07.2018 13:11О, вы уже второй раз объявили невозможным PGP, в котором есть «сеть доверия».
TrllServ
05.07.2018 13:15О, вы уже второй раз объявили невозможным PGP, в котором есть «сеть доверия».
Я и в третий раз могу вам напомнить как в даркнете работали спец.агенты втёрлись в доверие и работали в течении года.
Вы лично можете гарантировать, что в «сети доверия пгп» нет десятков точек от спец.служб лидирующих стран в разведке?
А что там не прописались мошенники или ещё кто-то?andreymal
05.07.2018 13:18Я не могу даже гарантировать, что мои родители не являются чьими-нибудь шпионами, чё тут уж про сеть доверия говорить.
Ну тут остаётся только шапочку из фольги надеть.
BeppeGrillo
05.07.2018 13:53Нет. Я не вижу проблем безопасности в том, что у Sci-Hub отозвали сертификат. Я вижу лишь обнаглевший COMODO, но не более. Когда COMODO выпишет для условного АНБ поддельный сертификат и останется безнаказанным, тогда и поговорим.
Symantec поддельных сертификатов выпустил тридцать тысяч за несколько лет.
А раз мы говорим Symantec то мы говорим и GeoTrust, VeriSign, Equifax, Thawte и RapidSSL. Впечатляет?
И это были не просто сертификаты вроде ЛетсЕнкрипт, это были дорогие суперсертификаты EV используемый банками и корпорациями, ну знаете это когда не просто зелёный замочек а ещё название компании.
Да их наказали, спустя несколько лет. А до этого? До этого HTTPS годами «защищал» вас.andreymal
05.07.2018 13:59Вот это уже более серьёзно.
Осталось предложить альтернативу.
TrllServ
05.07.2018 14:05+1Вот это уже более серьёзно.
Всмысле серьёзно?
Осталось предложить альтернативу.
Вы рассуждаете о доверии Сц, при этом не знаете важных событий ИБ?andreymal
05.07.2018 14:07То, что вы вспомнили зачем-то телеграм вместо Symantec, говорит о том, что вы тоже не знаете. Но всё же, если СЦ доверять нельзя — предложите альтернативу?
Temmokan
05.07.2018 02:39+1Процитируйте, где это я «предлагаю не использовать HTTPS» (именно в такой формулировке)?
При наличии достаточно надёжного способа передачи открытого ключа от HTTP-сервера вся последовательность предложенных мной действий предотвращает MITM.
Сервиса обмена ключами можно организовать и на HTTPS, суть моего утверждения — что нет необходимости во всеобщем переходе на HTTPS. Который без всеобщего внедрения того же DANE создаёт только иллюзию безопасной передачи.
И ещё раз попрошу не приписывать мне то, что я не утверждал.andreymal
05.07.2018 02:46-1Вам не понравился «single point of failure» в виде Let's Encrypt, то есть вы усомнились в центрах сертификации, с помощью которых работает HTTPS. Так как центры сертификации — основная фишка HTTPS, то я счёл допустимым сделать вывод, что вы предлагаете не использовать HTTPS. Если я ошибся, значит вы комментарий так коряво сформулировали)
Если не центры сертификации, то значит предложите какой-то другой «достаточно надёжный способ передачи открытого ключа в HTTP»
Сервиса обмена ключами можно организовать и на HTTPS
У которых HTTPS-сертификат от Let's Encrypt, который single point of failure, из-за которого всё плохо? Тогда останутся все те проблемы HTTPS, которые вы упомянули в своём комментарии («сдохнет доступ к его CA — что будем делать?»)
Temmokan
05.07.2018 03:08Ну конечно, это не вы так коряво поняли и что-то там предложили — это я коряво сформулировал. А как же ещё.
> У которых HTTPS-сертификат от Let's Encrypt,
Необязательно на Let's Encrypt. Опять вы сочиняете что-то, что я якобы подразумеваю, чтобы потом с довольным видом вести полемику с вашей же выдумкой?
Ляжет упомянутый мной канал — что уже представляет собой глобальную проблему — задействуйте другие каналы, где криптография работает (той же электронной почтой), и так далее, вплоть до личной передачи ключа на носителе (напоминаю ещё раз, чтобы вы мне ничего нового не приписывали, что альтернативные способы — для чрезвычайной ситуации, когда HTTPS для данного конкретного сервиса не работает).andreymal
05.07.2018 03:16-1Если вы не предлагаете не использовать HTTPS и если Let's Encrypt вас всё-таки устраивает, то тогда я совершенно перестал понимать, о чём был ваш комментарий
вплоть до личной передачи ключа на носителе
Это всё можно сделать в рамках HTTPS (в любом браузере есть ручное добавление «лично переданного на носителе» ключа в доверенные), так что я продолжаю вас не понимать
Temmokan
05.07.2018 03:43+1> Если вы не предлагаете не использовать HTTPS и если Let's Encrypt вас всё-таки устраивает
И опять вы приписываете мне то, что я не подразумеваю. А ведь я уже всё сказал выше. Цитирую себя:
«суть моего утверждения — что нет необходимости во всеобщем переходе на HTTPS»
Выделил жирным то, что именно утверждаю.
Если всё равно не понимаете — что ж, продолжайте не понимать.nagibat0r
05.07.2018 07:32+1Этот товарищ сам себе противоречит, не обращайте внимания. Он не понимает, что HTTPS в том виде, в котором он есть, является лишь иллюзией безопасности, о чем я неоднократно сказал… Но видимо, раз он решил, что удалив (!) все сертификаты и все центры из доверенных, он получает end-to-end, то спорить бесполезно
Temmokan
05.07.2018 08:14+1Согласен.
Так или иначе приходится кому-то (чем-то) доверять — тому, что ответ DNS никто не подменит, что сертификаты в хранилище компьютера не подменные, и так далее. По мне — чем меньше сущностей, которым придётся доверять «на слово», тем меньше головной боли.
andreymal
05.07.2018 10:56-2HTTPS в том виде, в котором он есть, является лишь иллюзией безопасности
HTTPS в том виде, в котором он есть — безопасность на базе доверия неподкупным центрам сертификации. Сомневаетесь в том, что они неподкупные — убираете «третью сторону», удалив корневые сертификаты из браузера, решаете вопрос доверия к каждому ключу самостоятельно и получаете end-to-end.
удалив (!) все сертификаты и все центры из доверенных, он получает end-to-end
А вы настолько весь такой компетентный, что до сих пор не смогли доказать обратное. Вы присылали определение end-to-end — я вам расписал, что HTTPS полностью под него подходит.
nagibat0r
05.07.2018 13:16Вы неверно трактуете понятия и описания — Ваше дело. Вы не понимаете отличий end-to-end от https? Очень жаль, хотя это уже Вам не раз говорилось. Я устал с Вами спорить, потому что Вам ничего не докажешь. И Вы прекрасно знаете, что end-to-end это далеко не https, даже если выпилить третью сторону, это разные вещи, и хватит заниматься троллингом, уже очень жирно, на самом деле.
andreymal
05.07.2018 13:42Вы так не объяснили, чем https с выпиленной третьей стороной принципиально отличается от end-to-end.
lorc
05.07.2018 20:50ДХ не аутентифицирует. ДХ лишь позволяет надежно установить общий секрет. Но вы не знаете с кем именно вы установили общий секрет.
PAE
03.07.2018 21:31+3С одной стороны — автор вроде как прав и считать такое "принуждение к HTTPS" принуждением — корректно, ведь само письмо построено как "условие".
С другой стороны — даже если сайт никак не принимает и не обрабатывает данные пользователей — он отдаёт данные, почему автор никак не задумался о целостности данных, которые "отдал" сайт и которые "получил" пользователь? Способов использовать то, что "летит" к пользователю масса: аналитика, реклама, фишинговые кнопки с джаваскриптовыми подарками от провайдера.
Было бы логично, например, жёстко запретить приём данных без HTTPS, а для контента просто выводить уведомление, а не "страшный" заголовок про "No secure", будто бы сайт фишинговый.
P.S.: не пользуюсь Chrome и не собираюсь до тех пор, пока Firefox не является его клоном — там хотя бы информацию о сертификате по клику в адресной панели не засунули в такое место, что приходится гуглить или выдумывать, как вернуть такую простейшую функцию обратно.
andreymal
03.07.2018 21:37+1P.S.: не пользуюсь Chrome и не собираюсь до тех пор, пока Firefox не является его клоном — там хотя бы информацию о сертификате по клику в адресной панели не засунули в такое место, что приходится гуглить или выдумывать, как вернуть такую простейшую функцию обратно.
Не знаю, чё там в Chrome, но в последних Chromium информация о сертификате стала даже на один клик ближе, чем в Firefox
ainu
03.07.2018 23:26Вот же, куда прощеalexey-m-ukolov
04.07.2018 05:39Это появилось в этой или прошлой версии. До этого пару лет кнопки «Certificate» там не было.
andreymal
03.07.2018 21:33+11Какой-то глупый пост.
Они [архивы] просто работают.
И обрабатываются человеком посередине. И совсем не факт, что обрабатываются в мирных целях.
Я хочу, чтобы людям было всё проще и проще запускать собственные веб-серверы.
nginx запускается с пол-пинка даже на винде. Сертификаты Let's Encrypt прикручиваются ещё с пол-пинка. А если разрабатывать собственный веб-сервер — зачем?
мы потеряем множество сайтов, созданных на коленке за 25 лет существования Сети
Множество HTTP-сайтов, которые имеют низкую посещаемость, несут ценные идеи и заслуживают сохранения.Возможно, это единственное что-то не совсем глупое в этом посте
не запрашивают у пользователя никакой информации
Зато отдают её пользователю, и человек посередине может подмешать туда что-нибудь нехорошее.
не упоминают, что [Google?] сами могут делать это в браузере
Никто не запрещает использовать, например, Firefox. И вообще что угодно другое — HTTPS вроде бы поддерживается всеми адекватными программами.
Если HTTPS — это так круто… Тогда зачем заставлять людей?
Затем, что люди нихрена не понимают в компьютерной безопасности. Даже те, кто делает сайты.
Мы не хотим, чтобы всё было безопасным.
Я хочу.
Столько всего небезопасно. Пересечение улицы.
Автор поста переходит дорогу не по переходу и/или на красный свет? Рад за него, а остальные-то тут при чём?
Жизнь вообще небезопасна.
Ну давайте теперь уберём светофоры и разметку и отменим правила дорожного движения, ага.
Но архив моего блога за 2001 год? Серьёзно, здесь нет нужды в особых требованиях.
Откуда я могу знать, что я вижу именно архив блога за 2001 год? Может, мой провайдер испытывает ненависть к автору поста и подменяет содержимое блога чем-нибудь нехорошим?
Google попытался взять под контроль открытый Интернет
Google попытался сделать интернет чуточку безопаснее, исключив MitM-атаки. Автор — белка-истеричка.
Пожалуй, единственное мало-мальски серьёзное беспокойство по поводу HTTPS — это Let's Encrypt. Сейчас он весь такой бесплатный и удобный — а вдруг в будущем испортится? Или, к примеру, тот же StartSSL прикрыли — вдруг и Let's Encrypt однажды прикроют? Не о том автор беспокоится, ох не о том.
VBKesha
03.07.2018 22:56-1Затем, что люди нихрена не понимают в компьютерной безопасности. Даже те, кто делает сайты.
Ну да раньше ктото делал фишерский сайт на HTTP и както не внушало доверия, а на HTTPS бац и уже зеленй красивый замочек а сертификаты всем дают.
deathadmin
03.07.2018 23:57+3Какой-то глупый пост.
не соглашусь
И обрабатываются человеком посередине. И совсем не факт, что обрабатываются в мирных целях.
Как HTTPS это вопрос решает? гугл-аналитика, яндекс метрика и т.д. и т.п. Все эти скрипты собирают достаточно много данных о пользователях, которые кто знает кто куда сливает потом.
nginx запускается с пол-пинка даже на винде. Сертификаты Let's Encrypt прикручиваются ещё с пол-пинка. А если разрабатывать собственный веб-сервер — зачем?
Например, если я захочу поднять в веб-сервере для локального теста сайт с именем example.dev, то хром меня будет посылать пока я не повешу на этот домен сертификат. Такое себе с пол пинка…
Зато отдают её пользователю, и человек посередине может подмешать туда что-нибудь нехорошее.
единственный верный пункт в вашем ответе
Никто не запрещает использовать, например, Firefox. И вообще что угодно другое — HTTPS вроде бы поддерживается всеми адекватными программами.
То есть, от недоверия к гуглу и провайдерам мы переходим до недоверия к браузерам.
Затем, что люди нихрена не понимают в компьютерной безопасности. Даже те, кто делает сайты.
Как часто во времена голого HTML+CSS вы чувствовали себя не в безопасности? Другое дело, что сейчас без VPN/AdBlock/NoScript в сеть выходить то еще удовольствие.
Я хочу.
А я нет.
Автор поста переходит дорогу не по переходу и/или на красный свет? Рад за него, а остальные-то тут при чём?
Мало людей сбивало на зебрах на зеленый свет? Или в вашем мире дураков на дорогах нет?
Ну давайте теперь уберём светофоры и разметку и отменим правила дорожного движения, ага.
Я так понимаю, что ваша альтернатива — это связать руки/ноги всем людям на земле, что бы все были в безопасности.
Откуда я могу знать, что я вижу именно архив блога за 2001 год? Может, мой провайдер испытывает ненависть к автору поста и подменяет содержимое блога чем-нибудь нехорошим?
Если вы раньше читали статью, то найдете несоответствие в архиве. Как вам такой вариант, а?
Google попытался сделать интернет чуточку безопаснее, исключив MitM-атаки. Автор — белка-истеричка.
Вас точно не смущает, что одна корпорация решает за всех?hVostt
04.07.2018 00:10+2— Давайте поставим перила, чтобы люди не сваливались, и настоятельно попросим всех остальных тоже ставить перила.
— Я так понимаю, что ваша альтернатива — это всё забором обнести и посадить всех в клетку?!?!?
Как почитаешь некоторые «аргументы», так сразу отношение к некоторым драконовским законам сразу смягчается.
andreymal
04.07.2018 00:12Как HTTPS это вопрос решает? гугл-аналитика, яндекс метрика и т.д. и т.п.
А без HTTPS — гугл-аналитика, яндекс метрика, билайн, мегафон, теле2, вася пупкин за соседним столиком в макдональдсе… Вот видите, HTTPS сразу отсекает кучу левака и оставляет только то, что подключено на сайте на самом деле :) А то, что там подключено — это уже проблемы сайта, я могу не посещать сайт с аналитиками и метриками, если не захочу.
example.dev, то хром меня будет посылать пока я не повешу на этот домен сертификат.
Полностью согласен с наличием проблемы, но это немного не по теме поста, и вам никто не мешает взять любой другой домен
То есть, от недоверия к гуглу и провайдерам мы переходим до недоверия к браузерам.
Да. Браузеру (да и гуглу тоже) я доверяю во много раз больше, чем провайдеру.
Как часто во времена голого HTML+CSS вы чувствовали себя не в безопасности?
Постоянно. Помогает только принцип Неуловимого Джо.
ваша альтернатива — это связать руки/ноги всем людям на земле
Моя альтернатива — заставить вас переходить дорогу на зелёный свет. Да, так тоже иногда убивают (вот буквально недалеко от моего дома месяц или два назад так сбили человека, переходившего на зелёный; не задержись я на десять минут — на том перекрёстке мог оказаться я), но что же теперь — нарушать правила и ходить на красный? Что так собьют, что этак собьют — какая разница? Давайте не доводить до абсурда.
Если вы раньше читали статью
А если не читал?
одна корпорация решает за всех
Как минимум две — ещё Mozilla. И решают они в целом правильно.
Вы бы лучше беспокоились за фактическую монополию Let's Encrypt (который теоретически может превратиться в тыкву) и за то, что на локалхост и на 192.168.1.1 (и на домены dev) тоже заставляют ставить HTTPS — вот это настоящие проблемы, а не то, про что ноет автор поста.
deathadmin
04.07.2018 01:01Вот видите, HTTPS сразу отсекает кучу левака и оставляет только то, что подключено на сайте на самом деле :)
Я бы сказал, что остается только «легальный левак». Другой пример, фейсбук сливал данные о пользователях без всяких MITM. Я к тому, что идеалезировать гугл не стоит. Им управляют люди, а люди известны своей переменчивостью.
Полностью согласен с наличием проблемы, но это немного не по теме поста, и вам никто не мешает взять любой другой домен
Да, не совсем по теме. Но факт того, что гугл за меня решил присутствует. :)
Да. Браузеру (да и гуглу тоже) я доверяю во много раз больше, чем провайдеру.
Меня гугл давно уже не устраивает как поисковик, хотя замены ему на данный момент нет. А рекомендации на youtube вообще бесполезны, так как я по ним не узнаю ничего нового, а лишь то что уже знаю. К браузеру я отношусь спокойнее. Во всяком случае до тех пор, пока есть chromium и открытый баг-трекинг.
Постоянно. Помогает только принцип Неуловимого Джо.
Не знаю… До появления Google Adsense и популяризации javascript было весьма весело жить.
Что так собьют, что этак собьют — какая разница? Давайте не доводить до абсурда.
Ну, иногда хочется бросаться в крайности. У каждого человека свои тараканы и привычки :)
А если не читал?
на сколько сильно вы цените личные мнения людей из архива? Автор не цепляется за мировую историю или еще какие-то научные статьи. Речь о личных сайтах. К тому же, мое мнение 10 лет назад из архива вполне может не совпадать с теперешним мнением.
Как минимум две — ещё Mozilla. И решают они в целом правильно.
О, это как размеры обуви. В целом все обуты, но в конкретном случае кому-то жмет и он ели ходит из-за мозолей.
Иными словами, я как и автор статьи наслаждался интернетом в те годы, когда им по сути управляли гики. Сейчас монополия сделала своё. Страница в вебе? — соц.сеть, вместо того, что бы сверстать свой тематический сайт/форум. Информация на тему IT? — оригинальный источник или перевод статьи на хабре, вместо поиска информации в сети на независимых сайтах. Чат? — еще десяток IM клиентов, вместо поддержки силами сообщества своего IRC/Jabber сервера.
Вы бы лучше беспокоились за фактическую монополию Let's Encrypt
Я бы не беспокоился, если бы из-за гугла не пришлось бы прибегнуть к услугам Let's Encrypt. Собственно, об этом автор оригинальной статьи и пишет. А, еще у гугла есть такая штука, как Google Content Manager. Что если, её взломают и на миллионах сайтах в сети злоумышленник разместит свой текст/код? Люди слишком доверяют одной корпорации.
dragoangel
04.07.2018 02:08а в чем сообственно проблема сгенерировать свой СА или сделать самоподписный сертификат на домены dev и на IP 192.168.1.1? =) Если конечно железо (сохо роутер на вскидку) «заимпортировать» или софт позволяет его прикрутить. После этого добавить СА или сертификат в центр довереных и все.
andreymal
04.07.2018 02:11Я себе так и сделал (не потому что заставляют, а потому что хочу HTTPS на локалхосте тестировать), но всё ж в целом это довольно бессмысленно (какой нафиг MitM в локальной сети — электромагнитный фон из витой пары соседи подслушивать будут что ли лол?)
dragoangel
04.07.2018 12:00По поводу DEV — тут https нужен что бы тестировать работу веб-приложения сразу под https. А на домашний роутер у меня https банально потому что он доступен из мира. Во вторых — есть роутеры без пропатченого WPA2 уязвимого к прослушиванию трафика из-за ключей реинициализации — и тут https на админку роутера становится как ни как к стати.
deathadmin
04.07.2018 14:23По поводу DEV — тут https нужен что бы тестировать работу веб-приложения сразу под https.
Это не совсем так. Гугл уже сделал доступными для публичной регистрации домены в зоне .app. Следующая на очереди зона — .dev
Подробности тут — www.registry.google
WebConn
04.07.2018 13:41Один из простых MitM в локалке — левый DHCP с нужными настройками на том же свитче, что и вы, плюс прокси для пропускания вашего трафика. С вайфаем аналогично, лишь бы доступ к сети получить. Не 100% гарантия срабатывания, но часто срабатывает. Если всё правильно сделать, пользователь ничего не заметит.
На практике именно с MitM такого типа не сталкивался, но со вторым DHCP в локалке — было дело с одной китайской железкой.
dartraiden
04.07.2018 14:56Домашние роутеры почти всегда имеют и беспроводную сеть. Если клиентское устройство не пропатчено от KRACK, то злоумышленник может пассивно прослушивать трафик беспроводной сети, даже не зная пароля от неё.
Я бы не хотел сдавать любопытному соседскому пареньку пароль от админки роутера или проекта, который тестирую у себя в локалке. Хорошо, если пароли везде уникальные, а если этот пароль идентичен или похож на пароль от беспроводной сети? (ну кто там будет слушать в моей локалке...) Или от ещё какого-то сервиса? Или в продакшен пойдёт с тем же паролем?
И ведь избежать этого так просто.
gremlin244
04.07.2018 18:20Моя альтернатива — заставить вас переходить дорогу на зелёный свет. Да, так тоже иногда убивают (вот буквально недалеко от моего дома месяц или два назад так сбили человека, переходившего на зелёный; не задержись я на десять минут — на том перекрёстке мог оказаться я), но что же теперь — нарушать правила и ходить на красный? Что так собьют, что этак собьют — какая разница? Давайте не доводить до абсурда.
Тут скорее уместнее провести аналогию, ну например с альпинизмом. Или каким-нибудь экстремальным видом спорта. Вообще небезопасные же вещи. Но это не означает что их надо запретить, а то там люди могут же шею себе свернуть. Если я имею желание зайти на потенциально вредоносный, небезопасный сайт, то с чего вдруг кто-то имеет право мне это запретить?khim
05.07.2018 09:32Если я имею желание зайти на потенциально вредоносный, небезопасный сайт, то с чего вдруг кто-то имеет право мне это запретить?
Скачиваете специальный, «альпинистский» браузер и заходите — делов-то.
belyvoron
04.07.2018 07:20nginx запускается с пол-пинка даже на винде. Сертификаты Let's Encrypt прикручиваются ещё с пол-пинка.
это если есть ngnix. А если там, прости господи, древний Lotus? Ставить перед ним reverse proxy? Можно, конечно, но за чей счёт банкет? И вообще, HTTP — это не только сайты в интернете. Устройства промавоматики часто имеют веб-морду. Да, по HTTP. А среди энтузиастов сейчас популярны микроконтроллеры ESP8266 за 1,5 доллара — это полноценный IoT с WiFi и там можно воткнуть веб-морду. Но только HTTP. На SSL в нём тупо не хватит памяти.F0iL
04.07.2018 10:04Устройства промавтоматики крайне опасно ставить голым задом в Интернет, они должны жить в изолированной сети, а если очень хочется получать к ним доступ удаленно — то перед этой сетью ставится фаервол и VPN-сервер — подобных штук достаточно много как в чисто программном, так и в железно-промышленном исполнении.
belyvoron
04.07.2018 10:18они могут быть и не в интернете. Только Хром будет ругаться на них в любом случае.
StallinHrusch
04.07.2018 15:41насколько я помню хром не ругается на http в локалке. там даж есть некие допущения по использованию media api (в нете оно доступно ток если сайт висит на https, но на локалхосте хром разрешает его и без S)
andreymal
04.07.2018 15:44Ругань — дело времени. Например, Firefox уже сопротивляется сохранению паролей на не-https сайтах даже на локалке. Стало менее удобно в настройки роутера заходить. Chromium вроде бы ещё не сопротивляется, но нет уверенности, что не станет сопротивляться в будущем
Bonio
04.07.2018 17:19Firefox уже сопротивляется сохранению паролей на не-https сайтах
В firefox это хотя бы можно отключить через about:config. А вообще идея сделать исключения для локальных ip адресов выглядит здраво, в локальных и корпоративных vpn сетях https попросту не нужен.
У нас на работе во внутренней, не причастной к интернету сети, есть много web сервисов, и все вот эти вот предупреждения о небезопасности и невозможность сохранения паролей иногда здорово портят мне нервы, а пользователи задалбывают вопросами. Поэтому сейчас при установке firefox esr я в обязательном порядке правлю так же еще и целую кучу параметров из about:config.
andreymal
04.07.2018 10:44А если там, прости господи, древний Lotus?
И из-за этого нужно снижать безопасность посетителей? Это уже безответственность и халатное отношение админа к посетителям. (Если админ есть, конечно)
Устройства промавоматики часто имеют веб-морду. Да, по HTTP.
Ну уж им-то точно нечего делать в интернете.
микроконтроллеры ESP8266 за 1,5 доллара
Им — тоже.
belyvoron
04.07.2018 11:09+1HTTP — протокол 7го уровня модели OSI. Под ним вполне может быть уже защищенный транспорт — IPSEC VPN, нативное шифрование IPv6 и т.п., про что браузер не знает и знать не может.
P.S. на самом деле одну жесть в этом роде мы уже пережили. Межсетевые экраны Cisco ASA массово поставлялись в Россию с выключенным сильным шифрованием. Их можно перепрошить, чтобы включить 3DES, но это незаконно без разрешения ФСБ. А так как это устройство безопасности, вендор заложил возможность управления только через HTTPS и SSH. Да, при единственном доступном протоколе шифрования 56-битном DES. Который выпилен из всех браузеров. Ага.andreymal
04.07.2018 11:12Это тоже проблема, согласен. Но совсем не причина выступать против HTTPS. Это причина выступать против поведения браузеров, которые неадекватно реагирует на отсутствие HTTPS там, где в нём нет необходимости
belyvoron
04.07.2018 11:21+3так никто и не против HTTPS как такового. HTTPS хорош там, где он нужен. В публичном интернете, например. Против попытки разработчиков бразуеров максимально усложнить жизнь пользователям HTTP.
TrllServ
04.07.2018 21:45Ну уж им-то точно нечего делать в интернете.
Вы правда уверены, что можете решать кто и что должен делать в интернете и кому там место?
Ведь может оказаться, что-то другой решит и вам там не место?
pansa
04.07.2018 22:21Очень неудачный пример. =)
nginx бесплатен, а настройкой его в режиме прокси справится даже ребенок.
При этом, если у вас, прости господи, Lotus, то это как бы автоматически говорит следующее: «Йо, мы жирный и богатый интерпрайз, мы можем позволить себе закупать софт hi-end класса».
И да. У платформы Lotus/Domino просто охренительно продуманная архитектура в плане безопасности. И прикрутить туда сертификат LE, который в общем-то совершенно обычный сертификат, нормальному админу Lotus не должно составить труда.
Scondo
04.07.2018 09:17+1Ключевой момент: а почему мы априори считаем, что любой человек посередине есть зло?
Раньше ведь сами прописывали провайдерские прокси ради роста скорости.
И да, большая часть «атак» о которых вы пишете решается не шифрованием, а подписанием.andreymal
04.07.2018 10:48Потому что мой трафик — моё личное дело. И я хочу, чтобы его не только не подменяли, но ещё и не читали. Поэтому просто подпись меня не устраивает.
Вот когда я буду не против, чтобы мой трафик прослушивал кто-то сторонний, тогда я своими собственными руками и пропишу «провайдерский прокси». А делать это без моего ведома не надо.
Scondo
04.07.2018 14:55Ну, если вы не хотите — это ваше право.
Для этого, во-первых есть VPN. Во-вторых есть возможность предоставлять к одному и тому же сайту как HTTP, так и HTTPS доступ.
Проблема-то собственно в том, что сегодня даже прописав руками провайдерский прокси от этого нельзя получить выгоду: десять одинаковых котиков по HTTPS будут переданы в виде десяти разных наборов байт зашифрованные для десяти разных получателей. Любой человек посередине считается злым, кроме ситуации, когда сайт передал ему свой сертификат (CDN). Включая все сервисы и службы, которые получатель хотел бы настроить сам.andreymal
04.07.2018 15:10во-первых есть VPN.
При наличии VPN ничего приниципиально не меняется, просто вопрос доверия провайдеру меняется на вопрос доверия держателю VPN-сервера
как HTTP, так и HTTPS доступ
С этим, пожалуй, соглашусь
Любой человек посередине считается злым
Да, я не хочу, чтобы человек посередине знал, какие именно котики меня умиляют)
Думаю, в браузерах нужно что-то вроде галочки типа «Я умный, разбираюсь в безопасности и хочу, чтобы мне не запрещали HTTP», отключенной по умолчанию
Scondo
04.07.2018 16:30Да, я не хочу, чтобы человек посередине знал, какие именно котики меня умиляют)
Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет. В другом большом числе случаев единственное для чего будет использована эта информация — для ускорения доставки вам котиков.
Более того, правильный прокси-сервер позволит вам скрыть вопрос «какие котики мне нравятся» уже от поставщика котиков. Чего в HTTPS сделать нельзя никак: каждый котик отправляется персонально для вас и значит можно определять кого ещё вы запрашивали и пытаться угадать кто вы есть.
В какой-то мере решение проблемы безопасности через HTTPS играет сильно на руку Гугла, как поставщика контента. Он оказывается монополистом на данные о структуре спроса на контент: вы не можете их скрыть, никто другой не может их получить… вы согласны с такой монополией?
Кстати, при отсутствии монополии таких данных не будет в едином целом вообще ни у кого: часть данных будет у Гугла, часть у оператора кэша, а их ещё может быть не один… так что опциональный HTTPS на само деле безопаснее(с точки зрения возможности скрытия данных), чем жёсткий.
что-то вроде галочки типа «Я умный, разбираюсь в безопасности и хочу, чтобы мне не запрещали HTTP», отключенной по умолчанию
Во-первых не забывайте про домашние устройства вне DNS, которые как минимум не смогут получить корректные сертификаты.
Во-вторых суть проблемы с HTTPS не только в давлении на пользователей, но и в давлении на сайты. Сайты с изображениями на HTTP обозначаются в заголовках значками, призванными символизировать проблемы и ошибки.
Я не хочу сказать, что это всё вина Гугла… нет, это скорее выглядит так, как будто столкнувшись с потенциальными проблемами всё сообщество web кидается прятать голову в песок TLS вместо того, чтобы разбираться с каждой проблемой соответственно.andreymal
04.07.2018 16:46Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет.
«Тут дело вот в чём: в достаточно большом числе случаев никакого водителя, мчащегося на переход с превышением скорости, не будет...»)
скрыть вопрос «какие котики мне нравятся» уже от поставщика котиков
Ну, может быть, но лично я поставщику котиков доверяю больше)
Сайты с изображениями на HTTP обозначаются в заголовках значками, призванными символизировать проблемы и ошибки.
При отключенной условной галочке «Я умный...» HTTP это действительно проблема и ошибка, потому что данные прослушиваются непонятно где непонятно кем без предварительного согласия пользователя. Хотя отсутствие у вас возможности согласиться на использование HTTP-прокси это тоже проблема и ошибка современного веба, это я не отрицаю
всё сообщество web кидается прятать голову в песок TLS вместо того, чтобы разбираться с каждой проблемой соответственно
Хорошо сказано
Scondo
04.07.2018 17:42данные прослушиваются непонятно где непонятно кем без предварительного согласия пользователя.
Не прослушиваются! Могут прослушиваться!
В рамках метафоры с водителем: водитель может мчаться с превышением… это не повод, например, запрещать наземные переходы.
Вообще конечно, кто-то может и у вас по местной улочке нестись 90, а кто-то может ваш вай-фай слушать… но давайте соизмерять?
лично я поставщику котиков доверяю больше)
Ну, это ваше право. Проблема в том, что сейчас под сомнение ставится право других людей НЕдоверять ему, а доверять больше своему провайдеру (или вообще собственноручно настроенной проксе).
Bonio
04.07.2018 17:29Тут дело вот в чём: в достаточно большом числе случаев никакого человека посередине не будет.
Говоря конкретно про россию, а именно тут мы с вами живем, на сегодня абсолютно каждый провайдер прослушивает http трафик, перенаправляя его на свои прокси-сервера. Именно так работает блокировка полных url адресов.
И если раньше открытость трафика не была проблемой, то в сегоднящних условиях это проблема, что не оправдывает конечно такое агрессивное запугивание пользователя плашками с предупреждением о «небезопасности».
Я вообще считаю, что браузер не должен пугать пользователя подобными сообщениями и как-то ограничивать функциональность сайта в зависимости от того, с шифрованием он или нет. Браузер должен просто отображать контент, все. Это дело конкретного сайта по какому протоколу ему работать. А меня, как продвинутого пользователя, такое поведение браузера, который считает себя умнее меня и вовсе бесит.
StallinHrusch
04.07.2018 15:02подписание не спасет от перехвата чувствительной информации
Scondo
04.07.2018 16:36Я и не имел ввиду, что всё надо решать подписанием.
Я про то, что там где мы боимся перехвата — да, надо шифровать.
Но там, где боимся только подмены — подписывать. И не подменять защиту от одной угрозы — защитой от другой угрозы. А не внедрять HTTPS на каждый чих, полагая, что он всё делает безопасным «автоматически».StallinHrusch
04.07.2018 16:46увы, но пока что HTTPS — это лучшее что мы имеем прямо сейчас, а HTTP — это шаг назад.
Scondo
04.07.2018 17:59Вот главное, что я хочу сказать: хотя появление HTTPS как возможности — это шаг вперёд, не надо рассматривать движение от HTTP к HTTPS как строгое поступательное движение. Внедрение HTTPS привносит не только плюсы, но и минусы. В каких-то случаях эти минусы пренебрежимы (особенно если дублируют те же проблемы от других причин), но нельзя сказать, что HTTPS всегда лучше HTTP, а HTTP — всегда шаг назад.
ntfs1984
04.07.2018 15:16Я хочу.
А я нет. И уже само существование двух разных мнений ДОЛЖНО давать альтернативу выбора. Давно у нас свободный интернет стал авторитарным?
Frintezza93
04.07.2018 18:25+1Лично меня немного смущают аргументы вроде «используйте другой браузер». Для моего дедули иконка браузера это и есть интернет, и ограничивается он парой каналов на Youtube да десятком закладок, половина из которых — это как раз-таки "[архивы] под http".
Думаю что у многих найдутся такие дедули, которые, увидя что-то непонятное на «неаншенском», быстренько ретируются из этого вашего интернета. Так что вот, жду звонка с содержанием наподобие — «сломался интернет».
Golem765
03.07.2018 22:42+1Странный посыл поста, будто Гугл закрывает интернет, они контролируют только то что принадлежит им — используй любой другой браузер (или вообще без браузера) и поисковик и никаких проблем с хттп не будет, а если ты хочешь использовать удобный хром, то зачем ныть?
Massacre
03.07.2018 23:08+3Монополия же. Хром — новый IE. Много популярных сайтов затачивают чисто под Хром. Конечно, можно найти клон с таким же движком, но без политики Гугла, но не факт, что там нет своих, особых багов.
superconductor
04.07.2018 00:03Не, новый IE — это сафари. Встроенный в ось браузер с альтернативным пониманием стандартов и такими невороятными глюками, что ие6 вспоминается с теплотой.
Newbilius
04.07.2018 07:31Проблема IE была в кривости поддержки стандартов И широкой распространённости. У Сафари второго пункта нет.
vanxant
04.07.2018 17:36К сожалению, монополия у сафари есть. Юзеры айфонов это очень вкусный кусок целевой аудитории, среди них много ваннаби богатых буратин, уж простите. И на этих самых айфонах никакой альтернативы сафари нет, эппл принципиально не пускает туда другие движки.
hVostt
04.07.2018 00:12+1Сижу на FF и Хроме. Проблем в обоих браузерах не наблюдаю. Даже наоборот, бывает так, что-то глючит на хроме, но работает в FF.
MikailBag
04.07.2018 08:14Есть подозрение, что достаточно закомментировать немного кода в chromium
jahr
04.07.2018 11:42Пробовали ли Вы собрать хромиум? Я, если честно, — нет, но подозреваю, что, как и со всяким опенсорсным проектом такого масштаба, это, мягко говоря, нетривиальная задача для большинства. Так что возможность редактировать его код кажется мне скорее теоретической.)
balsoft
04.07.2018 23:17Да, мне приходилось это делать аж 2 раза (ну ладно, я ничего не собирал, это все компилятор :)). Если интересует причина — я раньше сидел на nixos-unstable, и там частенько оказывалось так, что собранного chromium в кэше нет. Тогда при обновлении запускался процесс сборки. Комп задумывался на часик, а дальше все было хорошо. Учитывая гибкость nix, наложение простенького патча на chromium будет задачей тривиальной. Проблема будет в необходимости тратить час на каждое обновление.
TrllServ
04.07.2018 23:26Проблема будет в необходимости тратить час на каждое обновление.
А так же проблемой будет, что не каждыйвторойдесятыйсотый житель хабра может собрать себе сам. Уже не говоря про менее продвинутых пользователей.
Vilgelm
05.07.2018 07:11Нет, это довольно просто, мне приходилось собирать. Там довольно подробные мануалы и все сводится к ~20 командам. Но если вносить изменения, то как подебажить их я не знаю, а узнавать о том, что в коде ошибка после 6 часов сборки как-то не очень прикольно.
jahr
05.07.2018 10:34Мне регулярно приходится собирать большие проекты, обычно там даже не 20 команд, а три (autogen.sh — configure — make), и, в теории, все предельно просто. Танцы с бубном начинаются если вдруг случается какая-то ошибка, и тогда сборка затягивается на много дней. А ошибки такие случаются очень часто.
Давно не заглядывал на upwork, но раньше там регулярно встречалась задача собрать хромиум с какими-то изменениями. Если бы это было тривиальной задачей, то заказчики не стремились бы кого-то нанять для нее, мне кажется.
F0iL
04.07.2018 10:06Конечно, можно найти клон с таким же движком, но без политики Гугла
он есть с момента появления самого Google Chrome и называется Chromium, являясь базой с открытым кодом для него же, но без проприетарных компонентов и телеметрии гугла.
VBKesha
03.07.2018 22:53+1ИМХО оснавная проблема в HTTPS привязка к центрам сертификации. В итоге если у тебя отзовут сертификат сайт превратится в тыкву, а после завтра сертификаты могут стать платными на томже летсэнкрипте и давай плати.
Ну и в итоге очень удобно подмять под себя контроль кто куда ходит и что читает, при HTTP это может делать любой по пути следования трафика, а тут как не странно по сути только Google/Mozilla/M$ и доля гугла на рынке браузеров почти 60%.hVostt
04.07.2018 00:16+1За всё нужно платить, за безопасность в том числе. Если убрать привязку к доверенным центрам, то кому тогда доверять? А центры доверия за какие деньги должны работать и обслуживать миллионы клиентов? Вопросы риторические, уверен, ответы вы на них знаете по-лучше меня :)
VBKesha
04.07.2018 01:15Вот я не вижу безопасности. Да мой провайдер теперь не может менять мой трафик. Но на этом всё заканчивается. Но вообще да кто то же должен платить за предложение от которого нельзя отказаться.
Tangeman
04.07.2018 02:05Если убрать привязку к доверенным центрам, то кому тогда доверять?
Владельцу сайта же. Т.е. «доверенные центры» ну совершенно ничего не меняют — кроме, разве что, EV сертификатов (когда проводится проверка наличия компании). Для сертификатов типа DV они всего лишь проверяют тот факт что купивший его владеет доменом (или имеет доступ к его управлению) — а это стоит не больше чем уже упомянутый DANE, поскольку любой фишер может купить домен и сертификат к нему, заплатив анонимной кредиткой за то и другое — т.е. совершенно не привязывая себя (как физическое лицо или компанию) к ним.
Если бы доверенный центр гарантировал хотя бы тот факт что владельца сайта можно найти как физическое лицо (или компанию) — да, другое дело, но это уже будут совсем другие расходы на валидацию.
А центры доверия за какие деньги должны работать и обслуживать миллионы клиентов?
Они вообще не нужны кроме случаев EV — для этого хватит DANE. Цель «массовой» сертификации — защитить траффик от клинта к серверу, не более, с этим справится любой владелец сайта, достаточно выложить нужные данные в DNS (разумеется, речь про DNSSEC, а не простой DNS).
Если же говорить про EV, то банки и прочие компании которым это важно, вполне могут заплатить за сертификаты, которые действительно удостоверяют их существование — вот с этого CA и будут кормится.
PS: Наверное, вы в курсе про то что не все доверенные центры заслуживают доверия? Даже Symantec оказался не таким уж доверенным, несмотря на всю помпу.
BeppeGrillo
04.07.2018 08:37За всё нужно платить, за безопасность в том числе. Если убрать привязку к доверенным центрам, то кому тогда доверять?
Да, а вот центрам сертификации мы доверяем, правда?
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.
Bal
04.07.2018 06:22Ещё одна сторона той же проблемы. Раньше сайты могли сохраняться многими годами без вмешательства админов. В новой же реальности они будут жить только пока жив сертификат. С пресловутым LetsEncrypt — месяцы.
DaemonGloom
04.07.2018 07:38Особенность LetsEncrypt в том, что его не нужно обновлять руками — нужно просто настроить обновление сертификата в cron. И сайт будет жить, пока не умрёт сам letsencrypt. Да и потом на него можно будет зайти, просто будет предупреждение об истёкшем сертификате.
iproger
04.07.2018 08:15Потом они захотят что-то поменять и нужно будет фиксить обновление.
VBKesha
04.07.2018 11:38Ну да как например гугл в своё время поменял алгоритм рекапчи, и 2 сайта у меня осталось без регистрации, просто потому что за прошедшее с её установки время я уже и забыл что она там стояла.
StallinHrusch
04.07.2018 15:13плин, ну что за аргумент? а так-то ваш сайт работает вообще без каких-либо зависимостей? Ваш собственный веб-сервер, который не обновляется, ОС на которой он работает не обновляется, dns сервер который не обновляется, http наконец который не обновляется (1.1 -> 2.0), JS движки в браузерах не обновляются, html не обновляется? Всегда, даже у самого примитивного статичного сайта и так есть вагон зависимостей и всегда есть риск огрести проблем от обновления внешних зависимостей — это называется cost of support. В текущей реализации https да, добавляется зависимость и вынужденность «доверять» тому или иному CA выдавшему серт. Но это вынужденная мера и уж лучше «доверять» ограниченному числу лиц, минимизируя тем самым риски, чем всем подрят.
Bal
04.07.2018 17:36Есть сайты, которые 10-15 лет не обновлялись. И работают. Google хочет положить этому конец.
StallinHrusch
04.07.2018 18:00+1конечно если поискать, то найдется парочка. но стоит ли из-за пары сайтов возвращаться в пещеру с http? и второе — то что они не обновлялись, это скорее минус, т.к. обновления не всегда носят функциональный характер (или рюшечки), обновления так же могут быть для повышения безопасности (та же старая версия веб-сервера может содержать критическую уязвимость). Так что не надо эти сайты поддерживать и уж тем более их поощрять. Не хотят в безопасность? ну пусть закрываются, никто особо страдать не будет.
iproger
04.07.2018 18:16Да нет никаких зависимостей у сайтов 10+ лет.
Есть 2 типа зависимости:
— которые можно игнорить (как вы правильно сказали — обновление ОС);
— которые ломают сайт/etc.
Тема статьи про 2.
Bal
04.07.2018 08:24Я сам так и делаю. Но даже с такой простой автоматикой на своих паре десятков доменов за год пару раз уже получал просроченные сертификаты. А без внимания админа это произойдёт намного быстрее.
И это ещё без учёта возможных проблем со стороны самого LetsEncrypt.
Bonio
04.07.2018 17:32Ну, строго говоря, от того, что сертификат протух, сайт не перестает быть рабочим.
Bal
04.07.2018 17:41+1Пока — нет. Но Гугл обещает, что будет с этим бороться. И общий тренд к тому ведёт. Через несколько лет, вполне возможно, неквалифицированный пользователь с попасть на сайт с кривым сертификатом не сможет.
А что до встраиваемого контента — это проблема уже сейчас. Вот прямо в тему, вчера пользователи стали жаловаться, что на форуме перестали показываться картинки. Я потыкался, с виду работает. Сегодня жалоб стало больше, пошёл разбираться. Оказывается, на одном из серверов, выбираемом через round-robin DNS как раз протух сертификат Let's Encrypt. Его автоматическое обновление с round robin, вообще, дополнительная головная боль, вот у меня глюк и вылез.
Так что картинка на сайте с протухшим сертификатом не работает уже сейчас… А что будет завтра?
nikitasius
04.07.2018 00:30+4Доступность информации
По мне так — я согласен с тем, что нельзя искоренять http. Это прямо влияет на доступность информации.
С http не нужны никакие центры сертификации, ничего. Любой с калькулятора сможет получить доступ к сайту, при отсутствии фильтрации траффика со стороны провайдера.
Текущий уровень внедрения HTTPS
А он никакой. Просто никакой.Let's encryptэто конечно весело и по пацански, но DANE'то где?
Доверять свою безопасность стороннему регистратору сертификатов ИЛИ своему DNS серверу?
Ни один паблик DNS сервер в инете сие не поддерживает, потому, что не будет нужны в этих сертификатах от комоды, летса и иже с ними.
В итоге: HTTPS не допилен, доступность инфы зависит от третьих рыл, и они собрались искоренить HTTP, загнав всех в рамки недоHTTPS.
dragoangel
04.07.2018 02:05+1а вот по поводу DANE — тут реально система еще не готова — вопервых до сих пор даже не все корневые домены поддерживают DNSSEC, во вторых как не крути а DNS резолвинг в том виде котором он сейчас есть одно из узких мест в системе интернет и на нем и без SEC задержки по 30мс+ (в среднем 1\3-1\4 времени занимаемая на загрузку сайта), а если добавить к нему SEC то задержки увеличиваются втрое. Увы практических тестов я производительности я не делал, и опираюсь на публичные данные, могу быть не прав. Сейчас интернет и в правду шерстит «нестандартными инновациями» которые может ускорят обезапасят работу DNS без сильного оверхеда — DoH (DNS over HTTPS), DNS over TLS, и в юзерских ОС ими не возможно пользоватся с коробки — только через сторонний софт.
nikitasius
04.07.2018 14:02DNS over HTTPS
Это не оверхед?)
Прозрачный ответ от DNS с подписью и ее проверка на основе паблик ключа это быстрее чем поднять сессию (https) с проверкой сертификатов и отправить запрос, следом получить ответ.
DNS очень быстро работает. А когда кеширует, то локальный кеш вообще бомба (
путин-террористы). У меня везде используется google dns через dnsmasq с включенным dnssec. Дома на лаптопе и на серверах. Время ответа на серверах очень быстрое, гугл очень шустрый как и связь с ним. Дома, конечно, медленнее чем с ДНС провайдера, но последний слоупочный.
На счет DANE — не готова полная поддержка всех RFC для паблик сервисов (=днс хостингов), так как им просто не выгодно отнимать этот пирог у центров сертификации. Другое дело, что все DNS сервера, которые массово доступны (bind, nsd) поддерживают нужные нам записи. И ничего не мешает запустить свой DNS и прописать там записи для DANE.
А вот браузеры… тут я хз. Раньше были плагины, на свежие версии они не пашут (для firefox по крайней мере). Сайтов с самодельными сертификатами не нашел. Все "CA signed".
maslyaev
04.07.2018 00:37-1А если, допустим, древний никем не поддерживаемый сайт использует куки? Он же не сможет удолбать пользователя предупреждением про куки. Т.е. имеем нарушение Закона. Заперетить такие сайты и заблокировать на всегда. Тех, кто их создал, найти и оштрафовать. Тех, кто умер — посмертно.
DrDeimos
04.07.2018 00:38+1Идея поста хорошая, но все аргументы сведены к "Гугл плохой" и "Почему мне указывают что делать".
А как же осветить техническую сторону вопроса?
Ведь https это не только зелёная плашечка в браузеое, это нехилая нагрузка на CPU условного CDN или любого другого контент поставщика чей RPS начинается от 1000 и выше.andreymal
04.07.2018 01:08А есть точная инфа про нагрузку от какого-нибудь такого контент-поставщика? А то я когда-то давно читал, что всё почти наоборот — мол, почти весь HTTPS уже реализован аппаратно в процессорах и HTTPS на производительность якобы почти не влияет (хотя лично я не изменял, у меня нету 1000 RPS)
Tangeman
04.07.2018 02:20А вы измерьте и сравните максимальный RPS с и без HTTPS — на одном сервере, разница будет ощутима даже на static files, причем более ощутима на слабом железе (или на shared hosting).
Самый простой вариант — запустите openssl speed rsa и посмотрите sign/s — это и будет вашим лимитом на RPS (умножте на количество ядер) в случае HTTPS. Keep alive и session cache увеличивают RPS (для одного клиента), но если клиентов очень много — это мало помогает, нужно больше CPU со всеми вытекающими.
Впрочем, это всё имеет значение только для тех у кого действительно RPS выше 1000/s — остальные этого, скорее всего, не заметят (если у них не старинное железо, разумеется).andreymal
04.07.2018 02:54Что-то у меня wrk выдал всего полтысячи запросов в секунду при околонулевой нагрузке на проц — куда-то производительность упирается, но если не в проц и если статический файлик по идее закэшировался в оперативке, то я со своими скудными знаниями хайлоада не понял куда) А без этого понимания openssl смотреть даже неинтересно, хех
alexey-m-ukolov
04.07.2018 05:46Гугл, когда перевели весь Gmail на https, писали, что нагрузка на CPU выросла на 1%.
blind_oracle
04.07.2018 09:02В процессоре реализовано только симметричное шифрование. А ассиметрия, необходимая для установки соединения, делается чисто софтово. Тут, правда, помогает криптография на эллиптических кривых в которой математика в разы проще по нагрузке чем в RSA.
DrDeimos
04.07.2018 10:39Есть результаты синтетического теста на CPU 3.7 Ггц intel относительно новом из предпоследнего поколения.
На 6 ядрах было 10K rps по SSL на nginx сreturn 200 "OK";
И сравнения на виртулке в которую не пробросились флаги с проца что он умеет AES.
SSL на такой выжимает ~1-2K.
Без SSL — ~8K.
Все значения округлены в до тысяч в большую сторону и итоговая суммарная нагрузка на сервера предполагалась больше указанных выше значений.
bano-notit
04.07.2018 01:25А гугл даёт возможность отключить эту «опцию» в настройках?
Вообще конечно тут много интересного и сразу. Для меня вот встаёт делема «никто ничего не знает о безопасности, поэтому давайте обезопасим всех сами». У неё есть одна проблема — как ты не защищай всё это бейджиками, количеством кликов, двусторонним подтверждением подлинности на техническом уровне — за компом всё равно будет сидеть обезьяна, которой пофиг, какие войны устраивают айтишники на счёт безопасности. Обезьяне главное смотреть котиков. Ей пофиг какие технологии защищают её от «неправильных котиков», если ей захочется посмотреть на неправильных, она найдёт их.
Для меня вопрос заключается не в том, что юзеры будут убегать с сайта с криками «там не безопасно», для меня страшным является то, что пользователи будут спокойно вводить свои пароли в окошках рекламных баннеров, не думая, а полагаясь на зелёненький значёк в строке браузера.
Нет смысла бороться за безопасность пользователя, нужно бороться за грамотность в этой области.dragoangel
04.07.2018 01:51С одной стороны вы правы, а с другой стороны большинство людей просто не хотят думать, и как ты их учи, как не учи, им просто будет побоку — собтсвенно как вы написали выше: «Обезьяне главное смотреть котиков». Поэтому в конце-концов все таки машина должна в данном случае быть «защитой» от дурака, и максимально усложнить дураку доступ до «неправильных котиков». А те кому не пофиг и у кого голова на плечах и при желании найдут как им посмотреть «неправильных мокрых котиков» и как сделать машину простой, доступной и надежной и безопастной.
DaemonGloom
04.07.2018 07:42В дальнейших планах было убирание зелёного значка. Уже в сентябре из Хрома исчезнет зелёный цвет из значка (станет просто серым). В будущем он должен исчезнуть совсем.
Darth_Malok
04.07.2018 07:56Имхо, всё идёт к тому, что сайты по http вообще не будут открываться в будущем.
dragoangel
04.07.2018 01:47-2В корне не согласен с автором, приведу пару примеров:
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 какие пожелаете для любых целей и любых локальных ресурсов.
Сложно? Не думаю.Tangeman
04.07.2018 02:33сейчас любой желающий может спокойно сделать себе LetsEcnrypt
А потом? Letsencrypt, будучи бесплатным сервисом, не даёт никаких гарантий — и (теоретически) может превратиться в тыкву в любой момент. Или стать платным.
Я не хочу сказать что им не стоит пользоваться (наоборот — очень нужно), просто подобного рода сервис стоило бы гарантировать — раз уж он очень нужен. Но гугль почему-то не спешит раздавать сертификаты гарантированно бесплатно, и в то же время требует HTTPS «во избежание» — это несколько настораживает.
Плюс если кто не знал в https самое долгое это handshake — как только вы первый раз обмениваетесь dhparam, а потом все летит как по маслу
А ничего что это нужно делать заново как минимум для каждого нового клиента? Т.е. RPS уже заведомо ограничен процессором (и количеством ядер). Другое дело что для слабых нагрузок (а-ля домашний блог) это несущественно, но вот для нагруженных сайтов — уже нужны системы помощнее.
Не поймите меня неправильно, в целом я всеми щупальцами вас поддерживаю — просто не стоит забывать о рисках и затратах.Revertis
04.07.2018 08:07Другое дело что для слабых нагрузок (а-ля домашний блог) это несущественно, но вот для нагруженных сайтов — уже нужны системы помощнее.
Ну так чем больше пользователей, тем нужнее SSL/TLS. Ведь пользователи будут там авторизовываться, обмениваться информацией и так далее, ведь сейчас же Web 2.0 как-никак.
dragoangel
04.07.2018 12:08А потом? 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%, поэтому давайте не придумывать.nikitasius
04.07.2018 14:04До LetsEncrypt был StartSSL (китайцы)
До китайцев это были евреи, которые затем продали китайцам, которые и загадили сей проект.
Tangeman
04.07.2018 16:43сейчас за местно них 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 и других устройств (не подключенных к облаку) и всего двух пользователей, совсем не нужно шифрование.
StallinHrusch
04.07.2018 16:04Letsencrypt, будучи бесплатным сервисом, не даёт никаких гарантий — и (теоретически) может превратиться в тыкву в любой момент.
Да в общем-то так может сделать и платный сервис. Цена, большая чем 0 — никоим образом вам ничего не гарантирует сама по себе.Tangeman
04.07.2018 16:18Цена, большая чем 0 — никоим образом вам ничего не гарантирует сама по себе.
Согласен, но обычно те кто берет за что-то деньги имеют T&C в которых хоть что-то гарантируют, к тому же они имеют источник средств для поддержания сервиса.
Основная разница в том что платящий за сервис вправе требовать оказания услуг, в то время как «халявщик» вообще не имеет прав. На платный сервис можно подать в суд, с него можно стребовать компенсацию etc — с бесплатным этот номер не пройдёт.StallinHrusch
04.07.2018 16:27я понимаю о чем, но, именно что T&C в совокупности с локальным законодательством гарантирует вам хоть что-то. такие же T&C могут быть и у бесплатного сервиса (может и не быть, тогда вы можете им и не пользоваться) и
к тому же они имеют источник средств для поддержания сервиса.
взгляните на список спонсоров летсэнкрипта на главной, я думаю денег на саппорт они найдут легкоTangeman
04.07.2018 16:52взгляните на список спонсоров летсэнкрипта на главной, я думаю денег на саппорт они найдут легко
Спонсоры приходят и уходят, а затраты растут. Вы можете гарантировать что текущая ситуация не изменится ещё лет 5-10? А кто-то из спонсоров может гарантировать? Соберется совет акционеров Cisco и скажет «хватит, только бабло тратим» — и всё, нет крупного спонсора.
А теперь представьте что все (без исключения) станут пользоваться Letsencrypt, включая все IoT — представляете как возрастут их затраты на инфраструктуру?
Ещё раз повторю — нужно не верить в то что так будет всегда, нужен commitment — т.е. компании должны вместе собраться и подписать договор в духе — «да, мы гарантируем бесплатные сертификаты всем желающим до своего последнего вздоха под страхом утопления» — вот это будет другое дело, а сейчас они просто спонсоры, без обязательств, захотел — заплатил, не захотел — ушел.StallinHrusch
04.07.2018 16:57да, мы гарантируем бесплатные сертификаты всем желающим до своего последнего вздоха под страхом утопления
такое вам никто никогда не гарантирует, даже если вы им будете заносить по миллиону в месяц. Это утопия, будет круто если так будет, но так не будет.
Вы можете гарантировать что текущая ситуация не изменится ещё лет 5-10?
Платный сервис вам так же не будет гарантировать работу «до гроба» только лиш потому что вы ему 10 баксов закинули. Да и способов монетизации бесплатных сервисов вагон (вон у гугла все кругом бесплатное для пользователей, но что-то все никак не свернется).Tangeman
04.07.2018 17:53Платный сервис вам так же не будет гарантировать работу «до гроба» только лиш потому что вы ему 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 — тогда гарантированно у них будут средства на развитие инфраструктуры по мере её роста, независимо от спонсоров. Можно было бы даже сделать тендер — и любая адекватная фирма могла бы предложить свои услуги для выполнения этих обязательств.
В конце концов, если регистратор имен становится банкротом, домены-то никуда не деваются — предусмотрены процедуры, передача управления и данных другому регистратору (всё бесплатно для владельцев доменов) — почему с сертификатами должно быть иначе?StallinHrusch
04.07.2018 18:13ISRG 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. Так что я вынужден и платить и при этом так же не имею никаких прав.Tangeman
04.07.2018 18:39платный может прописать у себя ровно то же самое, вам решать — соглашаться или нет.
Может — но тогда потеряет много клиентов, которые за свою плату не захотят произвола. Поэтому обычно не пишет.
VBKesha
04.07.2018 02:381. Да как то вот жил интернет без этого уже сколько лет, но тут вдруг стало ясно что дальше так жить нельзя, надо срочно исправлять.
2. Да всё клёво вот вам на халяву дают, берите радуйтесь. Но почему то не хочется думать а что будет если завтра перестанут давать халяву?dragoangel
04.07.2018 17:02Вчера давали одни *(чайте выше), сегодня дают другие, упадет Let'sEncrypt — 100% появятся третие, но поскольку в него столько денег вкинули то он еще минимум 10 лет не упадет, а через 10 лет интернет уже будет совсем другой.
none7
04.07.2018 10:55Я и сейчас захожу не пойми на, что. Ведь владелец ресурса никак не подтвердил свою личность. Если на ресурсе я не планирую оставлять ни одного пароля, то, что с того, что содержимое можно подменить?
Насчёт самоподписанных сертификатов, gpg же как то работает без абсолютно доверенных серверов. Если мне действительно нужно подтвердить сертификат, то можно просто можно спросить сервера которым Вы лично доверяете, какой хеш ключа у данного сервера. Маловероятно, что и Вы и он окажетесь под одним MITM.
То, что HTTP/2 и WebSocket не работают без TLS это тоже «заслуга» гугла из за его стремления навязать HTTPS повсюду. Из за этого на ровном месте создаются проблемы с созданием отладочного сервера, на своей машине за парой натов. С HTTP сервер разворачивается парой кликов, с HTTPS придётся создавать собственную инфраструктуру сертификации, что даже не близко к паре кликов. А с кешем SSL-сессий есть проблема, в мире довольно сильно распространены CDN и при каждом новом соединении там будет новый сервер, даже если IP-адрес один и тот же и сессионные ключи они обычно не делят между собой.
Ну и напоследок скажу, мой процессор Intel E5700 ничего не знает об AES, зажрались владельцы топовых Core i7.
eugeneb0
04.07.2018 02:46+1Автор, конечно, слегка преуменьшает проблему безопасности конечных пользователей. Ибо таки да, возможно, что страницу перед показом человеку поменяют.
Но в переходе на HTTPS есть другая проблема, которую почему-то редко упоминают. Сейчас, чтобы создать страницу, мне не надо ничьего разрешения, кроме наличия самого интернета. Хоститься можно дома, а DNS-ов бесплатных полно. Для простейшей странички с полезными людям текстовыми архивами вполне достаточно.
Переход же на HTTPS — это уже интернет по паспорту. Ибо Ктото Гдетович должен будет этот сертификат, то есть «паспорт», мне выдать, чтобы страница работала. Да, сегодня выдача очень легка и проста (тот же LetsEncrypt). Но само введение этого обязательного элемента в процесс создания любой страницы — это закладка барьера потенциально произвольной высоты в будущем.Bal
04.07.2018 06:29Интернет, вообще, по всему миру становится всё менее свободным. Чувствую, ещё придётся внукам рассказывать легенды про IT-фронтир рубежа 1990/2000-х. Сейчас такое осталось только в децентрализованных сетях, типа ZeroNet. И, вопрос, останется ли оно таким хотя бы при внуках :-/
Многие это не понимают, потому что вода в котле греется очень медленно. А многим просто сравнивать не с чем. И этот тред тому подтверждение...
evgenWebm
04.07.2018 12:37-1Тут проблема не в том, что не понимают.
А в том, что не понимают причин этого.
Отсюда и рождаются такие посты, где автор неграмотно высказывает свои опасения.
Увы, реальность в том, что да, интернет становится все менее и менее свободным.
И это прекрасно.
Свобода не синоним хорошего.
Может быть и свободно и плохо или свободно и хорошо. Это два состояния, которые связаны между собой косвенными связями.Bal
04.07.2018 17:44Это частично коррелируемые параметры. Несвободно и плохо бывает гораздо чаще, чем несвободно и хорошо. Равно, как и свободно и хорошо встречается чаще, чем свободно и плохо.
Поэтому при прочих равных следует стремиться к свободе.
evgenWebm
04.07.2018 17:50Конечно надо стремится к свободе.
Но и стремится к свободе, ради свободы, тоже еще та крайность.
Тут надо уметь баланс соблюдать. А не кричать(как в интернете любят) свободу попугаем ради свободы попугаем.
И еще раз. Как бы я с вами не согласился, поймите что свобода и хорошо это не синонимы. А что лучше, вместе или раздельно, это уже другой разговор.
vikarti
04.07.2018 07:26Да. И вспоминается недавняя история когда CA принудили по суду отозвать сертификат SciHub'а. На минуточку — процедура отзыва же предусмотрена для компроментации сертификата а НЕ для других целей.
Tangeman
04.07.2018 16:10Да. И вспоминается недавняя история когда CA принудили по суду отозвать сертификат SciHub'а. На минуточку — процедура отзыва же предусмотрена для компроментации сертификата а НЕ для других целей.
Принципиально это не отличается от блокировки доменного имени — в случае чего, регистратор имен может устроить не менее веселую жизнь по запросу властей, и наличие сертификата тут не поможет.vikarti
04.07.2018 17:14+1Регистраторов больше. И есть лояльные регистраторы (в том числе откровенно abuse-устойчивые). Стать регистратором проще.
Стать CA — сложнее. При этом чтобы создать CA большие проблемы — достаточно надавить на одного из производителей браузеров.
Существует страновые домены и если у меня на сайте в .ru будет контент, который не понравится американскому суду но к которому у российского суда претензий нет… американский суд пойдет лесом.
С CA так нельзя, сейчас нет CA 'только для .ru',(насколько я помню — технически сделать чтобы этот CA мог только для .ru выписывать — тоже нельзя), попытка же сделать Российский CA сразу приведет к скандалу в том числе и тут на тему того что ФСБ принудит его к выдаче сертификатов для прослушки всего. И этим обвинениям — противопоставить нечего будет.
rogoz
04.07.2018 14:09Сейчас, чтобы создать страницу, мне не надо ничьего разрешения, кроме наличия самого интернета. Хоститься можно дома, а DNS-ов бесплатных полно. Для простейшей странички с полезными людям текстовыми архивами вполне достаточно.
Если очень хочется, то создаётся самоподписанный сертификат. Причём как я понимаю, опасность MitM будет только при первом подключении, а потом браузер запоминает сертификат и имеется такая же защита, как при «правильном» HTTPS.eugeneb0
05.07.2018 02:14Пробовали. У меня друг один так и хостит. При каждом посещении с нового девайса приходится этот сертификат устанавливать. Довольно неудобно. А некоторых пользователей просто отпугивает.
andreymal
05.07.2018 02:20Теоретически это решается выдачей вместо ошибки простого вопроса типа «Опечаток такой-то, доверять? Да/Нет» (или можно даже из отпечатка сгенерировать няшную картинку, чтоб совсем юзерфрендли) — так же, как делают в SSH, PGP, OMEMO и прочих. Но, похоже, браузеры слишком любят центры сертификации и делать подобное не будут( Ну и никудышная грамотность населения мешает ещё
iproger
04.07.2018 08:21Одна из самых важных проблем — зависимость от решений центра. Если по каким-то причинам сайт перестаёт угождать ему то он становится недоступен. А причины всегда найдутся.
И да, хром станет новой монополией и это нужно учитывать.
Wolf4D
04.07.2018 09:59+1В условиях крайне, крайне дрянной связи, в которых я сижу едва ли не пол-дня, мой телефон "прыгает" по базовым станциям до нескольких раз в минуту. Иногда связь пропадает на десятки секунд вообще.
Сайты на HTTPS очень болезненно реагируют на подобное поведение. Или рушится сеанс, или сервер даётся отлуп, или выпадают совсем странные ошибки типа "SSL INTERFERENCE". Сайты на HTTP же вполне спокойно открываются и догружаются.
И как же невероятно бесит, когда я по 10 минут обновляю страницу, не в силах зайти на сайт нужного справочника или прочитать искомую статью только потому, что кто-то решил, что доступ к сайту будет только через HTTPS!Areso
04.07.2018 13:13И KeepAlive в 10-15 секунд добивает ситуацию. Да, в банкинг зайти нереально в таких условиях.
nagibat0r
04.07.2018 10:09-1HTTPS вообще не имеет смысла. TLS небезопасен же, так как есть третья сторона. Тем более, HTTPS в принципе не гарантирует никакой безопасности. Провайдер, или кто-то еще, с легкостью может сбампить трафик тем же Squid (возможно, уже сделал), подписав при этом subordinate CA у рутов, и никакой ругани о сертификатах не будет, и при этом будет работать MiTM.
andreymal
04.07.2018 10:55Прикол в том, что договориться с этой «третьей стороной» или «подписать при этом subordinate CA у рутов» намного, НАМНОГО сложнее, чем просто раздать поддельный вайфай в макдональдсе. Поэтому при наличии HTTPS меня будут прослушивать только какие-нибудь спецслужбы. А без HTTPS меня ещё и будет прослушивать какой-нибудь анонимный вася пупкин из соседнего подъезда. Поэтому HTTPS нужен. Не для защиты от спецслужб, а для защиты от васей пупкиных. А также от админов провайдера, у которых руки зачешутся трафик послушать.
nagibat0r
04.07.2018 12:04Я уже выше сказал, в том числе, про админов провайдера. Сложностей в том, что я написал, никаких практически нет. Нужны только деньги. HTTPS небезопасен априори, какая безопасность, Вы о чем? Если нужна безопасность, для этого есть действительно хорошие инструменты, но никак не HTTPS.
andreymal
04.07.2018 12:06Нужны только деньги.
Которых у васи пупкина не хватит. Так что HTTPS всё-таки добавляет безопасности :)
Если нужна анонимность, для этого есть действительно хорошие инструменты
Все они работают на тех же самых алгоритмах, на которых работает HTTPS
nagibat0r
04.07.2018 12:09Все они работают на тех же самых алгоритмах, на которых работает HTTPS
Да ну? Вот это новости!!! То есть, в Вашем понимании, все инструменты базируются на TLS? Извините, но Вы в корне неправы.
всё-таки добавляет безопасности
Я к чему разговор — то веду… HTTPS всего лишь создает иллюзию безопасности. Не более. И это вводит в заблуждение других, в результате чего страдает безопасность. А кто-нибудь говорит людям, что такое HTTPS? Что такое TLS? Нет, не говорит.andreymal
04.07.2018 12:17Все инструменты базируются на RSA и AES плюс всякие разные режимы с паддингами (ECB, CBC, OAEP, MGF1 и прочие умные буковки). Самые важные различия в основном в протоколе и способе доверия. В HTTPS доверяют центрам сертификации. В PGP и похожих системах доверяют личным встречам и друзьям. Но в основе PGP — тот же самый RSA, что и в основе TLS.
(Если я что-то проспал и появилось что-то более крутое, чем RSA и AES — просветите, пожалуйста.)
nagibat0r
04.07.2018 12:25И еще раз. Как я уже написал, вся безопасность TLS (HTTPS) рушится парочкой строчек в конфиге Squid и красивым сертификатом. А раз так, то это не безопасность, а лишь её иллюзия.
что-то более крутое
А я и не говорил, эти алгоритмы чем-то плохи. Я сказал про HTTPS. Что то лучше HTTPS? Да пожалуйста. Обфускация трафика. Использование end-to-end. Больше ничего и не нужно.evgenWebm
04.07.2018 12:31Только ситхи возводят все в абсолют.
Нет ничего безопасного в этом мире. Даже самая крутая криптостойкая система, не является 100% безопасной.
По вашей логике, любая мера безопасности, это всеголишь иллюзия.
Кстати, это правда. Защита это иллюзия, дающая нам душевное спокойствие. Уже не помню кто сказал.
И если есть, что то лучше А, то это не означает что А плохое и не нужное.nagibat0r
04.07.2018 12:49Разумеется, 100% безопасности не существует, прежде всего из-за самого человека-пользователя. Но простите, в TLS ее нет практически полностью.
evgenWebm
04.07.2018 13:04Но простите, в TLS ее нет практически полностью.
Я не профильный специалист данной тематики. Можно подробней?
Я читал выше, про подмену и сквад, и я не хочу принимать эту глупость как довод.
Ибо, то что вы говорите сделать, надо кроме знаний иметь и возможность.
А такой возможности обладают… очень мало.
Отсюда возникает вопрос. Если технология может защитить от 99% проблем, то почему она стала не защитой в абсолюте, как вы трактуете?
Хочу привести пример из жизни.
Вы переходите дорогу через зебру и на зеленый свет? А вы знали, что это не дает никакой вам гарантии безопасности?
Но вы же переходите все равно на зеленый и на зебре?
Так и эта технология. Она не дает абсолютной защиты. Она дополняет защиту и облегчает внедрение.
Это не значит, что другие способы защиты не нужны или лишние.
Конечно же имхо. Может в TLS дыра лежит, что любой школьник может взломать любой сайт. Тогда я соглашусь. Но я не уверен, что это так легко.nagibat0r
04.07.2018 13:13и я не хочу принимать эту глупость как довод
Что Вы назвали глупостью?
Если технология может защитить от 99% проблем
На чем основано данное утверждение?
Надо кроме знаний иметь и возможность
Не думайте, что у Вашего Интернет-провайдера недостаточно знаний, возможностей и денег, чтобы организовать такой MITM, о котором Вы и не узнаете. Речь именно о провайдерах, а не о Васях, Петях и прочих «хакерятах»
Может в TLS дыра лежит,
Конечно лежит. Это третья сторона. И это самая большая дыра в TLS.evgenWebm
04.07.2018 13:22Что Вы назвали глупостью?
Что ТЛС небезопасен априори.
На чем основано данное утверждение?
Где утверждение?
Я написал вроде четко «ЕСЛИ». Я предположил.
И цифра взята с неба. Может не 99%, может 50%. А может 30.
Что от этого меняется?
Не думайте, что у Вашего Интернет-провайдера недостаточно знаний, возможностей и денег, чтобы организовать такой MITM, о котором Вы и не узнаете. Речь именно о провайдерах, а не о Васях, Петях и прочих «хакерятах»
Я уверен, что провайдер последний человек, который будет этим заниматься.
И при этом мой провайдер, это ОДНА точка.
А без ТЛС у меня таких точек будет больше одной.
Понимаете?
Я с провайдером разберусь, а вот с ноунеймами в интернете, не смогу.
Понимаете?
Конечно лежит. Это третья сторона. И это самая большая дыра в TLS.
Это глупость.
Третья сторона не означает, что не безопасно.
Я не понимаю вашей паники.
ТЛС не панацея, но и не бесполезная технология.
Ваши доводы могут лечь на любую технологию. Замени ТЛС на Телеграм и будет таже правда )
Не надо так.nagibat0r
04.07.2018 13:29Третья сторона не означает, что не безопасно.
Всё понятно.
Я с провайдером разберусь
Да ну? Каким образом? Предотвратите MITM, который даже не увидите?
Я уверен, что провайдер последний человек, который будет этим заниматься.
Уверяю, что скоро это будет первый человек. Про закон Яровой слышали? А Вы подумайте, зачем провайдерам хранить кучу нечитаемых данных? Конечно же, незачем.
А без ТЛС у меня таких точек будет больше одной.
Так используйте, кто не дает?
Что ТЛС небезопасен априори
Еще раз. Что может быть безопасного в технологии, которая ломается напрочь прозрачным прокси с подменой сертификатов? Это самый большой недостаток TLS.
Я написал вроде четко «ЕСЛИ». Я предположил.
Ок. HTTPS не только не решает проблемы, он еще их добавляет.
evgenWebm
04.07.2018 18:04Всё понятно.
Люблю такие доводы.
Да ну? Каким образом? Предотвратите MITM, который даже не увидите?
Это вопрос третий как.
Главный вопрос, лучше разбираться с одним провайдером или с миллионами пользователей?
Как мне подсказывает логика, разобраться один раз, легче и реальней, чем со всеми в мире.
Уверяю, что скоро это будет первый человек. Про закон Яровой слышали? А Вы подумайте, зачем провайдерам хранить кучу нечитаемых данных? Конечно же, незачем.
Да я слышал про закон Яровой. Вот только вы видимо слышали, да не поняли про что он.
А это плохо, так как ваше некомпетентное мнение искажает реальность.
Цель у закона, чтобы ты в интернете вел себя как на улице, не писал «всех убью и изнасилую ублюдки» (грубый пример), а писал с осторожностью. И понимал, что теперь тебя можно взять за яйки если словят.
Хотя я конечно могу ошибаться, но кричать и паниковать как тут в интернете любят, я не буду.
Так используйте, кто не дает?
Вы!
Ну серьезно. Вы противник технологии, я наоборот. Для чего мы ведем диалог, чтобы какашками покидаться?
Еще раз. Что может быть безопасного в технологии, которая ломается напрочь прозрачным прокси с подменой сертификатов? Это самый большой недостаток TLS.
Вы явно не понимаете что пишите.
То что теоретически можно сделать(как вы уверяете), это еще не значит что технология бесполезная.
А я вас уверяю, ваш вариант очень хлипкий. И в большинстве случаев просто нерабочий.
Замечу, в большинстве случаев, не означает во всех.
Вот в таких случаях, эта технология помогает очень сильно.
Если она не дает 100% защиты, используйте связку разных технологий.
ТЛС не одна технология и не монополист в использовании.
Ок. HTTPS не только не решает проблемы, он еще их добавляет.
Чтобы не быть многословным.
напишите мне адекватный обзор технологии, где приводятся минусы и плшюсы.
Прошу заметить, без плюсов я не приму ответа. Так как это будет неадекватно. Я хочу адекватной информации. Может я не прав.
andreymal
04.07.2018 12:32И еще раз. Вася пупкин не сможет получить красивый сертификат.
И нет ничего абсолютно безопасного на практике, кстати. (Есть теоретически безопасные одноразовые блокноты, но на практике их особо не попользуешь)
Обфускация трафика.
Ни от чего не поможет.
Использование end-to-end.
HTTPS — это и есть один из вариантов end-to-end! Один end — клиент, другой end — сервер, между ними всё зашифровано доверенным сертификатом. Доверенным, потому что у васи пупкина не хватит денег, чтобы подкупить центр сертификации и получить поддельный красивый сертификат.
Если вы боитесь, что вася пупкин слишком богат, и не хотите доверять центрам сертификации — удаляйте всё предустановленное и добавляйте только те сертификаты, которым доверяете лично вы. Во всех основных браузерах такая возможность присутствует.
Больше ничего и не нужно.
Да, HTTPS вполне достаточно :)
nagibat0r
04.07.2018 12:46Это и есть один из вариантов end-to-end
в каком он, извините, месте end-to-end'ом стал, если принимает участие третья сторона?
Обфускация трафика ни от чего не поможет
Да ну? Расшифруйте OBFS4.
потому что у васи пупкина не хватит денег
Да что Вы своим Васей? Он уже икотой заболел (юмор). А если серьезно, что да, при чем здесь Василий? Беспокоиться надо совсем не о Васе из соседнего подъезда, а о том, что Ваши личные данные будут складироваться сами знаете, где. А уж на это, я Вас уверяю, у нужных компаний достаточно денег.
Да, HTTPS вполне достаточно :)
Я понял Вас. Предлагаю закончить диалог, раз Вам HTTPS кажется end-to-end и безопасным.andreymal
04.07.2018 13:13-1в каком он, извините, месте end-to-end'ом стал, если принимает участие третья сторона?
Никто вас не заставляет пользоваться центрами сертификации. Встречаетесь с админом сайта, получаете от него сертификат, добавляете его в доверенные — всё, полноценный end-to-end на базе HTTPS готов.
Беспокоиться надо совсем не о Васе из соседнего подъезда
«Сам знаю где» не будет воровать у меня деньги из киви-кошелька (у «них» есть способы хитрее вроде манипуляций с пенсионным возрастом). Если предположить, что «мне нечего скрывать»©, то на «сам знаю где» мне плевать. А вот вася будет очень рад перехватить логин и пароль от моего киви-кошелька. Ну или написать о том, как я очень люблю чью-нибудь маму, на стене ВК, перехватив куки. (Между прочим в мой ВК и правда писали, когда я по неосторожности попользовал публичный Wi-Fi без HTTPS. А могли бы и все личные сообщения по-тихому слить, чтобы я не заметил.) (Впрочем, наверняка и так слили, чего это я)
И вообще в RSA и AES наверняка есть уязвимости, известные американским спецслужбам. А в ГОСТовском шифровании наверняка есть уязвимости, известные российским спецслужбам. А чтобы изобрести своё шифрование, нужно быть гением. Так что АБСОЛЮТНО ЛЮБОЕ шифрование небезопасно. Надевайте шапочку из фольги :)
(Про OBFS4 я ещё матчасть не изучил)
nagibat0r
04.07.2018 13:21полноценный end-to-end
Вы меня рассмешили. Какой это еще end-to-end? Вы хотя бы прочитайте, что это такое, а потом делайте утверждение, что это полноценный end-to-end (который ваш провайдер одной левой поломает). Не вводите в заблуждение других. HTTPS (TLS) — это ни разу не end-to-end и никогда им не был и не будет.
И поверьте. Даже HTTPS Вас не спасет от того же Васи Пупкина. Что спасет? Обфускация. Это спасёт. Но поведение в паблик вайфаях требует бОльшего. Это уже другая история.
Про OBFS4 я ещё матчасть не изучил
советую как можно скорее заняться этим вопросом.andreymal
04.07.2018 13:24который ваш провайдер одной левой поломает
Как именно, если отказаться от центров сертификации? Раз вы такой умный, расскажите нам всем, не стесняйтесь. (Про OBFS4 тоже было бы неплохо, если бы вы рассказали. Уверен, я на хабре не один такой, который не знает матчасть.)
nagibat0r
04.07.2018 13:36Про OBFS4
А зачем мне перепечатывать то, что уже итак в Гугле ищется? Начинайте с Tor.
если отказаться от центров сертификации
А можно подробнее, аж интересно стало :)
Как именно
Если коротко, то
ssl_bump bump allandreymal
04.07.2018 13:39ssl_bump bump all
Ничего не понял. В документации про bump сказано, что оно «establishes a secure connection with the client». Но чтобы установить соединение с клиентом, нужно передать сертификат, которому клиент доверяет. Но если клиент не доверяет центрам сертификации, то откуда у этого вашего bump'а возьмётся сертификат, которому клиент станет доверять?
nagibat0r
04.07.2018 13:41Да господи, Вы читаете то, что я выше написал? Провайдер без проблем подпишет у рутов сертификат за деньги, и всё.
andreymal
04.07.2018 13:45Да господи, Вы читаете то, что я выше написал? Рассматриваемый мной клиент-параноик не доверяет рутам!
Удалите из вашего браузера все рутовые сертификаты, и вы получите end-to-end HTTPS. Как в таком случае подписанный у рутов сертификат поможет провайдеру?
nagibat0r
04.07.2018 13:53И еще раз. Это не мешает провайдеру перехватить весь Ваш https. Никак. И к тому же, Ваш способ уже явно ломает всю так называемую безопасность TLS, только не на уровне провайдера, а лично в Вашем компьютере\планшете\etc
andreymal
04.07.2018 13:55И вы по-прежнему увиливаете от ответов на вопросы, как именно провайдер перехватит и как именно ломается безопасность без центров сертификации. Видимо, ветку действительно стоит закончить, раз вы не умеете конструктивно беседовать.
nagibat0r
04.07.2018 13:58И вы по-прежнему увиливаете от ответо
Вам еще раз скинуть строку из конфига Squid?)
как именно провайдер перехватит и как именно ломается безопасность
Заворачивается 443 порт на порт Squid. Всё. Весь трафик на этом порту летит через прозрачный прокси. Так и ломается.andreymal
04.07.2018 14:00Вам еще раз скинуть строку из конфига Squid?)
Эта строчка требует владеть сертификатом, которому клиент будет доверять. Если клиент не доверяет рутам, то как в таком случае подписанный у рутов сертификат поможет провайдеру?
трафик на этом порту летит через прозрачный прокси
И браузер отклоняет все соединения через него, потому что не доверяет подсунутому сертификату. Безопасность не сломана.
Будем продолжать демагогию и хождение по кругу до бесконечности?
nagibat0r
04.07.2018 14:04Конечно, будем. Вот только Вы попробуйте, для начала, сделать, о чем Вы пишите. И отпишитесь, что же у Вас получилось)
andreymal
04.07.2018 14:13Попробовал. Убрал рутовые сертификаты GlobalSign из доверенных в настройках Firefox — гугл перестал открываться.
Скриншот
nagibat0r
04.07.2018 14:23И Вы проиграли! Внимательно прочитайте то, что Вам написал Ваш браузер. На будущее — сначала проверьте свои утверждения, прежде чем предлагать
andreymal
04.07.2018 14:25И Вы проиграли! Внимательно прочитайте то, что написал мне мой браузер:
The certificate is not trusted because the issuer certificate is unknown.
Перевожу на кухонно-бытовой: браузер отказался открывать сайт, потому что он не знает, кто выпустил сертификат, и не доверяет ему.
Произошло ровно то, что и должно было произойти. Браузер не доверяет рутам.
Безопасность HTTPS по-прежнему не нарушена.
nagibat0r
04.07.2018 14:26Безопасности угрозы нет, конечно, ведь соединения тоже нет.
Как вы соединитесь с Гуглом? А верно, никак, пока не добавите его рут в доверенные. А раз добавите его рут, то и провайдер спокойненько произведет MITM. Так что, проиграли Вы!andreymal
04.07.2018 14:31Безопасность есть, потому что соединения нет и никакие личные данные провайдер не смог подслушать из-за отсутствия соединения.
Как вы соединитесь с Гуглом?
Если делать по всем канонам безопасности — схожу к администратору гугла, получу сертификат с открытым ключом лично из его рук и добавлю его в доверенные. (Не в исключения, в которые добавить невозможно, как написано на скриншоте, а сразу в доверенные.) Это будет настоящее честное end-to-end HTTPS шифрование, в которое провайдер никак не сможет вмешаться.
Как вы предлагаете устанавливать end-to-end шифрование при соединении с гуглом? Если не получать открытый ключ лично из рук админа гугла, то как? Расскажите во всех подробностях.
Вы не указали, что исключение браузер добавить не сможет!
В исключения добавлять не надо. Надо добавлять в доверенные. Это разные вещи, не путайте.
nagibat0r
04.07.2018 14:33Я не утверждал, что для Гугла нужен end-to-end. Обфусцируйте свой трафик. Всё. И никто не подменит Вам сертификаты.
настоящее честное end-to-end HTTPS
Сходите в Википедию, прочитайте, что такое end-to-end.
хожу к администратору гугла, получу сертификат с открытым ключом лично из его рук и добавлю его в доверенные
Это бред, мсье
Как вы предлагаете устанавливать end-to-end шифрование
Речь не о Гугле, а обо всём. Использовать тот же ssh. Вот там наичистейший end-to-end. Никто не вмешается в трафик. Никак. А если вдруг что-то случится, то вы не соединитесь, так как отпечаток будет другим. Всё.andreymal
04.07.2018 14:37Обфусцируйте свой трафик.
Допустим, я (клиент) обфусцирую. Но на другом конце кто-то (сервер) кто-то должен его, эм, деобфусцировать, чтобы прочитать мой запрос. Пожалуйста, объясните на пальцах, как мне убедиться, что этот кто-то, кто деобфусцировал мой запрос — на самом деле гугл, а не кто-то выдающий себя за гугл?
Это бред, мсье
Ваше утверждение про бред — это бред, мсье. Обмен ключами при личной встрече — самый надёжный способ обеспечения безопасности. Именно с этого предлагается начинать, например, в PGP.
Сходите в Википедию, прочитайте, что такое end-to-end.
Вы тоже сходите и убедитесь, что TLS без рутов подходит под определение end-to-end.
nagibat0r
04.07.2018 14:53TLS без рутов
Это уже не TLS, так как TLS предусматривает третью сторону априори.
Обмен ключами при личной встрече — самый надёжный способ обеспечения безопасности
я уже написал про SSH.
кто деобфусцировал мой запрос
obfs4 — вполне себе хорошая идея для этого. Если вам важна приватность, используйте Tor+obfs4. Всё. Прочитайте подробнее об этих вещах, всё станет понятно.
Вы тоже сходите и убедитесь, что TLS без рутов подходит под определение end-to-end
ничего похожего в TLS с end-to-end НЕТ. Абсолютно. Это совершенно разные вещи.andreymal
04.07.2018 15:00Это уже не TLS, так как TLS предусматривает третью сторону априори.
Но на практике я вот взял и отказался от третьей стороны в Firefox. Осталось лишь добавить сертификат, которому я доверяю, в доверенные, и можно использовать TLS без третьей стороны. Что я делаю не так?
SSH
SSH при первом подключении к серверу не пускает вас, а спрашивает «Вы довереяете этому ключу? y/n» При согласии ключ сервера добавляется в доверенные. При несогласии никакого соединения не устанавливается. Прямо как с гуглом в моём Firefox! Всё абсолютно то же самое, что и в TLS без третьей стороны.
Прочитайте подробнее об этих вещах, всё станет понятно.
Вы так старательно увиливаете от ответа, что создаётся впечатление, будто вы сами не понимаете, как работает obfs4.
ничего похожего в TLS с end-to-end НЕТ. Абсолютно. Это совершенно разные вещи.
Выше я продемонстрировал, что TLS без третьей стороны удивительно похож на SSH.
nagibat0r
04.07.2018 15:12Вы так старательно увиливаете от ответа, что создаётся впечатление, будто вы сами не понимаете, как работает obfs4.
Вас в Гугле забанили? Ах да, Вы же отказались от рут… Ах да, я имею прекрасное представление о технологии обфускации, о Tor.
Выше я продемонстрировал, что TLS без третьей стороны удивительно похож на SSH
Чем!? END-to-END предусматривает сравнение своих отпечатков открытых ключей. При end-to-end ВСЯ информация пользователя недоступна даже серверам, передающим данные. Где Вы увидели это в TLS?
Прямо как с гуглом в моём Firefox
Кто Вам даст сертификат Гугла? Вы предлагаете палить из базуки по блошкам. Не так обеспечивается безопасность и приватность, как Вы себе представляете, о чем я уже выше сказал. А вот теперь я предлагаю закончить диалог. Окончательно. Вы в корне не понимаете, как работает end-to-end и как работает TLS, хотя даже в Википедии об этом исчерпывающе написано. Всего доброго.
andreymal
04.07.2018 15:13Ах да, я имею прекрасное представление о технологии обфускации, о Tor.
Расскажите, не стесняйтесь, а то я забанил гугл)
Кто Вам даст сертификат Гугла?
А кто вам даёт ключ SSH-сервера при первом подключении?
Где Вы увидели это в TLS?
Когда я получу сертификат гугла из рук админа гугла, я прочитаю его отпечаток и буду сравнивать при подключении, очевидно.
Вы в корне не понимаете, как работает end-to-end и как работает TLS, и почему-то считаете, что TLS и SSH работают по-разному, хотя даже в Википедии об этом исчерпывающе написано.
nagibat0r
04.07.2018 15:18А кто вам даёт ключ SSH-сервера при первом подключении?
А Вы пробовали подключаться-то хоть разок? Видимо нет, раз такие вопросы.
Расскажите, не стесняйтесь, а то я забанил гугл)
Толсто, сэр.
Когда я получу сертификат гугла из рук админа гугла
Вперед. Жду подробный отчет с фотографиями.
Вы в корне не понимаете, как работает end-to-end и как работает TLS, и почему-то считаете, что TLS и SSH работают по-разному
Куда уж мне, действительно.
До свидания.andreymal
04.07.2018 15:22А Вы пробовали подключаться-то хоть разок?
А вы? SSH-клиент показывает вам отпечаток при первом подключении к серверу. Как вы проверяете, что отпечаток правильный?
Вперед.
Мне это не нужно, я доверяю рутам, в отличие от вас. А вот как вы собираетесь доверять гуглу с этим вашим obfs4, вы так и не рассказали, как будто не понимаете, как он работает, и пытаетесь скрыть это отправками в гугл.
До свидания.
До свидания.
nagibat0r
04.07.2018 15:27Напоследок.
я доверяю рутам
Вы троллить не умеете. Пока Вы там доверяете рутам, провайдер у этих рутов подпишет сертификат и будет производить MITM, это скоро будет, поверьте.
Мне это не нужно
Ну вот и отлично)
как будто не понимаете, как он работает
Вот понимаете, я могу рассказать о том, чего явно не написано в Интернете. А рассказывать о такой вещи, как обфускация — потратьте своё личное время для своих личных целей и читайте.andreymal
04.07.2018 15:28Вопрос про проверку отпечатка SSH тактично проигнорировали. И опять гуглить отправили, максируя собственное незнание. Что ж, до свидания.
nagibat0r
04.07.2018 15:33Так, а вот теперь стоп.
Как вы проверяете, что отпечаток правильный?
для каких целей используется SSH в плане безопасности и приватности? Вы поднимаете\покупаете в определенном доверенном месте сервер с SSH, который будет Вас маскировать. Вам ЛИЧНО дадут отпечаток для проверки.
максируя собственное незнание
Толсто. Очень.
я доверяю рутам, в отличие от вас
Я где-то выше сказал, что не доверяю рутам? Это Вы уже потом покрылись и доказывали тут, что вы убираете доверие к рут сертификатам и получаете супер шифрование. Я ни слова о недоверии рутам не сказал. Я лишь сказал, что TLS предусматривает третью сторону, и это проблема, так как провайдер легко за деньги подпишет свой сертификат у рута и произведет MITM.
Не надо переиначивать все и переворачивать!andreymal
04.07.2018 15:41Вам ЛИЧНО дадут отпечаток для проверки.
И чем это принципиально отличается от получения HTTPS-сертификата из рук админа гугла? (Кроме того, что встретиться с админом гугла немножко труднее, конечно, но мы ведём речь о технической стороне вопроса.)
TLS предусматривает третью сторону
Доверять которой вас никто не заставляет.
провайдер легко за деньги подпишет свой сертификат у рута
Я всю ветку игнорирую, что у провайдера не найдётся столько денег, чтоб рута подкупить. Если мы говорим про техническую возможность — идите берите сертификат из рук админа гугла и тем самым защитите себя от прослушки провайдером. Если мы говорим про реальность — ну не сможет провайдер этого сделать, денег не хватит. (Ну или продемонстрируйте обратное на практике.)
Толсто. Очень.
Но всё же уклоняться от конструктивного ответа вы продолжаете.
nagibat0r
04.07.2018 15:46И чем это принципиально отличается от получения HTTPS-сертификата из рук админа гугла?
Я Вам повторяю, что TLS и end-to-end — это разные вещи в корне! Изучите матчасть, прежде чем делать заявление, что TLS без доверия к рутам = end-to-end.
у провайдера не найдётся столько денег, чтоб рута подкупить
Да ну!? На реализацию пакета Яровой находят. А оно стоит намного дороже сертификата.
идите берите сертификат из рук админа гугла и тем самым защитите себя от прослушки провайдером
Не смешите, пожалуйста.andreymal
04.07.2018 15:54Я Вам повторяю, что TLS и end-to-end — это разные вещи в корне!
Я вам повторяю, что TLS и end-to-end — это очень похожие вещи в корне! Что в TLS, что в SSH вы можете получить отпечаток на руки и сравнивать его при подключении. Что в TLS, что в SSH используется RSA для ключей. И ещё в PGP всё то же самое, кстати.
А оно стоит намного дороже сертификата.
Намного дороже поддельного сертификата, выпущенного в обход всех правил? Озвучьте тогда точную стоимость поддельного сертификата — видимо, вы её знаете, раз пишете такие утверждения, нам всем на хабре это будет очень интересно. (Может, вы ещё и сами выпуском поддельных сертификатов занимаетесь и случайно проболтались? Тогда это всё объясняет!)
Не смешите, пожалуйста.
То же самое в SSH и PGP вас почему-то не смешит.
nagibat0r
04.07.2018 19:47Я вам повторяю, что TLS и end-to-end — это очень похожие вещи в корне!
Эх. Ну что ж, раз Вы не знаете матчасть, мне очень жаль. Любите факты? Да пожалуйста.
end-to-end:
Шифрование происходит на конечных устройствах, данные остаются зашифрованными, пока не будут доставлены к месту назначения. Ключи шифрования известны только двум сторонам. Всё. Никому более. Никогда. Кроме того, обе стороны сравнивают свои отпечатки открытых ключей.
tls: нет никаких «своих отпечатков открытых ключей» здесь нет. Вся безопасность сводится лишь к проверке валидности сертификата у root'a. Вы предлагаете отказаться от корневых центров? Вы ломаете эту Вашу безопасность. Без корневых центров вообще никак не проверить подлинность сертификатов. Брать у админа ресурса? Вы шутите? Конечно же шутите. Ведь никто Вам не даст сертификат. Кому это надо? Только Вам, и никому более, никто о Вас и думать не будет. А если добавляете корневые центры, то это ничего не добавит, кроме иллюзии безопасности. Никто не отменял ssl_bump и sslstrip. В end-to-end в принципе невозможна такая атака. Никак.
Озвучьте тогда точную стоимость
А Вы сами спросите у центра сертификации. С чего мне рассказывать Вам подробности получения сертификата?
Может, вы ещё и сами выпуском поддельных сертификатов занимаетесь
Вы меня раскрыли. Какой ужас.
То же самое в SSH и PGP вас почему-то не смешит.
Потому что принцип действия SSH совсем отличается от HTTPS. В корне. Поэтому меня это нисколько не смущает.andreymal
04.07.2018 19:57Шифрование происходит на конечных устройствах
Как в HTTPS.
данные остаются зашифрованными, пока не будут доставлены к месту назначения
Как в HTTPS.
Ключи шифрования известны только двум сторонам. Всё. Никому более. Никогда.
Как и в HTTPS. Центрам сертификации известны только открытые ключи, закрытых они не знают.
Кроме того, обе стороны сравнивают свои отпечатки открытых ключей.
Браузр обязательно занимается этим для каждого HTTPS-соединении, а если что-то не так, то сообщает о проблеме пользователю — скриншот Firefox я вам показывал.
tls: нет никаких «своих отпечатков открытых ключей» здесь нет.
Неправда. Загляните хотя бы разок в свойства сертификата в любом браузере.
Вся безопасность сводится лишь к проверке валидности сертификата у root'a.
Неправда. Вы можете оказаться от root'а и добавлять каждый раз сертификат в доверенные самостоятельно, точно как в SSH.
Ведь никто Вам не даст сертификат.
Неправда. Все спокойно пересылают сертификаты по интернету, и ничто не мешает мне точно так же попросить сертификат у админа сайта по сторонним каналам связи (например, при личной встрече) — главное, чтобы он согласился. (Согласится ли админ гугла — это не относится к технической стороне вопроса.)
А если добавляете корневые центры, то это ничего не добавит, кроме иллюзии безопасности.
Неправда. Поддельный сертификат будет стоить баснословных денег, которых ни у кого не найдётся, поэтому корневые центры обеспечивают безопасность.
В end-to-end в принципе невозможна такая атака. Никак.
Неправда. Достаточно любым образом заставить пользователя доверять ключу. С учётом того, что личные встречи всем организовывать лень — это очень легко, нужно всего лишь немножко социальной инженерии.
А Вы сами спросите у центра сертификации.
Боюсь, что он мне ответит, что выпуском поддельных сертификатов он не занимается, потому что это удар по репутации.
Потому что принцип действия SSH совсем отличается от HTTPS. В корне.
Как я вам наглядно не раз продемонстрировал в моих комментариях, HTTPS приницпиально ничем не отличается от SSH, кроме существования центров сертификации. Перечитайте их ещё раз и не поленитесь изучить матчасть хотя бы на википедии.
nagibat0r
04.07.2018 21:51И ещё раз. Даже если Вы уберёте корневые центры из доверенных, да хоть что сделаете, это не мешает ни разу производить mitm. Покупка сертификата провайдером — это лишь для создания иллюзии Вашей безопасности. Провайдер может этого не делать, а дать Вам сертификат для импорта в браузер. Вы можете отказаться. Но при открытии ресурса Вы все равно не обеспечите безопасность с помощью https, так как bump будет произведён в любом случае, так как 443 порт завернут на прокси. Достаточный довод? Или мне нужно процитировать пример из той же squid wiki?
andreymal
04.07.2018 21:58это не мешает ни разу производить mitm
И ещё раз. Как провайдер проведёт mitm без доверия купленному сертификату?
дать Вам сертификат для импорта в браузер. Вы можете отказаться.
Да, естественно я откажусь.
Но при открытии ресурса Вы все равно не обеспечите безопасность с помощью https, так как bump будет произведён в любом случае
Браузер прервёт соединение, потому что не доверяет сертификату провайдера. Безопасность будет обеспечена путём недоверия сертификату и обрыва соединения.
Достаточный довод? Или мне нужно процитировать пример из той же squid wiki?
Нет.
Давайте вы подтвердите свои слова на практике? Получите валидный сертификат на мой домен andreymal.org и поднимите веб-сервер с ним. Дайте мне IP-адрес сервера, я внесу его в файл hosts (тем самым имитировав вмешательство провайдера в трафик). Перед подключением я удалю все корневые сертификаты из моего браузера. Если браузер успешно подключится к вашему серверу и автоматически признает ваш сертификат безопасным, то я признаю свою неправоту, компенсирую вам расходы на покупку сертификата (если покажете, что они были) и ещё на сотню литров пива сверху докину.
nagibat0r
04.07.2018 22:05И ещё раз. Как провайдер проведёт mitm без доверия купленному сертификату?
SSL Bump будет произведен в любом случае, как только Вы откроете ресурс, независимо от того, есть ли у Вас сертификат в списке доверенных или нет. Просто, если сертификат провайдером не куплен, а самоподписан, у вас «значок не зелененький» будет, пока не добавите провайдеровский сертификат в доверенные.
Браузер прервёт соединение, потому что не доверяет сертификату провайдера
Ну а Вам-то надо попасть на ресурс!? В чем заключается безопасность? Нет соединения-нет проблем? Прикольная у Вас логика.
автоматически признает ваш сертификат безопасным
Вы читаете, что я пишу? Мне кажется нет. При чем здесь автоматическое признание? Я что, Ваш провайдер? Уже сказал, что провайдер может купить сертификат, может дать Вам для внесения в список доверенных, и Вы можете отказаться. Но Вам нужно попасть на ресурс, не так ли? И как Вы туда попадете с помощью Вашего суперзащищенного HTTPS? Я уже устал повторять, я говорю о том, что HTTPS небезопасен, так как его можно расшифровать с помощью SSL Bump. Где здесь безопасность? А плюс к этому, третья сторона в протоколе. Это не безопасность вовсе.andreymal
04.07.2018 22:09пока не добавите провайдеровский сертификат в доверенные
Никогда не добавлю.
Ну а Вам-то надо попасть на ресурс!?
На небезопасный — не надо.
его можно расшифровать с помощью SSL Bump.
Хорошо, давайте по-другому. Поставьте прокси с этим вашим squid и ssl bump между мной и моим сервером. Я точно так же внесу его в hosts или в настройки браузера и попользуюсь своим сайтом (root'ы удалять не стану). Если браузер не выдаст ошибку безопасности и если вы мне покажете расшифрованный трафик, перехваченный вами — я также признаю свою неправоту и кину вам на пиво.
nagibat0r
04.07.2018 22:17Товарищ Андрей (Вас ведь так зовут?), а теперь перечитайте ветку. При осуществлении SSL Bump происходишь дешифровка. Полная. Далее идет обратный процесс, только своим сертификатом. Он должен быть либо в списке доверенных, либо подписан корневым центром, но лишь для того, чтобы показывался «зеленый значок». Не более! И так для всех https ресурсов.
На небезопасный — не надо.
Ресурс — безопасный. Небезопасный протокол! Вы откажетесь от всего Интернета?
Если браузер не выдаст ошибку безопасности
Я не сказал, что он не выдаст ее! Вы либо добавляете в список доверенных мой сертификат, либо я его подписываю в корневом центре. Иначе-ошибка. Но на ресурс вы зайти сможете.andreymal
04.07.2018 22:50Вы либо добавляете в список доверенных мой сертификат, либо я его подписываю в корневом центре. Иначе-ошибка.
Вот именно!
Иначе — ошибка.
Иначе — данные не будут переданы.
Иначе — утечка HTTP-трафика с секретной информацией не произойдёт.
Иначе — безопасность будет обеспечена.
HTTPS безопасен.
nagibat0r
04.07.2018 23:08Нет, и еще раз нет. Вы в корне неверно рассуждаете.
andreymal
04.07.2018 23:15Это вы в корне неверно рассуждаете. Почему-то считаете, что я буду доверять поддельному сертификату, хотя я не буду доверять. Почему-то считаете, что провайдер купит поддельный доверенный сертификат, хотя у него денег не хватит и не факт что вообще продаст хоть кто-нибудь.
nagibat0r
05.07.2018 06:59Если Вы не сможете доверять сертификату, как Вы попадете на ресурс!? Ведь MITM будет в любом случае, хотите Вы этого или нет, добавите вы в «доверенные» сертификаты или нет. Я Вам уже задавал этот вопрос, но Вы не ответили. В этом и заключается Ваша безопасность — не использовать Интернет?
Scondo
05.07.2018 09:44Тут мне кажется вы смешиваете два совершенно разных класса задач:
1) Подтверждение, что установленное соединение не прослушивается.
2) Установка соединения несмотря на попытки его прослушать.
Вторая задача в общем виде вообще не решается: провайдер в этом смысле может как запретить SSL без подмены сертификата, так и вообще запретить SSL.
andreymal
05.07.2018 11:08Если Вы не сможете доверять сертификату, как Вы попадете на ресурс!?
Никак. В том и суть. Я не попадаю на ресурс и благодаря этому не передаю секретные данные, зашифрованные левым сертификатом — безопасность обеспечена.
Ведь MITM будет в любом случае, хотите Вы этого или нет
И мне плевать, потому что браузер не доверяет сертификату и пишет ошибку, и я не попадаю на ресурс — безопасность обеспечена.
В этом и заключается Ваша безопасность — не использовать Интернет?
Спустя сутки вы наконец-то это поняли!
Только это не значит, что при MitM остаётся сидеть ничего не делать.
Можно как минимум:
сменить провайдера (в моём доме их штук пять, плюс как минимум четыре мобильных оператора в Петербурге);
осилить DNSSEC (мой провайдер осуществляет MitM для deviantart.com путём подмены DNS-ответов с подсовыванием IP-адресов серверов, имеющих поддельные сертификаты, и DNSSEC спасает от такого MitM);
подключить какой-нибудь такой VPN или SOCKS-прокси, который не будет заниматься подменой HTTPS-сертификатов.
Вот когда ВСЕ ТРИ варианта окажутся неработоспособными, тогда катастрофа. А пока я MitM моего провайдера успешно обхожу.
nagibat0r
05.07.2018 13:25Я в самом начале обсуждения сказал, что HTTPS небезопасен, и нужно использовать другие средства защиты, а Вы мне сейчас Америку открыли!!??
осилить DNSSEC
Это нужно было осилить уже давно.
сменить провайдера
Смысл?
подключить какой-нибудь такой VPN или SOCKS-прокси
VPN рубится и факт его использования на стороне провайдера очень даже отлично определяется теми же Цисками. Да куда там, даже Kerio умеет. Как и SOCKS — рубится с полпинка практически. Так что единственное, что поможет в корне — это obfs+tor. О чем я, черт возьми, в начале и сказал, но Вы развели демагогию, дназывая https безопасным и доказывая это чуть ли не со свистом, но при этом предлагая удалять доверительные отношения с рутами (на чем и в принципе основан https). И при этом в конце сказав, что Вы боретесь с MITM… Уважаемый, у меня нет слов :)
А пока я MitM моего провайдера успешно обхожу
Скоро по-другому будет)andreymal
05.07.2018 13:34HTTPS небезопасен
HTTPS безопасен. От государства и от АНБ не защитит ничего кроме шапочки из фольги (об этом даже нет смысла разговаривать), а от васи пупкина и от провайдера HTTPS очень даже защищает.
Смысл?
Другой провайдер может не делать MitM.
VPN рубится
Я вам больше скажу — весь интернет рубится! Было бы желание. Только оттого, что вы перерубите свою витую пару, HTTPS не станет небезопасным.
Так что единственное, что поможет в корне — это obfs+tor.
Не поможет, если, например, отрублен весь интернет. Ну или если провайдер будет рубить абсолютно весь подозрительный трафик, например по белому списку. Но опять же к безопасности или небезопасности HTTPS это не имеет никакого отношения.
TrllServ
05.07.2018 13:43а от васи пупкина и от провайдера HTTPS очень даже защищает.
Не сертификат, а шифрование. Уже лет 15-20 как защищает.
И ещё очень долго будет защищать, потому как у васи пупок развяжется стать посередине и пускать через себя весь трафик. Не говоря уже о том, что б его дважды гонять через шифрование.
Техническое и финансовое ограничение единственная причина почему провайдер не становится митм, а не СЦ.andreymal
05.07.2018 13:53Весь трафик «дважды гонять» совсем не обязательно, достаточно лишь трафик одного конкретного неугодного пользователя прослушивать, а с этим даже дохлый андроид справится. Но для этого нужно получить доверенный сертификат у СЦ. Если государство ещё как-то может теоретически надавить на СЦ этими вашими судами и РКНами, то вася пупкин и провайдер (сам по себе, без помощи государства) уже ничего поделать не смогут.
nagibat0r
05.07.2018 14:19HTTPS безопасен
Да ради Бога, думайте так дальше, я Вам не мама, чтобы воспитывать.
Другой провайдер может не делать MitM
И не факт, что Вы это узнаете ;-)
Я вам больше скажу — весь интернет рубится
Я понял уже давно, что для Вас безопасность — не пользоваться вообще ничем. Но мы говорим не об этом.
например по белому списку
Какие белые списки? Вы о чем? OBFS маскирует трафик, делает нечитабельным. Отрубить неизвестный трафик — это убийство, на это даже Китай не пошел, от чего там успешно работает OBFS.andreymal
05.07.2018 14:26Отрубить неизвестный трафик
… вполне технически возможно. Сегодня Китай не пошёл — а вдруг завтра пойдёт? Центрам сертификации и провайдерам вы не доверяете, а Китаю доверяете?)) И, кстати, вы так и не рассказали, как obfs4 работает, как будто не знаете, как он работает.
TrllServ
05.07.2018 14:39+1как будто не знаете, как он работает.
Зачотный троллинг.
Малыш нашёл себе бесплатных учителей, но оно так не работает.
PS:
Даже если расскажут как, ученик имеет слишком поверхностный подход, не утруждает обдумыванием полученой информации т.е. теряет 80-90% даже кратко изложенного.
Такие «знания» только, что б «пыть в глаза» пускать.andreymal
05.07.2018 15:25А вы окончательно скатились в бессмысленную демагогию. Если собеседник не готов доказывать свои утверждения, значит не нужно было ничего писать. nagibat0r говорит, что с OBFS4 всё хорошо — вот пусть объяснит мне и другим читателям, почему с ним всё хорошо.
TrllServ
05.07.2018 15:55nagibat0r говорит, что с OBFS4 всё хорошо
Как специалист я с ним согласен.
Правда стоит уточнить, у него намного лучше, чем у большинства других для соответствующих целей.
Для нашей ситуации эти решения избыточны чуть больше чем полностью.
вот пусть объяснит мне и другим читателям, почему с ним всё хорошо.
Путин лично выписал особые полномочия, что я наблюдаю повелительный тон?
Когда решит написать статью, что б разложить особенности для неофитов, тогда и «объяснит» почему и как там лучше.andreymal
05.07.2018 15:57Когда решит написать статью, что б разложить особенности для неофитов, тогда и «объяснит» почему и как там лучше.
Если собеседник не готов подтверждать свои слова сейчас, значит не нужно было вообще начинать эту бессмысленную ветку.
TrllServ
05.07.2018 16:14Если собеседник не готов подтверждать свои слова сейчас, значит не нужно было вообще начинать эту бессмысленную ветку.
Если собеседник не готов восполнять пробелы в знаниях из энциклопедий и статей по ключевым словам в ответах, значит не нужно было вообще начинать эту бессмысленную ветку.andreymal
05.07.2018 16:16-1Когда эти энциклопедии и статьи не содержат ответов на мои вопросы, мне ничего не остаётся, кроме как задать их тому, кто меня отправил в эти энциклопедии и статьи. Если собеседник уворачивается от ответов на них, значит не нужно было вообще начинать эту бессмысленную ветку.
nagibat0r
06.07.2018 09:04Для нашей ситуации эти решения избыточны чуть больше чем полностью.
Именно.
Путин лично выписал особые полномочия, что я наблюдаю повелительный тон?
Да у этого персонажа, видимо, все полномочия, насколько он думает. Однако…
Когда решит написать статью, что б разложить особенности для неофитов
Возможно и стоит написать, да. Но позже. Дел по-горло. Итак одна долгожданная статья в черновиках висит уже месяц, никак не доделаю.
nagibat0r
05.07.2018 14:42вполне технически возможно
Я не сказал, что это НЕВОЗМОЖНО! Я сказал, что этого никто не сделает! По понятным причинам!
вы так и не рассказали
Если Вам сложно открыть Гугл, ок, специально для Вас, коли Вы такой лентяй.
Obfs4 использует протокол, который маскирует свой трафик, чтобы он выглядел как случайные данные. Obfs4 основывается на ScrambleSuit — транспортном протоколе, который затрудняет, для DPI, идентификацию и блокировку трафика. ScrambleSuit обеспечивает защиту от атак зондированием, используемым Великим китайским файрволом. При использовании obfs4, рукопожатие всегда делает полный обмен ключами. Рукопожатие использует метод согласования ключей NTor, который запутывает открытые ключи при помощи алгоритма Elligator 2; Шифрования канального уровня использует библиотеку (NaCl) с имитовставками (Poly1305 и XSalsa20). Считается лучшим в том, что он быстрее, чем другие транспорты. Для реализации обфускации obfs4 используется obfsproxy. Obfsproxy работает по принципу клиент-сервер, на стороне клиента Tor трафик обфусцируется (маскируется) в obfsproxy и уже потом отправляется в направлении т.з. моста, где также стоит obfsproxy который снимает с трафика маскировку и шлёт его уже в Tor сеть. Таким образом скрывается факт использования Tor сети и повышается безопасность TLS/SSL трафика за счет его дополнительной модификации (обфускации). Надеюсь, внятно?
а Китаю доверяете
А при чем здесь Китай? Какая разница, доверяю я ему или нет? О чем Вы? Так, чтобы спросить и поболтать ни о чем?andreymal
05.07.2018 15:20Много умных терминов без конкретики, но хоть что-то.
При использовании obfs4, рукопожатие всегда делает полный обмен ключами.
Обмен ключами с кем? Как убедиться, что обмен произошёл с кем надо, а не с кем-то подконтрольным условному Китаю?
моста, где также стоит obfsproxy
Как убедиться, что мост не подконтролен условным китайским властям? Какое из перечисленных вами заумных слов обеспечивает это? Или даже так: откуда клиент вообще узнаёт адрес моста?
А при чем здесь Китай?
Это я вас спросить хотел, это вы зачем-то вспомнили Китай.
Я сказал, что этого никто не сделает! По понятным причинам!
По причинам, в правильность которых вы решили верить.
nagibat0r
05.07.2018 15:39без конкретики
Я что, бесплатная Википедия? Я рассказал все довольно подробно, что еще требуется? Потратьте своё личное время и перечитайте 100 раз, может и поймете.
Обмен ключами с кем? Как убедиться, что обмен произошёл с кем надо, а не с кем-то подконтрольным условному Китаю?
Извините. но я спрошу. Вы в себе?
подконтрольным условному Китаю
Выше спросил.
Это я вас спросить хотел, это вы зачем-то вспомнили Китай.
А почитать в Гугле не судьба, как связан OBFS и Китай? Мне снова тратить личное время на ответ на глупый вопрос?
Речь о Великом Китайском Файрволе, который славится тем, что кастрировал все, что можно, но Tor работает через OBFS.
правильность которых вы решили верить
Кормитесь в другой веткеandreymal
05.07.2018 15:43Опять уклонились от всех ответов.
Вы в себе?
А вы в себе? Если бы вы были в себе, то спокойно ответили бы, как решается вопрос доверия серверу в OBFS4, без вот такой вот демагогии.
nagibat0r
05.07.2018 19:50Я ещё раз повторяю, я Вам рассказал, как оно работает, и я прекрасно знаю, но так как Вы неспособны усвоить ничего, идите в Гугл, пожалуйста. Я не намерен отвечать на вопросы, которые ставятся в такой форме. Во первых, я не на экзамене, а Вы далеко не учитель. Во вторых, Вы все равно не согласитесь ни с чем в силу своего жирного троллинга
andreymal
05.07.2018 20:08-1Ну я ещё раз напоминаю вам, что вы не доказали, что OBFS4 достаточно. Вы просто нахватали терминов из гугла и накопипастили их мне. Видимо, на этом ветку можно завершать, раз отвечать на вопросы вы не желаете.
nagibat0r
05.07.2018 20:16Ещё раз. В моём сообщении указано то, о чем спрашивали. Нужны подробности? Вот спецификация https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt. Читайте.
andreymal
05.07.2018 20:25Я её читал и не нашёл там ответа на свой вопрос. Эта спецификация или чего-то не договаривает, или всё же предполагает, что клиенту «server's Node ID and identity public key» сервера заранее известны. Но откуда клиент OBFS4 их узнает-то?
nagibat0r
05.07.2018 20:27Читайте ещё раз.
andreymal
05.07.2018 21:21Прочитал ещё раз, внимательно-превнимательно, и нашёл вот что:
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» идёт речь — по вашей ссылке нигде не сказано.
Может, скажете вы?
nagibat0r
06.07.2018 07:27Это внеполосные данные — логически независимый канало передачи между парой поточных сокетов.
andreymal
06.07.2018 07:31Какой конкретно «логически независимый канал передачи» (или несколько каналов) нужно использовать для получения «the identity key (B) and NODEID» при работе c OBFS4? Какой конкретно канал будете использовать лично вы, например?
nagibat0r
06.07.2018 07:55Может быть Вы изучите матчасть, в конце концов?
Я сказал, что HTTPS небезопасен в том виде, в котором он есть и всем рекалмируется. Пояснил, почему. Предложил альтернативу. Безоговорочную. OBFS4 сигнатуры не существует и вряд ли она появится, так что он не может быть обнаружен. Дал описание работы протокола, краткое. Дал ПОЛНУЮ спецификацию, в конце концов.
Какой конкретно канал будете использовать лично вы
Еще раз ВНИМАТЕЛЬНО прочитайте спецификацию. Зайдите в Tor WIKI, в конце концов. Там есть ВСЯ информация. Правда, на английском, но понять там все прекрасно можно.
Obfsproxy гарантирует соединение с именно тем бриджом, который указали в конфиге. Гарантирует, что пакеты будут доставлены в обфусцированном виде до бриджа и будут посланы дальше в Tor-сеть. Гарантирует, что пакеты будут приняты в обратном порядке именно Вами, а не Васей. Почему? Потому что происходит обфускация всего трафика от obfsproxy на Вашем ПК до obfsproxy на бридже. Как так происходит? Это написано в спецификации. Пожалуйста, потратьте своё личное время, в конце концов.
З.Ы.: любой протокол, у которого существует сигнатура, считается не совсем безопасным. В чем состоит безопасность? Что никто не сможет вмешаться в ваше соединение и не сможет отследить ничего касаемо вашего соединения. Есть сигнатура — можно отследить. Можно вмешаться. Всё.
И да, Вы так и не признали, что проиграли в споре про безопасность HTTPS. Что ж, в таком случае я прекращаю с Вами диалог с этой минуты. Всего доброго, и удачи в изучении матчасти.andreymal
06.07.2018 08:00Не увиливайте от ответа.
бриджом, который указали в конфиге
Чтобы указать бридж в конфиге, надо его откуда-то получить. Откуда? Откуда лично вы взяли (или возьмёте в будущем) бридж?
andreymal
06.07.2018 08:10Нет уж, давайте вы продемонстрируете свою некомпетентность публично! Вы мне в личке ответили:
Слушайте, Андрей, может вы прекратите ТУПИТЬ и включите голову? Бриджи берутся с сайта Tor! Это известно всем! Нигде более их не взять! Совмеваетесь в том, что показано на сайте после капчи? Пишите разработчикам на емейл, который указан! Вам пришлют бриджи! Чего Вам нужно? Потроллить? Или Вы глупый?
Признайте, что спор Вы проиграли. А Вы его проиграли с треском.Сайт может быть подменён провайдером с помощью поддельного сертификата, вы сами мне об этом целые сутки рассказывали.
На почту можно писать только с адресов Gmail, Riseup!, или Yahoo! — опять же все три могут быть подконтрольны каким-нибудь американцам. При этом в почте даже не предлагается использовать шифрование (а если бы предлагалось, то всё равно непонятно, как доверять ключу).
То есть все упомянутые способы заведомо небезопасны и могут подсунуть бридж злоумышленника.
Так как же получить такой бридж, которому можно доверять? Вы мне так и не рассказали. Пока не расскажете — проигравшим считаетесь вы.
nagibat0r
06.07.2018 08:42проигравшим считаетесь
HTTPS небезопасен, что я доказал, Вы проиграли. Мне всё равно, что вы там считаете, но раз Вы не можете просто признать, что проиграли спор, то разговривать с Вами не о чем.
могут подсунуть бридж злоумышленника
О май гад, Вам еще рассказывать, как работает луковая маршрутизация? Если Вы читали спецификацию и Tor WIKI, то поняли бы, что после деобфускации идет Tor — трафик, который дешифровать на самом бридже нельзя. Никак.
При этом в почте даже не предлагается использовать шифрование
Можете использовать шифрование, кто не дает? Ваша безопасность — это ваша безопасность!
Сайт может быть подменён провайдером с помощью поддельного сертификата
Вы приписываете мне то, чего я никогда не говорил! Я сказал, что можно подменить сертификат и расшифровать трафик, о подменах сайта речи не было, не свистите.
вы сами мне об этом целые сутки рассказывали
Вы сутки доказывали, что HTTPS безопасен, но проиграли этот спор. Где слова: «Да, я проиграл спор»? Вы балабол и только.
З.Ы.: если Вы не доверяете своему почтовому провайдеру и не хотите получать бриджи с сайта Tor, поднимайте свой бридж там, где угодно, и подключайтесь к нему, о чем кстати тоже написано в Tor WIKI.
З.Ы2: на этот раз, я действительно прекращаю с Вами диалог:) Вы проиграли спор и не признали это. Вы откровенно глупите и троллите, демонстрируя всем свою глупость. До свидания. Нет желания общаться с троллем.andreymal
06.07.2018 09:25-1Имея сертификат с приватным ключом, провайдер может не только слушать, но и менять данные как угодно, подняв поддельный сервер — это же самые основы HTTPS, которые должны быть вам прекрасно известны. Кроме того, сайт можно просто заблокировать, а gmail может не пускать письма от Tor или для Tor. Даже если вы получите адрес какого-то бриджа, провайдер всё подслушает (у него же поддельный сертификат, вы сами говорили) и тупо заблокирует бридж по айпишнику. Так что вы в любом случае остаётесь без бриджа — до луковой маршрутизации дело вообще не доходит, она ни при чём.
Для того, чтобы поднять свой бридж, нужен провайдер, который не будет резать тор и который вообще позволит подключаться извне. Таких провайдеров с каждым днём всё меньше. И кстати чем свой бридж принципиально будет отличаться от бриджа на локалхосте?
Чтобы получить гарантированно хороший бридж, остаётся только лично встретиться с админом бриджа и получить от него Node ID и публичный ключ. И надеяться, что провайдер не забанит его по айпишнику. То есть безопасность абсолютно такая же, как и в HTTPS при отказе от центров сертификации — только там мы пытались встретиться с админом гугла.
HTTPS безопасен ровно на столько же, насколько безопасен OBFS4 — безопасность обоих упирается в доверие заранее известному публичному ключу. Недоверенный OBFS4-сервер может даже не слушать, а просто не пускать ваш трафик.
Вы говорили, что OBFS4 трафик рубить не получится — я вам рассказал, как его обрубить.
Вы пытаетесь замаскировать свой проигрыш демагогией и манипулированием терминами, так что, наверно, разговаровать с вами действительно не о чем. До свидания.
nagibat0r
05.07.2018 20:25Вы, кстати, не доказали, что https безопасен. Абсолютно. Никак. Потому как есть такие вещи, как sni и splice. И я как провайдер легко даже без подмены сертификатов увижу, куда Вы заходили, и даже терминирую туннель, если нужно. Это абсолютно неоспоримо. Так что спор Вы проиграли. Можете идти в другую ветку и упорно доказывать всем всё, что угодно
TrllServ
05.07.2018 16:09Извините. но я спрошу. Вы в себе?
Очень даже в себе.
Просто выуживает информацию, которую не может найти в полноценных статьях.
rogoz
04.07.2018 22:36Это уже не TLS, так как TLS предусматривает третью сторону априори.
Вы полегче с такими обобщениями.
en.wikipedia.org/wiki/TLS-PSK
nagibat0r
04.07.2018 14:31И еще, переводите на кухонно-бытовой язык сообщения своего браузера кому-нибудь другому, но не мне, однако не лукавьте, и исправьте свой перевод. Вы не указали, что исключение браузер добавить не сможет!
nagibat0r
04.07.2018 14:06Вы хотя бы знаете суть работы ssl bump? Знаете, подмена чего именно происходит?
stork_teadfort
04.07.2018 16:15Итог ветки:
нагибатор 0:1 андреймалnagibat0r
04.07.2018 19:17Увы, я не могу бесконечно сидеть и отвечать на бесконечные глупые утверждения)
Zenitchik
04.07.2018 19:31Так Вы же не отвечали. Вы уклонялись от ответов.
nagibat0r
04.07.2018 19:53В чем же я уклонялся? Мне что, присылать ответы вида «давай я поищу в гугле вместо тебя»? Может быть, будем уважать друг друга и дурацкие вопросы будем задавать Гуглу?
Ведь если посмотреть на то, каким образом работают end to end и HTTPS, то очевидны недостатки последнего. Если есть третья сторона — это не безопасность по причинам, которые я указал выше. Удалять руты? Да ни один здравомыслящий человек это не сделает, потому что он на половину сайтов никогда не зайдет из-за HSTS.
pansa
04.07.2018 22:49Простите, чушь.
Все CA сейчас выписывают сертификаты только с обязательной регистрацией в Certificate transparency. А это значит, что выписать за денежку рутовый сертификат, которым провайдер сможет читать весь трафик — это палево на весь мир, и ни один адекватный CA на это сейчас не пойдет. Ну а если пойдет, то будет быстро запален и вырезан из доверенных. Вмиг.
И да, пропихнул эту тему — злой гугл.andreymal
04.07.2018 22:52Чисто теоретически вроде бы можно выписать липовый сертификат по старинке в обход Certificate transparency. И тогда, возможно, палево случится не сразу. Впрочем, я всё равно не верю, что это возможно на практике, даже за большие деньги)
vikarti
06.07.2018 11:54Очень хорошо. Допустим открыт Российский CA, который прямо заявил, мы понимаем что возможны вопросы с доверием поэтому мы (пока) обслуживаем клиентов ТОЛЬКО из РФ (и спрашиваем скан паспорта) + только для доменов .ru/.рф (хотя технически способа и нет).
Допустим в браузеры его допустили.
И реально делают как обещал. Поддерживает и DV и EV/OV. Авторизация только через госуслуги.
Что он сможет сделать если придет ФСБ с ордером в котором:
— выдать сертификат на сайт террористы.com
— НЕ светить эту информацию нигде (в том числе в Certificate transparency)
Для упрощения задачи — против сайта террористы.com в США исков не подают только потому что свобода слова но в том что там таки террористы — даже в США очень у многих людей сомнений нет.
Также для упрощения задачи — ФСБ получила этот ордер с соблюдением всех процедур, судья не за 10 минут принял решение, у ФСБ ЕСТЬ основания считать что террористы.com реально используется для координации деятельности организации (ну и пропаганды тоже) и они хотят провести теракт в России. Суду эти доказательства были предъявлены.
CA оспорил решение.
Еще одно заседание (опять закрытое) — опять доказательства предъявлены + Роскомсвободу позвали (ну допустим они юридической защите CA помогают).
Материалы закрыты но все участники (и Роскомсвобода тоже) подтверждают что ФСБ вообщем не врет, и весьма вероятно — мониторинг трафика из России к этому сайту — поможет предотвратить теракт. Но детали публике сказать не можем. Сначала все было секретным но потом на публику утек сам факт (без указания сайта).
Что должен делать CA? С учетом что решения законное, даже оспорить дали, все кто в курсе — понимают что ну вообщем то запрос обоснован да и просят они один конкретный сайт (а не subCA). Но — это нарушение их политики (они прямо обещали что НЕ будут для .com выдавать) + CA Browser Forum может иметь определенные вопросы к ним на базе хотя бы этой утечки и могут превентивно даже выпилить (или как минимум потребуют подтверждение — но CA прямо запрещено ж разглашать эту информацию — как изначальным запросом ФСБ так и решением суда).
И что CA делать? Технически возможность сделать что просят — у них есть, законное требование — есть. Последствия даже не самого действия а слуха что они это сделали — вообщем то же очевидны.
Если они в итоге вылетят из доверенных — где гарантия что не начнется новый вой на тему антироссийских санкций и «а какие гарантии что АНБ такое не потребует у своих»…
И как быть?
Всем участникам этой истории (Считаем что ФСБ реально считает что им нужен сертификат для перехвата и что польза- будет и готова это доказать независимым экспертам и разрешить опубликовать отчет (без идентифицирующих деталей))
evgenWebm
04.07.2018 12:03-2Хе.
Автор говорит, что он работает в сфере «Информационная безопасность».
Но после прочтения вот этого текста(ну на самом деле, не только)
Согласно письму я должен «перейти на HTTPS, чтобы избежать срабатывания предупреждений и помочь защитить данные пользователей».
Это блог. Я не запрашиваю никакие данные у пользователей.
То я как минимум понимаю, что человек не компетентный в вопросах, которые он тут поднимает.
Автор я не хочу тебя обидеть. Но твой пост пропитан юношеским максимализмом и при этом технически безграмотен.
…
Довод понравился… ну верней я посмеялся от души.
Если HTTPS — это так круто…
Тогда зачем заставлять людей?
А можно я продолжу мысль?
Если ездить 60км в час так круто, то зачем людей заставлять?
Если пешеходный переход это так круто, то зачем людей заставлять?
и тп.
И я замечу, это говорит человек, который утверждает, что он работает в сфере информационной безопасности.
Интернет небезопасен. Это правильно. Мы не хотим, чтобы всё было безопасным.
Это вы не хотите. А я, и большинство пользователей хотят.
Конечно достичь 100% безопасности нельзя(вы наверно знаете, раз инф.без. занимаетесь).
Но стремится надо.
А то с такой логикой, давайте вернемся в пещеры. Будем бить себя дубинками по голове и насиловать женщин.
Ведь мы не хотим что было все безопасно. А что всё, это определяют специалисты по безопасности.
Пометка «ненадёжный» от Google обозначает: «Google попытался взять под контроль открытый Интернет, и этот сайт сказал «нет»».
Пометка ненадежный означает, что сайт передает информацию по не защищенным соединениям.
А то что вы написали, это юношеская глупость.
Помимо гугла есть Микрософт, есть Мозила, есть Эпл. У всех есть браузеры. Все лежат в свободном доступе. Бери не хочу.
Есть более одного варианта, как и где получить сертификат.
От нуля рубля до небес. Сертификат можно купить за 15 баксов на год.
Так скажите, где тут контроль гугла? Вы явно путаете монополизм и контроль.
Вещи хоть и в чемто схожи, но в целом это два разных понятия.
Не надо их путать.
Мне кстати довод про историю интернета понравилось.
забудем, что это нужно двум калекам и то чисто поржать.
Я скажу только одно. Интернет давно стал свалкой. Свалкой, где свежая информация перемешана с «говном мамонта». С каждым годом, найти адекватную и свежую информацию становится сложней. Так как приходится перекапывать тонны старья.
И если с помощью гугла отвалятся бложики специалистов по безопасности за 2000-й год, то я будут очень этому рад. Так как в интернете и так хватает мусор. Меньше мусора, больше свободы.
З.Ы. Хотел написать маленькое замечание. А вообще пост напоминает картинку против вакцинации.
Заголовок спойлера
Alexey2005
04.07.2018 13:07Да как раз мусор в Интернете — он весь свежий. И проблемы с поиском как раз по вине новых ресурсов. Например, таких помоек как pinterest, который уже забивает первые 10 страниц поисковика по большинству запросов и которого век бы не видеть.
А ещё проблемы с поиском из-за всех тех ресурсов, которые додумались сделать бесконечную прокрутку. Так что если у вас поисковик выдал ссылку на какой-нибудь ВКонтакт, вам ещё постараться придётся, чтобы по этой ссылке найти нужное.
Зато вот с появлением HTTPS перестали работать кэширующие прокси — они стали попросту бесполезными. А ведь они очень неплохо помогали экономить трафик, да и плавность работы с ними была куда как выше.evgenWebm
04.07.2018 13:15+1Я не отрицаю про новый мусор.
С этим тоже надо разбираться. Ибо такие помойки как пикабу(ну хоть ресурс по себе интересен) или pinterest, засоряют интернет.
Я не отрицаю и согласен с вами.
Зато вот с появлением HTTPS перестали работать кэширующие прокси
Данную функцию переложили с плеч прокси на плечи разработчика сайтов.
Теперь вы сами должны кешировать свои данные на «проксях» чтобы сайт был доступный во всех регионах мира.
К примеру CDNNOW.
И поверьте, я как разработчик, очень рад, что теперь мой трафик не будет кешироваться на левых проксях. Так как, прокся позволяет потерять контроль над трафиком.
А это к слову уже не безопасно.
А ведь они очень неплохо помогали экономить трафик, да и плавность работы с ними была куда как выше.
Мир движется. Конечно любая новая технология приносит и минусы.
Но надо впервую очередь смотреть на то, что решает данная технология.Scondo
04.07.2018 17:48Во-первых для того, чтобы CDN работал вы должны тем или иным способом дать CDN право представляться вашим сайтом. И это исключительно вопрос вашего доверия в службе CDN, что данные не будут подменены на пути, а статистика запрашиваемых данных не будет использована третьими лицами.
Во-вторых, я писал выше, что да, для разработчика контроль над трафиком — это удобно и выгодно. Однако пользователю выгоднее, чтобы никто не контролировал весь трафик целиком.
nagibat0r
04.07.2018 13:43Да, HTTPS — это проблема… Ну конечно же bump помогает, но там еще динамический контент, который только storeid разрулит. Однако, занятие долгое — настройка.
DRVTiny
04.07.2018 18:52+1Не далее как позавчера читал статью о заводе «Рубин», датированную 1995-м годом.
Я не должен был её читать, потому что они слишком старая? Возможно, мне не стоило бы читать свежие воспоминания участников событий 1993-го, 1996-го, 1998-го, 1999-го годов, потому что в них — правда, а не то, что придумывают об этих событиях в 2018-м году. Да, наверное, с точки зрения разного рода полицаев всех мастей, необходимо ограничить доступ ко всему старому, потому что интернет — это своеобразная коллективная память, и я прекрасно понимаю, что многим, наверняка и вам в том числе, выгодно, чтобы эта память была как можно короче.
>А то с такой логикой, давайте вернемся в пещеры. Будем бить себя дубинками по голове
Да, кстати, если уж говорить про «себя дубинкой по голове», то да, у меня есть неотъемлемое право бить себя дубинкой по голове — и никто у меня это право просто так не отнимет. И уже моё личное дело, буду я им пользоваться или нет, вас это абсолютно не касается.
Ilya81
04.07.2018 12:46В некотором смысле это так — чтоб зайти, игнорируя это предупреждение, нужно проходить основательный quest. Да и методология проверки сомнительна, что это для безопасности, а не для доходов самого Google. Но в то ж время на счёт мелких сайтов преувеличение — если это просто старые данные, то также однажды могут выключить сервер и разобрать его на запчасти/металлолом. На счёт новых — а много ли их нынче — всё равно нынче в 99,9% случаев выбираются социальные сети.
ananazzz
04.07.2018 15:33+2Автор, вы меня опередили. Позавчера проводил аудит системы, и не было времени написать. Спасибо, что начали открывать глаза на то, что любая коммерческая контора в первую очередь думает именно о своей прибыли, а никак ни о клиентах или качестве товаров. Особенно если эта контора — (пока ещё нет, слава всем и вся!) монополист в своей области.
Strain
04.07.2018 17:20+2Не понимаю доводов автора. Google это частная коммерческая фирма и они имеют право делать что угодно со СВОИМ браузером. Кто запрещает вам пользоваться любым другим веб-браузером?
iproger
04.07.2018 18:28+1Есть 100 человек. 99 стали пользоваться Хромом и все сайты стали делать только под Хром. Пользоваться чем-то иным уже невозможно.
Да, пока Хрому далеко до 99, но это вопрос времени.
Tatikoma
04.07.2018 17:37+1В интернете всегда все были равны, — каждый делал то что хотел. И это на месте — гугл продолжает делать то, что хочет.
Не нравится гугл хром? — Сделайте свой браузер. Серьёзно, форкнуть хромиум — не самая хитрая задача.
Как разработчику — мне важно, чтобы мой сайт и сайты контент которых я могу встраивать были безопасны (какая-нибудь АПИшка определения страны по IP например, через JSONP).
Как посетителю — мне важно получать именно тот контент, который мне хотел передать разработчик сайта. При этом я не желаю, чтобы мои действия отслеживал мой оператор связи или оператор VPN.
Поэтому лично для меня в переводе всего интернета на HTTPS — есть только плюсы. Перечисленные в статье минусы я назвал бы смехотворными, нет смысла их даже комментировать.
Нужно понимать, что у любого решения всегда будут защитники и противники. В том числе в интернете, однако чтобы интернет развивался, а не стоял на месте — какие-то решения должны приниматься.
Решение о переводе интернета на HTTPS большинству пользователей принесёт пользу, поэтому меньшинство, которое против, — может только принять этот факт.
Учитывать мнение меньшинства это конечно прекрасно, однако я могу быть против тегов video, против JavaScript, против ajax, против iframe. Но я не говорю гуглу, что он должен убрать всё это из хрома (но Go ему следует переименовать, ну правда, занято же было).
mxms
04.07.2018 18:59Зашёл прочитать о том, почему QUIC хуже HTTP, а увидел переливание из пустого в порожнее о вариациях последнего.
Boooring!
kenny_gomel
04.07.2018 19:55Палка на двух концах. С одной стороны полностью согласен с автором, с другой — сейчас практически на всех сайтах стоят метрики и прочая дичь, данные от которой я бы предпочёл передавать по https, хоть я и не параноик :)
DeveloperLite
04.07.2018 19:56Выступать за или против усилий Google по дискредитации протокола HTTP… мне кажется, искать плюсы и минусы бесполезно, поскольку https будет (уже есть), и от этого уже никуда не денешься. Что делать? А ничего нового: подстраиваться к изменениям, повлиять на которые мы не можем.
tcapb1
04.07.2018 20:48+1Меня всегда смущала «не-вечность» информации в вебе. Чтобы сайт сохранялся в сети, нужно его постоянно поддерживать. Я ещё в самом начале 2000-х сделал несколько сайтов, которые давно уже не веду (впрочем, посетители до сих пор ведут их сами), но которые по-прежнему живут и собирают несколько тысяч посетителей в день. Если со мной что-то случится, и я выпаду из жизни на длительный период — эти сайты пропадут. Если мне просто надоест их поддерживать — эти сайты пропадут так же. И это касается не только чьих-то мелких хомяков, крупные компании тоже могут закрывать те или иные сервисы. Archive.org решает проблему лишь частично.
Переход на HTTPS — ещё один кирпичик к этой «не-вечности». Ладно, я до сих пор занимаюсь вебом, и могу поставить сертификаты. А есть куча компаний, которым просто сделали сайт по заказу, сайт крутится где-то на хостинге, действий никаких не требует, нужно только продлевать хостинг и домен. Будут ли они искать специалистов и заморачиваться с переходом на HTTPS? Или просто забьют? Или увидят падение трафика из-за того, что браузер стал показывать предупреждения и просто перестанут поддерживать сайт полностью?
Может быть проблемы таких «хоумпаг» — не самая большая проблема интернета, но мне лично приятно знать, что вот я зашёл на страницу, получил информацию, и смогу эту информацию потом найти на том же месте и спустя 10 лет.dartraiden
05.07.2018 09:30В таком случае, вам нужны децентрализованные сайты (ZeroNet, IPFS), где информация сохраняется до тех пор, пока она кем-то востребована. Это решает главную проблему — проблему хостинга.
Darth_Malok
05.07.2018 08:53+3Спасибо за пост и комментарии. Не то чтобы узнал много нового, но взглянул на проблемы «по-другому».
Проблема номер раз: «сайты, открытые по https, не являются безопасными. Защищённость соединения означаете только защищённость соединения. Надеюсь, браузеры рано или поздно будут явно об этом информировать. Да хотя бы плашку „достоверность информации и защита от перехвата паролей не гарантируется“ на всех http-сайтах.
Два: заставлять переходить на https и скрывать „незащищённые сайты“ в результатах выдачи поисковиков — неправильно. Доступность накопленной в сети информации уменьшится — это плохо.
Три: Необходим какой-нибудь https-lite без шифрования, но с контролем целостности, и с пониженной сложностью настройки для реализации на маломощных устройствах. Понятия не имею, как сделать что-то подобное, но было бы неплохо) В своё время реализовывал „веб-сервер“ с минимальной функциональностью. Тогда поразило, насколько http-протокол прост и понятен. Если бы браузеры тогда ультимативно требовали наличие шифрования, у меня бы ничего не получилось.Scondo
05.07.2018 09:54В рамках https-lite:
Есть такая штука, как Subresource Integrity. Если расширить её на медиа-данные это был бы уже неплохой шаг вперёд по крайней мере в части mixed-content.Darth_Malok
05.07.2018 11:17«Человек посередине» перепишет какие нужно хэши в теле странице, так что это не то) Но штука интересная, учту, спасибо.
Я не уверен, что проблема вообще решаема без сложной криптографии.Scondo
05.07.2018 11:28Ну, это решение проблемы mixed content: сама страница при этом требует HTTPS с его защитой от MitM, а вот загружаемые ресурсы уже могут оставаться на HTTP.
В принципе можно пытаться решить задачу защиты основной страницы подписью в теле HTML. Но тут требуется стандартизация подписи, поскольку HTML не XML и XMLDSig не покатит… ну и опять же это по выч.ресурсам не сильно проще чем HTTPS для динамических страниц. А вот для статики (вздох ностальгии по Web 1.0) было бы неплохо.TrllServ
05.07.2018 11:41+1ну и опять же это по выч.ресурсам не сильно проще чем HTTPS для динамических страниц.
Вы утверждаете, что смотреть на ютубе котиков или обзор windows 33 с шифрованием и без него не сильно отличается по вычислительной нагрузке?Scondo
05.07.2018 11:51Нет, я утверждаю, что проверять подпись на данных и шифровать/расшифровывать данные не сильно отличаются по вычислительной нагрузке (при условии правильной организации метода).
sumanai
05.07.2018 18:58Но тут требуется стандартизация подписи
Для скриптов и стилей вроде как уже есть, правда только для скриптов и стилей.Scondo
05.07.2018 22:09Это не подпись. Это подтверждение что страница не была подменена.
Полноценный MitM с атакой на весь протокол оно предотвратить не в состоянии…
strofimov79
05.07.2018 18:39Хочется поддержать тезисы автора статьи. Другое дело, что поднимать стандарты требований для тех ресурсов, которые обладают большой посещаемостью (например, публичные форумы, онлайн-магазины и тд), наверно всё таки стоит. Потому что безопасность и приватность пользователей куда важнее меркантильных интересов каких-то корпораций.
strofimov79
05.07.2018 19:01Опять же, если коммерческий сайт, работающий с клиентами через интернет, предлагает клиентам заполнить на сайте формочку, куда требуется ввести Имя клиента и Номер телефона, чтобы «Наш сотрудник перезвонил Вам в удобное время», то должен ли такой сайт соответствовать каким-то минимальным требованиям к безопасности передачи и хранения собранных данных своих клиентов?
herrjemand
Just use LetsEncrypt ffs
https://letsencrypt.org/getting-started/
Massacre
А зачем это ему? Тут же целый пост написан про то, почему незачем) Я тоже так считаю, а у кого проблема с провайдерами, портящими трафик — пусть VPN настраивают.
И у HTTPS через LetsEncrypt есть фатальный недостаток — превратится в тыкву вместе с LetsEncrypt. Нужно децентрализованное решение. Все эти списки доверенных сертификатов, загружающихся в ОС или браузер — порочны. Особенно, в случае хромоподобных, берущих списки из хранилища ОС, в которое новые сертификаты можно добавить только через пляски с бубном.
maslyaev
Как-то я открыл список доверенных корневых центров сертификации, почитал немножко, пошевелил волосами на голове, закрыл.
AlexTest
Также интересно почему никто не рассматривает альтернативные возможности по защите HTTP трафика от подмены?
К примеру поставить перед старым сервером, раздающим HTTP, некий прокси, который сам будет чего-то добавлять (хеши, цифровую подпись и т.п.) в контент (заголовки, куки) анализируя которые некое браузерное расширение (которому все доверяют) выдавало бы предупреждение если контент был изменен.
Ну или какое-то подобное решение, которое позволит не особо напрягаясь и не влезая в дебри настроек этого старого сервера хоть как-то защитить от подмены HTTP контент, который он раздает, без использования услуг третьих лиц (центров сертификации и т.п.).
DaemonGloom
Если мы можем поставить перед старым сервером некий прокси — он вполне может реализовывать терминирование ssl и передачу запросов. Никаких дополнительных браузерных расширений не требуется. Таким могут заниматься, например, haproxy. Или nginx.
StallinHrusch
не пойму за что вас заминусили. Тоже хотел напомнить про варик с LetsEncrypt. Это как раз тот вариант «для бедных», да, имеет некоторые недостатки, но бесплатно. Кому нужен энтерпрайз-энтерпрайзович — купят себе серт. А описаные в статье «архивы» (лол что за архвивы в 21 веке я хз, ну лан) — за 10 сек могут настроить себе https от LetsEncrypt с автоматическим продлением и куртизанками. И второе — хром это поделка гугла, они вольны делать с ней все что захотят. Так что не пойму этого выпада аля «гугол принуждает». Юзайте яндекс-браузер тогда.
Areso
Под архивами стоит понимать необновляющуюся информацию, скорее всего сделанную на статике без какого-либо интерактива.
KorDen32
Давайте представим, что Let's Encrypt перестанет выдавать сертификаты. У вас есть бесплатные альтернативы?
StallinHrusch
это из разряда «если бы да кабы». Сейчас LentsEncrypt есть и работает? Ок, пользуйтесь. Я бы понял поток негодования если бы бесплатного варианта не существовало вообще, но он есть. И он как раз для таких:
P.S. Если честно я сильно-сильно сомневаются что «ценные идеи» на таких сайтах существуют в единственном экземпляре. Все ценное давно уже растащено по сотням других сайтов (с https в том числе)
Vamp
Альтернатива — сертификаты, идущие в комплекте с CDN от Cloudflare.
Но даже если откажет LE и в CF никто не переедет, значит произойдёт массовый откат к HTTP и как следствие — массовый отказ от Google Chrome как от браузера, поддерживающего только и исключительно HTTPS. Гугл в этом случае спешно выпустит обновление, возвращающее HTTP к жизни, либо сделает новый Let's Encrypt.
В любом случае, оба варианта развития ситуации мне не кажутся хоть сколько-нибудь реальными. Ваш вопрос можно перефразировать как «Давайте представим, что DNS сервера перестанут резолвить домены. У вас есть бесплатные альтернативы?»
LE позиционируется как важная часть интернет инфраструктуры, поэтому и усилия по его поддержке будут соответствующие. Он не умрёт вот так вот запросто.
alexkbs
Какой массовый отказ, о чём вы? Тут же на месте LE вырастет ещё несколько альтернатив. Раньше они были, те же StartSSL, пока они не почили в бозе вместе с WoSign. Это ещё если не говорить о том что сейчас обычный, платный, SSL сертификат для сайта стоит примерно $4 в год.
Vilgelm
Есть более простой бесплатный способ: Cloudflare. Он по умолчанию добавляет https, сертификат не нужно получать, не нужно обновлять и так далее, это все забота Cloudflare.
Но тотальный и обязательный переход на https по указке Google мне не нравится.
PS Нужно дочитывать ветку перед тем, как отвечать
ntfs1984
Я отвечу.
Его хостинг не поддерживает LetsEncrypt. Какой смазкой вы посоветуете смазывать задницу дальше? Покупать ультрасовременный хостинг, только чтобы удовлетворить КОПРОРАЦИЮ ЗЛА?
bjornd
Оставить все как есть? Единственное последствие — надпись «Not secure» в address bar'е.
geher
Пока единственное.
nickName0
— Кстати, яндекс-браузер — этот тот-же chromium (речь — о ядре).