Недавно мы переместили веб-сервер с Fedora 2 и Plesk 8.2.1 на виртуальную машину. С тех пор qmail отказывался отправлять сообщения на определенные серверы, жалуясь в почтовом журнале, что «TLS_connect_failed: _error: 24064064: random_number_generator: SSLEAY_RAND_BYTES: PRNG_not_seeded». Очевидно, это проблема OpenSSL, связанная с переключением с реального оборудования на виртуальное. Есть ли способ изменить, откуда OpenSSL получает свои случайные данные, или, по крайней мере, указать qmail, что нужно использовать незащищенные протоколы. SSL / TLS не работает?
Помимо проверки наличия соответствующих устройств (согласно ответу Дэвида Смита), вам необходимо убедиться, что в пуле действительно есть некоторая энтропия.
cat /proc/sys/kernel/random/entropy_avail
сообщит вам его текущий уровень. Если этого недостаточно, то отправка почты через поток TLS (т. Е. С шифрованием) будет либо блокироваться (ожидая, пока будет достаточно), либо завершится ошибкой, если только вы не используете агент пересылки почты, который вместо этого использует неблокирующее случайное устройство название предполагает, что не блокирует, но теоретически менее безопасен).
Пул энтропии пополняется ядром с течением времени с использованием данных из таймингов прерываний, вызванных операциями ввода-вывода, но если машина (или виртуальная машина) не видит большой активности, для роста пула требуется много времени, а их очень мало Операции ввода-вывода для сбора данных о времени.
На небольшой машине в нашей компании, которая действует как не более чем интернет-шлюз и SMTP-реле, мы решили эту проблему с помощью exim
. Чтобы обойти это, я просто установил небольшой скрипт, работающий через init, который ничего не делает, кроме как медленно читает с диска, запустив pv --rate-limit 2m /home/4GigFile > /dev/null
затем спать 30 секунд в цикле. Вашему провайдеру ВМ вряд ли понравится это решение, поскольку оно создает ненужную дополнительную нагрузку ввода-вывода на хост-машину. - хотя вы можете обойтись менее агрессивным скриптом, который проверяет содержимое /proc/sys/kernel/random/entropy_avail
и запускает произвольную операцию ввода-вывода цикла только в том случае, если найденное значение меньше, скажем, 1000.
Существуют сценарии / инструменты, которые позволяют извлекать «случайные» значения из других источников для пополнения пула энтропии. Если вы счастливы предоставить MTA менее действительно случайный (а значит менее безопасный) источник энтропии, вы можете попробовать скормить пул энтропии из '/ dev / urandom', используя rngd или даже просто сделать /dev/random
синссылка на /dev/urandom
, хотя некоторые программы будут достаточно тщательными, чтобы проверить это, и потерпят неудачу, если они по умолчанию настроены так, чтобы параноидально относиться к качеству своего источника энтропии.
Редактировать:
Вы сталкиваетесь с этой проблемой только периодически по одной или обеим из двух причин: во-первых, пул может быть достаточно заполнен большую часть времени, а во-вторых, qmail
может взаимодействовать с некоторыми серверами через простые (незашифрованные) потоки в качестве запасного варианта (некоторые, возможно, многие принимающие серверы будут отказываться от незашифрованных соединений, поэтому этот запасной вариант не всегда может использоваться при сбое согласования TLS-соединения).
Вы проверили, существуют ли в системе / dev / random и / dev / urandom? Я нашел этот сайт с инструкциями по их воссозданию, если они этого не сделают.