forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Доступен второй черновой вариант спецификации HTTP 2.0, opennews (??), 10-Июл-13, (0) [смотреть все]

Ну, и как это поможет анонимности , Евгений (??), 00:05 , 10-Июл-13, (1) –1 //

примерно так же, как и голодающим детям Зимбабве, ваноним (?), 01:17 , 10-Июл-13, (7) +16 //

голодающим детям Зимбабве очень просто помочь, если заставить их работать, rico (ok), 17:51 , 10-Июл-13, (84) –2 //

Ты не поверишь, но детский труд в Африке эксплуатируется с ранних лет и так, что, CAP (?), 22:18 , 10-Июл-13, (129) +2

на добывания алмазов, агаа жрать себе дети не могут с пальмы достать или как в, rico (ok), 18:49 , 11-Июл-13, (163) +3

Хорошо писать это сытым , Аноним (-), 09:32 , 15-Июл-13, (165) –1

неплохо, особенно после 8 часового рабочего днядите в африке таким похвастается , rico (ok), 20:42 , 01-Авг-13, (168)

А кто-то обещал, что поможет HTTP 2 0 это не анонимность, это увеличение скорост, Аноним (-), 11:17 , 10-Июл-13, (49) +1

под PRISM заточен , Аноним (-), 00:08 , 10-Июл-13, (2) +1 //

Судя по всему упрощение АНБ отлов брут трафика в сеансах , Аноним (-), 01:26 , 10-Июл-13, (12) //

Не АНБ, а ЗОГ, kurokaze (ok), 11:05 , 10-Июл-13, (43)

Изобретаем еще раз sctp, Аноним (-), 00:30 , 10-Июл-13, (3) +2 //

Ну так ты иди, убеди MS драйвер SCTP написать - все тебе спасибо скажут , Аноним (-), 01:20 , 10-Июл-13, (9) –2 //

Напиши сам для них , A_n_D (ok), 06:14 , 10-Июл-13, (30) //

А зачем я буду что-то писать для них что бы они в очередной раз специально , x (?), 08:31 , 10-Июл-13, (33) +2
А оно мне надо У меня то линух Но кроме меня на этой планете есть еще и другие, Аноним (-), 15:44 , 10-Июл-13, (73)

Если у M ещё нет реализации SCTP, то это значит, что её ещё нет или она недоста, Аноним (-), 13:12 , 10-Июл-13, (61) +2

В sctp реализовано мультиплексирование в SSL-канале Прокси, NAT и их админы повс, serg1224 (ok), 01:24 , 10-Июл-13, (10) –11 //

да, Аноним (-), 01:26 , 10-Июл-13, (13) +4 //

Ссылка есть , serg1224 (ok), 01:45 , 10-Июл-13, (17) –1

grep -i SCTP Library Developer CommandLineTools SDKs MacOSX10 9 sdk usr incl, Аноним (-), 02:04 , 10-Июл-13, (21) +1

Прям все пользователи кинутся компилировать Ну допустим даже в ядре уже есть по, serg1224 (ok), 03:04 , 10-Июл-13, (27) –5
132 и в Африке 132, а что толку , Сергей (??), 13:10 , 10-Июл-13, (59)

https nplab fh-muenster de groups wiki wiki f366c SCTP_on_Mountain_Lion html, Аноним (-), 02:05 , 10-Июл-13, (22)

Т е скоро должно появиться, но пока ИЗ КОРОБКИ нету , serg1224 (ok), 02:58 , 10-Июл-13, (26) –2

Это, пожалуй, единственная фича, которую нужно реализовывать не на транспортном , Аноним (-), 01:28 , 10-Июл-13, (14) +7 //

Можно ещё на IPSec перейти вместо HTTPS - Как бы только это сделать поюзабельне, serg1224 (ok), 01:44 , 10-Июл-13, (16) –10

А можно просто не нести херни Неужели это так сложно Если хочется секса - можно, Аноним (-), 02:01 , 10-Июл-13, (19) +1

Если для Вас шифрование трафика - это херня, то не нужно говорить за всех Это ж, serg1224 (ok), 02:54 , 10-Июл-13, (25) –7

Деточка, иди учи модель OSI и TCP IP и не неси херни, не путай сеансовый и сетев, Аноним (-), 08:10 , 10-Июл-13, (32) +3

Может пожилой гений всё-таки перестанет постоянно брызгать слюной и предложит хо, serg1224 (ok), 12:48 , 10-Июл-13, (57) –5

Подумайте над реализацией мультиплексирования ethernet в SSL-канале Возможно, э, Аноним (-), 14:28 , 10-Июл-13, (72) +4

Так про то и речь Какого хрена тогда сравниваете SPDY и SCTP , serg1224 (ok), 18:26 , 10-Июл-13, (87) –1

Нет, херня то, что вы несете А именно - засовывание задач уровня представления , Аноним (-), 13:53 , 10-Июл-13, (64) +3

Доказательство от противного видимо в школе не все изучали Изначально Аноним зая, serg1224 (ok), 18:49 , 10-Июл-13, (89) –1

8230 а на четвертый день великий вождь Зоркий Глаз заметил, что перевод браузе, Аноним (-), 19:30 , 10-Июл-13, (103)

Великий вождь потому и вождь, что понимает простую истину замена одного компоне, serg1224 (ok), 19:39 , 10-Июл-13, (106) –1

И как великий вождь собирается разрушить основание IPv4 и построить на его мес, Аноним (-), 20:49 , 10-Июл-13, (112)

Ну и как, быстро разрушается Прям все так и ломанулись на ipv6 Ага, уже не пер, serg1224 (ok), 21:15 , 10-Июл-13, (119) –1

шифрование трафика 8212 это хорошо а https всё-таки херня , arisu (ok), 18:48 , 10-Июл-13, (88)

Пока безальтернативная херня , serg1224 (ok), 19:20 , 10-Июл-13, (96) –1

http habr habrastorage org comment_images 4cf e60 3de 4cfe603defb0942faa2a7c8c, Аноним (-), 07:20 , 10-Июл-13, (31)

Какое страшилище Винда 3 0 с SPDY , Аноним (-), 16:34 , 10-Июл-13, (78)

Плоская юнисекс версия с 0 размером груди, Аноним (-), 01:02 , 11-Июл-13, (152)

гугл должен пойти и написать что-то для IE при живых-то, прастигосспади разрабо, Клыкастый (ok), 09:28 , 10-Июл-13, (38)
Пересобрать ядро можно на любом дистрибутиве если ты не знал, ггг, kurokaze (ok), 11:08 , 10-Июл-13, (44)

Но безо всякого смысла, ради самого процесса - этим занимаются почти исключитель, Аноним (-), 13:56 , 10-Июл-13, (66) –1

аптгетчикам давно пора выйти из тени и добиваться сакрализации исходников и, соо, Клыкастый (ok), 11:07 , 11-Июл-13, (159)

IPSec после двух натов уже не работает Для простых смертных оно будет не раньше, Аноним (-), 14:13 , 10-Июл-13, (70)

IPSec не заменит HTTP, IMAP, POP3, SMTP, SSL Даже после перехода на ipv6 , serg1224 (ok), 18:55 , 10-Июл-13, (92) –1

http www bluestop org SctpDrv , Аноним (-), 01:57 , 10-Июл-13, (18) //

Этого нет в штатной поставке Windows, поэтому для обычного пользователя работать, serg1224 (ok), 02:33 , 10-Июл-13, (24) –3

Flash то-же недоступен в штатной поставке Windows И таки работает для обычного , 123 (??), 08:49 , 10-Июл-13, (34) +1

В 8 доступен, и обновляется штатными средствами самой системы, milkman (?), 10:19 , 10-Июл-13, (41) –2

8 неработает нормально для обычного пользователя, kurokaze (ok), 11:09 , 10-Июл-13, (45) +3

Брешешь И НЕ с глаголами пишется раздельно, нерусь , Аноним (-), 12:01 , 10-Июл-13, (54) –3

В другое время я был бы с тобой согласен, о мой тёзка-опричник, но win8 именно ч, Аноним (-), 12:14 , 10-Июл-13, (55) +4
Неработает - это не не с глаголом, а нарицательное имя для Шindoшs , Аноним (-), 16:17 , 10-Июл-13, (77) +1
Не брешет Работой это называть больно жирно Это функционирование какое-то , Аноним (-), 16:35 , 10-Июл-13, (79)

Linux для конечного пользователя неработает еще эффективнее , Аноним (-), 13:12 , 10-Июл-13, (60) –2

Эта проблема - не в технике, а в пиаре и продвижении В отличие от , Аноним (-), 13:55 , 10-Июл-13, (65) +1
Наверное именно поэтому Dota2 пилят под линь, CryTek нанимает линухового разрабо, Аноним (-), 16:36 , 10-Июл-13, (80) +1

Mozilla Firefox тоже ставится и работает для обычного пользователя Очень даже м, serg1224 (ok), 15:50 , 11-Июл-13, (162) –1

Только на этот раз - впендюривая протокол транспортного уровня на прикладной Ко, Аноним (-), 01:24 , 10-Июл-13, (11)
Сравнил теплое с мягким SCTP - протокол транспортного уровня HTTP что первый, Unknown (??), 15:38 , 11-Июл-13, (161) +2
SCTP is an entirely different transport protocol Almost no router supports it , Victor (??), 14:46 , 12-Июл-13, (164) –1

SSH чтоль изобрели опять PS Согласен, сперва нужно почитать w3c Но в новости з, klalafuda (?), 00:33 , 10-Июл-13, (4) –1 //

Да И с массовым переходом интернеты с plain HTTP на SSL гугловые боты тупо поло, klalafuda (?), 00:35 , 10-Июл-13, (5) –1 //

Что доступно для ботов, шифровать смысла нет , Аноним (-), 01:29 , 10-Июл-13, (15)
А что, планируется отрубить возможность доступа без шифрования, даже к публично , Аноним (-), 02:02 , 10-Июл-13, (20) +2 //

А что, ещё остались герои , которые работают без SSL со своей публичной почтой , serg1224 (ok), 03:07 , 10-Июл-13, (28) –5

fixed, Аноним (-), 09:10 , 10-Июл-13, (36) –2

конечно все пользователи gmail, например , arisu (ok), 18:52 , 10-Июл-13, (91) +1

Любого почтового хостера можно туда же отнести, если конечно он не хочет потерят, serg1224 (ok), 19:24 , 10-Июл-13, (99) –1

