1.2, Аноним (2), 11:53, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
>>для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом
>>Для атаки на клиентские браузеры может применяться метод, требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы через подстановку кода в любой >>незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом
----------------------------------------
O'rly? Может в конечном итоге вообще требуется возможность запуска вредоносного кода из загрузочного с сектора жёсткого диска до загрузки оси, а потом ось грузить внутри виртуальной машины нападающего кода и там уже перехватывать весь сетевой трафик? Контроль же за сетевым шлюзом как никак нужен, ну. Такие забавные условия нужны: и тебе исполнение кода на CPU жертвы, и тебе контроль сетевого шлюха и нешированный простой HTTP (не HTTPS) трафик, ага.
| |
|
2.3, Аноним (3), 12:13, 10/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
С контролем транзитного трафика проблем как раз меньше всего - для выуживания паролей и номеров кредитных карт устраивается ловля на подставную WiFi точку доступа. А для более серьёзных применений у спецслужб есть административный рычаг. Труднее с выполнением кода на стороне клиента, но до недавних пор через JavaScript вполне можно было проводить атаки по анализу кэша. Теперь разве что для атаки спецслужб на облака описанный метод применим.
| |
2.4, Аноним (4), 13:55, 10/02/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
а смысл возиться с расшифровкой трафика если имея доступ к тачке можно снимать уже расшифрованные сообщения из самих программ?
| |
|
3.9, Коммунист (?), 17:09, 10/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
А кто сказал, что у твоего кода будут локальные привилегии на прослушивание сетевого трафика? В уязвимости главное то, чтобы твой код исполнялся на одном CPU, даже если он из-под отдельного пользователя или в песочнице браузера.
| |
|
|
1.8, Ilya Indigo (ok), 16:40, 10/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Если я правильно понял, для защиты на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых и разрешить только TLS 1.3?
| |
|
2.10, A.Stahl (ok), 17:29, 10/02/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
>на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых
Да, эпилептики неуязвимы!
| |
|
3.19, InuYasha (?), 11:33, 11/02/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
FU****
Извиняюсь, промахнулся, хотел +1 поставить.
А по теме - устойчивость эллиптических кривых еще не совсем доказана.
| |
|
4.20, Аноним (20), 11:34, 11/02/2019 [^] [^^] [^^^] [ответить]
| +/– |
В АНБ почему-то не то что не спешат их использовать, а спешат их НЕ использовать... для себя.
Вот и думай - почему.
| |
|
|
2.12, axredneck (?), 19:33, 10/02/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
причем обязательно на идиопатических, потому что фотосенсибили... (язык сломаешь) короче, фото-эти-самые уязвимы, так как недостаточно кривые.
| |
|
1.15, Аноним (15), 01:06, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Помнится, кто-то недавно в комментах к другой новости очень громко кричал, что TLS 1.3 не нужен и совсем-совсем не улучшает безопасность. И отказывался предоставить доказательства, типа как же я предоставлю доказательства отсутствия чего-то.
| |
|
2.16, Аноним (-), 03:09, 11/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
К чему такие глупые коментарии на техническом ресурсе? Не можете что-то дельное сказать - не говорите ниче. Хочется высказаться - валите в соцсети или заведите блог.
| |
|
1.17, Аноним (17), 04:00, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом)
И потом ыксперты тут говорят, что никакой проблемы в открытом http нет. Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.
| |
|
2.21, Аноним84701 (ok), 17:46, 11/02/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> И потом ыксперты тут говорят, что никакой проблемы в открытом http нет.
> Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.
Это потому что еще ранее Ыксперты заучили мантру "аутентификация совсем-совсем не нужна, если шифровать канал, поэтому можно и нужно сэкономить 0.001% CPU!".
В итоге, до сих пор нет нормальной авторизации/аутентификации в стандарте веба, пароли и прочее могут спокойно хранить в плейн -- зато/ведь канал передачи зашифрован!!1
разъясняю:
проблема не в отсутсвии шифрования (содержимое скрипта может узнать любой, обратившийся к тому же серверу), а в отсутсвии аутентификации, когда содержимое подменяется. HTTPS тут не более, чем костыль.
Не верящим предлагаю попробовать подменить мое сообщение:
-----BEGIN PGP SIGNATURE-----
iHUEAREIAB0WIQTQaLRjLMt2TTkWkoZ+PeLyUDdO7wUCXGGJWwAKCRB+PeLyUDdO
799RAP9Od5K6EBPLx1h2qxCvDoAZtuPTnN1yUc7+r8Tmz+m1bAEAgP4y9YFhRjrZ
VHqKm8N8SsjAnN8XK4aaGZ1LeDinu3Y=
=vjuZ
-----END PGP SIGNATURE-----
| |
|
1.18, ыы (?), 08:48, 11/02/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
следующим этапом развития процессоров- вероятно станет выделение процессора на каждую задачу в монопольном режиме. Ядер сейчас в процессорах- как грязи...и дальше будет больше... так чего мелочится? к том уже разные задачи требуют мягко говоря разной процессорнной мощности. зачем занимать сложное ядро простой задачей? соответственно ядра в процессорах будут тоже разными - 1000 простых ядер, 100 чуть более сложных, 10 сложных... вангую новый виток .искомерятельных тредов...
| |
|