Некоммерческая правозащитная организация Electronic Frontier Foundation (EFF) представила (https://www.eff.org/deeplinks/2012/10/https-everywhere-3-and...) релиз HTTPS Everywhere 3.0 (https://www.eff.org/https-everywhere) - дополнения к Firefox, позволяющего на всех сайтах где это возможно использовать шифрование трафика. Дополнение призвано решить проблему с сайтами, по умолчанию предоставляющими доступ без шифрования, но тем не менее поддерживающими HTTPS, а также ресурсами, использующими ссылки из безопасной области на незашифрованные страницы. Для таких сайтов HTTPS Everywhere обеспечивает автоматическое перенаправление запросов на HTTPS-области сайтов.
В новой версии удвоен размер поддерживаемой проектом базы данных с набором правил, отражающих особенностей использования HTTPS на сайтах и сервисах - в базу добавлено 1500 новых правил перенаправления. Среди мотивов создания дополнения HTTPS Everywhere отмечаются участившиеся случаи сниффинга в локальных сетях: появление таких инструментов, как Firesheep (http://codebutler.github.com/firesheep/), сделало доступным для любого желающего процесс перехвата паролей и сессионных cookie к различным социальным сетям и web-сервисам. HTTPS Everywhere также позволяет защититься от участившихся попыток провайдеров вклиниться в трафик клиента, например, некоторые провайдеры были уличены в подстановке своего рекламного контента на открываемые страницы.
Кроме того, можно отметить утверждение (http://www.ietf.org/mail-archive/web/ietf-announce/current/m...) организацией IETF статуса предложенного стандарта для протокола HSTS (HTTP Strict Transport Security), позволяющего владельцам сайтов указать о необходимости использования шифрованного соединения и определить правила для переброса на соответствующую HTTPS-область. Для переброса пользователя, зашедшего через HTTP на соответствующую область HTTPS, используется HTTP-заголовок Strict-Transport-Security. Статус предложенного стандарта присвоен после 14 предварительных черновых версий RFC. Следующей стадией развития RFC является придание статуса чернового стандарта (Draft Standard), по сути означающего полную стабилизацию протокола и учёт всех высказанных замечаний. А настоящее время поддержка HSTS уже реализована в браузерах Chrome, Firefox и Opera.URL: https://www.eff.org/deeplinks/2012/10/https-everywhere-3-and...
Новость: http://www.opennet.me/opennews/art.shtml?num=35036
Все бы ничего если бы не одно но: любой му...^W удостоверяющий центр может выписать сертификат на все что угодно. И тот факт что некто перегенерил сертификат "гуглю", "мозилле" и прочим - никак не будет отловлен. А вот это уже хреново. По поводу чего https в текущем виде больше похож на декоративно-прикладные упражнения в имитации секурити.Соответственно я все понимаю, но стремление внедрить декоративную секурити как-то не радует.
можно пользоваться хромом и гуглом.
Это не починит фундаментальный косяк протокола. Зато подставит под удар еще и приваси + втравит в зависимость от сервисов одной единственной шараги. Нафига б такое счастье?
Это не косяк протокола, а косяк используемого способа проверки сертификата. Этот способ _не требуется_ протоколом SSL/TLS, и вы не обязаны его использовать. К примеру, вы можете отключить все корневые сертификаты и при каждой смене отпечатка проверять его вручную по нескольким каналам. Кроме того, есть надежда, что скоро начнёт активно использоваться DANE - передача сертификата через DNSSEC, при использовании которой отправить вам фальшивый сертификат может только авторитативный DNS-сервер, обслуживающий посещённый вами адрес.
> Это не косяк протокола, а косяк используемого способа проверки сертификата. Этот способ
> _не требуется_ протоколом SSL/TLS, и вы не обязаны его использовать. К
> примеру, вы можете отключить все корневые сертификаты и при каждой смене
> отпечатка проверять его вручную по нескольким каналам. Кроме того, есть надежда,
> что скоро начнёт активно использоваться DANE - передача сертификата через DNSSEC,
> при использовании которой отправить вам фальшивый сертификат может только авторитативный
> DNS-сервер, обслуживающий посещённый вами адрес.Это не косяк используемого способа проверки сертификата. Это косяк концепции слепого доверия, основанного на "мамой клянусь!"^WCertificate Policy Statement любого му..^Wудостоверяющего центра.
> вы можете отключить все корневые сертификаты и при каждой смене
> отпечатка проверять его вручную по нескольким каналам.а ещё можно смотреть http в telnet. примерно так же удобно.
> передача сертификата через DNSSEC
как будто есть какая-то разница между разными местами централизации. идея централизации defective by design, и любая система, основаная на «доверии» какому-то центру, должна считаться скомпрометированой ещё до публичного релиза.
Не надоело писать один и тот же бред в каждой новости про HTTPS? Ремень безопасности тоже декоративная мера при лобовом столкновении с камазом. А если за руль посадить слепого безногого имбецила с суицидальными наклонностями, то наличие ABS и никак не повлияет на тормозной путь.
> Не надоело писать один и тот же бред в каждой новости про HTTPS?нет, не надоело. явное отсутствие средств безопасности намного лучше, чем наличие нерабочих имитаторов. это понятно даже лысому ежу.
>Кроме того, можно отметить утверждение организацией IETF статуса предложенного стандарта для протокола HSTS (HTTP Strict Transport Security), позволяющего владельцам сайтов указать о необходимости использования шифрованного соединения и определить правила для переброса на соответствующую HTTPS-область. Для переброса пользователя, зашедшего через HTTP, на соответствующую область HTTPS, используется HTTP-заголовок Strict-Transport-Security.При этом нет гарантии что заголовок не подменили и правила не убрали.
> При этом нет гарантии что заголовок не подменили и правила не убрали.Вы подсказываете провайдерам как hijack-ать протокол? :)
Кому надо все и без нас знают.
> При этом нет гарантии что заголовок не подменили и правила не убрали.кстате говоря -- надо не забывать о том что для HTTP (не HTTPS) -- заголовок Strict-Transport-Security -- совершенно ничего не делает.
..другими словами внутри HTTP-трафика его подмена совершенно ни на что не влияет.
>Для переброса пользователя, зашедшего через HTTP, на соответствующую область HTTPS, используется HTTP-заголовок Strict-Transport-Securityчто-то непонятно Вы выразились - как это не повлияет? Провайдер уберет заголовок и пользователь не перебросится, ибо браузер не будет знать куда перебросить. Останетесь на незашифрованном соединении
В Squid бы такое. Чтоб между сайтом и прокси по HTTPS, а браузеру отдавал уже нешифрованное. Заодно и кешировал бы попрежнему. А то если браузер будет преимущественно по HTTPS работать, эффективность Squid сведётся на нет. Разумеется, всё это для маленькой домашней сетки.
> В Squid бы такое. Чтоб между сайтом и прокси по HTTPS, а
> браузеру отдавал уже нешифрованное. Заодно и кешировал бы попрежнему. А то
> если браузер будет преимущественно по HTTPS работать, эффективность Squid сведётся на
> нет. Разумеется, всё это для маленькой домашней сетки.Тю, умник! А про SSLBUMP ты никогда, сталоть, не слышал? В том самом сквиде? М? Тоже мне, нашел ж.пу с лабиринтом!
Что-то мне кажется, что получится как с Do Not Track. "Всё-таки включить шифрование, если есть техническая возможность", если кто-то сознательно не включил его раньше, значит и теперь будут отключать.
По-моему аддон HTTPS Finder лучше: он сам ищет какой сайт поддерживает HTTPS, а в HTTPS Everywhere забит список сайтов, которые поддерживают HTTPS (еще бесит, когда каждый раз предлагает их сохранить).
лучше бы публично отрывали руки идиотам, которые делают принудительный https через перенаправления. от этого всяко пользы больше.
а чем хуже принудительный https? что кто то его не поддерживает?
> а чем хуже принудительный https?тем, что это вредная иллюзия безопасности, которая даёт только лишние тормоза и никакого толка.
чем вредная? по пути никто не сможет перехватить пароль, а так то например разработчик сайта может тупо перехватывать себе все)))
> по пути никто не сможет перехватить парольбугога. g://diginotar g://trustwave
всё, этого достаточно. не бывает «немножко скомпрометированой системы» — или беременна, или нет. особенно это касается систем с централизоваными центрами «доверия».
для тупых можно по шагам?
что это: g://diginotar g://trustwave ?
google это. на два самых известных факта про «удостоверяющие центры», их честность и эпик фэйлы.
>> по пути никто не сможет перехватить пароль
> бугога. g://diginotar g://trustwaveага, вероятно это скомпрометированные центры сертификации...
их сертификаты можно подписывать корневым сертификатом зашитым в браузер, но при этом
делать запросы куда то в центр за списками отмены сертификатов центров сертификации которые (эти списки) подписаны закрытым ключем корневого центра, открытый ключ которого у нас зашит в браузер...
Ваш дверной замок - такая же иллюзия безопасности, (бугога g://взлом замков )
Однако дверку в квартиру Вы закрываете чтоб бомж не насрал.
>только лишние тормозаНу это только на твоем домашнем говносерваче из пня второго
третьего.
это конечно полезно, но не то. Ожидаемая фича: встроенный в браузер шифрованный туннель по http к доверительному серверу-посреднику от производителя браузера, как у opera режим турбо. Это нужно там, где https невозможен или недоступен...