поэтому лучше использовать свой сервер , arisu (ok), 19:43 , 10-Июл-13, (107)

Конечно остались Почему бы и нет , freehck (ok), 09:48 , 10-Июл-13, (40) +1
Публичная почта - это как Когда любой может зайти и поковыряться в ящике , Аноним (-), 13:50 , 10-Июл-13, (63) +3

GMail, Yandex, Mail ru и т п , serg1224 (ok), 18:23 , 10-Июл-13, (86) –1

И с каких это пор содержимое писем стало публично доступным контентом , Аноним (-), 19:24 , 10-Июл-13, (98) +1

Имеется в виду, что GMail и ему подобные провайдеры предоставляет публичную услу, serg1224 (ok), 19:29 , 10-Июл-13, (101) –1

Нет, это в твоём сообщении http www opennet ru openforum vsluhforumID3 90781 , Аноним (-), 20:54 , 10-Июл-13, (113) +1

Нам конечно не мешало бы использовать единую терминологию и интерпретацию Письм, serg1224 (ok), 21:25 , 10-Июл-13, (122) –1

Да, контент Да, на сервере Нет, не на публичном Публичный сервер на то и публ, Аноним (-), 21:52 , 10-Июл-13, (126) +1

Вы видимо не учитываете, что SSL может обеспечивать не только шифрование, но и д, serg1224 (ok), 22:49 , 10-Июл-13, (134) –1
может но в данный момент 8212 не обеспечивает увы , arisu (ok), 22:54 , 10-Июл-13, (135) +2
В целом ряде применений и в достаточной степени обеспечивает Без SSL было бы хуж, serg1224 (ok), 23:20 , 10-Июл-13, (143) –1
угу 171 еда в достаточной степени съедобна 187 ну, то есть, после употребл, arisu (ok), 00:11 , 11-Июл-13, (148)
Вы продуктовым магазинам доверяете С какой вероятностью Дайте уж ссылки, наконец, serg1224 (ok), 00:42 , 11-Июл-13, (151) –1

А вот это хорошо Кроме всего прочего это сорвет потуги классификации траффика в, Аноним (-), 16:38 , 10-Июл-13, (81)
а это нынче модно попробуй, например, зайти на моднявенький гитхаб без https , arisu (ok), 18:51 , 10-Июл-13, (90)

Модно Скорее необходимо Тем более для сайтов разработчиков ПО , serg1224 (ok), 19:22 , 10-Июл-13, (97) –1

модно я осознаю, что такое http я НЕ ПРОСИЛ https зачем мне его в глотку заби, arisu (ok), 19:33 , 10-Июл-13, (104) –1

Видимо владельцы ресурса посчитали это не просто полезным, а даже обязательным О, serg1224 (ok), 19:45 , 10-Июл-13, (108) –1

разве я с этим спорю модно потому что таким, что там интересные исходники доста, arisu (ok), 19:50 , 10-Июл-13, (110)

Т е Вы бы на своём сервере, который предоставляет услуги Вашим клиентам, не ста, serg1224 (ok), 21:05 , 10-Июл-13, (116) –1

попробуй понять разницу между опциональным https и принудительным https я верю,, arisu (ok), 21:11 , 10-Июл-13, (118) –1

Серьёзные вопросы безопасности не бывают опциональными Или паспорт гражданина Вы, serg1224 (ok), 21:47 , 10-Июл-13, (125) –1

и это говорит человек, который считает, что https до сих пор имеет какое-то отно, arisu (ok), 22:36 , 10-Июл-13, (131)
Если Вы - не троль, то укажите нам истинный путь Вариант уж лучше совсем не жит, serg1224 (ok), 23:00 , 10-Июл-13, (137) –1
для начала 8212 выкинуть на мороз торговцев воздухом сделать кросс-подпись в, arisu (ok), 23:10 , 10-Июл-13, (141) +1
Коллега, Вы всё спутали в кучу недостатки самой технологии и практику её примен, serg1224 (ok), 23:42 , 10-Июл-13, (145) –1
в данном случае совершенно без разницы, замок ли плохой, или он просто вставле, arisu (ok), 23:51 , 10-Июл-13, (146)
Ни дверь, ни замок сами по себе никакой безопасности не обеспечивают Но при опр, serg1224 (ok), 00:16 , 11-Июл-13, (149) –1
всё, хватит с меня идиотов на сегодня практика в очередной раз доказала, что ид, arisu (ok), 02:20 , 11-Июл-13, (153) +2
Жаль, что у Вас совсем маленький запас аргументов и фактов в поддержку Ваших же , serg1224 (ok), 02:38 , 11-Июл-13, (155)

увеличит ли это LA , Аноним (-), 01:10 , 10-Июл-13, (6) //

да, обеспечивает увеличение до 10см, Нанобот (?), 11:22 , 10-Июл-13, (52) +3 //

Enlarge you load average for FREE 10cm month , Аноним (-), 14:00 , 10-Июл-13, (68) //

your , конечно же , Аноним (-), 14:00 , 10-Июл-13, (69)

Так стоп, это просто спиди и всё А то https - это как бы может и хорошо, ноа ме, vitalif (?), 01:17 , 10-Июл-13, (8) –1
Аналитики собрались Вы, это, драфт прочитать пробовали , Anonymous000 (?), 02:09 , 10-Июл-13, (23) //

они читать не умеют, только комменты писать , crypt (??), 09:22 , 10-Июл-13, (37) +1

кого оверхэд напрягает - WebSocket-ы для продакшна бо разница эдак в сотни раз о, Аноним (-), 05:35 , 10-Июл-13, (29)
SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность обеспечить пе, Аноним (-), 08:53 , 10-Июл-13, (35) –3 //

для твоих претензий это более чем странное решение НИЧЕГО не меняющее, Клыкастый (ok), 09:31 , 10-Июл-13, (39) +1
Спасибо, ваш растаманский бред сделал мне утро, kurokaze (ok), 11:12 , 10-Июл-13, (46)
Заказывает броузер по Вашему поручению , YetAnotherOnanym (ok), 11:52 , 10-Июл-13, (53)
Открою тебе страшную правду за тобой уже следит протокол IP В каждом IP-пакете, Аноним (-), 13:58 , 10-Июл-13, (67) +2

Есть альтернатива SPDY , A_n_D (ok), 10:50 , 10-Июл-13, (42) //

QUIC HSTS, Аноним (-), 11:16 , 10-Июл-13, (47)
Есть, HTTP , лох (?), 11:20 , 10-Июл-13, (51) –1 //

HTTP и SPDY 8212 протоколы совсем разных уровней, вообще-то первый 8212 п, Аноним (-), 12:31 , 10-Июл-13, (56) –1 //

Тащeмта, оба прикладные Просто в SPDY засунут микс из фич транспортного уровня и, Аноним (-), 14:26 , 10-Июл-13, (71)
Читаем заголовок новости Теперь что, HTTP 0 9, 1 0 и 1 1 - прикладные протоколы,, Аноним (-), 16:11 , 10-Июл-13, (75)

Уж не дурак ли ты Аноним выше ничего не говорит про HTTP 2 0 Транспортным уров, Аноним (-), 16:45 , 10-Июл-13, (83) +1

А как же тогда обеспечить безопасность трафика в web-сеансе TCP 443 уже отлажен , serg1224 (ok), 19:15 , 10-Июл-13, (93) –1

Нет, нельзя SPDY работает вместе с HTTP, а не вместо HTTP , Аноним (-), 19:19 , 10-Июл-13, (95)

Ну пусть будет SPDY HTTP 1 1 1Так пойдёт , serg1224 (ok), 19:26 , 10-Июл-13, (100) –1

Нет, не пойдёт Повторю для альтернативно одарённых SPDY работает вместе с HTTP, Аноним (-), 21:08 , 10-Июл-13, (117) +1

Ну хорошо, эмоциональный коллега, читаем http dev chromium org spdy spdy-whit, serg1224 (ok), 22:16 , 10-Июл-13, (128) –1

А там нет картиночки, которая показывает, что TCP тинкапсулирует SPDY, а IP инка, Аноним (-), 23:08 , 10-Июл-13, (140)

Зачем она Вам Вы же и сами это прекрасно понимаете - Вы бы ещё OID ы вспомнили, serg1224 (ok), 23:29 , 10-Июл-13, (144) –1
8230 а может и не взять Об этом варианте Вы не подумали , Аноним (-), 10:39 , 11-Июл-13, (158)
Подумал Конечно можно и трусы через голову одевать, но это как минимум дольш, serg1224 (ok), 14:46 , 11-Июл-13, (160) –1

а trustwave, например, гарантирует отсутствие mitm, ага , arisu (ok), 19:30 , 10-Июл-13, (102)

HTTPS может и неидеален, но альтернатива где , serg1224 (ok), 19:35 , 10-Июл-13, (105) –1

он не просто 171 не идеален 187 , он скомпрометирован за сим на нём можно сп, arisu (ok), 19:48 , 10-Июл-13, (109)

Ну подождите Прежде, чем от HTTPS отказываться, нужно понять в пользу чего Во, serg1224 (ok), 20:59 , 10-Июл-13, (114) –1

прежде всего надо отказаться тогда появится стимул для развития нормальных веще, arisu (ok), 21:20 , 10-Июл-13, (120) +1

Не появится Изобрести какой-никакой костыль проще и быстрее Можно узнать, что, serg1224 (ok), 22:36 , 10-Июл-13, (130) –2
diginotar trustwave это уже на два раза больше, чем допустимо а надо, чтобы д, arisu (ok), 22:46 , 10-Июл-13, (133)
Вы имеете в виду возможный выпуск левых сертификатов Т е если кто-то нарушил , serg1224 (ok), 23:17 , 10-Июл-13, (142) –1
да нет, не напрашивается дырка в системе мало того, что известна, но и была усп, arisu (ok), 00:07 , 11-Июл-13, (147) +2
Ну с кем не бывает Технологией предусмотрены CRL-списки Есть ссылочка на эту де, serg1224 (ok), 00:40 , 11-Июл-13, (150) –1
нет, не в гугель намного дальше пошлю иди, собственно , arisu (ok), 02:24 , 11-Июл-13, (154)
Ну вот, заземлилась энергия аналитика , serg1224 (ok), 02:40 , 11-Июл-13, (156)

Альтернатива чему Замку, который можно открыть ногтем без ключа Отсутствие люб, Аноним (-), 21:01 , 10-Июл-13, (115) +1

