Hi all I have had that issue in 6.0,6.1 and 6.2 I haven't tried current yet.. I haven't had enough time to diagnose it to provide an adequate bug report myself. just restarting relayd seems to resolve it Im just confiming that I have seen this issue also ...
On 14 March 2018 at 15:27, Mischa <obs...@high5.nl> wrote: > Hi Claudio, > >> On 25 Dec 2017, at 15:54, Mischa <obs...@high5.nl> wrote: >> >>> On 24 Dec 2017, at 19:07, Claudio Jeker <cje...@diehard.n-r-g.com> wrote: >>> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote: >>>>> On 23 Dec 2017, at 13:08, Claudio Jeker <cje...@diehard.n-r-g.com> wrote: >>>>>> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote: >>>>>> Hi All, >>>>>> >>>>>> Since OpenBSD 6.2, just confirmed this in the latest snapshot >>>>>> (GENERIC.MP#305) as well, for some reason relayd stops processing >>>>>> traffic and starts flooding the log file with the following message: >>>>>> >>>>>> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout >>>>>> [snip] >>>>>> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout >>>>>> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout >>>>>> ...etc... >>>>>> >>>>>> Restarting the daemon "fixes" the problem. >>>>>> Not sure how to trouble shoot this but I am able to reproduce this >>>>>> consistently by pointing SSLLabs towards relayd. >>>>>> Would be great to get some pointers. >>>>>> >>>>> >>>>> I have seen this as well on our production systems. This is a problem in >>>>> the privsep part of the TLS code. I could not do more testing yet but my >>>>> assumption is that a new option / feature is freaking this code out. >>>> >>>> Anything I can do or collect to give you more information? >>> >>> So, I think I found the problem. The ca process did not handle errors from >>> RSA_private_encrypt correctly. So once you got a bad signature in the >>> system chocked and stopped. This diff seems to work for me (against >>> SSLlabs). >> >> Awesome! Can confirm that it continues processing traffic when hitting it >> with sslabs. >> Will also move it to a more bussier machine to see how that handles. >> >> I am seeing the following messages now: >> Dec 25 15:51:07 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF06B:rsa >> routines:CRYPTO_internal:block type is not 02 >> Dec 25 15:51:08 lb2 relayd[27420]: ca_dispatch_relay: error:04FFF071:rsa >> routines:CRYPTO_internal:null before block missing >> Dec 25 15:51:17 lb2 relayd[7541]: ca_dispatch_relay: error:04FFF072:rsa >> routines:CRYPTO_internal:padding check failed >> Dec 25 15:51:33 lb2 relayd[73631]: ca_dispatch_relay: error:04FFF071:rsa >> routines:CRYPTO_internal:null before block missing > > Not sure if this is supposed to be taken care of, but I am still seeing the > following messages in 6.3-beta. > $ uname -a > OpenBSD lb2l 6.3 GENERIC.MP#58 amd64 > > Mar 13 23:43:38 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF06B:rsa > routines:CRYPTO_internal:block type is not 02 > Mar 13 23:43:39 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF072:rsa > routines:CRYPTO_internal:padding check failed > Mar 13 23:43:48 lb2 relayd[14775]: ca_dispatch_relay: error:04FFF06B:rsa > routines:CRYPTO_internal:block type is not 02 > Mar 13 23:44:03 lb2 relayd[96581]: ca_dispatch_relay: error:04FFF071:rsa > routines:CRYPTO_internal:null before block missing > > Any knobs that need to be turned? > > Mischa > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
