LINUX.ORG.RU
ФорумTalks

Безобидно ли настойчивое желание всюду впарить https

 , , ,


2

2

Мысли навеяны заявлением мозиловцев, что теперь безопасность будут пихать во все щели: https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

Обещают, что все новое отныне будут делать, насколько смогут, доступным только для https. Включая новые стили css, заголовки http, фичи жабоскрипта и api браузера для расширений.

Считаю разумным принцип, что забота о чьей-то безопасности только тогда является реально заботой о ней, когда озабочиваемый имеет возможность сознательно отказаться от нее. Если же забота доходит до назойливого навязывания с фактической невозможностью отказа или больших сложностей, то тут что-то уже не правильно и надо посмотреть, а нет ли тут второго (а может и третьего) слоя?

Как минимум вырисовывается интерес сертификатной мафии (боюсь по другому это уже не назвать) широко навязать свои услуги даже тем, кому защита нафиг не вперлась, например, в интранете или для простых сайтов, статических или где заведомо ничего важного нет и не будет. Потому что, например, хром очень не любит самоподписанные сертификаты (да их и вообще мало кто любит).

Let's encrypt - это не совсем решение. Хотя бы потому что де-факто вынуждает ставить на сайт их код, который что-то там выкачивает. Но в принципе можно обойтись и без их кода, все-равно, это какой-то контроль получается и вообще неудобно.

Более дальняя перспектива, это что простейший следующий шаг - это запрос не только клиентом сертификата, но и наоборот, сервером у клиента. Причем, если дойдет до дела, преподнесено это опять будет как «защита». Например, для интернет-банкинга и т.п. В принципе, юзер и сейчас получается при https-соединении уникально идентифицированным (и это не куки) даже за NAT и прокси, правда только в рамках одного сеанса.

Но самое неприятное, что защиты-то особой https и не дает, если можно перехватить DNS-соединение или насовать левых сертификатов на комп, с чем скандальчики уже тоже были. Если конечно, сайт не из тех, что pinned.

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

★★★★★
Ответ на: комментарий от atrus

А вот когда договорились на 100, а внезапно вылезает 102, то господину «на эти 2 процента и живу» пора бить морду.)

Ну надо же было так переврать хороший анекдот. Там же вся соль была в том, что он покупал по рублю, а продавал по три, и вот на эти два процента и жил. А ты взял и подменил реальными двумя процентами.

redgremlin ★★★★★
()
Ответ на: комментарий от praseodim

Но между прочим, а почему такой короткий срок всего три месяца, чем он логически обусловлен.

Тем, что чем меньше срок действия, тем меньше у злоумышленника времени на поиск приватного ключа или времени его использования, если ключ был украден. И т.д.

Проблема-то в чём, при условии, что сертификат выпускается новый автоматически? Хоть каждую неделю. :)

atrus ★★★★★
()
Ответ на: комментарий от KivApple

Вообще-то может отозвать. Понятно, с компов он их не удалит, но по мере расползания списка отозванных им станет нельзя пользоваться.

praseodim ★★★★★
() автор топика

Просто когда-то никто не думал о безопасности и надежности в сети, теперь наверстывают упущенное.

peregrine ★★★★★
()
Ответ на: комментарий от redgremlin

Ну надо же было так переврать хороший анекдот.

Не переврал, а сделал отсылку. А вот смешного здесь мало. Если с миллиона человек собрать по 2 рубля (пустяки же), то выйдет совершенно не кисло.

atrus ★★★★★
()
Ответ на: комментарий от KivApple

Изучи матчасть. Связь с CA для установки https соединения не требуется в принципе. Корневые сертификаты хранятся в ОС или браузере. Сервер отдаёт цепочку всех остальных сертификатов необходимых для проверки и браузер их проверяет.

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

Napilnik ★★★★★
()
Последнее исправление: Napilnik (всего исправлений: 1)
Ответ на: комментарий от KivApple

Да будто он этого не понимает. Просто у кого-то вечер троллинга. :)

atrus ★★★★★
()
Ответ на: комментарий от praseodim

Это значит лишь, что если отрубить связь с центром сертификации, перестанет работать отзыв сертификатов. Но сам то https не сломается.

KivApple ★★★★★
()
Ответ на: комментарий от Napilnik

Парсинг и рендеринг HTML и CSS, а также исполнение JS жрёт на порядки больше ресурсов, чем любое шифрование. Приватный ключ при правильных действиях может никогда не покидать сервер, только публичный. Даже во время выдачи сертификата. Man асимметричная криптография. Так что выудить его анализом трафика нельзя.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от Napilnik

то можно вытащить все сертификаты и прочее для расшифровки трафика.

Вообще-то есть такая штука под названием forward security. Почитай о ней, смысл в том, что даже имея все сертификаты у одной из сторон, задним числом записанный трафик расшифровать не получится, только если mitm делать или заиметь сертификаты обоих. https://ru.wikipedia.org/wiki/Perfect_forward_secrecy

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

praseodim ★★★★★
() автор топика
Ответ на: комментарий от KivApple

возможно не отдавать приватный ключ центру сертификации

