| 1.1, User294 (ok), 22:10, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
 А в чем прикол - использовать для работы с открытыми исходниками SSL с ножом к горлу? Вообще, этот гитхаб многовато пиарится на опенсорсе, а сами сорсы движка сайта зажимают.
| | |
| |
| 2.3, rm_ (ok), 23:22, 08/11/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > А в чем прикол - использовать для работы с открытыми исходниками SSL
А в чём прикол передавать свой пароль на изменение каких-нибудь из этих исходников, используемых тысячами или сотнями тысяч людей, открытым текстом по интернету?
| | |
| |
| 3.9, User294 (ok), 12:32, 09/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Я не имею ничего такого против шифрования логина и пароля, а вот шифрование больших объемов данных при том что эти данные заведомо не секретны - выглядит странноватой затеей. При этом заведомо не случится попадания в кеш на проксях, а сервера и клиенты почем зря озадачатся шифрованием тонны данных которые... которые с самого начала не секретны!
Кроме того, иногда, такое может сыграть с вами злую шутку. Например у некоторых особо параноидальных контор на границе с интернетом стоят проксики, которые порой не разрешают HTTPS из-за невозможности анализа запросов. Не то чтобы банальный досмотр - это здорово, однако ж двойной пролет - еще менее здорово. Все-таки одно дело например банкинг и другое - это когда В. Пупкин хочет всего-то сорц какой-то посмотреть.
| | |
| |
| 4.21, Аноним (-), 18:34, 09/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
То есть, возможность MITM вас не пугает? Скачает Пупкин сорц, а сорц-то по дороге кто-то добрый уже подменить успел нужным образом, а?
Вообще все ресурсы надо на SSL переводить. Без исключения.
| | |
| |
| 5.22, Аноним (-), 18:35, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> То есть, возможность MITM вас не пугает? Скачает Пупкин сорц, а сорц-то
> по дороге кто-то добрый уже подменить успел нужным образом, а?
> Вообще все ресурсы надо на SSL переводить. Без исключения.
md5 суммы тоже. Они же тоже не по SSL в предложенном вами варианте будут передаваться.
| | |
| 5.23, User294 (ok), 00:09, 10/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> То есть, возможность MITM вас не пугает?
Если у меня на проводе MITM засел - он меня вообще может завернуть на произвольный левый сайт. Тупо вернув мне на мои DNS запросы левый ответ, например. Есть, конечно, dnssec, но он как-то не часто юзается, в общем то.
> Скачает Пупкин сорц, а сорц-то по дороге кто-то добрый уже подменить успел нужным образом, а?
А можно и не по дороге. А на сервере. А откуда вы знаете насколько честный стафф в гитхабе и насколько этот стафф хорошо заботится о безопасности серверов? Сломать гитхаб - как-то сильно перспективнее по соотношению гемор/результат чем какой-то роутер по пути к вам или что там еще + еще и на лету гзипари в реалтайме патчить :). Для такого вообще-то подписи релизных версий ключами разработчиков бывают + проверка коммитов. А промежуточные версии ... ну вы в любом случае можете надеяться только на свои глаза и что никто из разработчков или прочих не закоммитит ничего разрушительного, специально или нечаянно. В конце концов, разработчику могут незаметно троян вбросить который ему допатчит чутка сорс. Потом он честно закоммитит сорс ничего не подозревая. А вы по SSL получите его, ага :)
> Вообще все ресурсы надо на SSL переводить. Без исключения.
Ага. Давайте все видеохостинги с гигабитными потоками пригрузим шифрованием ... публично доступного контента :). Правда, мне кажется что обладатели серверов будет резко против.
| | |
| |
| 6.26, Аноним (-), 01:48, 10/11/2010 [^] [^^] [^^^] [ответить] | +/– | Ну так вот ровно для защиты от таких вещей SSL и нужен Шифрование - только втор... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.2, savant (ok), 22:39, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Зажимают - их право, насильно опенсорсу мил не будешь. А то, что пиарятся - так они сделали если не самый удобный хостинг проектов, то как минимум один из самых. Тем более, что опенсорсные проекты там хостятся бесплатно, а это нехилые такие объёмы.
| | |
| 1.4, iav (ok), 03:05, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Почему нельзя было только логин сделать защищённым?
Зачем использовать хттпс, отказываться от кэширования, если 90% обращений - чтение открытого контента?
| | |
| |
| |
| 3.6, iav (ok), 04:36, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Ради оставшихся 10%?
Вот я и не понимаю — почему нельзя требовать ссл только для этих 10%?
Я ж не требую «всё клиртекстом», хотя челенж-респонс, вообще-то, и с ним нормально работает.
Это же так естественно — практически «сама природа»: изменения репозитория, редактирование профиля и аутентификация — только по ссл. Остальное — как угодно.
| | |
|
| 2.7, tulskiy (ok), 06:18, 09/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Они в блоге писали что недавно были атаки на гитхаб, и они из-за этого решили ужесточить систему безопасности. Видимо это из той же песни.
| | |
| 2.8, rm_ (ok), 08:03, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Почему нельзя было только логин сделать защищённым?
Защищённый только-логин - это ни от чего не спасающая примочка, и атаки по перехвату сессии, например, она никак не останавливает. См. http://codebutler.com/firesheep
> Зачем использовать хттпс, отказываться от кэширования, если 90% обращений - чтение открытого контента?
Зачем браузеры отказываются от кэширования при использовании https - хороший вопрос, возможно именно это стоит изменить, и где-то в обсуждениях мне уже неоднократно встречались голоса в поддержку этого. Можно кэшировать либо подразумевая, что домашний каталог пользователя - и так уже только ему доступное место, либо если этого недостаточно - кэшировать зашифрованные объекты.
| | |
| |
| 3.10, User294 (ok), 12:43, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Зачем браузеры отказываются от кэширования при использовании https - хороший вопрос,
Как зачем?! Чтобы у вас не сперли например всякие там банковские реквизиты и прочая с диска!
> возможно именно это стоит изменить,
А может быть, шифрование следует юзать для шифрования реально СЕКРЕТНЫХ данных, для которых гемор оправдан? Да, в случае онлайн-банка - пусть лучше он сильнее тормозит но зато гарантирует безопасность :). Но зачем требуется супер-пупер-безопасность при сливе публично доступного исходника? Алсо, а не факапнет ли это поиск поисковиками?
> и где-то в обсуждениях мне уже неоднократно встречались голоса в поддержку этого.
> Можно кэшировать либо подразумевая, что домашний каталог пользователя -
> и так уже только ему доступное место,
Ну да, сели вы в интернет-кафешке за комп... конечно же, только вам доступный, специально для вас установленный. SSL по идее должен и в таком случае не спасовать, по крайней мере если машина не пробэкдорена на момент вашей работы с банком.
> либо если этого недостаточно - кэшировать зашифрованные объекты.
А что помешает их расшифровать не только вашему браузеру, но и злоумышленнику??? Одно дело если клиент и сервер делают динамический обмен ключами, но с файлом то динамически ключом не покидаешься, а статичный ключ шифрования - ну он где-то должен быть сохранен, чтобы сам браузер мог читать кеш. А ключ оттуда как-бы и злоумышленник может прочитать, а? После чего расшифрует кеш не хуже браузера.
| | |
| |
| 4.11, rm_ (ok), 12:52, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> А может быть, шифрование следует юзать для шифрования реально СЕКРЕТНЫХ данных,
А собственно почему? Я например не хочу, чтобы мой провайдер и все по дороге знали, что именно я ищу на поисковиках и о чём читаю в википедии. Или вы здесь типичные аргументы противников прайваси вытащите, "ну а мне нечего скрывать, пускай смотрят", или "да кому я нужен, кто будет следить".
> для которых гемор оправдан?
Не знаю, я уже давненько поставил в браузере расширение HTTPS Everywhere (все сайты, где это возможно, автоматом редиректит на HTTPS + позволяет задавать свои редиректы дополнительно) - полёт нормальный, никаких неудобств не чувствую.
| | |
| |
| 5.19, Аноним (-), 18:09, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Я например не хочу, чтобы мой провайдер и все по дороге знали, что именно я ищу на поисковиках и о чём читаю в википедии.
Единственный вариант в таком случае - VPN. Иначе это просто смешно. По адресам и так всё видно, куда ты заходишь и что читаешь.
| | |
| |
| 6.20, rm_ (ok), 18:15, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Единственный вариант в таком случае - VPN. Иначе это просто смешно. По
> адресам и так всё видно, куда ты заходишь и что читаешь.
Вы в курсе, как работает SSL в HTTP (https:// )? URLы-то тоже шифруются, если что.
Да, видно что я приконнектился к такому-то сайту или поисковику. Но какую страницу или поисковый запрос я там задал - уже нет.
| | |
| |
| 7.24, User294 (ok), 00:27, 10/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> страницу или поисковый запрос я там задал - уже нет.
При этом допускается что гугеля или википедию нельзя разуть на информацию "такой-то айпи что-то искал" (а вот это - совсем не факт). Поэтому хорошо бы отвязаться от провайдерского айпи, не так ли? :) Кроме того - есть вероятность что страниц с таким же размером на том же ресурсе не так уж и много. И можно по соотношению время-траффик прикинуть что вы там такое отправили/укачали. Спасает от такого банального зондирования только шифрованный впн до своего хоста в доверяемой местности, желательно гонящий все по одному шифрованному тунелю. Вперемешку с рандомными всплесками бесполезного траффа - чтобы поломать атаки на соотношение время-траффик. А то вроде кто-то так даже VoIP ломал, восстанавливая фразы по характерным для них пульсациям соотношений траффик-время :). При этом, кстати, вообще не обязательно знать алгоритм шифрования.
| | |
|
|
|
| 4.12, zazik (ok), 12:57, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > при сливе публично доступного исходника? Алсо, а не факапнет ли это
> поиск поисковиками?
Нет, всё должно работать. Ходить по HTTPS-ссылками ничего сложного нет. Но авторизованные пользователи должны в любом случае по HTTPS ходить. Анонимусов можно и по HTTP gecrfnm/
| | |
|
|
| 2.13, СуперАноним (?), 14:57, 09/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Представьте, качаете исходники. А тут в уже установленную нешифрованную сессию вклинивается man_in_middle и подсовывает Вам изменённый файлик с добавленным зловредным кодом.
| | |
| |
| 3.14, zazik (ok), 16:15, 09/11/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Представьте, качаете исходники. А тут в уже установленную нешифрованную сессию вклинивается
> man_in_middle и подсовывает Вам изменённый файлик с добавленным зловредным кодом.
Представьте, хотите вы скачать исходники. А тут в момент установления шифрованной сессии вклинивается man_in_middle и затем подсовывает Вам изменённый файлик с добавленным зловредным кодом.
| | |
| |
| 4.15, К.О. (?), 17:13, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации :-)
| | |
| |
| 5.25, User294 (ok), 00:34, 10/11/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации
> :-)
MITM может элементарно выбросить вас на клон сайта без SSL вообще. И какая вероятность что вы заметите что это не тот сайт? Практика показывает что не очень уж и большая :)
| | |
| |
| 6.27, Аноним (-), 01:51, 10/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Тащемта SSL устойчив к man-in-the-middle, если не считать недавние баги в спецификации
>> :-)
> MITM может элементарно выбросить вас на клон сайта без SSL вообще. И
> какая вероятность что вы заметите что это не тот сайт? Практика
> показывает что не очень уж и большая :)
99.99%
Мой любимый фаерфокс мне цветами всё подкрашивает. Очень удобно. И только с большого бодуна можно не понять, туда ли ты попал.
| | |
|
|
| 4.16, iav (ok), 17:45, 09/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Представьте, хотите вы скачать исходники. А тут в момент установления шифрованной сессии
> вклинивается man_in_middle и затем подсовывает Вам изменённый файлик с добавленным зловредным
> кодом.
Представьте, хотите вы скачать исходники. А тут вдруг снайпер метким выстрелом разбивает вам голову!
Вероятность, во всяком случае, сопоставима. Если, конечно, учесть, что подсадить зловреда в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить и снарядить снайпера.
| | |
| |
| 5.17, 8288ано8288ним (?), 17:59, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Вероятность, во всяком случае, сопоставима
Бред.
> Если, конечно, учесть, что подсадить зловреда в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить и снарядить снайпера.
Во-первых, не обязательно в произвольный. Во-вторых, и в произвольный элементарно. Видишь вызов read? Добавь после него 1 строчку со сравнением первых 4 байт буффера с сигнатурой и если совпадает вызови system на buffer+4. Следующий.
| | |
| 5.18, zazik (ok), 18:01, 09/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Представьте, хотите вы скачать исходники. А тут вдруг снайпер метким выстрелом разбивает
> вам голову!
Аналогия со снайпером плоха, так как достигаются разные цели.
> Вероятность, во всяком случае, сопоставима. Если, конечно, учесть, что подсадить зловреда
> в произвольный код, сохранив его работоспособность - задача посложнее, чем обучить
> и снарядить снайпера.
Подсадить зловреда в произвольный код, сохранив его работоспособность в случае нешифрованной сессии - простая задача?
| | |
| 5.28, СуперАноним (?), 15:25, 10/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
А зачем в произвольный? Что, злоумышленнику трудно проанализировать конкретный файл исходников конкретного проекта с этого GitHub? И заранее сделать его модифицированную версию.
| | |
|
|
|
|
|
