Простой пример такой. Например вы хотите не хешировать пароли, а шифровать (например на стороне клиента) и у вас хранится 100000 шифрованных паролей. Без IV одинаковые пароли будут иметь одинаковое значение в шифрованном виде, и по повторениям одного и того же шифротекста можно будет не только увидеть для каких учеток заданы слабые часто используемые пароли, но и довольно легко угадать их, зная примерное распределение словарных паролей по частоте использования. Примерно то же для файлов, например есть у вас 100 конфигурационных файлов с единственной строкой enabled=0 или enabled=1, без IV или со статическим IV можно будет сказать какая у вас конфигурация, если угадать значение хотя бы одном файле (что обычно не проблема). Со случайным IV одинаковые файлы или пароли будут иметь разное значение шифра.
В режимах OFB и CTR IV еще более критичен, зная содержимое одного файла можно расшифровать как минимум часть содержимого любого другого зашифрованного с тем же IV. Но при этом сам по себе IV все равно не секретен, и его так же можно хранить вместе с шифрованными данными.
Соль хранится вместе с хешем, например в
$5$MnfsQ4iN$ZMTppKN16y/tIsUYs/obHlhdP.Os80yXhTurpBMUbA5
MnfsQ4iN это соль, и при бруте она известна.
От радужных таблиц она защищает именно потому что с разной солью получаются разные хеши одного и того же пароля, нельзя их заранее просчитать и нельзя брутить всю базу паролей одновременно, каждый пароль надо брутить поотдельности.
У IV ровно такое же назначение, получать разные шифротексты при отдинаковых входных данных. IV не должен быть секретным, он должен быть уникальным.
accountnujen, IV как раз и нужен для того чтобы каждый раз получался разный результат и нельзя было между собой сравнить два шифрованных блока, аналогично соли в хеше. Поэтому сам по себе IV не секретен и хранят его так же как и соль, с результатом.
accountnujen, зачем его делать одинаковым? IV делают рандомным, просто хранят его вместе с результатом шифрования. Даже если вы дважды шифруете одни и те же данные - получите два разных результата с разными IV.
Пример не валиден, т.к. порядок команд имеет значение, proxy должна идти в конце, после задания ACL и редиректа.
Помимо этого, так стоит делать только в том случае, если порт 20001 будет прописан как HTTP прокси в клиенте. Если надо просто отобразить порт на порт, то достаточно команды
sendmail в данном случае просто название бинарника, чтобы из командной строки почту отправлять, а в качестве MTA стоит exim. Соответственно настраивать надо exim, а не sendmail.
Ставить sendmail не надо, это пережиток прошлого, сейчас обычно используются exim или postfix.
Многие получатели пессимизируют письма с доменов без MX-записей или полностью их блокируют, например в postfix есть такое правило, поэтому MX лучше делать всегда, даже если он совпадает с A-записью.
`mx` ест 2 разрешения имени и при этом вам не нужен
`a` ест 1 разрешение имени и при этом тоже вам не нужен (у вас даже PTR на этом IP нет)
getcourse.ru убирайте на отдельный домен - там полный треш или по крайней мере уносите в конец SPF записи чтобы он не топил остальные сервисы
Прописывайте везде DKIM, потому что в плане авторизации домена SPF и DKIM взаимозаменяемы и для надежности лучше иметь и то и другое
> а может сразу у хрома есть подобные ключи \ флаги в глубине настроек?
Насколько я знаю, по крайней мере раньше такого флага в хроме не было.
> но ping как рыба об лёд только с -6 работает даже если у домена только ip6
Все это знависит от того, по какому алгоритму пинг выбирает адрес назначения по имени. Этот алгоритм зависит от клиента и может (и будет) не совпадать с алгоритмом в Хроме. Используйте прокси, он гарантирует приоритет разрешения имен
Да, для клиентов поддерживающих RFC 6724 и не поддерживающих Happy Eyeballs тередо пессимизируется правилом приоритета равенства лейблов у адреса назначения и исходного адреса, для тередо они будут различаться. Можно попробовать решить это удалением префикса для тередо или заданием одинаковых лейблов для тередо и IPv6, но не уверен дает ли такое Windows и какие будут побочные эффекты.
Quqas, 2a03:2880:f213:e4:face:b00c:0:4420 и 157.240.205.174 это AAAA и A записи для одного имени, на уровне роутинга или трансляции адресов они никак не связаны и зная один из этих адресов никак нельзя получить другой (в общем случае). Приоритет имел бы значение, например, если бы был IPv6 стек с трансляцией IPv4 over IPv6, чтобы IPv4 мог ходить поверх IPv6, тогда за счет приоритета можно было бы выбирать куда идет IPv4 трафик. У тебя IPv4 и IPv6 ходят по разным сетям, поэтому все определяется тем, во что разрешилось имя.
ValdikSS, в случае dual stack клиент резолвит имя либо в IPv4 либо в IPv6 адрес и дальше делает коннект с этим адресом и попадает в соответствующий стек. Поэтому ответ про Happy Eyeballs более чем разумен.
Alexey Dmitriev, список обзора держит имена клиентов, он не хранит IP адреса, механизм разрешения имени в IP адрес не связан с обозревателем, это разные сервисы
.