Хостинг свободных проектов GitHub.com, базирующийся на системе управления исходными текстами Git и позволяющий разработчикам общаться формате единой социальной сети, перешел (https://github.com/blog/738-sidejack-prevention-phase-2-ssl-...) на использование SSL-шифрования и защищенных "cookie" при закрытом и публичном доступе к сайту. Отныне по умолчанию все запросы к сайту возможны только по HTTPS.
В настоящее время отмечается наличие одной недоработки, которую планируется устранить в течение нескольких дней: при входе на сайт по прямой ссылке с внешнего ресурса, после переброса на HTTPS-представление страницы, выводится связанное с SSL предупреждение.URL: https://github.com/blog/738-sidejack-prevention-phase-2-ssl-...
Новость: http://www.opennet.me/opennews/art.shtml?num=28574
А в чем прикол - использовать для работы с открытыми исходниками SSL с ножом к горлу? Вообще, этот гитхаб многовато пиарится на опенсорсе, а сами сорсы движка сайта зажимают.
> А в чем прикол - использовать для работы с открытыми исходниками SSLА в чём прикол передавать свой пароль на изменение каких-нибудь из этих исходников, используемых тысячами или сотнями тысяч людей, открытым текстом по интернету?
Я не имею ничего такого против шифрования логина и пароля, а вот шифрование больших объемов данных при том что эти данные заведомо не секретны - выглядит странноватой затеей. При этом заведомо не случится попадания в кеш на проксях, а сервера и клиенты почем зря озадачатся шифрованием тонны данных которые... которые с самого начала не секретны!Кроме того, иногда, такое может сыграть с вами злую шутку. Например у некоторых особо параноидальных контор на границе с интернетом стоят проксики, которые порой не разрешают HTTPS из-за невозможности анализа запросов. Не то чтобы банальный досмотр - это здорово, однако ж двойной пролет - еще менее здорово. Все-таки одно дело например банкинг и другое - это когда В. Пупкин хочет всего-то сорц какой-то посмотреть.
То есть, возможность MITM вас не пугает? Скачает Пупкин сорц, а сорц-то по дороге кто-то добрый уже подменить успел нужным образом, а?Вообще все ресурсы надо на SSL переводить. Без исключения.
> То есть, возможность MITM вас не пугает? Скачает Пупкин сорц, а сорц-то
> по дороге кто-то добрый уже подменить успел нужным образом, а?
> Вообще все ресурсы надо на SSL переводить. Без исключения.md5 суммы тоже. Они же тоже не по SSL в предложенном вами варианте будут передаваться.
> То есть, возможность MITM вас не пугает?Если у меня на проводе MITM засел - он меня вообще может завернуть на произвольный левый сайт. Тупо вернув мне на мои DNS запросы левый ответ, например. Есть, конечно, dnssec, но он как-то не часто юзается, в общем то.
> Скачает Пупкин сорц, а сорц-то по дороге кто-то добрый уже подменить успел нужным образом, а?
А можно и не по дороге. А на сервере. А откуда вы знаете насколько честный стафф в гитхабе и насколько этот стафф хорошо заботится о безопасности серверов? Сломать гитхаб - как-то сильно перспективнее по соотношению гемор/результат чем какой-то роутер по пути к вам или что там еще + еще и на лету гзипари в реалтайме патчить :). Для такого вообще-то подписи релизных версий ключами разработчиков бывают + проверка коммитов. А промежуточные версии ... ну вы в любом случае можете надеяться только на свои глаза и что никто из разработчков или прочих не закоммитит ничего разрушительного, специально или нечаянно. В конце концов, разработчику могут незаметно троян вбросить который ему допатчит чутка сорс. Потом он честно закоммитит сорс ничего не подозревая. А вы по SSL получите его, ага :)
> Вообще все ресурсы надо на SSL переводить. Без исключения.
Ага. Давайте все видеохостинги с гигабитными потоками пригрузим шифрованием ... публично доступного контента :). Правда, мне кажется что обладатели серверов будет резко против.
>> То есть, возможность MITM вас не пугает?
> Если у меня на проводе MITM засел - он меня вообще
> может завернуть на произвольный левый сайт. Тупо вернув мне на мои
> DNS запросы левый ответ, например. Есть, конечно, dnssec, но он как-то
> не часто юзается, в общем то.
>Ну так вот ровно для защиты от таких вещей SSL и нужен. Шифрование - только вторая по значимости задача, для которой используется SSL в www.
>[оверквотинг удален]
> соотношению гемор/результат чем какой-то роутер по пути к вам или что
> там еще + еще и на лету гзипари в реалтайме патчить
> :). Для такого вообще-то подписи релизных версий ключами разработчиков бывают
> + проверка коммитов. А промежуточные версии ... ну вы в любом
> случае можете надеяться только на свои глаза и что никто из
> разработчков или прочих не закоммитит ничего разрушительного, специально или нечаянно.
> В конце концов, разработчику могут незаметно троян вбросить который ему допатчит
> чутка сорс. Потом он честно закоммитит сорс ничего не подозревая. А
> вы по SSL получите его, ага :)
>Вопросы защиты самого разработчика - это вопросы защиты самого разработчика. Разработчиков не так часто ломают, как ни странно.
>> Вообще все ресурсы надо на SSL переводить. Без исключения.
> Ага. Давайте все видеохостинги с гигабитными потоками пригрузим шифрованием ... публично
> доступного контента :). Правда, мне кажется что обладатели серверов будет резко
> против.Убедительно. Так и быть, медиа-контент разрешаю отдавать без SSL, пока мощности не подрастут, текстовой составляющей медиа-сайтов это не касается.
Давайте ещё немного пофантазируем. Отдаётся без SSL некий видеоролик. Кто-то успевает вклиниться в вашу сессию, и подменить видео-ролик на тот, который вызовет сегфолт вашего VLC, mplayer или сразу Adobe Flash. А потом немного причешет ролик, подсунет его ещё раз, и заставит ваш плеер выполнить произвольный код на вашей системе. Не так уж и редко находятся уязвимости в библиотеках разбора видео и аудио форматов, pdf-файлов, даже изображений, не говоря уже про несчастный Adobe Flash.В результате вы попадёте в ситуацию, когда вы качали что-то с ресурса, которому вы полностью доверяете, и который даже не виноват будет в том, что вам поимели.
Одно дело тытруба, другое - ваш собственный ресурс, на котором вы все ролики перед выкладыванием в обязательном порядке clamavу скармливаете, и потому полностью им доверяете.SSL нужен.
Зажимают - их право, насильно опенсорсу мил не будешь. А то, что пиарятся - так они сделали если не самый удобный хостинг проектов, то как минимум один из самых. Тем более, что опенсорсные проекты там хостятся бесплатно, а это нехилые такие объёмы.
Почему нельзя было только логин сделать защищённым?
Зачем использовать хттпс, отказываться от кэширования, если 90% обращений - чтение открытого контента?
Ради оставшихся 10%?
> Ради оставшихся 10%?Вот я и не понимаю — почему нельзя требовать ссл только для этих 10%?
Я ж не требую «всё клиртекстом», хотя челенж-респонс, вообще-то, и с ним нормально работает.Это же так естественно — практически «сама природа»: изменения репозитория, редактирование профиля и аутентификация — только по ссл. Остальное — как угодно.
Они в блоге писали что недавно были атаки на гитхаб, и они из-за этого решили ужесточить систему безопасности. Видимо это из той же песни.
> Почему нельзя было только логин сделать защищённым?Защищённый только-логин - это ни от чего не спасающая примочка, и атаки по перехвату сессии, например, она никак не останавливает. См. http://codebutler.com/firesheep
> Зачем использовать хттпс, отказываться от кэширования, если 90% обращений - чтение открытого контента?
Зачем браузеры отказываются от кэширования при использовании https - хороший вопрос, возможно именно это стоит изменить, и где-то в обсуждениях мне уже неоднократно встречались голоса в поддержку этого. Можно кэшировать либо подразумевая, что домашний каталог пользователя - и так уже только ему доступное место, либо если этого недостаточно - кэшировать зашифрованные объекты.
> Зачем браузеры отказываются от кэширования при использовании https - хороший вопрос,Как зачем?! Чтобы у вас не сперли например всякие там банковские реквизиты и прочая с диска!
> возможно именно это стоит изменить,
А может быть, шифрование следует юзать для шифрования реально СЕКРЕТНЫХ данных, для которых гемор оправдан? Да, в случае онлайн-банка - пусть лучше он сильнее тормозит но зато гарантирует безопасность :). Но зачем требуется супер-пупер-безопасность при сливе публично доступного исходника? Алсо, а не факапнет ли это поиск поисковиками?
> и где-то в обсуждениях мне уже неоднократно встречались голоса в поддержку этого.
> Можно кэшировать либо подразумевая, что домашний каталог пользователя -
> и так уже только ему доступное место,Ну да, сели вы в интернет-кафешке за комп... конечно же, только вам доступный, специально для вас установленный. SSL по идее должен и в таком случае не спасовать, по крайней мере если машина не пробэкдорена на момент вашей работы с банком.
> либо если этого недостаточно - кэшировать зашифрованные объекты.
А что помешает их расшифровать не только вашему браузеру, но и злоумышленнику??? Одно дело если клиент и сервер делают динамический обмен ключами, но с файлом то динамически ключом не покидаешься, а статичный ключ шифрования - ну он где-то должен быть сохранен, чтобы сам браузер мог читать кеш. А ключ оттуда как-бы и злоумышленник может прочитать, а? После чего расшифрует кеш не хуже браузера.
> А может быть, шифрование следует юзать для шифрования реально СЕКРЕТНЫХ данных,А собственно почему? Я например не хочу, чтобы мой провайдер и все по дороге знали, что именно я ищу на поисковиках и о чём читаю в википедии. Или вы здесь типичные аргументы противников прайваси вытащите, "ну а мне нечего скрывать, пускай смотрят", или "да кому я нужен, кто будет следить".
> для которых гемор оправдан?
Не знаю, я уже давненько поставил в браузере расширение HTTPS Everywhere (все сайты, где это возможно, автоматом редиректит на HTTPS + позволяет задавать свои редиректы дополнительно) - полёт нормальный, никаких неудобств не чувствую.
> Я например не хочу, чтобы мой провайдер и все по дороге знали, что именно я ищу на поисковиках и о чём читаю в википедии.Единственный вариант в таком случае - VPN. Иначе это просто смешно. По адресам и так всё видно, куда ты заходишь и что читаешь.
> Единственный вариант в таком случае - VPN. Иначе это просто смешно. По
> адресам и так всё видно, куда ты заходишь и что читаешь.Вы в курсе, как работает SSL в HTTP (https:// )? URLы-то тоже шифруются, если что.
Да, видно что я приконнектился к такому-то сайту или поисковику. Но какую страницу или поисковый запрос я там задал - уже нет.
> страницу или поисковый запрос я там задал - уже нет.При этом допускается что гугеля или википедию нельзя разуть на информацию "такой-то айпи что-то искал" (а вот это - совсем не факт). Поэтому хорошо бы отвязаться от провайдерского айпи, не так ли? :) Кроме того - есть вероятность что страниц с таким же размером на том же ресурсе не так уж и много. И можно по соотношению время-траффик прикинуть что вы там такое отправили/укачали. Спасает от такого банального зондирования только шифрованный впн до своего хоста в доверяемой местности, желательно гонящий все по одному шифрованному тунелю. Вперемешку с рандомными всплесками бесполезного траффа - чтобы поломать атаки на соотношение время-траффик. А то вроде кто-то так даже VoIP ломал, восстанавливая фразы по характерным для них пульсациям соотношений траффик-время :). При этом, кстати, вообще не обязательно знать алгоритм шифрования.
> при сливе публично доступного исходника? Алсо, а не факапнет ли это
> поиск поисковиками?Нет, всё должно работать. Ходить по HTTPS-ссылками ничего сложного нет. Но авторизованные пользователи должны в любом случае по HTTPS ходить. Анонимусов можно и по HTTP gecrfnm/
Представьте, качаете исходники. А тут в уже установленную нешифрованную сессию вклинивается man_in_middle и подсовывает Вам изменённый файлик с добавленным зловредным кодом.
> Представьте, качаете исходники. А тут в уже установленную нешифрованную сессию вклинивается
> man_in_middle и подсовывает Вам изменённый файлик с добавленным зловредным кодом.Представьте, хотите вы скачать исходники. А тут в момент установления шифрованной сессии вклинивается man_in_middle и затем подсовывает Вам изменённый файлик с добавленным зловредным кодом.
Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации :-)
> Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации
> :-)MITM может элементарно выбросить вас на клон сайта без SSL вообще. И какая вероятность что вы заметите что это не тот сайт? Практика показывает что не очень уж и большая :)
>> Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации
>> :-)
> MITM может элементарно выбросить вас на клон сайта без SSL вообще. И
> какая вероятность что вы заметите что это не тот сайт? Практика
> показывает что не очень уж и большая :)99.99%
Мой любимый фаерфокс мне цветами всё подкрашивает. Очень удобно. И только с большого бодуна можно не понять, туда ли ты попал.
> Представьте, хотите вы скачать исходники. А тут в момент установления шифрованной сессии
> вклинивается man_in_middle и затем подсовывает Вам изменённый файлик с добавленным зловредным
> кодом.Представьте, хотите вы скачать исходники. А тут вдруг снайпер метким выстрелом разбивает вам голову!
Вероятность, во всяком случае, сопоставима. Если, конечно, учесть, что подсадить зловреда в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить и снарядить снайпера.
> Вероятность, во всяком случае, сопоставимаБред.
> Если, конечно, учесть, что подсадить зловреда в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить и снарядить снайпера.
Во-первых, не обязательно в произвольный. Во-вторых, и в произвольный элементарно. Видишь вызов read? Добавь после него 1 строчку со сравнением первых 4 байт буффера с сигнатурой и если совпадает вызови system на buffer+4. Следующий.
> Представьте, хотите вы скачать исходники. А тут вдруг снайпер метким выстрелом разбивает
> вам голову!Аналогия со снайпером плоха, так как достигаются разные цели.
> Вероятность, во всяком случае, сопоставима. Если, конечно, учесть, что подсадить зловреда
> в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить
> и снарядить снайпера.Подсадить зловреда в произвольный код, сохранив его работоспособность в случае нешифрованной сессии - простая задача?
А зачем в произвольный? Что, злоумышленнику трудно проанализировать конкретный файл исходников конкретного проекта с этого GitHub? И заранее сделать его модифицированную версию.