кстати, человек как раз наглядно демонстрирует опасность иллюзий он считает, чт, arisu (ok), 21:24 , 10-Июл-13, (121)

Правильней было бы сказать, что хоть какой-то замок лучше, чем совсем без замка , serg1224 (ok), 21:38 , 10-Июл-13, (124) –1

банку по барабану вообще а вот во всяких root authorities таки лохов есть и ес, arisu (ok), 22:38 , 10-Июл-13, (132) +1
Банк рискует деньгами и репутацией А что стоит за Вашими словами Мечты о лучшей, serg1224 (ok), 23:02 , 10-Июл-13, (138) –1

Послушайте, коллега Ну возьмите, для примера, клиент-банк Отказаться от онла, serg1224 (ok), 21:30 , 10-Июл-13, (123) –1

Если тебе ДЕЙСТВИТЕЛЬНО важен твой кошелёк 8212 отказывайся Ну не обеспечива, Аноним (-), 21:58 , 10-Июл-13, (127)

Частник это ещё может быть и переживёт, но для бизнеса сегодня это уже невозможн, serg1224 (ok), 22:55 , 10-Июл-13, (136) –2
да ничем они не рискуют вообще 171 мы предупреждали а доцент тупой сам вин, arisu (ok), 23:03 , 10-Июл-13, (139)

Average page load times for SPDY-over-TCP1 loss 6690 ms2 loss 8823 msAverage, Аноним (-), 11:17 , 10-Июл-13, (48) +2 //

http habrahabr ru post 117230 comment_3812340http habrahabr ru post 117230 , Аноним (-), 11:19 , 10-Июл-13, (50) +1

Гипотеза Гугл продвигает протокол опритизированный для собственных нужд , A_n_D (ok), 12:50 , 10-Июл-13, (58) //

Ну если так подумать - кто в трезвом уме и здравой памяти будет продвигать что-т, klalafuda (?), 13:32 , 10-Июл-13, (62)

для копирайтеров нормально будет, solar (??), 15:49 , 10-Июл-13, (74) –1 //

Каким местом это для ребят, которые пишут рекламные листовки , Аноним (-), 16:13 , 10-Июл-13, (76) +1
А какое дело копирайтерам до SPDY O_O, Аноним (-), 16:43 , 10-Июл-13, (82)

В Google уже осознали, что со SPDY они лажанулись, и изобретают QUIC http en , PyMonty (?), 18:11 , 10-Июл-13, (85) //

Одно другому не мешает Пусть экспериментируют Время покажет какие опытные обра, serg1224 (ok), 19:18 , 10-Июл-13, (94) –1

Давно пора , lucentcode (ok), 20:20 , 10-Июл-13, (111) –1
разработанный компанией Google протокол SPY - Протокол-шпион - Простит, Аноним (-), 19:20 , 01-Авг-13, (166) //

а по-моему, 171 SPY 187 лучше 8230 , arisu (ok), 19:25 , 01-Авг-13, (167)

Сообщения [Сортировка по времени | RSS]

56. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от Аноним (-), 10-Июл-13, 12:31

> Есть, HTTP.
HTTP и SPDY — протоколы совсем разных уровней, вообще-то: первый — прикладной, второй — транспортный.

Ответить | Правка | Наверх | Cообщить модератору

71. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 10-Июл-13, 14:26

Тащeмта, оба прикладные.
Просто в SPDY засунут микс из фич транспортного уровня и уровня представления. Но прикладным он от этого быть не перестает. А вот уродливым - становится, это да.

Ответить | Правка | Наверх | Cообщить модератору

75. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 10-Июл-13, 16:11

> HTTP и SPDY — протоколы совсем разных уровней, вообще-то: первый — прикладной, второй — транспортный.
Читаем заголовок новости
> "Доступен второй черновой вариант спецификации HTTP 2.0"
Теперь что, HTTP 0.9, 1.0 и 1.1 - прикладные протоколы, а HTTP 2.0 - транспортный?

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

83. "Доступен второй черновой вариант спецификации HTTP 2.0" +1 +/–

Сообщение от Аноним (-), 10-Июл-13, 16:45

> Теперь что, HTTP 0.9, 1.0 и 1.1 - прикладные протоколы, а HTTP 2.0 - транспортный?
Уж не дурак ли ты? Аноним выше ничего не говорит про HTTP 2.0. Транспортным уровнем он назвал SPDY. Не то чтобы это не было глупостью:
> Протокол SPDY разработан для минимизации задержек при соединении и обмене данными между клиентом и сервером. По данным Google ускорение работы реальных сайтов при использовании SPDY составляет от 15% до 50%. SPDY добавляет сеансовый уровень поверх SSL
Сеансовый уровень — он как раз где-то между транспортным и прикладным, если что. Так что предложение использовать HTTP как "альтернативу SPDY" всё равно весьма сомнительно.
Хотя учитывая, что SSL — представительский уровень, и что SPDY почему-то реализуют поверх него, а не под ним, как положено по модели OSI, можно предположить, что целью создания SPDY было введение в заблуждение как можно большего числа людей, а это значит, что альтернативой SPDY вполне может стать произвольный набор помех.

Ответить | Правка | Наверх | Cообщить модератору

93. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 19:15

> Хотя учитывая, что SSL — представительский уровень, и что SPDY почему-то реализуют
> поверх него, а не под ним
А как же тогда обеспечить безопасность трафика в web-сеансе?
TCP:443 уже отлажен годами. Поверх него и будет работать SPDY.
Можно рассматривать SPDY как рабочее название новой версии HTTP.

Ответить | Правка | Наверх | Cообщить модератору

95. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 10-Июл-13, 19:19

> Можно рассматривать SPDY как рабочее название новой версии HTTP.
Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP.

Ответить | Правка | Наверх | Cообщить модератору

100. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 19:26

>> Можно рассматривать SPDY как рабочее название новой версии HTTP.
> Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP.
Ну пусть будет: SPDY == HTTP 1.1.1
Так пойдёт?

Ответить | Правка | Наверх | Cообщить модератору

117. "Доступен второй черновой вариант спецификации HTTP 2.0" +1 +/–

Сообщение от Аноним (-), 10-Июл-13, 21:08

>>> Можно рассматривать SPDY как рабочее название новой версии HTTP.
>> Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP.
> Ну пусть будет: SPDY == HTTP 1.1.1
> Так пойдёт?
Нет, не пойдёт. Повторю для альтернативно одарённых: SPDY работает вместе с HTTP. Не вместо. И исполняет он не "функции HTTP + какие-то свои", а именно что "только свои".

Ответить | Правка | Наверх | Cообщить модератору

128. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 22:16

>>>> Можно рассматривать SPDY как рабочее название новой версии HTTP.
>>> Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP.
>> Ну пусть будет: SPDY == HTTP 1.1.1
>> Так пойдёт?
> Нет, не пойдёт. Повторю для альтернативно одарённых: SPDY работает вместе с HTTP.
> Не вместо. И исполняет он не "функции HTTP + какие-то свои",
> а именно что "только свои".
Ну хорошо, эмоциональный коллега, читаем: http://dev.chromium.org/spdy/spdy-whitepaper
Q: Is SPDY a replacement for HTTP?
A: No. SPDY replaces some parts of HTTP, but mostly augments it.
Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP.
Поясняю. Для того, чтобы сейчас не переписывать web-приложения SPDY берёт на себя часть функций HTTP, но по мере поддержки SPDY разработчиками, прежний HTTP канет в лету. Именно поэтому я и говорю, что SPDY - это развитие HTTP.

Ответить | Правка | Наверх | Cообщить модератору

140. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 10-Июл-13, 23:08

> Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP.
А там нет картиночки, которая показывает, что TCP тинкапсулирует SPDY, а IP инкапсулирует TCP? А они это делают. Или ты всерьез думаешь, что TCP можно назвать "HTTP 1.1.1.1"?

Ответить | Правка | Наверх | Cообщить модератору

144. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 23:29

>> Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP.
> А там нет картиночки, которая показывает, что TCP тинкапсулирует SPDY, а IP
> инкапсулирует TCP? А они это делают.
Зачем она Вам? Вы же и сами это прекрасно понимаете :-)
> Или ты всерьез думаешь, что
> TCP можно назвать "HTTP 1.1.1.1"?
Вы бы ещё OID'ы вспомнили (а-ля 1.3.6.1.4.1.5518.1.5.47)
Боюсь Вы не уловили направление моей мысли.
Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой.

Ответить | Правка | Наверх | Cообщить модератору

158. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 11-Июл-13, 10:39

> Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой.
…а может и не взять. Об этом варианте Вы не подумали?

Ответить | Правка | Наверх | Cообщить модератору

160. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 11-Июл-13, 14:46

>> Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой.
> …а может и не взять. Об этом варианте Вы не подумали?
Подумал. Конечно можно и трусы через голову одевать, но это (как минимум!) дольше, чем через ноги.
Если SPDY будет покрывать весь функционал HTTP, то станет естественным приемником HTTP.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

102. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 10-Июл-13, 19:30

> TCP:443 уже отлажен годами.
а trustwave, например, гарантирует отсутствие mitm, ага.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

105. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 19:35

>> TCP:443 уже отлажен годами.
> а trustwave, например, гарантирует отсутствие mitm, ага.
HTTPS может и неидеален, но альтернатива где?

Ответить | Правка | Наверх | Cообщить модератору

109. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 10-Июл-13, 19:48

> HTTPS может и неидеален
он не просто «не идеален», он скомпрометирован. за сим на нём можно спокойно ставить крест.
> но альтернатива где?
нигде. торговцы воздухом очень не хотят переставать торговать воздухом, поэтому нормальные замены никто массово не поддержит. впрочем, https совсем не обязательно полностью заменять, его можно «аугментировать». но это опять поломает весь бизнес торговцев воздухом.
кстати: http://www.research.rutgers.edu/~ashwink/ajaxcrypt/
забавка.

Ответить | Правка | Наверх | Cообщить модератору

114. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 20:59

