Некоторые языки лучше годятся для определенных задач. У Go горутины и «автоматический» M:N, что делает его подходящим для написания сетевых программ. В тех же условиях, например, Python будет сильно проигрывать, потому что из-за проблемы раскраски функций далеко не все протоколы реализованы в asyncio-варианте. А на тредах/форках хорошо масштабирующееся приложение не напишешь.
Правда, у DNSCrypt свой протокол. Если чувак пишет, что ротация сертифкатов помогает с forward secrecy, видимо, этого perfect secrecy в самом протоколе нет.
> Во-первых, это чрезвычайно полезно для безопасности: если сервер скомпрометирован или ключ утёк, то вчерашний трафик не может быть расшифрован. Ключ уже изменился. Вероятно, это составит проблему для исполнения «закона Яровой», который вынуждает провайдеров хранить весь трафик, в том числе зашифрованный. Подразумевается, что позже его можно будет расшифровать при необходимости, запросив ключ у сайта. Но в данном случае сайт просто не сможет его предоставить, потому что использует кратковременные ключи, удаляя старые.
В TLS и так достаточно давно есть forward secrecy, при котором никакая утечка ключа от сертификата не позволит ничего расшифровать.
ОС должна явно включить поддержку расширенных наборов команд (чтобы не было такого, что программа в юзерспейсе использует какой-нибудь zmm0, а ядро ОС не знает, что такой существует и его надо сохранять при переключении контекста). В embox это сделано?
Если сервер не отвечает на запрос и рвет коннект, браузеры втихую даже POST переотправляют (ещё), что стало для меня сюрпризом. На вкладке Network отладчика этого даже не видно.
Даже если и можно сделать EAP без сертификата сервера (сомневаюсь, но не буду врать), то он же все равно будет хуже PSK, именно по той причине, что я выше описал: станция (клиент) не сможет проверить точку доступа.
По-моему, это все избыточно. White list MAC-адресов практически бесполезен с точки зрения безопасности. Обычный WPA2-PSK достаточно безопасен.
Я бы даже сказал, что WPA2-EAP чем-то даже более опасен. На устройствах бывает сложно нормально поставить сертификаты, и это может закончиться «ну похер, подключусь без проверки». А такой сетап хуже, чем PSK, потому что атакующий может поднять свою точку доступа с таким же именем и EAP, и клиент спокойно к ней подключится. EAP можно так настроить, чтобы сервер принимал любой пароль (что невозможно в PSK из-за свойств 4-way handshake, который аутентифицирует как точку доступа перед станцией, так и наоборот). Это не даст атакующему возможности подключиться к самой сети, впрочем, но всё же.
Пожалуй, основное преимущество EAP — возможность заводить кучу юзеров, и менять пароли/лочить аккаунты независимо. Но полезность этого дома сомнительна. Для гостевого Wi-Fi лучше поднять ещё одну точку доступа, тоже с PSK, но другим паролем. Даже непродвинутые SOHO-роутеры это часто поддерживают, ну а Mikrotik — вы и сами знаете :)
В играх серии Unreal Tournament (twitch arena shooter) сортировка пузырьком применяется для сортировки скорборда в матче. Причем эта функции вызывается каждую перерисовку экрана, и при этом все работает отлично. Я даже скажу больше: это идеальный алгоритм сортировки для этой задачи (и он останется таковым, даже если сделать чуть умнее и сортировать только при изменении счета у одного из игроков).
Да, всё так. Но это все же P2P-протоколы, и тут, кажется, от таких проблем никуда не деться. uPnP и STUN есть, уже неплохо.
> FTP протокол позволяет докачивать большие файлы в отличие от http например.
В HTTP есть Range, и он хорошо поддерживается.
Можете привести пример протоколов, у которых плохо или никак с NAT?
Некоторые языки лучше годятся для определенных задач. У Go горутины и «автоматический» M:N, что делает его подходящим для написания сетевых программ. В тех же условиях, например, Python будет сильно проигрывать, потому что из-за проблемы раскраски функций далеко не все протоколы реализованы в asyncio-варианте. А на тредах/форках хорошо масштабирующееся приложение не напишешь.
Вот так и получаются LPE.
В TLS и так достаточно давно есть forward secrecy, при котором никакая утечка ключа от сертификата не позволит ничего расшифровать.
Если они не хотят знать, они же могут её использовать без декларации. Exchange может быть создан кем-то другим.
Я бы даже сказал, что WPA2-EAP чем-то даже более опасен. На устройствах бывает сложно нормально поставить сертификаты, и это может закончиться «ну похер, подключусь без проверки». А такой сетап хуже, чем PSK, потому что атакующий может поднять свою точку доступа с таким же именем и EAP, и клиент спокойно к ней подключится. EAP можно так настроить, чтобы сервер принимал любой пароль (что невозможно в PSK из-за свойств 4-way handshake, который аутентифицирует как точку доступа перед станцией, так и наоборот). Это не даст атакующему возможности подключиться к самой сети, впрочем, но всё же.
Пожалуй, основное преимущество EAP — возможность заводить кучу юзеров, и менять пароли/лочить аккаунты независимо. Но полезность этого дома сомнительна. Для гостевого Wi-Fi лучше поднять ещё одну точку доступа, тоже с PSK, но другим паролем. Даже непродвинутые SOHO-роутеры это часто поддерживают, ну а Mikrotik — вы и сами знаете :)