Вообще-то его никто и не отдает. CA оформляет сертификат на основе подписанного приватным ключом CSR, внутри которого только публичный ключ и также идентификационные данные.

baka-kun ★★★★★
()
Ответ на: комментарий от KivApple

если отрубить связь с центром сертификации, перестанет работать отзыв сертификатов.

Серверу это не поможет, клиент запросит у CA самостоятельно. Ему же ты не отрубишь?

А на случай проблем связи клиента с AC (и снижения нагрузки с AC) настраивают OCSP stapling.

baka-kun ★★★★★
()
Ответ на: комментарий от KivApple

Парсинг и рендеринг HTML и CSS, а также исполнение JS жрёт на порядки больше ресурсов, чем любое шифрование.

JS можно отключить и до спецнеобходимостей не включать, на стили - подзабить.

Приватный ключ при правильных действиях может никогда не покидать сервер, только публичный. Даже во время выдачи сертификата. Man асимметричная криптография. Так что выудить его анализом трафика нельзя.

А у нас открытые исходники во все поля:) Следовательно, есть возможность переписать шифровальную либу для генерации сертификата которому поверит браузер на клиенте. А сервер обмануть ещё проще. Все сертификаты что получил клиент, могут быть скопированы тем, кто сидит на проводе с траффиком, следовательно, можно им прикинуться.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

если всё ценное из трафика сохранять и анализировать, то можно вытащить все сертификаты и прочее для расшифровки трафика

Нельзя. Там этой информации просто нет, а forward secrecy гаррантирует, что ты не сможешь расшифровать прошлые целиком записанные сессии, даже если в будущем получишь доступ к ключам и сертификатам сервера.

baka-kun ★★★★★
()
Ответ на: комментарий от Napilnik

*Зевая* почитай уже википедию на тему ассиметричного шифрования. Вообще, стоило бы, конечно, в Гринпис обратиться, чтобы они тебя привлекли за жестокое обращение с животными — ты постоянно и жестоко порешь чушь, а ей, между прочим, больно.

redgremlin ★★★★★
()
Ответ на: комментарий от Napilnik

есть возможность переписать шифровальную либу для генерации сертификата которому поверит браузер на клиенте.

Все сертификаты что получил клиент, могут быть скопированы тем, кто сидит на проводе с траффиком, следовательно, можно им прикинуться.

Какие же глупости ты пишешь. Сертификат сервера вообще доступен всем желающим, для этого даже «на проводе» сидеть не нужно. Но он тебе ничем не поможет, поскольку там только публичный ключ.

baka-kun ★★★★★
()
Ответ на: комментарий от KivApple

Нельзя. И точка. Объяснять тебе вещи, которые легко гуглятся мне лень.

Много что «нельзя и гуглится» опроверг Сноуден.

Napilnik ★★★★★
()
Ответ на: комментарий от baka-kun

Некоторые центры сертификации позволяют отдать всю генерацию сертификата серверу центра и скачать готовый сертификат в один клик, а не заморачиваться со всеми этими запросами.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от Napilnik

Ну не буду же я человеку, не осилившему школьный курс, советовать релевантные источники университетского уровня. Так что читай википедию, там специальные люди смотрят, чтобы материал доступен был даже школьникам.

redgremlin ★★★★★
()
Ответ на: комментарий от atrus

Вы хотя бы понимаете, что жизнь на Земле не ограничивается Российской Федерацией. Равно как и IT с его развитием и поддержкой расположены далеко не здесь? И уж точно не правительство РФ и его «спецслужбы» решают какие технологии и куда пропихивать.

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

vaddd ★☆
()
Ответ на: комментарий от baka-kun

Нельзя. Там этой информации просто нет, а forward secrecy гаррантирует, что ты не сможешь расшифровать прошлые целиком записанные сессии, даже если в будущем получишь доступ к ключам и сертификатам сервера.

Разве при шифровании используется уникальная информация прошитая в железяки клиента? Потому что если нет, то при установке аналогичного ПО можно слепить симулятор который будет кормить браузер пакетами из записанной информации чтобы тот на лету её дешифровал думая что общается с сервером. Не совсем понятно каким жабоскриптом эмулировать действия пользователя в таком эмуляторе, потому возможна не 100% расшифровка трафика а кусками. Уверенность в надёжности шифрования меня умиляет.

Napilnik ★★★★★
()
Ответ на: комментарий от atrus

как человекаайпадоножка

Не членайпад, а сегмент членайпада, не путай.

вы вытекаете из него...

Вы начинаете читать сообщение, которое заканчиваете читать.

такие вопросы должны оговариваться заранее

Так в договоре с платёжным провайдером оговаривается же :->

Закон о связи регламентирует опсосам только деятельность по передаче трафика

Так они и передают. Свой.

bodqhrohro_promo
()
Ответ на: комментарий от redgremlin

Ну почему, если человек идиот, так он обязательно одновременно и фашист и конспиролух?

В тебе всё сплелось воедино: идиот-жидофашист-лохотронщик. И никто не удивляется такому симбиозу - привыкли.

Napilnik ★★★★★
()
Ответ на: комментарий от KivApple