>> HTTPS может и неидеален
> он не просто «не идеален», он скомпрометирован. за сим на нём можно
> спокойно ставить крест.
Ну подождите... Прежде, чем от HTTPS отказываться, нужно понять в пользу чего.
>> но альтернатива где?
> нигде.
Вот в том-то и дело...
В онлайн-банк как заходить частникам и юрлицам?!
> торговцы воздухом очень не хотят переставать торговать воздухом, поэтому
> нормальные замены никто массово не поддержит.
Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у. Все толстосумы против и технология не самая удобная, и не самая правильная, но люди пользуют. Причём не только "ботаники", но и простые смертные.
Если появится технология, более защищённая, чем HTTPS и, в то же время, простая в применении, то люди начнут на неё переходить, а Mozilla поддержит это.
> впрочем, https совсем не обязательно полностью
> заменять, его можно «аугментировать». но это опять поломает весь бизнес торговцев
> воздухом.
Где-то ещё существует PGP, но мало кто знает где :-)
Конечно технология должна быть удобна и безопасна для всех участников: и для пользователей, и для серверов, и для центров сертификации, и для целых государств.
> кстати: http://www.research.rutgers.edu/~ashwink/ajaxcrypt/
> забавка.
Красиво, но практически мало полезно. Что мешает подменить URL для загрузки JavaScript-скрипта, особенно если HTTP-трафик не защищён SSL-ем? Пользователь будет полагать, что его сообщения шифруются, а на самом деле нет.

Ответить | Правка | Наверх | Cообщить модератору

120. "Доступен второй черновой вариант спецификации HTTP 2.0" +1 +/–

Сообщение от arisu (ok), 10-Июл-13, 21:20

> Ну подождите… Прежде, чем от HTTPS отказываться, нужно понять в пользу чего.
прежде всего надо отказаться. тогда появится стимул для развития нормальных вещей.
> В онлайн-банк как заходить частникам и юрлицам?!
как угодно. https не обеспечивает НИКАКОЙ защиты. вообще. «один раз скомпрометированая система безопасности» == «отсутствующая система безопасности». причём второй вариант лучше, потому что не даёт ложного ощущения защищённости.
> Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у.
это вообще совсем другая опера.
> Все толстосумы против и технология не самая удобная, и не самая
> правильная, но люди пользуют. Причём не только «ботаники», но и простые
> смертные.
«скачать кинцо» люди понимают. а вот криптографию — мягко говоря, не очень.
> Если появится технология, более защищённая, чем HTTPS и, в то же время,
> простая в применении
это невозможно. не бывает «простой в применении» криптобезопасности. человек должен *понимать*, что делает и что при этом происходит, иначе даже самая совершенная система безопасности будет скомпрометирована при помощи прокладки между креслом и клавиатурой.
> то люди начнут на неё переходить, а Mozilla поддержит это.
очень сложно «начать переходить» на то, что не поддерживается.
> Где-то ещё существует PGP, но мало кто знает где :-)
а это опять из другой оперы.
> Конечно технология должна быть удобна и безопасна для всех участников
см. выше. ради безопасности *всегда* придётся жертвовать некими удобствами.
> Красиво, но практически мало полезно. Что мешает подменить URL для загрузки JavaScript-скрипта,
> особенно если HTTP-трафик не защищён SSL-ем? Пользователь будет полагать, что его
> сообщения шифруются, а на самом деле нет.
я же сказал: забавка. впрочем, как и https: что мешает купить сертификат у конторы наподобие trustwave и радостно смотреть на http? подавляющее большинство пользователей не просто не читает предупреждения браузеров о сертификатах, но даже не понимает, зачем они вообще выводятся. поэтому подменённый сертификат они подтвердят не думая. обложив попутно матом «безмозглых компьютерщиков, которые только и делают, что усложняют жизнь».

Ответить | Правка | Наверх | Cообщить модератору

130. "Доступен второй черновой вариант спецификации HTTP 2.0" –2 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 22:36

>> Ну подождите… Прежде, чем от HTTPS отказываться, нужно понять в пользу чего.
> прежде всего надо отказаться. тогда появится стимул для развития нормальных вещей.
Не появится. Изобрести какой-никакой "костыль" проще и быстрее.

>> В онлайн-банк как заходить частникам и юрлицам?!
> как угодно. https не обеспечивает НИКАКОЙ защиты. вообще. «один раз
> скомпрометированая
> система безопасности» == «отсутствующая система безопасности». причём
> второй вариант лучше, потому что не даёт ложного ощущения защищённости.
Можно узнать, что именно Вы имеете в виду? Какую компрометацию?

>> Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у.
> это вообще совсем другая опера.
Это простой пример того, как технология идёт из народа, а не спускается сверху толстосумами.
> «скачать кинцо» люди понимают. а вот криптографию — мягко говоря, не очень.
Выгода очевидней :-)
Уверяю Вас, человек у которого стырили денежку из-за халатного обращения с ключами шифрования, потом делает всё по инструкции и даже больше.
>> Если появится технология, более защищённая, чем HTTPS и, в то же время,
>> простая в применении
> это невозможно. не бывает «простой в применении» криптобезопасности.
Бывет. Одноразовые пароли через OTP-модули или даже SMS.
Весьма простое решение.
> человек должен *понимать*, что делает и что при этом происходит, иначе даже
> самая совершенная система безопасности будет скомпрометирована при помощи
> прокладки между креслом и клавиатурой.
Если удобство будет сопоставимо с использованием автосигнализации, этого будет вполне достаточно.
>> то люди начнут на неё переходить, а Mozilla поддержит это.
> очень сложно «начать переходить» на то, что не поддерживается.
Вопрос времени.
>> Где-то ещё существует PGP, но мало кто знает где :-)
> а это опять из другой оперы.
Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата - можете пользовать свой центр сертификации и даже альтернативное решение у себя на сервере для себя любимого, но о массовом применении этого решения Вашими клиентами придётся забыть.
>> Конечно технология должна быть удобна и безопасна для всех участников
> см. выше. ради безопасности *всегда* придётся жертвовать некими удобствами.
Согласен. Нужен разумный компромисс.

Ответить | Правка | Наверх | Cообщить модератору

133. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 10-Июл-13, 22:46

> Можно узнать, что именно Вы имеете в виду? Какую компрометацию?
diginotar. trustwave. это уже на два раза больше, чем допустимо.
> Уверяю Вас, человек у которого стырили денежку из-за халатного обращения с ключами
> шифрования, потом делает всё по инструкции и даже больше.
а надо, чтобы *до того*.
> Бывет. Одноразовые пароли через OTP-модули или даже SMS.
> Весьма простое решение.
(умилительно) офигенное «секурити».
> Если удобство будет сопоставимо с использованием автосигнализации, этого будет вполне
> достаточно.
…для того, чтобы хомячок успокоился. но недостаточно для защиты. как-то фиговато сигнализация мешает и угонам, и кражам из салонов.
>>> то люди начнут на неё переходить, а Mozilla поддержит это.
>> очень сложно «начать переходить» на то, что не поддерживается.
> Вопрос времени.
сколько бы времени ни прошло, перейти на то, что не поддерживается, не получится. просто потому, что оно не поддерживается.
> Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата
> — можете пользовать свой центр сертификации и даже альтернативное решение у
> себя на сервере для себя любимого, но о массовом применении этого
> решения Вашими клиентами придётся забыть.
и о безопасности тоже не вспоминать. откуда мне, как клиенту, знать, что «самодельный» сертификат — настоящий?
>>> Конечно технология должна быть удобна и безопасна для всех участников
>> см. выше. ради безопасности *всегда* придётся жертвовать некими удобствами.
> Согласен. Нужен разумный компромисс.
«компромиссы» в отношении безопасности работают только в одну сторону: убирают безопасность.

Ответить | Правка | Наверх | Cообщить модератору

142. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 23:17

>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию?
> diginotar. trustwave. это уже на два раза больше, чем допустимо.
Вы имеете в виду (возможный) выпуск левых сертификатов?
Т.е. если кто-то нарушил закон, то значит закон - фуфло?!
Напрашивается аналогия с правилами дорожного движения.
>> Уверяю Вас, человек у которого стырили денежку из-за халатного обращения
>> с ключами шифрования, потом делает всё по инструкции и даже больше.
> а надо, чтобы *до того*.
Кто ж захочет поумнеть, до "граблей"?
Человеки именно так и воспитываются.
>> Бывет. Одноразовые пароли через OTP-модули или даже SMS.
>> Весьма простое решение.
> (умилительно) офигенное «секурити».
Что не так? Нормальное решение для двухфазной аутентификации. Даже в теории вероятности допускается, что произведение двух маловероятных событий считается событием невероятным. Я не очень сложно объясняю?
>> Если удобство будет сопоставимо с использованием автосигнализации,
>> этого будет вполне достаточно.
> …для того, чтобы хомячок успокоился. но недостаточно для защиты. как-то фиговато
> сигнализация мешает и угонам, и кражам из салонов.
Есть конечно "одарённые" пользователи, оставляющие без присмотра и брелок от сигнализации. Но таким "хомячкам" только грабли помогут, даже целый курс хождения по граблям.
Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки больше.
>>>> то люди начнут на неё переходить, а Mozilla поддержит это.
>>> очень сложно «начать переходить» на то, что не поддерживается.
>> Вопрос времени.
> сколько бы времени ни прошло, перейти на то, что не поддерживается, не
> получится. просто потому, что оно не поддерживается.
SPDY тоже пока не поддерживается, но скоро будет.
SSL тоже сначала не поддерживался.
>> Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата
>> — можете пользовать свой центр сертификации и даже альтернативное решение у
>> себя на сервере для себя любимого, но о массовом применении этого
>> решения Вашими клиентами придётся забыть.
> и о безопасности тоже не вспоминать. откуда мне, как клиенту, знать, что
> «самодельный» сертификат — настоящий?
Вы поставьте себя на место провайдера услуг. В том-то и дело, что забота о безопасности - это прежде всего его забота, а уж потом клиента. Клиент может просто следовать в русле, заданном поставщиком услуг. Или отказаться от услуги.
>>>> Конечно технология должна быть удобна и безопасна для всех участников
>>> см. выше. ради безопасности *всегда* придётся жертвовать некими удобствами.
>> Согласен. Нужен разумный компромисс.
> «компромиссы» в отношении безопасности работают только в одну сторону: убирают
> безопасность.
В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной.

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

147. "Доступен второй черновой вариант спецификации HTTP 2.0" +2 +/–

Сообщение от arisu (ok), 11-Июл-13, 00:07

