Mailing List Archive

TLS certificates
Why does the documentation state that a client does not need to include
its private key and certificate in its configuration? It says to only
use the CA public certificate (ca.pem).

Peter
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
2008/12/1 Peter Matulis <peter.matulis@canonical.com>:
> Why does the documentation state that a client does not need to include
> its private key and certificate in its configuration? It says to only
> use the CA public certificate (ca.pem).

That depends on what you want to do.

If you only want to verify, that a client is sending it's messages to
the right server, then it only needs the CA to verify that.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
Michael Biebl wrote:
> 2008/12/1 Peter Matulis <peter.matulis@canonical.com>:
>> Why does the documentation state that a client does not need to include
>> its private key and certificate in its configuration? It says to only
>> use the CA public certificate (ca.pem).
>
> That depends on what you want to do.
>
> If you only want to verify, that a client is sending it's messages to
> the right server, then it only needs the CA to verify that.
>
> Michael
>


Right. I want to encrypt.

Peter
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
On Mon, Dec 1, 2008 at 13:04, Peter Matulis <peter.matulis@canonical.com> wrote:
> Right. I want to encrypt.

Encryption is still possible without a client certificate. Generally
speaking, in SSL all a client cert adds is the ability for the server
to verify the client's identity at the transport layer.


RB
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
Jupp. I'd also like to mention the more elaborate guide. It is part of
the doc set, but also available online:

http://www.rsyslog.com/doc-rsyslog_secure_tls.html

Rainer

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com
> [mailto:rsyslog-bounces@lists.adiscon.com] On Behalf Of RB
> Sent: Monday, December 01, 2008 9:08 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] TLS certificates
>
> On Mon, Dec 1, 2008 at 13:04, Peter Matulis
> <peter.matulis@canonical.com> wrote:
> > Right. I want to encrypt.
>
> Encryption is still possible without a client certificate. Generally
> speaking, in SSL all a client cert adds is the ability for the server
> to verify the client's identity at the transport layer.
>
>
> RB
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
I has reading the docs [1] and this confusd me to. It says

"neither the client nor the server are authenticated. So while the
message transfer is encrypted, you can not be sure which peer you are
talking to"

Also, how can client encrypt without having any keys specified in its config?

Example for the client shows:

$DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
$ActionSendStreamDriverAuthMode anon # server is NOT authenticated

2nd question: Why is the server not authenticated?

/juan

[1] http://www.rsyslog.com/doc-rsyslog_tls.html
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com> wrote:
> "neither the client nor the server are authenticated. So while the
> message transfer is encrypted, you can not be sure which peer you are
> talking to"

I'm hoping Rainer will jump in and clarify precisely how much
handshake validation he's implemented. The fact that the client must
have a copy of the CA's public material seems to indicate he is at
least verifying that the server's certificate was issued by the CA.
It's possible to not do so, but the result is rather susceptible to
MITM.

> Also, how can client encrypt without having any keys specified in its config?

This isn't the forum to discuss the particulars of the SSL handshake,
but suffice it to say that SSL incorporates a challenge/response
mechanism (using the server's presented certificate) followed by
negotiation of an ephemeral session key. See also: public-key
cryptography.

> $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
> $ActionSendStreamDriverAuthMode anon # server is NOT authenticated
>
> 2nd question: Why is the server not authenticated?

Without looking at the code, I presume the 'anon' AuthMode is the
switch used to tell the SSL library whether or not to check the server
certificate against the CA. If so, it should make specifying the CA
public key redundant - the client just accepts whatever certificate
the server (or MITM) presents and starts encrypting to it.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of RB
> Sent: Tuesday, December 02, 2008 4:57 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] TLS certificates
>
> On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com> wrote:
> > "neither the client nor the server are authenticated. So while the
> > message transfer is encrypted, you can not be sure which peer you
are
> > talking to"
>
> I'm hoping Rainer will jump in and clarify precisely how much
> handshake validation he's implemented. The fact that the client must
> have a copy of the CA's public material seems to indicate he is at
> least verifying that the server's certificate was issued by the CA.
> It's possible to not do so, but the result is rather susceptible to
> MITM.

Just a quick note, I am quite busy at the moment (guess what ;)). If the
auth is set to "anon" nothing at all is validated and MITM *is*
absolutely possible. That's why the doc does not recommend to use that
mode. I posted a link to the long TLS setup guide, which creates a
fairly safe scenario (but your milage may vary... ;)).