Проблемы криво настроенного пауэрменеджмента. У меня при питании от батареи троттлится на минимальную частоту; хоть грузи ядра, хоть не грузи — без разницы.

bodqhrohro_promo
()
Ответ на: комментарий от redgremlin

Так что читай википедию, там специальные люди смотрят, чтобы материал доступен был даже школьникам.

А нормальных источников у тебя нет, не для лохов?

Napilnik ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

Нужна, а если не понимаешь, то ты - депутат. Они тоже порой не понимают ситуацию, а с очередным законом лезут.

peregrine ★★★★★
()
Ответ на: комментарий от Napilnik

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

peregrine ★★★★★
()
Ответ на: комментарий от Napilnik

Сессионные ключи генерируются рандомно в момент коннекта и их закрытая часть не покидает клиента и сервера соответственно. После окончания коннекта ключи уничтожаются.

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Некоторые центры сертификации позволяют отдать всю генерацию

Тогда я бы немного перефразировал: не, «возможно не отдавать приватный ключ», а «возможно довериться CA». Согласись, смысл немного разный?

Но по умолчанию всё равно CSR и так далее.

baka-kun ★★★★★
()
Ответ на: комментарий от Napilnik

Разве при шифровании используется уникальная информация прошитая в железяки клиента?

Используются уникальные случайные сессионные ключи, которые ты не повторишь постфактум и не вытянешь из записи сеанса, поскольку они там не передаются.

можно слепить симулятор который будет кормить браузер пакетами из записанной информации чтобы тот на лету её дешифровал думая что общается с сервером

Вот только каждый раз запрос браузера отличается, а соответственно ответ, и следующий запрос… Фарш невозможно провернуть назад.

Уверенность в надёжности шифрования меня умиляет.

Напротив, известен предел надежности. Есть уверенность в математике. Но ты же её всё равно не знаешь и не понимаешь.

baka-kun ★★★★★
()
Ответ на: комментарий от praseodim

Ну вот ты уже заранее назвал горсткой неадекватов, тех кто хотел бы от чего-то отказаться

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

но против, чтобы их запихнули во все щели

Я что-то непонятно объяснил? Либо так, либо никак. Не делают забор только с 3 сторон участка.

А про DNS тут смысл в том, что все должно равномерно развиваться

Не должно. Нет никакого смысла защищаться от подмены DNS, пока по сети летает открытый трафик. Сначала должен быть обязательный HTTPS, потом будет смысл затыкать другие дыры.

slovazap ★★★★★
()
Ответ на: комментарий от peregrine

в вебе оно сделано через жопу видимо в угоду тем, кто хочет сидеть посередине и слушать

Ещё один… Нормально оно сделано. «Сидеть посередине» можно только изменяя данные, то есть выступая прокси между сервером и клиентом. Пассивно слушать не получится.

baka-kun ★★★★★
()
Ответ на: комментарий от slovazap

Вы хотите чтобы ради ваших странных желаний, продиктованных, к слову, исключительно безграмотностью, «от чего-то отказались» другие.

Привязывать браузерные фичи к https - это как называется?

Либо так, либо никак. Не делают забор только с 3 сторон участка.

Аналогия хромая. Но если к ней прибегаешь, то тебе и же верну ее по поводу DNS.

Нет никакого смысла защищаться от подмены DNS, пока по сети летает открытый трафик. Сначала должен быть обязательный HTTPS, потом будет смысл затыкать другие дыры.

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

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

Привязывать браузерные фичи к https - это как называется?

Правильная стратегия.

Открытые данные в сети не являются дырой

Являются, любые и всегда.

А обязательный HTTPS дурно пахнет, потому что следствием его является де-факто обязательное приобретение сертификата у третьей стороны

Ага, как и домен, и подключение к сети, и компьютер. Ужас-ужас.

slovazap ★★★★★
()
Ответ на: комментарий от baka-kun

Слышал что в Казахстане HTTPS слушают активно, подменой сертификата. Такое должно быть запрещено на уровне протокола. Хотят власти такой страны форкаться, пусть форкают весь браузер и занимаются его поддержкой.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Слышал что в Казахстане HTTPS слушают активно, подменой сертификата.

Пытались. И это не «слушать», а именно проксировать.

baka-kun ★★★★★
()
Ответ на: комментарий от peregrine

Ты не понимаешь как работает асимметричное шифрование

Я не понимаю как оно при существующих реалиях может абсолютно гарантировать от расшифровки товарищем майором, если он приложит силы и средства. Начальный обмен информацией хорошо зашифровать нельзя, а значит гипотетическая уязвимость есть. С другой стороны, если товарищ майор навинтит свои закрытые системы шифрования, то всем кроме него расшифровать трафик может будет и сложнее.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Никак, щяс квантовые компьютеры взлетят и плакала вся эта криптография. А простым смертным до доступных квантовых компьютеров пока далеко. Такие пирожки.

bodqhrohro_promo
()
Ответ на: комментарий от bodqhrohro_promo

Никак, щяс квантовые компьютеры взлетят и плакала вся эта криптография.

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

Napilnik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.