>>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию?
>> diginotar. trustwave. это уже на два раза больше, чем допустимо.
> Вы имеете в виду (возможный) выпуск левых сертификатов?
да.
> Т.е. если кто-то нарушил закон, то значит закон — фуфло?!
> Напрашивается аналогия с правилами дорожного движения.
нет, не напрашивается. дырка в системе мало того, что известна, но и была успешно использована. на публике. и не починена. а это автоматически означает, что уровень безопасности системы — нулевой.
> Кто ж захочет поумнеть, до «граблей»?
> Человеки именно так и воспитываются.
да вот не хотят. я, например, тут уже сколько толкую, что безопасность https — иллюзия (ergo, https бесполезен, ибо не выполняет свои задачи). ан нет, не доходит.
>>> Бывет. Одноразовые пароли через OTP-модули или даже SMS.
>>> Весьма простое решение.
>> (умилительно) офигенное «секурити».
> Что не так?
всё не так. sms нельзя считать довереным каналом передачи даже если хорошо накушаться веществ. а «otp-модули»… только после аудита квалифицированой незаинтересованой стороной (если я верно понял, что подразумевается).
> Нормальное решение для двухфазной аутентификации.
нормальное. а надо — хорошее.
> Даже в теории вероятности
> допускается, что произведение двух маловероятных событий считается событием невероятным.
я очень рад. то, что конкретно меня может сбить конкретная машина с конкретным номером в конкретное время — очень маловероятно. невероятно, фактически. однако если это произойдёт, я мало утешусь тем, что случилось «невероятное событие».
> Я не очень сложно объясняю?
нормально. для уровня человека, который о security слышал краем уха.
> Есть конечно «одарённые» пользователи, оставляющие без присмотра и брелок от сигнализации.
> Но таким «хомячкам» только грабли помогут, даже целый курс хождения по
> граблям.
я думаю, владелец машины будет просто в восторге от того, что когда у него разбили стекло в салоне и что-нибудь оттуда спёрли, сигнализация таки визжала. как его от этого защитит носимый с собой брелок?
> Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки
> больше.
и поэтому мушину можно бросать где угодно: сигнализация же защитит!
> SPDY тоже пока не поддерживается
интересно, а зачем тогда в about:config опции со словом «spdy»? в частности, например, network.spdy.enabled?
> Вы поставьте себя на место провайдера услуг. В том-то и дело, что
> забота о безопасности — это прежде всего его забота, а уж
> потом клиента.
нет. в такой ситуации ни о какой безопасности речи идти опять не может.
> Клиент может просто следовать в русле, заданном поставщиком услуг.
> Или отказаться от услуги.
только при этом клиенту как-то забывают пояснить, что «мы заботимся о вашей безопасности» — рекламный булшит до тех пор, пока клиент вопросы безопасности ставит не на первое место и не думает об этом сам. увы, такая вот у безопасности специфика: без взаимодействия обеих сторон ничего хорошего не получится.
>> «компромиссы» в отношении безопасности работают только в одну сторону: убирают
>> безопасность.
> В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной.
верно. но это ни разу не является причиной считать безопасным то, что уже как минимум два раза публично облажалось, и не подверглось с тех пор никакой починке.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

150. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 11-Июл-13, 00:40

>>>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию?
>>> diginotar. trustwave. это уже на два раза больше, чем допустимо.
>> Вы имеете в виду (возможный) выпуск левых сертификатов?
> да.
Ну с кем не бывает. Технологией предусмотрены CRL-списки.
>> Т.е. если кто-то нарушил закон, то значит закон — фуфло?!
>> Напрашивается аналогия с правилами дорожного движения.
> нет, не напрашивается. дырка в системе мало того, что известна, но и
> была успешно использована. на публике.
Есть ссылочка на эту демонстрацию?

>> Кто ж захочет поумнеть, до «граблей»?
>> Человеки именно так и воспитываются.
> да вот не хотят. я, например, тут уже сколько толкую, что безопасность
> https — иллюзия (ergo, https бесполезен, ибо не выполняет свои задачи).
> ан нет, не доходит.
Обжечься нужно чтобы понять, что ГОРЯЧО.

>>>> Бывет. Одноразовые пароли через OTP-модули или даже SMS.
>>>> Весьма простое решение.
>>> (умилительно) офигенное «секурити».
>> Что не так?
> всё не так. sms нельзя считать довереным каналом передачи даже если хорошо
> накушаться веществ. а «otp-модули»… только после аудита квалифицированой
> незаинтересованой стороной (если я верно понял, что подразумевается).
По отдельности эти средства безопасности мало полезны, а вот в совокупности дают удовлетворительный эффект.

>> Нормальное решение для двухфазной аутентификации.
> нормальное. а надо — хорошее.
"Нормальное" здесь значит удовлетворительное. Приемлемое по цене/качеству. Для бизнеса это крайне важно. А предела совершенству нет, как известно.

>> Даже в теории вероятности
>> допускается, что произведение двух маловероятных событий считается
>> событием невероятным.
> я очень рад. то, что конкретно меня может сбить конкретная машина с
> конкретным номером в конкретное время — очень маловероятно. невероятно,
> фактически.
> однако если это произойдёт, я мало утешусь тем, что случилось «невероятное
> событие».
Разработчики систем массового обслуживания (в т.ч. государство) сознательно пренебрегают такой "мелочью" как отдельные случаи.

>> Есть конечно «одарённые» пользователи, оставляющие без присмотра и брелок
>> от сигнализации.
>> Но таким «хомячкам» только грабли помогут, даже целый курс хождения по
>> граблям.
> я думаю, владелец машины будет просто в восторге от того, что когда
> у него разбили стекло в салоне и что-нибудь оттуда спёрли, сигнализация
> таки визжала. как его от этого защитит носимый с собой брелок?
От рисунков гвоздиком на борту автомобиля сигнализация тоже не спасает :-)
Кстати, надеюсь Вы в курсе, от прямого попадания в ПК ядерной бомбы SSL тоже не защищает :-)
Давайте всё-таки говорить о соизмеримых угрозах и средствах противодействия им.

>> Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки
>> больше.
> и поэтому мушину можно бросать где угодно: сигнализация же защитит!
"Абсолютно?" - конечно не защитит, но риск снизит. Особенно, если рядом будет стоять машина без сигнализации.

>> SPDY тоже пока не поддерживается
> интересно, а зачем тогда в about:config опции со словом «spdy»? в частности,
> например, network.spdy.enabled?
Готовится. Уже есть массовое использование?
Да и потом, Вы себе же противоречите:
> сложно «начать переходить» на то, что не поддерживается.
>> Вы поставьте себя на место провайдера услуг. В том-то и дело, что
>> забота о безопасности — это прежде всего его забота, а уж
>> потом клиента.
> нет. в такой ситуации ни о какой безопасности речи идти опять не
> может.
Голословно. Аргументы есть?

>> Клиент может просто следовать в русле, заданном поставщиком услуг.
>> Или отказаться от услуги.
> только при этом клиенту как-то забывают пояснить, что «мы заботимся о вашей
> безопасности» — рекламный булшит до тех пор, пока клиент вопросы безопасности
> ставит не на первое место и не думает об этом сам.
Я Вам даже больше скажу. В соглашении (договоре), как правило указывается, что риски компрометации ключей шифрования несёт клиент.

> увы, такая вот у безопасности специфика: без взаимодействия обеих сторон ничего
> хорошего не получится.
Согласен. Хотя и выбор у клиента небольшой: принять условия или отказаться от услуги этого поставщика.

>>> «компромиссы» в отношении безопасности работают только в одну сторону: убирают
>>> безопасность.
>> В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной.
> верно. но это ни разу не является причиной считать безопасным то, что
> уже как минимум два раза публично облажалось, и не подверглось с
> тех пор никакой починке.
Ссылочками поделитесь или в Гугл пошлёте? :-)

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

154. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 11-Июл-13, 02:24

нет, не в гугель. намного дальше пошлю. иди, собственно.

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

156. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от serg1224 (ok), 11-Июл-13, 02:40

> нет, не в гугель. намного дальше пошлю. иди, собственно.
Ну вот, заземлилась энергия "аналитика".

Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

115. "Доступен второй черновой вариант спецификации HTTP 2.0" +1 +/–

Сообщение от Аноним (-), 10-Июл-13, 21:01

>>> TCP:443 уже отлажен годами.
>> а trustwave, например, гарантирует отсутствие mitm, ага.
> HTTPS может и неидеален, но альтернатива где?
Альтернатива чему? Замку, который можно открыть ногтем без ключа? Отсутствие любого замка — хорошая альтернатива. Всё равно те секунды, которых злоумышленнику стоит его открыть, не стоят тех часов, которых теряешь на его открытие/закрытие за весь год ты сам.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

121. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 10-Июл-13, 21:24

кстати, человек как раз наглядно демонстрирует опасность иллюзий: он считает, что https «пусть и немножко скомпрометирована, но обеспечивает безопасность». логика примерно того же уровня, что и в таком: написать на входной двери слова «тут очень надёжный замок» и верить, что это работает.

Ответить | Правка | Наверх | Cообщить модератору

124. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 21:38

> кстати, человек как раз наглядно демонстрирует опасность иллюзий: он считает, что https
> «пусть и немножко скомпрометирована, но обеспечивает безопасность». логика
> примерно того же уровня, что и в таком: написать на входной
> двери слова «тут очень надёжный замок» и верить, что это работает.
Правильней было бы сказать, что хоть какой-то замок лучше, чем совсем без замка.
Речь о том, чтобы свести к минимуму вероятность взлома в процессе короткой транзакции (клиент-банк). Понятное дело, что от спецслужб это не спасает и от других серьёзных охотников тоже. Но для массового банковского обслуживания, как ни странно, подходит. А это всё-таки реальные денежные риски! Или во всех банках одни лохи сидят?

Ответить | Правка | Наверх | Cообщить модератору

132. "Доступен второй черновой вариант спецификации HTTP 2.0" +1 +/–

Сообщение от arisu (ok), 10-Июл-13, 22:38

> Или во всех банках одни лохи сидят?
банку по барабану вообще. а вот во всяких root authorities таки лохов есть. и если бы банки *действительно* волновала безопасность…

Ответить | Правка | Наверх | Cообщить модератору

138. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 23:02

>> Или во всех банках одни лохи сидят?
> банку по барабану вообще.
Банк рискует деньгами и репутацией.
А что стоит за Вашими словами? Мечты о лучшей жизни на другой планете?

Ответить | Правка | Наверх | Cообщить модератору

123. "Доступен второй черновой вариант спецификации HTTP 2.0" –1 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 21:30