>
> > Also, how can client encrypt without having any keys specified in
its
> config?
>
> This isn't the forum to discuss the particulars of the SSL handshake,
> but suffice it to say that SSL incorporates a challenge/response
> mechanism (using the server's presented certificate) followed by
> negotiation of an ephemeral session key. See also: public-key
> cryptography.
>
> > $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
> > $ActionSendStreamDriverAuthMode anon # server is NOT authenticated
> >
> > 2nd question: Why is the server not authenticated?
>
> Without looking at the code, I presume the 'anon' AuthMode is the
> switch used to tell the SSL library whether or not to check the server
> certificate against the CA. If so, it should make specifying the CA
> public key redundant - the client just accepts whatever certificate
> the server (or MITM) presents and starts encrypting to it.

The modes are mostly rooted in the upcoming RFC5225 (or 5226, don't
remember correctly). Anon is an insecure extension. While being
insecure, it is a mode that allows low end devices deployed in
no-knowledge environmebnt (hopefully read: home users) to have at least
the benefit of encryption (obfuscation would be more precise) but
nothing (nothing!) above that.

Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
On Tue, Dec 2, 2008 at 09:00, Rainer Gerhards <rgerhards@hq.adiscon.com> wrote:
> Just a quick note, I am quite busy at the moment (guess what ;)). If the
> auth is set to "anon" nothing at all is validated and MITM *is*
> absolutely possible. That's why the doc does not recommend to use that
> mode. I posted a link to the long TLS setup guide, which creates a
> fairly safe scenario (but your milage may vary... ;)).

Understood. For everyone else's edification, here is the comment in
the related code, outlining what modes are used:

