Mailing List Archive

Omfwd OpenSSL TLS fails on 2023.04.0
Hi,

I've been using RSyslog to accumulate and aggregate messages in an
intermediary and then send them to another server. This intermediary runs
rsyslog with an Omfwd rule and uses OpenSSL to connect to the main server.
I've been running with this configuration for a while and it's been
working just fine for a while with the same configuration.

I've got one intermediary running 8.2302.0 and it works just fine, but
another one that is running 8.2304.0 is failing with the following
repeating logs:

May 31 16:12:51 DIA-SLHS rsyslogd: Warning: Certificate file is not set
[v8.2304.0 try https://www.rsyslog.com/e/2330 ]
May 31 16:12:51 DIA-SLHS rsyslogd: Warning: Key file is not set [v8.2304.0
try https://www.rsyslog.com/e/2331 ]
May 31 16:12:51 DIA-SLHS rsyslogd: nsd_ossl: TLS Connection initiated with
remote syslog server. [v8.2304.0]
May 31 16:12:51 DIA-SLHS rsyslogd: SSL_ERROR_SYSCALL Error in
'osslHandshakeCheck Client': 'error:00000005:lib(0):func(0):DH lib(5)'
with ret=-1, errno=104, sslapi='SSL_do_handshake' [v8.2304.0]

The rsyslog omfwd rule says:

action(type="omfwd"
protocol="tcp"
StreamDriver="ossl"
StreamDriverAuthMode="x509/certvalid"
StreamDriverMode="1"
StreamDriver.CAFile="/etc/ssl/certs/rsyslog_ca_cert.pem"
target="<log server>"
port="6514"
gnutlsPriorityString="Protocol=ALL,-SSLv2,-SSLv3,-TLSv1
MinProtocol=TLSv1.2"
template="<my template>"
)

If it matters, I also have an input imtcp rule with openssl turned on, but
that appears to be working just fine and I'm getting data into the
intermediary.

Is there some way to better debug why the omfwd is not working?

Thanks,

-derek

--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
Hi,

There has been no change on nsd_ossl.c driver since January 2023, so I
believe this is not related to the different rsyslog versions you are
running.
The warnings tell you, that there is no client certificate configured which
can be ok but unusual in this setup. The get rid of them I would recommend
configuring a client certificate as well.

Regarding the SSL_ERROR_SYSCALL, it indicates a lower system level error
which is 104 in your case. 104 means "Connection Reset by peer", so most
likely the server dropped the client during handshake for some reason.
To tell more I would have to see debug log from the server.

Best regards,
Andre Lorbach
--
Adiscon GmbH
Mozartstr. 21
97950 Großrinderfeld, Germany
Ph. +49-9349-9298530
Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB
560610
Ust.-IDNr.: DE 81 22 04 622
Web: www.adiscon.com - Mail: info@adiscon.com

Informations regarding your data privacy policy can be found here:
https://www.adiscon.com/data-privacy-policy/

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient or have received this e-mail in error please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

> -----Original Message-----
> From: rsyslog <rsyslog-bounces@lists.adiscon.com> On Behalf Of Derek
> Atkins
> via rsyslog
> Sent: Donnerstag, 1. Juni 2023 14:45
> To: rsyslog@lists.adiscon.com
> Cc: Derek Atkins <derek@ihtfp.com>
> Subject: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>
> Hi,
>
> I've been using RSyslog to accumulate and aggregate messages in an
> intermediary and then send them to another server. This intermediary runs
> rsyslog with an Omfwd rule and uses OpenSSL to connect to the main server.
> I've been running with this configuration for a while and it's been
> working just
> fine for a while with the same configuration.
>
> I've got one intermediary running 8.2302.0 and it works just fine, but
> another
> one that is running 8.2304.0 is failing with the following repeating logs:
>
> May 31 16:12:51 DIA-SLHS rsyslogd: Warning: Certificate file is not set
> [v8.2304.0 try https://www.rsyslog.com/e/2330 ] May 31 16:12:51 DIA-
> SLHS rsyslogd: Warning: Key file is not set [v8.2304.0 try
> https://www.rsyslog.com/e/2331 ] May 31 16:12:51 DIA-SLHS rsyslogd:
> nsd_ossl: TLS Connection initiated with remote syslog server. [v8.2304.0]
> May
> 31 16:12:51 DIA-SLHS rsyslogd: SSL_ERROR_SYSCALL Error in
> 'osslHandshakeCheck Client': 'error:00000005:lib(0):func(0):DH lib(5)'
> with ret=-1, errno=104, sslapi='SSL_do_handshake' [v8.2304.0]
>
> The rsyslog omfwd rule says:
>
> action(type="omfwd"
> protocol="tcp"
> StreamDriver="ossl"
> StreamDriverAuthMode="x509/certvalid"
> StreamDriverMode="1"
> StreamDriver.CAFile="/etc/ssl/certs/rsyslog_ca_cert.pem"
> target="<log server>"
> port="6514"
> gnutlsPriorityString="Protocol=ALL,-SSLv2,-SSLv3,-TLSv1
> MinProtocol=TLSv1.2"
> template="<my template>"
> )
>
> If it matters, I also have an input imtcp rule with openssl turned on, but
> that
> appears to be working just fine and I'm getting data into the
> intermediary.
>
> Is there some way to better debug why the omfwd is not working?
>
> Thanks,
>
> -derek
>
> --
> Derek Atkins 617-623-3745
> derek@ihtfp.com www.ihtfp.com
> Computer and Internet Security Consultant
>
> _______________________________________________
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL:
> This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites
> beyond
> our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
Hi,

On Fri, June 2, 2023 9:17 am, Andre Lorbach wrote:
> Hi,
>
> There has been no change on nsd_ossl.c driver since January 2023, so I
> believe this is not related to the different rsyslog versions you are
> running.
> The warnings tell you, that there is no client certificate configured
> which
> can be ok but unusual in this setup. The get rid of them I would recommend
> configuring a client certificate as well.

I'm not using client-authentication, which is why there is no client cert.
Not sure why you consider it "unusual". But that's not the error I am
concerned about.

>
> Regarding the SSL_ERROR_SYSCALL, it indicates a lower system level error
> which is 104 in your case. 104 means "Connection Reset by peer", so most
> likely the server dropped the client during handshake for some reason.
> To tell more I would have to see debug log from the server.

I wonder if there was some middleware that was doing something? I used
"openssl s_client" to connect to the server and it worked, and shortly
thereafter rsyslog started working too.

Strange, but still disconcerting.

Thanks,

-derek

>
> Best regards,
> Andre Lorbach
> --
> Adiscon GmbH
> Mozartstr. 21
> 97950 Großrinderfeld, Germany
> Ph. +49-9349-9298530
> Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB
> 560610
> Ust.-IDNr.: DE 81 22 04 622
> Web: www.adiscon.com - Mail: info@adiscon.com
>
> Informations regarding your data privacy policy can be found here:
> https://www.adiscon.com/data-privacy-policy/
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient or have received this e-mail in error
> please
> notify the sender immediately and delete this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.
>
>> -----Original Message-----
>> From: rsyslog <rsyslog-bounces@lists.adiscon.com> On Behalf Of Derek
>> Atkins
>> via rsyslog
>> Sent: Donnerstag, 1. Juni 2023 14:45
>> To: rsyslog@lists.adiscon.com
>> Cc: Derek Atkins <derek@ihtfp.com>
>> Subject: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>>
>> Hi,
>>
>> I've been using RSyslog to accumulate and aggregate messages in an
>> intermediary and then send them to another server. This intermediary
>> runs
>> rsyslog with an Omfwd rule and uses OpenSSL to connect to the main
>> server.
>> I've been running with this configuration for a while and it's been
>> working just
>> fine for a while with the same configuration.
>>
>> I've got one intermediary running 8.2302.0 and it works just fine, but
>> another
>> one that is running 8.2304.0 is failing with the following repeating
>> logs:
>>
>> May 31 16:12:51 DIA-SLHS rsyslogd: Warning: Certificate file is not set
>> [v8.2304.0 try https://www.rsyslog.com/e/2330 ] May 31 16:12:51 DIA-
>> SLHS rsyslogd: Warning: Key file is not set [v8.2304.0 try
>> https://www.rsyslog.com/e/2331 ] May 31 16:12:51 DIA-SLHS rsyslogd:
>> nsd_ossl: TLS Connection initiated with remote syslog server.
>> [v8.2304.0]
>> May
>> 31 16:12:51 DIA-SLHS rsyslogd: SSL_ERROR_SYSCALL Error in
>> 'osslHandshakeCheck Client': 'error:00000005:lib(0):func(0):DH lib(5)'
>> with ret=-1, errno=104, sslapi='SSL_do_handshake' [v8.2304.0]
>>
>> The rsyslog omfwd rule says:
>>
>> action(type="omfwd"
>> protocol="tcp"
>> StreamDriver="ossl"
>> StreamDriverAuthMode="x509/certvalid"
>> StreamDriverMode="1"
>> StreamDriver.CAFile="/etc/ssl/certs/rsyslog_ca_cert.pem"
>> target="<log server>"
>> port="6514"
>> gnutlsPriorityString="Protocol=ALL,-SSLv2,-SSLv3,-TLSv1
>> MinProtocol=TLSv1.2"
>> template="<my template>"
>> )
>>
>> If it matters, I also have an input imtcp rule with openssl turned on,
>> but
>> that
>> appears to be working just fine and I'm getting data into the
>> intermediary.
>>
>> Is there some way to better debug why the omfwd is not working?
>>
>> Thanks,
>>
>> -derek
>>
>> --
>> Derek Atkins 617-623-3745
>> derek@ihtfp.com www.ihtfp.com
>> Computer and Internet Security Consultant
>>
>> _______________________________________________
>> rsyslog mailing list
>> https://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL:
>> This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites
>> beyond
>> our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
>


--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
> -----Original Message-----
> From: Derek Atkins <derek@ihtfp.com>
> Sent: Freitag, 2. Juni 2023 15:27
> To: alorbach@adiscon.com
> Cc: rsyslog-users <rsyslog@lists.adiscon.com>; Derek Atkins
> <derek@ihtfp.com>
> Subject: RE: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>
> Hi,
>
> On Fri, June 2, 2023 9:17 am, Andre Lorbach wrote:
> > Hi,
> >
> > There has been no change on nsd_ossl.c driver since January 2023, so I
> > believe this is not related to the different rsyslog versions you are
> > running.
> > The warnings tell you, that there is no client certificate configured
> > which can be ok but unusual in this setup. The get rid of them I would
> > recommend configuring a client certificate as well.
>
> I'm not using client-authentication, which is why there is no client cert.
> Not sure why you consider it "unusual". But that's not the error I am
> concerned about.

That is ok, but you will only have anon ciphers if you do not use a client
side certificate.

> > Regarding the SSL_ERROR_SYSCALL, it indicates a lower system level
> > error which is 104 in your case. 104 means "Connection Reset by peer",
> > so most likely the server dropped the client during handshake for some
> reason.
> > To tell more I would have to see debug log from the server.
>
> I wonder if there was some middleware that was doing something? I used
> "openssl s_client" to connect to the server and it worked, and shortly
> thereafter rsyslog started working too.

Indeed, that's odd. If it happens again, I would be interested in the
server-side error logged at the same time.

Best regards,
Andre Lorbach
--
Adiscon GmbH
Mozartstr. 21
97950 Großrinderfeld, Germany
Ph. +49-9349-9298530
Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB
560610
Ust.-IDNr.: DE 81 22 04 622
Web: www.adiscon.com - Mail: info@adiscon.com

Informations regarding your data privacy policy can be found here:
https://www.adiscon.com/data-privacy-policy/

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient or have received this e-mail in error please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren und die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
HI,

On Fri, June 2, 2023 10:07 am, Andre Lorbach wrote:
>> -----Original Message-----
>> From: Derek Atkins <derek@ihtfp.com>
>> Sent: Freitag, 2. Juni 2023 15:27
>> To: alorbach@adiscon.com
>> Cc: rsyslog-users <rsyslog@lists.adiscon.com>; Derek Atkins
>> <derek@ihtfp.com>
>> Subject: RE: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>>
>>
>> I'm not using client-authentication, which is why there is no client
>> cert.
>> Not sure why you consider it "unusual". But that's not the error I am
>> concerned about.
>
> That is ok, but you will only have anon ciphers if you do not use a client
> side certificate.

Yes, I know -- but setting up the client certs would be an added overhead
to the system.

>> > Regarding the SSL_ERROR_SYSCALL, it indicates a lower system level
>> > error which is 104 in your case. 104 means "Connection Reset by peer",
>> > so most likely the server dropped the client during handshake for some
>> reason.
>> > To tell more I would have to see debug log from the server.
>>
>> I wonder if there was some middleware that was doing something? I used
>> "openssl s_client" to connect to the server and it worked, and shortly
>> thereafter rsyslog started working too.
>
> Indeed, that's odd. If it happens again, I would be interested in the
> server-side error logged at the same time.

Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SYSCALL Error in
'osslRecordRecv': 'error:00000005:lib(0):func(0):DH lib(5)' with ret=-1,
errno=104, sslapi='SSL_read' [v8.2208.0]
Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: netstream session
0x7fe3f411f3b0 from <source> will be closed due to error [v8.2208.0]
Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SSL Error in
'osslEndSess': 'error:00000001:lib(0):func(0):reason(1)(1)' with ret=-1,
errno=0, sslapi='SSL_shutdown' [v8.2208.0]
Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: nsd_ossl:OpenSSL Error Stack:
error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
[v8.2208.0]
Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: nsd_ossl: TLS session
terminated successfully to remote syslog server '<source>' with SSL Error
'-1': End Session [v8.2208.0]


-derek

--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
> On Fri, June 2, 2023 10:07 am, Andre Lorbach wrote:
> >> -----Original Message-----
> >> From: Derek Atkins <derek@ihtfp.com>
> >> Sent: Freitag, 2. Juni 2023 15:27
> >> To: alorbach@adiscon.com
> >> Cc: rsyslog-users <rsyslog@lists.adiscon.com>; Derek Atkins
> >> <derek@ihtfp.com>
> >> Subject: RE: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
> >>
> >>
> >> I'm not using client-authentication, which is why there is no client
> >> cert.
> >> Not sure why you consider it "unusual". But that's not the error I
> >> am concerned about.
> >
> > That is ok, but you will only have anon ciphers if you do not use a
> > client side certificate.
>
> Yes, I know -- but setting up the client certs would be an added overhead
> to
> the system.

You could use the same client certificate on all clients, it's not that
uncommon.

> >> > Regarding the SSL_ERROR_SYSCALL, it indicates a lower system level
> >> > error which is 104 in your case. 104 means "Connection Reset by
> >> > peer", so most likely the server dropped the client during
> >> > handshake for some
> >> reason.
> >> > To tell more I would have to see debug log from the server.
> >>
> >> I wonder if there was some middleware that was doing something? I
> >> used "openssl s_client" to connect to the server and it worked, and
> >> shortly thereafter rsyslog started working too.
> >
> > Indeed, that's odd. If it happens again, I would be interested in the
> > server-side error logged at the same time.
>
> Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SYSCALL Error in
> 'osslRecordRecv': 'error:00000005:lib(0):func(0):DH lib(5)' with ret=-1,
> errno=104, sslapi='SSL_read' [v8.2208.0] Jun 1 12:56:33 ip-172-31-18-117
> rsyslogd: netstream session
> 0x7fe3f411f3b0 from <source> will be closed due to error [v8.2208.0] Jun
> 1
> 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SSL Error in
> 'osslEndSess': 'error:00000001:lib(0):func(0):reason(1)(1)' with ret=-1,
> errno=0, sslapi='SSL_shutdown' [v8.2208.0] Jun 1 12:56:33 ip-172-31-18-
> 117 rsyslogd: nsd_ossl:OpenSSL Error Stack:
> error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
> [v8.2208.0] Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: nsd_ossl: TLS
> session
> terminated successfully to remote syslog server '<source>' with SSL Error
> '-1': End Session [v8.2208.0]

Is that from Server? I would expect an error about failed finding a shared
cipher. That looks like a NON-TLS Connection attempt.

Best regards,
Andre Lorbach
--
Adiscon GmbH
Mozartstr. 21
97950 Großrinderfeld, Germany
Ph. +49-9349-9298530
Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB
560610
Ust.-IDNr.: DE 81 22 04 622
Web: www.adiscon.com - Mail: info@adiscon.com

Informations regarding your data privacy policy can be found here:
https://www.adiscon.com/data-privacy-policy/

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient or have received this e-mail in error please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren und die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
On 5.06.2023 09:23, Andre Lorbach via rsyslog wrote:
>> On Fri, June 2, 2023 10:07 am, Andre Lorbach wrote:
>>>> -----Original Message-----
>>>> From: Derek Atkins <derek@ihtfp.com>
>>>> Sent: Freitag, 2. Juni 2023 15:27
>>>> To: alorbach@adiscon.com
>>>> Cc: rsyslog-users <rsyslog@lists.adiscon.com>; Derek Atkins
>>>> <derek@ihtfp.com>
>>>> Subject: RE: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>>>>
>>>>
>>>> I'm not using client-authentication, which is why there is no client
>>>> cert.
>>>> Not sure why you consider it "unusual". But that's not the error I
>>>> am concerned about.
>>> That is ok, but you will only have anon ciphers if you do not use a
>>> client side certificate.
>> Yes, I know -- but setting up the client certs would be an added overhead
>> to
>> the system.
> You could use the same client certificate on all clients, it's not that
> uncommon.

It might be common, but it's wrong. If you're using cert-based
authentication, reusing the same certificate is effectively defeating
the purpose. True, in some specific use cases it might be OK but a
decision to do so should be preceeded by risk analysis. In general -
using the same cryptographic material to mass-authenticate multiple
clients does not differ significantly from not authenticating them at all.

It all depends on what you want to achieve. If you just want to limit
who can send to your "collector", you can as well do it with firewall
and drop the encryption completely (maybe saving some CPU cycles on the
way). If you want to have at least a bit of authentication of the actual
subject sending (and have some level of non-repudiation), you need
individual certs per subject.

YMMV of course

MK


_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
> It might be common, but it's wrong. If you're using cert-based
> authentication, reusing the same certificate is effectively defeating
> the purpose. True, in some specific use cases it might be OK but a
> decision to do so should be preceeded by risk analysis. In general -
> using the same cryptographic material to mass-authenticate multiple
> clients does not differ significantly from not authenticating them at all.

I basically agree. There seems to be a common use case, with
vendor-provided monitoring devices where the customer has no real
access. I've often seen this used in those settings. But: it's
definitely not as secure as it (c|sh)ould be ;-)

Just my 2cts
Rainer
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
Derek, Andre,

> > There has been no change on nsd_ossl.c driver since January 2023, so I
> > believe this is not related to the different rsyslog versions you are
> > running.
> > The warnings tell you, that there is no client certificate configured
> > which
> > can be ok but unusual in this setup. The get rid of them I would recommend
> > configuring a client certificate as well.
>
> I'm not using client-authentication, which is why there is no client cert.
> Not sure why you consider it "unusual". But that's not the error I am
> concerned about.

Derek: I agree and would actually say it is a common scenario.

Andre: For that reason, I think we should at most emit an "info"
message if it is not set. Not sure what the gtls driver does, but that
doesn't really matter - it may need to be changed as well.

Also: I think that when server side cert is in place, we are NOT
limited to anon ciphers! The server provides its public key, and if I
am not totally mistaken, that should be sufficient to use all ciphers,
including async ones.

Of course, without client cert, we have one-way anon traffic and
cannot detect man in the middle.

Am I wrong?

Rainer
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
HI,

On Mon, June 5, 2023 4:21 am, Rainer Gerhards wrote:
> Derek, Andre,
>
>> > There has been no change on nsd_ossl.c driver since January 2023, so I
>> > believe this is not related to the different rsyslog versions you are
>> > running.
>> > The warnings tell you, that there is no client certificate configured
>> > which
>> > can be ok but unusual in this setup. The get rid of them I would
>> recommend
>> > configuring a client certificate as well.
>>
>> I'm not using client-authentication, which is why there is no client
>> cert.
>> Not sure why you consider it "unusual". But that's not the error I am
>> concerned about.
>
> Derek: I agree and would actually say it is a common scenario.

In my case, I am just looking for confidentiality, not client
authentication. I know the server's CA cert so I can install that into
the clients.

> Andre: For that reason, I think we should at most emit an "info"
> message if it is not set. Not sure what the gtls driver does, but that
> doesn't really matter - it may need to be changed as well.
>
> Also: I think that when server side cert is in place, we are NOT
> limited to anon ciphers! The server provides its public key, and if I
> am not totally mistaken, that should be sufficient to use all ciphers,
> including async ones.
>
> Of course, without client cert, we have one-way anon traffic and
> cannot detect man in the middle.
>
> Am I wrong?
>
> Rainer


Andre,

>> Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SYSCALL Error in
>> 'osslRecordRecv': 'error:00000005:lib(0):func(0):DH lib(5)' with ret=-1,
>> errno=104, sslapi='SSL_read' [v8.2208.0] Jun 1 12:56:33
>> ip-172-31-18-117
>> rsyslogd: netstream session
>> 0x7fe3f411f3b0 from <source> will be closed due to error [v8.2208.0] Jun
>> 1
>> 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SSL Error in
>> 'osslEndSess': 'error:00000001:lib(0):func(0):reason(1)(1)' with ret=-1,
>> errno=0, sslapi='SSL_shutdown' [v8.2208.0] Jun 1 12:56:33
>> ip-172-31-18-
>> 117 rsyslogd: nsd_ossl:OpenSSL Error Stack:
>> error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
>> [v8.2208.0] Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: nsd_ossl: TLS
>> session
>> terminated successfully to remote syslog server '<source>' with SSL
>> Error
>> '-1': End Session [v8.2208.0]
>
> Is that from Server? I would expect an error about failed finding a shared
> cipher. That looks like a NON-TLS Connection attempt.
>

Yes, this is from the Server. It might be the same underlying issue,
errno 104.

Perhaps there was a firewall at the installation site that was blocking
packets?

-derek

--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Omfwd OpenSSL TLS fails on 2023.04.0 [ In reply to ]
> -----Original Message-----
> From: Derek Atkins <derek@ihtfp.com>
> Sent: Montag, 5. Juni 2023 14:00
> To: Rainer Gerhards <rgerhards@hq.adiscon.com>
> Cc: rsyslog-users <rsyslog@lists.adiscon.com>; alorbach@adiscon.com; Derek
> Atkins <derek@ihtfp.com>
> Subject: Re: [rsyslog] Omfwd OpenSSL TLS fails on 2023.04.0
>
>
> >> Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SYSCALL Error in
> >> 'osslRecordRecv': 'error:00000005:lib(0):func(0):DH lib(5)' with
> >> ret=-1, errno=104, sslapi='SSL_read' [v8.2208.0] Jun 1 12:56:33
> >> ip-172-31-18-117
> >> rsyslogd: netstream session
> >> 0x7fe3f411f3b0 from <source> will be closed due to error [v8.2208.0]
> >> Jun
> >> 1
> >> 12:56:33 ip-172-31-18-117 rsyslogd: SSL_ERROR_SSL Error in
> >> 'osslEndSess': 'error:00000001:lib(0):func(0):reason(1)(1)' with
> >> ret=-1, errno=0, sslapi='SSL_shutdown' [v8.2208.0] Jun 1 12:56:33
> >> ip-172-31-18-
> >> 117 rsyslogd: nsd_ossl:OpenSSL Error Stack:
> >> error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
> >> [v8.2208.0] Jun 1 12:56:33 ip-172-31-18-117 rsyslogd: nsd_ossl: TLS
> >> session terminated successfully to remote syslog server '<source>'
> >> with SSL Error
> >> '-1': End Session [v8.2208.0]
> >
> > Is that from Server? I would expect an error about failed finding a
> > shared cipher. That looks like a NON-TLS Connection attempt.
> >
>
> Yes, this is from the Server. It might be the same underlying issue,
> errno 104.
>
> Perhaps there was a firewall at the installation site that was blocking
> packets?

104 means "Connection Reset by peer" which I would expect if the remote site
closed the connection for some reason during TLS Handshake. Most likely
because no Shared Cipher could be determined.

IF you could run a client with debug logging enabled, and look for
"osslPostHandshakeCheck" output, this would be helpful.


Best regards,
Andre Lorbach
--
Adiscon GmbH
Mozartstr. 21
97950 Großrinderfeld, Germany
Ph. +49-9349-9298530
Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB
560610
Ust.-IDNr.: DE 81 22 04 622
Web: www.adiscon.com - Mail: info@adiscon.com

Informations regarding your data privacy policy can be found here:
https://www.adiscon.com/data-privacy-policy/

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient or have received this e-mail in error please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.