>>>> TCP:443 уже отлажен годами.
>>> а trustwave, например, гарантирует отсутствие mitm, ага.
>> HTTPS может и неидеален, но альтернатива где?
> Альтернатива чему? Замку, который можно открыть ногтем без ключа? Отсутствие любого замка
> — хорошая альтернатива. Всё равно те секунды, которых злоумышленнику стоит его
> открыть, не стоят тех часов, которых теряешь на его открытие/закрытие за
> весь год ты сам.
Послушайте, коллега... Ну возьмите, для примера, клиент-банк. Отказаться от онлайна? Опять переходим на бумажные платёжки?!
Банки сделали двухфакторную аутентификацию, но от SSL не отказались. А одноразовые пароли ввели скорее из-за недоверия к защищённости ключей на стороне пользователя, чем к самой технологии SSL.

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

127. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от Аноним (-), 10-Июл-13, 21:58

>>>>> TCP:443 уже отлажен годами.
>>>> а trustwave, например, гарантирует отсутствие mitm, ага.
>>> HTTPS может и неидеален, но альтернатива где?
>> Альтернатива чему? Замку, который можно открыть ногтем без ключа? Отсутствие любого замка
>> — хорошая альтернатива. Всё равно те секунды, которых злоумышленнику стоит его
>> открыть, не стоят тех часов, которых теряешь на его открытие/закрытие за
>> весь год ты сам.
> Послушайте, коллега... Ну возьмите, для примера, клиент-банк. Отказаться от онлайна? Опять
> переходим на бумажные платёжки?!
Если тебе ДЕЙСТВИТЕЛЬНО важен твой кошелёк — отказывайся. Ну не обеспечивает тебе SSL никакой безопасности и никакой целостности. Ни-ка-кой. Вообще. Как и замок, который открывается всем подряд без ключа. А если нет никакой разницы в безопасности и целостеости, зачем лишний оверхед?

Ответить | Правка | Наверх | Cообщить модератору

136. "Доступен второй черновой вариант спецификации HTTP 2.0" –2 +/–

Сообщение от serg1224 (ok), 10-Июл-13, 22:55

>>>>>> TCP:443 уже отлажен годами.
>>>>> а trustwave, например, гарантирует отсутствие mitm, ага.
>>>> HTTPS может и неидеален, но альтернатива где?
>>> Альтернатива чему? Замку, который можно открыть ногтем без ключа? Отсутствие любого замка
>>> — хорошая альтернатива. Всё равно те секунды, которых злоумышленнику стоит его
>>> открыть, не стоят тех часов, которых теряешь на его открытие/закрытие за
>>> весь год ты сам.
>> Послушайте, коллега... Ну возьмите, для примера, клиент-банк. Отказаться от онлайна? Опять
>> переходим на бумажные платёжки?!
> Если тебе ДЕЙСТВИТЕЛЬНО важен твой кошелёк — отказывайся.
Частник это ещё может быть и переживёт, но для бизнеса сегодня это уже невозможно.
> Ну не обеспечивает тебе
> SSL никакой безопасности и никакой целостности. Ни-ка-кой. Вообще.
Не нужно повторять это тысячу раз как молитву. Слаще от слова "сахар" не становится.
Достаточно одного логического довода.
Вы уж извините меня, но на фоне Ваших "доказательств" убедительней выглядят банкиры, рискующие деньгами и репутацией.

Ответить | Правка | Наверх | Cообщить модератору

139. "Доступен второй черновой вариант спецификации HTTP 2.0" +/–