/* Set the authentication mode. For us, the following is supported:
* anon - no certificate checks whatsoever (discouraged, but
supported)
* x509/certvalid - (just) check certificate validity
* x509/fingerprint - certificate fingerprint
* x509/name - cerfificate name check
* mode == NULL is valid and defaults to x509/name
* rgerhards, 2008-05-16
*/
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
2008/12/2 RB <aoz.syn@gmail.com>:
> On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com> wrote:
>> "neither the client nor the server are authenticated. So while the
>> message transfer is encrypted, you can not be sure which peer you are
>> talking to"
>
> I'm hoping Rainer will jump in and clarify precisely how much
> handshake validation he's implemented. The fact that the client must
> have a copy of the CA's public material seems to indicate he is at
> least verifying that the server's certificate was issued by the CA.
> It's possible to not do so, but the result is rather susceptible to
> MITM.
>
>> Also, how can client encrypt without having any keys specified in its config?
>
> This isn't the forum to discuss the particulars of the SSL handshake,
> but suffice it to say that SSL incorporates a challenge/response
> mechanism (using the server's presented certificate) followed by
> negotiation of an ephemeral session key. See also: public-key
> cryptography.
>
>> $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
>> $ActionSendStreamDriverAuthMode anon # server is NOT authenticated
>>
>> 2nd question: Why is the server not authenticated?
>
> Without looking at the code, I presume the 'anon' AuthMode is the
> switch used to tell the SSL library whether or not to check the server
> certificate against the CA. If so, it should make specifying the CA
> public key redundant - the client just accepts whatever certificate
> the server (or MITM) presents and starts encrypting to it.

Thank you. I change my config and logging is hapenning on the server
end. However, I get such lines in the logs on the server end when I
restart the client system:

invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 42
invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 45
invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 46
invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 47
invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 49
invalid or yet-unknown config file command - have you forgotten to
load a module?
the last error occured in /etc/rsyslog.conf, line 51


This happens for each TLS line in my client config (comments removed):

$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /home/client/Data/tls/ca/ca.pem
$DefaultNetstreamDriverCertFile /home/client/Data/tls/client/client-cert.pem
$DefaultNetstreamDriverKeyFile /home/client/Data/tls/client/client-key.pem
$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverMode 1
*.* @@192.168.4.102:10514


/juan
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
Too old version?

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Juan Miscaro
> Sent: Tuesday, December 02, 2008 5:31 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] TLS certificates
>
> 2008/12/2 RB <aoz.syn@gmail.com>:
> > On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com>
> wrote:
> >> "neither the client nor the server are authenticated. So while the
> >> message transfer is encrypted, you can not be sure which peer you
> are
> >> talking to"
> >
> > I'm hoping Rainer will jump in and clarify precisely how much
> > handshake validation he's implemented. The fact that the client
must
> > have a copy of the CA's public material seems to indicate he is at
> > least verifying that the server's certificate was issued by the CA.
> > It's possible to not do so, but the result is rather susceptible to
> > MITM.
> >
> >> Also, how can client encrypt without having any keys specified in
> its config?
> >
> > This isn't the forum to discuss the particulars of the SSL
handshake,
> > but suffice it to say that SSL incorporates a challenge/response
> > mechanism (using the server's presented certificate) followed by
> > negotiation of an ephemeral session key. See also: public-key
> > cryptography.
> >
> >> $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
> >> $ActionSendStreamDriverAuthMode anon # server is NOT authenticated
> >>
> >> 2nd question: Why is the server not authenticated?
> >
> > Without looking at the code, I presume the 'anon' AuthMode is the
> > switch used to tell the SSL library whether or not to check the
> server
> > certificate against the CA. If so, it should make specifying the CA
> > public key redundant - the client just accepts whatever certificate
> > the server (or MITM) presents and starts encrypting to it.
>
> Thank you. I change my config and logging is hapenning on the server
> end. However, I get such lines in the logs on the server end when I
> restart the client system:
>
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 42
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 45
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 46
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 47
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 49
> invalid or yet-unknown config file command - have you forgotten to
> load a module?
> the last error occured in /etc/rsyslog.conf, line 51
>
>
> This happens for each TLS line in my client config (comments removed):
>
> $DefaultNetstreamDriver gtls
> $DefaultNetstreamDriverCAFile /home/client/Data/tls/ca/ca.pem
> $DefaultNetstreamDriverCertFile /home/client/Data/tls/client/client-
> cert.pem
> $DefaultNetstreamDriverKeyFile /home/client/Data/tls/client/client-
> key.pem
> $ActionSendStreamDriverAuthMode x509/name
> $ActionSendStreamDriverMode 1
> *.* @@192.168.4.102:10514
>
>
> /juan
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
My boxes are running 3.18.1

/juan

2008/12/2 Rainer Gerhards <rgerhards@hq.adiscon.com>:
> Too old version?
>
>> -----Original Message-----
>> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
>> bounces@lists.adiscon.com] On Behalf Of Juan Miscaro
>> Sent: Tuesday, December 02, 2008 5:31 PM
>> To: rsyslog-users
>> Subject: Re: [rsyslog] TLS certificates
>>
>> 2008/12/2 RB <aoz.syn@gmail.com>:
>> > On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com>
>> wrote:
>> >> "neither the client nor the server are authenticated. So while the
>> >> message transfer is encrypted, you can not be sure which peer you
>> are
>> >> talking to"
>> >
>> > I'm hoping Rainer will jump in and clarify precisely how much
>> > handshake validation he's implemented. The fact that the client
> must
>> > have a copy of the CA's public material seems to indicate he is at
>> > least verifying that the server's certificate was issued by the CA.
>> > It's possible to not do so, but the result is rather susceptible to
>> > MITM.
>> >
>> >> Also, how can client encrypt without having any keys specified in
>> its config?
>> >
>> > This isn't the forum to discuss the particulars of the SSL
> handshake,
>> > but suffice it to say that SSL incorporates a challenge/response
>> > mechanism (using the server's presented certificate) followed by
>> > negotiation of an ephemeral session key. See also: public-key
>> > cryptography.
>> >
>> >> $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
>> >> $ActionSendStreamDriverAuthMode anon # server is NOT authenticated
>> >>
>> >> 2nd question: Why is the server not authenticated?
>> >
>> > Without looking at the code, I presume the 'anon' AuthMode is the
>> > switch used to tell the SSL library whether or not to check the
>> server
>> > certificate against the CA. If so, it should make specifying the CA
>> > public key redundant - the client just accepts whatever certificate
>> > the server (or MITM) presents and starts encrypting to it.
>>
>> Thank you. I change my config and logging is hapenning on the server
>> end. However, I get such lines in the logs on the server end when I
>> restart the client system:
>>
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 42
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 45
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 46
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 47
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 49
>> invalid or yet-unknown config file command - have you forgotten to
>> load a module?
>> the last error occured in /etc/rsyslog.conf, line 51
>>
>>
>> This happens for each TLS line in my client config (comments removed):
>>
>> $DefaultNetstreamDriver gtls
>> $DefaultNetstreamDriverCAFile /home/client/Data/tls/ca/ca.pem
>> $DefaultNetstreamDriverCertFile /home/client/Data/tls/client/client-
>> cert.pem
>> $DefaultNetstreamDriverKeyFile /home/client/Data/tls/client/client-
>> key.pem
>> $ActionSendStreamDriverAuthMode x509/name
>> $ActionSendStreamDriverMode 1
>> *.* @@192.168.4.102:10514
>>
>>
>> /juan
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
Re: TLS certificates [ In reply to ]
Jup, that's the problem.

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Juan Miscaro
> Sent: Tuesday, December 02, 2008 5:40 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] TLS certificates
>
> My boxes are running 3.18.1
>
> /juan
>
> 2008/12/2 Rainer Gerhards <rgerhards@hq.adiscon.com>:
> > Too old version?
> >
> >> -----Original Message-----
> >> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> >> bounces@lists.adiscon.com] On Behalf Of Juan Miscaro
> >> Sent: Tuesday, December 02, 2008 5:31 PM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] TLS certificates
> >>
> >> 2008/12/2 RB <aoz.syn@gmail.com>:
> >> > On Tue, Dec 2, 2008 at 06:55, Juan Miscaro <jmiscaro@gmail.com>
> >> wrote:
> >> >> "neither the client nor the server are authenticated. So while
> the
> >> >> message transfer is encrypted, you can not be sure which peer
you
> >> are
> >> >> talking to"
> >> >
> >> > I'm hoping Rainer will jump in and clarify precisely how much
> >> > handshake validation he's implemented. The fact that the client
> > must
> >> > have a copy of the CA's public material seems to indicate he is
at
> >> > least verifying that the server's certificate was issued by the
> CA.
> >> > It's possible to not do so, but the result is rather susceptible
> to
> >> > MITM.
> >> >
> >> >> Also, how can client encrypt without having any keys specified
in
> >> its config?
> >> >
> >> > This isn't the forum to discuss the particulars of the SSL
> > handshake,
> >> > but suffice it to say that SSL incorporates a challenge/response
> >> > mechanism (using the server's presented certificate) followed by
> >> > negotiation of an ephemeral session key. See also: public-key
> >> > cryptography.
> >> >
> >> >> $DefaultNetstreamDriverCAFile /path/to/contrib/gnutls/ca.pem
> >> >> $ActionSendStreamDriverAuthMode anon # server is NOT
> authenticated
> >> >>
> >> >> 2nd question: Why is the server not authenticated?
> >> >
> >> > Without looking at the code, I presume the 'anon' AuthMode is the
> >> > switch used to tell the SSL library whether or not to check the
> >> server
> >> > certificate against the CA. If so, it should make specifying the
> CA
> >> > public key redundant - the client just accepts whatever
> certificate
> >> > the server (or MITM) presents and starts encrypting to it.
> >>
> >> Thank you. I change my config and logging is hapenning on the
> server
> >> end. However, I get such lines in the logs on the server end when
I
> >> restart the client system:
> >>
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 42
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 45
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 46
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 47
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 49
> >> invalid or yet-unknown config file command - have you forgotten to
> >> load a module?
> >> the last error occured in /etc/rsyslog.conf, line 51
> >>
> >>
> >> This happens for each TLS line in my client config (comments
> removed):
> >>
> >> $DefaultNetstreamDriver gtls
> >> $DefaultNetstreamDriverCAFile /home/client/Data/tls/ca/ca.pem
> >> $DefaultNetstreamDriverCertFile
/home/client/Data/tls/client/client-
> >> cert.pem
> >> $DefaultNetstreamDriverKeyFile /home/client/Data/tls/client/client-
> >> key.pem
> >> $ActionSendStreamDriverAuthMode x509/name
> >> $ActionSendStreamDriverMode 1
> >> *.* @@192.168.4.102:10514
> >>
> >>
> >> /juan
> >> _______________________________________________
> >> rsyslog mailing list
> >> http://lists.adiscon.net/mailman/listinfo/rsyslog
> >> http://www.rsyslog.com
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com
> >
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com