Сообщение от arisu (ok), 10-Июл-13, 23:03

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	56. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от Аноним (-), 10-Июл-13, 12:31
	> Есть, HTTP. HTTP и SPDY — протоколы совсем разных уровней, вообще-то: первый — прикладной, второй — транспортный.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от Аноним (-), 10-Июл-13, 14:26
	Тащeмта, оба прикладные. Просто в SPDY засунут микс из фич транспортного уровня и уровня представления. Но прикладным он от этого быть не перестает. А вот уродливым - становится, это да.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от Аноним (-), 10-Июл-13, 16:11
	> HTTP и SPDY — протоколы совсем разных уровней, вообще-то: первый — прикладной, второй — транспортный. Читаем заголовок новости > "Доступен второй черновой вариант спецификации HTTP 2.0" Теперь что, HTTP 0.9, 1.0 и 1.1 - прикладные протоколы, а HTTP 2.0 - транспортный?
	Ответить \| Правка \| К родителю #56 \| Наверх \| Cообщить модератору


	83. "Доступен второй черновой вариант спецификации HTTP 2.0"	+1 +/–
	Сообщение от Аноним (-), 10-Июл-13, 16:45
	> Теперь что, HTTP 0.9, 1.0 и 1.1 - прикладные протоколы, а HTTP 2.0 - транспортный? Уж не дурак ли ты? Аноним выше ничего не говорит про HTTP 2.0. Транспортным уровнем он назвал SPDY. Не то чтобы это не было глупостью: > Протокол SPDY разработан для минимизации задержек при соединении и обмене данными между клиентом и сервером. По данным Google ускорение работы реальных сайтов при использовании SPDY составляет от 15% до 50%. SPDY добавляет сеансовый уровень поверх SSL Сеансовый уровень — он как раз где-то между транспортным и прикладным, если что. Так что предложение использовать HTTP как "альтернативу SPDY" всё равно весьма сомнительно. Хотя учитывая, что SSL — представительский уровень, и что SPDY почему-то реализуют поверх него, а не под ним, как положено по модели OSI, можно предположить, что целью создания SPDY было введение в заблуждение как можно большего числа людей, а это значит, что альтернативой SPDY вполне может стать произвольный набор помех.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 19:15
	> Хотя учитывая, что SSL — представительский уровень, и что SPDY почему-то реализуют > поверх него, а не под ним А как же тогда обеспечить безопасность трафика в web-сеансе? TCP:443 уже отлажен годами. Поверх него и будет работать SPDY. Можно рассматривать SPDY как рабочее название новой версии HTTP.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от Аноним (-), 10-Июл-13, 19:19
	> Можно рассматривать SPDY как рабочее название новой версии HTTP. Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 19:26
	>> Можно рассматривать SPDY как рабочее название новой версии HTTP. > Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP. Ну пусть будет: SPDY == HTTP 1.1.1 Так пойдёт?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	117. "Доступен второй черновой вариант спецификации HTTP 2.0"	+1 +/–
	Сообщение от Аноним (-), 10-Июл-13, 21:08
	>>> Можно рассматривать SPDY как рабочее название новой версии HTTP. >> Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP. > Ну пусть будет: SPDY == HTTP 1.1.1 > Так пойдёт? Нет, не пойдёт. Повторю для альтернативно одарённых: SPDY работает вместе с HTTP. Не вместо. И исполняет он не "функции HTTP + какие-то свои", а именно что "только свои".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	128. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 22:16
	>>>> Можно рассматривать SPDY как рабочее название новой версии HTTP. >>> Нет, нельзя. SPDY работает вместе с HTTP, а не вместо HTTP. >> Ну пусть будет: SPDY == HTTP 1.1.1 >> Так пойдёт? > Нет, не пойдёт. Повторю для альтернативно одарённых: SPDY работает вместе с HTTP. > Не вместо. И исполняет он не "функции HTTP + какие-то свои", > а именно что "только свои". Ну хорошо, эмоциональный коллега, читаем: http://dev.chromium.org/spdy/spdy-whitepaper Q: Is SPDY a replacement for HTTP? A: No. SPDY replaces some parts of HTTP, but mostly augments it. Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP. Поясняю. Для того, чтобы сейчас не переписывать web-приложения SPDY берёт на себя часть функций HTTP, но по мере поддержки SPDY разработчиками, прежний HTTP канет в лету. Именно поэтому я и говорю, что SPDY - это развитие HTTP.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	140. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от Аноним (-), 10-Июл-13, 23:08
	> Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP. А там нет картиночки, которая показывает, что TCP тинкапсулирует SPDY, а IP инкапсулирует TCP? А они это делают. Или ты всерьез думаешь, что TCP можно назвать "HTTP 1.1.1.1"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	144. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 23:29
	>> Там же есть картиночка, которая показывает, что SPDY инкапсулирует данные HTTP. > А там нет картиночки, которая показывает, что TCP тинкапсулирует SPDY, а IP > инкапсулирует TCP? А они это делают. Зачем она Вам? Вы же и сами это прекрасно понимаете :-) > Или ты всерьез думаешь, что > TCP можно назвать "HTTP 1.1.1.1"? Вы бы ещё OID'ы вспомнили (а-ля 1.3.6.1.4.1.5518.1.5.47) Боюсь Вы не уловили направление моей мысли. Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	158. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от Аноним (-), 11-Июл-13, 10:39
	> Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой. …а может и не взять. Об этом варианте Вы не подумали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	160. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 11-Июл-13, 14:46
	>> Я имел в виду, что SPDY на данном этапе развития/использования, принимает данные от HTTP (чтобы не переписывать web-приложения), но в дальнейшем SPDY может взять на себя и весь функционал HTTP, по сути став его заменой. > …а может и не взять. Об этом варианте Вы не подумали? Подумал. Конечно можно и трусы через голову одевать, но это (как минимум!) дольше, чем через ноги. Если SPDY будет покрывать весь функционал HTTP, то станет естественным приемником HTTP.
	Ответить \| Правка \| К родителю #158 \| Наверх \| Cообщить модератору


	102. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от arisu (ok), 10-Июл-13, 19:30
	> TCP:443 уже отлажен годами. а trustwave, например, гарантирует отсутствие mitm, ага.
	Ответить \| Правка \| К родителю #93 \| Наверх \| Cообщить модератору


	105. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 19:35
	>> TCP:443 уже отлажен годами. > а trustwave, например, гарантирует отсутствие mitm, ага. HTTPS может и неидеален, но альтернатива где?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от arisu (ok), 10-Июл-13, 19:48
	> HTTPS может и неидеален он не просто «не идеален», он скомпрометирован. за сим на нём можно спокойно ставить крест. > но альтернатива где? нигде. торговцы воздухом очень не хотят переставать торговать воздухом, поэтому нормальные замены никто массово не поддержит. впрочем, https совсем не обязательно полностью заменять, его можно «аугментировать». но это опять поломает весь бизнес торговцев воздухом. кстати: http://www.research.rutgers.edu/~ashwink/ajaxcrypt/ забавка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	114. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 20:59
	>> HTTPS может и неидеален > он не просто «не идеален», он скомпрометирован. за сим на нём можно > спокойно ставить крест. Ну подождите... Прежде, чем от HTTPS отказываться, нужно понять в пользу чего. >> но альтернатива где? > нигде. Вот в том-то и дело... В онлайн-банк как заходить частникам и юрлицам?! > торговцы воздухом очень не хотят переставать торговать воздухом, поэтому > нормальные замены никто массово не поддержит. Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у. Все толстосумы против и технология не самая удобная, и не самая правильная, но люди пользуют. Причём не только "ботаники", но и простые смертные. Если появится технология, более защищённая, чем HTTPS и, в то же время, простая в применении, то люди начнут на неё переходить, а Mozilla поддержит это. > впрочем, https совсем не обязательно полностью > заменять, его можно «аугментировать». но это опять поломает весь бизнес торговцев > воздухом. Где-то ещё существует PGP, но мало кто знает где :-) Конечно технология должна быть удобна и безопасна для всех участников: и для пользователей, и для серверов, и для центров сертификации, и для целых государств. > кстати: http://www.research.rutgers.edu/~ashwink/ajaxcrypt/ > забавка. Красиво, но практически мало полезно. Что мешает подменить URL для загрузки JavaScript-скрипта, особенно если HTTP-трафик не защищён SSL-ем? Пользователь будет полагать, что его сообщения шифруются, а на самом деле нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	120. "Доступен второй черновой вариант спецификации HTTP 2.0"	+1 +/–
	Сообщение от arisu (ok), 10-Июл-13, 21:20
	> Ну подождите… Прежде, чем от HTTPS отказываться, нужно понять в пользу чего. прежде всего надо отказаться. тогда появится стимул для развития нормальных вещей. > В онлайн-банк как заходить частникам и юрлицам?! как угодно. https не обеспечивает НИКАКОЙ защиты. вообще. «один раз скомпрометированая система безопасности» == «отсутствующая система безопасности». причём второй вариант лучше, потому что не даёт ложного ощущения защищённости. > Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у. это вообще совсем другая опера. > Все толстосумы против и технология не самая удобная, и не самая > правильная, но люди пользуют. Причём не только «ботаники», но и простые > смертные. «скачать кинцо» люди понимают. а вот криптографию — мягко говоря, не очень. > Если появится технология, более защищённая, чем HTTPS и, в то же время, > простая в применении это невозможно. не бывает «простой в применении» криптобезопасности. человек должен понимать, что делает и что при этом происходит, иначе даже самая совершенная система безопасности будет скомпрометирована при помощи прокладки между креслом и клавиатурой. > то люди начнут на неё переходить, а Mozilla поддержит это. очень сложно «начать переходить» на то, что не поддерживается. > Где-то ещё существует PGP, но мало кто знает где :-) а это опять из другой оперы. > Конечно технология должна быть удобна и безопасна для всех участников см. выше. ради безопасности всегда придётся жертвовать некими удобствами. > Красиво, но практически мало полезно. Что мешает подменить URL для загрузки JavaScript-скрипта, > особенно если HTTP-трафик не защищён SSL-ем? Пользователь будет полагать, что его > сообщения шифруются, а на самом деле нет. я же сказал: забавка. впрочем, как и https: что мешает купить сертификат у конторы наподобие trustwave и радостно смотреть на http? подавляющее большинство пользователей не просто не читает предупреждения браузеров о сертификатах, но даже не понимает, зачем они вообще выводятся. поэтому подменённый сертификат они подтвердят не думая. обложив попутно матом «безмозглых компьютерщиков, которые только и делают, что усложняют жизнь».
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Доступен второй черновой вариант спецификации HTTP 2.0"	–2 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 22:36
	>> Ну подождите… Прежде, чем от HTTPS отказываться, нужно понять в пользу чего. > прежде всего надо отказаться. тогда появится стимул для развития нормальных вещей. Не появится. Изобрести какой-никакой "костыль" проще и быстрее. >> В онлайн-банк как заходить частникам и юрлицам?! > как угодно. https не обеспечивает НИКАКОЙ защиты. вообще. «один раз > скомпрометированая > система безопасности» == «отсутствующая система безопасности». причём > второй вариант лучше, потому что не даёт ложного ощущения защищённости. Можно узнать, что именно Вы имеете в виду? Какую компрометацию? >> Я бы с Вами согласился, если бы не было открытий, подобных Torrent'у. > это вообще совсем другая опера. Это простой пример того, как технология идёт из народа, а не спускается сверху толстосумами. > «скачать кинцо» люди понимают. а вот криптографию — мягко говоря, не очень. Выгода очевидней :-) Уверяю Вас, человек у которого стырили денежку из-за халатного обращения с ключами шифрования, потом делает всё по инструкции и даже больше. >> Если появится технология, более защищённая, чем HTTPS и, в то же время, >> простая в применении > это невозможно. не бывает «простой в применении» криптобезопасности. Бывет. Одноразовые пароли через OTP-модули или даже SMS. Весьма простое решение. > человек должен понимать, что делает и что при этом происходит, иначе даже > самая совершенная система безопасности будет скомпрометирована при помощи > прокладки между креслом и клавиатурой. Если удобство будет сопоставимо с использованием автосигнализации, этого будет вполне достаточно. >> то люди начнут на неё переходить, а Mozilla поддержит это. > очень сложно «начать переходить» на то, что не поддерживается. Вопрос времени. >> Где-то ещё существует PGP, но мало кто знает где :-) > а это опять из другой оперы. Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата - можете пользовать свой центр сертификации и даже альтернативное решение у себя на сервере для себя любимого, но о массовом применении этого решения Вашими клиентами придётся забыть. >> Конечно технология должна быть удобна и безопасна для всех участников > см. выше. ради безопасности всегда придётся жертвовать некими удобствами. Согласен. Нужен разумный компромисс.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	133. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от arisu (ok), 10-Июл-13, 22:46
	> Можно узнать, что именно Вы имеете в виду? Какую компрометацию? diginotar. trustwave. это уже на два раза больше, чем допустимо. > Уверяю Вас, человек у которого стырили денежку из-за халатного обращения с ключами > шифрования, потом делает всё по инструкции и даже больше. а надо, чтобы до того. > Бывет. Одноразовые пароли через OTP-модули или даже SMS. > Весьма простое решение. (умилительно) офигенное «секурити». > Если удобство будет сопоставимо с использованием автосигнализации, этого будет вполне > достаточно. …для того, чтобы хомячок успокоился. но недостаточно для защиты. как-то фиговато сигнализация мешает и угонам, и кражам из салонов. >>> то люди начнут на неё переходить, а Mozilla поддержит это. >> очень сложно «начать переходить» на то, что не поддерживается. > Вопрос времени. сколько бы времени ни прошло, перейти на то, что не поддерживается, не получится. просто потому, что оно не поддерживается. > Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата > — можете пользовать свой центр сертификации и даже альтернативное решение у > себя на сервере для себя любимого, но о массовом применении этого > решения Вашими клиентами придётся забыть. и о безопасности тоже не вспоминать. откуда мне, как клиенту, знать, что «самодельный» сертификат — настоящий? >>> Конечно технология должна быть удобна и безопасна для всех участников >> см. выше. ради безопасности всегда придётся жертвовать некими удобствами. > Согласен. Нужен разумный компромисс. «компромиссы» в отношении безопасности работают только в одну сторону: убирают безопасность.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	142. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 23:17
	>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию? > diginotar. trustwave. это уже на два раза больше, чем допустимо. Вы имеете в виду (возможный) выпуск левых сертификатов? Т.е. если кто-то нарушил закон, то значит закон - фуфло?! Напрашивается аналогия с правилами дорожного движения. >> Уверяю Вас, человек у которого стырили денежку из-за халатного обращения >> с ключами шифрования, потом делает всё по инструкции и даже больше. > а надо, чтобы до того. Кто ж захочет поумнеть, до "граблей"? Человеки именно так и воспитываются. >> Бывет. Одноразовые пароли через OTP-модули или даже SMS. >> Весьма простое решение. > (умилительно) офигенное «секурити». Что не так? Нормальное решение для двухфазной аутентификации. Даже в теории вероятности допускается, что произведение двух маловероятных событий считается событием невероятным. Я не очень сложно объясняю? >> Если удобство будет сопоставимо с использованием автосигнализации, >> этого будет вполне достаточно. > …для того, чтобы хомячок успокоился. но недостаточно для защиты. как-то фиговато > сигнализация мешает и угонам, и кражам из салонов. Есть конечно "одарённые" пользователи, оставляющие без присмотра и брелок от сигнализации. Но таким "хомячкам" только грабли помогут, даже целый курс хождения по граблям. Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки больше. >>>> то люди начнут на неё переходить, а Mozilla поддержит это. >>> очень сложно «начать переходить» на то, что не поддерживается. >> Вопрос времени. > сколько бы времени ни прошло, перейти на то, что не поддерживается, не > получится. просто потому, что оно не поддерживается. SPDY тоже пока не поддерживается, но скоро будет. SSL тоже сначала не поддерживался. >> Из той же. Не нравится, что кто-то может издать дубликат Вашего сертификата >> — можете пользовать свой центр сертификации и даже альтернативное решение у >> себя на сервере для себя любимого, но о массовом применении этого >> решения Вашими клиентами придётся забыть. > и о безопасности тоже не вспоминать. откуда мне, как клиенту, знать, что > «самодельный» сертификат — настоящий? Вы поставьте себя на место провайдера услуг. В том-то и дело, что забота о безопасности - это прежде всего его забота, а уж потом клиента. Клиент может просто следовать в русле, заданном поставщиком услуг. Или отказаться от услуги. >>>> Конечно технология должна быть удобна и безопасна для всех участников >>> см. выше. ради безопасности всегда придётся жертвовать некими удобствами. >> Согласен. Нужен разумный компромисс. > «компромиссы» в отношении безопасности работают только в одну сторону: убирают > безопасность. В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной.
	Ответить \| Правка \| К родителю #133 \| Наверх \| Cообщить модератору


	147. "Доступен второй черновой вариант спецификации HTTP 2.0"	+2 +/–
	Сообщение от arisu (ok), 11-Июл-13, 00:07
	>>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию? >> diginotar. trustwave. это уже на два раза больше, чем допустимо. > Вы имеете в виду (возможный) выпуск левых сертификатов? да. > Т.е. если кто-то нарушил закон, то значит закон — фуфло?! > Напрашивается аналогия с правилами дорожного движения. нет, не напрашивается. дырка в системе мало того, что известна, но и была успешно использована. на публике. и не починена. а это автоматически означает, что уровень безопасности системы — нулевой. > Кто ж захочет поумнеть, до «граблей»? > Человеки именно так и воспитываются. да вот не хотят. я, например, тут уже сколько толкую, что безопасность https — иллюзия (ergo, https бесполезен, ибо не выполняет свои задачи). ан нет, не доходит. >>> Бывет. Одноразовые пароли через OTP-модули или даже SMS. >>> Весьма простое решение. >> (умилительно) офигенное «секурити». > Что не так? всё не так. sms нельзя считать довереным каналом передачи даже если хорошо накушаться веществ. а «otp-модули»… только после аудита квалифицированой незаинтересованой стороной (если я верно понял, что подразумевается). > Нормальное решение для двухфазной аутентификации. нормальное. а надо — хорошее. > Даже в теории вероятности > допускается, что произведение двух маловероятных событий считается событием невероятным. я очень рад. то, что конкретно меня может сбить конкретная машина с конкретным номером в конкретное время — очень маловероятно. невероятно, фактически. однако если это произойдёт, я мало утешусь тем, что случилось «невероятное событие». > Я не очень сложно объясняю? нормально. для уровня человека, который о security слышал краем уха. > Есть конечно «одарённые» пользователи, оставляющие без присмотра и брелок от сигнализации. > Но таким «хомячкам» только грабли помогут, даже целый курс хождения по > граблям. я думаю, владелец машины будет просто в восторге от того, что когда у него разбили стекло в салоне и что-нибудь оттуда спёрли, сигнализация таки визжала. как его от этого защитит носимый с собой брелок? > Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки > больше. и поэтому мушину можно бросать где угодно: сигнализация же защитит! > SPDY тоже пока не поддерживается интересно, а зачем тогда в about:config опции со словом «spdy»? в частности, например, network.spdy.enabled? > Вы поставьте себя на место провайдера услуг. В том-то и дело, что > забота о безопасности — это прежде всего его забота, а уж > потом клиента. нет. в такой ситуации ни о какой безопасности речи идти опять не может. > Клиент может просто следовать в русле, заданном поставщиком услуг. > Или отказаться от услуги. только при этом клиенту как-то забывают пояснить, что «мы заботимся о вашей безопасности» — рекламный булшит до тех пор, пока клиент вопросы безопасности ставит не на первое место и не думает об этом сам. увы, такая вот у безопасности специфика: без взаимодействия обеих сторон ничего хорошего не получится. >> «компромиссы» в отношении безопасности работают только в одну сторону: убирают >> безопасность. > В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной. верно. но это ни разу не является причиной считать безопасным то, что уже как минимум два раза публично облажалось, и не подверглось с тех пор никакой починке.
	Ответить \| Правка \| К родителю #142 \| Наверх \| Cообщить модератору


	150. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 11-Июл-13, 00:40
	>>>> Можно узнать, что именно Вы имеете в виду? Какую компрометацию? >>> diginotar. trustwave. это уже на два раза больше, чем допустимо. >> Вы имеете в виду (возможный) выпуск левых сертификатов? > да. Ну с кем не бывает. Технологией предусмотрены CRL-списки. >> Т.е. если кто-то нарушил закон, то значит закон — фуфло?! >> Напрашивается аналогия с правилами дорожного движения. > нет, не напрашивается. дырка в системе мало того, что известна, но и > была успешно использована. на публике. Есть ссылочка на эту демонстрацию? >> Кто ж захочет поумнеть, до «граблей»? >> Человеки именно так и воспитываются. > да вот не хотят. я, например, тут уже сколько толкую, что безопасность > https — иллюзия (ergo, https бесполезен, ибо не выполняет свои задачи). > ан нет, не доходит. Обжечься нужно чтобы понять, что ГОРЯЧО. >>>> Бывет. Одноразовые пароли через OTP-модули или даже SMS. >>>> Весьма простое решение. >>> (умилительно) офигенное «секурити». >> Что не так? > всё не так. sms нельзя считать довереным каналом передачи даже если хорошо > накушаться веществ. а «otp-модули»… только после аудита квалифицированой > незаинтересованой стороной (если я верно понял, что подразумевается). По отдельности эти средства безопасности мало полезны, а вот в совокупности дают удовлетворительный эффект. >> Нормальное решение для двухфазной аутентификации. > нормальное. а надо — хорошее. "Нормальное" здесь значит удовлетворительное. Приемлемое по цене/качеству. Для бизнеса это крайне важно. А предела совершенству нет, как известно. >> Даже в теории вероятности >> допускается, что произведение двух маловероятных событий считается >> событием невероятным. > я очень рад. то, что конкретно меня может сбить конкретная машина с > конкретным номером в конкретное время — очень маловероятно. невероятно, > фактически. > однако если это произойдёт, я мало утешусь тем, что случилось «невероятное > событие». Разработчики систем массового обслуживания (в т.ч. государство) сознательно пренебрегают такой "мелочью" как отдельные случаи. >> Есть конечно «одарённые» пользователи, оставляющие без присмотра и брелок >> от сигнализации. >> Но таким «хомячкам» только грабли помогут, даже целый курс хождения по >> граблям. > я думаю, владелец машины будет просто в восторге от того, что когда > у него разбили стекло в салоне и что-нибудь оттуда спёрли, сигнализация > таки визжала. как его от этого защитит носимый с собой брелок? От рисунков гвоздиком на борту автомобиля сигнализация тоже не спасает :-) Кстати, надеюсь Вы в курсе, от прямого попадания в ПК ядерной бомбы SSL тоже не защищает :-) Давайте всё-таки говорить о соизмеримых угрозах и средствах противодействия им. >> Согласитесь, что если бы не было автосигнализаций, угонов было бы на порядки >> больше. > и поэтому мушину можно бросать где угодно: сигнализация же защитит! "Абсолютно?" - конечно не защитит, но риск снизит. Особенно, если рядом будет стоять машина без сигнализации. >> SPDY тоже пока не поддерживается > интересно, а зачем тогда в about:config опции со словом «spdy»? в частности, > например, network.spdy.enabled? Готовится. Уже есть массовое использование? Да и потом, Вы себе же противоречите: > сложно «начать переходить» на то, что не поддерживается. >> Вы поставьте себя на место провайдера услуг. В том-то и дело, что >> забота о безопасности — это прежде всего его забота, а уж >> потом клиента. > нет. в такой ситуации ни о какой безопасности речи идти опять не > может. Голословно. Аргументы есть? >> Клиент может просто следовать в русле, заданном поставщиком услуг. >> Или отказаться от услуги. > только при этом клиенту как-то забывают пояснить, что «мы заботимся о вашей > безопасности» — рекламный булшит до тех пор, пока клиент вопросы безопасности > ставит не на первое место и не думает об этом сам. Я Вам даже больше скажу. В соглашении (договоре), как правило указывается, что риски компрометации ключей шифрования несёт клиент. > увы, такая вот у безопасности специфика: без взаимодействия обеих сторон ничего > хорошего не получится. Согласен. Хотя и выбор у клиента небольшой: принять условия или отказаться от услуги этого поставщика. >>> «компромиссы» в отношении безопасности работают только в одну сторону: убирают >>> безопасность. >> В реальной жизни, а особенно в IT, безопасность никогда не бывает абсолютной. > верно. но это ни разу не является причиной считать безопасным то, что > уже как минимум два раза публично облажалось, и не подверглось с > тех пор никакой починке. Ссылочками поделитесь или в Гугл пошлёте? :-)
	Ответить \| Правка \| К родителю #147 \| Наверх \| Cообщить модератору


	154. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от arisu (ok), 11-Июл-13, 02:24
	нет, не в гугель. намного дальше пошлю. иди, собственно.
	Ответить \| Правка \| К родителю #150 \| Наверх \| Cообщить модератору


	156. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от serg1224 (ok), 11-Июл-13, 02:40
	> нет, не в гугель. намного дальше пошлю. иди, собственно. Ну вот, заземлилась энергия "аналитика".
	Ответить \| Правка \| К родителю #154 \| Наверх \| Cообщить модератору


	115. "Доступен второй черновой вариант спецификации HTTP 2.0"	+1 +/–
	Сообщение от Аноним (-), 10-Июл-13, 21:01
	>>> TCP:443 уже отлажен годами. >> а trustwave, например, гарантирует отсутствие mitm, ага. > HTTPS может и неидеален, но альтернатива где? Альтернатива чему? Замку, который можно открыть ногтем без ключа? Отсутствие любого замка — хорошая альтернатива. Всё равно те секунды, которых злоумышленнику стоит его открыть, не стоят тех часов, которых теряешь на его открытие/закрытие за весь год ты сам.
	Ответить \| Правка \| К родителю #105 \| Наверх \| Cообщить модератору


	121. "Доступен второй черновой вариант спецификации HTTP 2.0"	+/–
	Сообщение от arisu (ok), 10-Июл-13, 21:24
	кстати, человек как раз наглядно демонстрирует опасность иллюзий: он считает, что https «пусть и немножко скомпрометирована, но обеспечивает безопасность». логика примерно того же уровня, что и в таком: написать на входной двери слова «тут очень надёжный замок» и верить, что это работает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	124. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 21:38
	> кстати, человек как раз наглядно демонстрирует опасность иллюзий: он считает, что https > «пусть и немножко скомпрометирована, но обеспечивает безопасность». логика > примерно того же уровня, что и в таком: написать на входной > двери слова «тут очень надёжный замок» и верить, что это работает. Правильней было бы сказать, что хоть какой-то замок лучше, чем совсем без замка. Речь о том, чтобы свести к минимуму вероятность взлома в процессе короткой транзакции (клиент-банк). Понятное дело, что от спецслужб это не спасает и от других серьёзных охотников тоже. Но для массового банковского обслуживания, как ни странно, подходит. А это всё-таки реальные денежные риски! Или во всех банках одни лохи сидят?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	132. "Доступен второй черновой вариант спецификации HTTP 2.0"	+1 +/–
	Сообщение от arisu (ok), 10-Июл-13, 22:38
	> Или во всех банках одни лохи сидят? банку по барабану вообще. а вот во всяких root authorities таки лохов есть. и если бы банки действительно волновала безопасность…
	Ответить \| Правка \| Наверх \| Cообщить модератору


	138. "Доступен второй черновой вариант спецификации HTTP 2.0"	–1 +/–
	Сообщение от serg1224 (ok), 10-Июл-13, 23:02
	>> Или во всех банках одни лохи сидят? > банку по барабану вообще. Банк рискует деньгами и репутацией. А что стоит за Вашими словами? Мечты о лучшей жизни на другой планете?
	Ответить \| Правка \| Наверх \| Cообщить модератору