Subject: RE: [Syslog] Summary of the syslog/tls issues resolving

From: Miao Fuyou <[email-masked]>
Date: Mon, 08 May 2006 14:20:00 +0800

Yes, we need. But, it may not harm. The scenario may look like this:

Client already has the locally stored hostname/url of a Syslog server(A). It
sends a resolution request to DNS server, then get an IP from DNS server.
When the response is falsified by an attacker, the IP address is fake, in
fact the IP address is for Syslog server B. After client starts to talk to
server B using the fake IP address, it gets B's certificate. There is
hostname in the certificate. Client finds the hostname (B) in the
certificate and locally stored hostname (A) are not consistent, then it
disconnect the TLS connection. This is correct Syslog/TLS behavior we
expected. 
 
One may argue that server B may send a certificate with Server A's hostname
in its CN/SubjectAltName. In such case, there must be something wrong at CA
when issuing certificate or private key for the certificate is compromised.
It's CA or Certificate owner's job to make it correct. Syslog/TLS can do
nothing in this case.

> -----Original Message-----
> From: Balazs Scheidler [mailto:[email-masked]] 
> Sent: Sunday, April 30, 2006 9:15 PM
> To: Miao Fuyou
> Cc: 'David B Harrington'; [email-masked]
> Subject: RE: [Syslog] Summary of the syslog/tls issues resolving
> 
> On Sun, 2006-04-30 at 17:30 +0800, Miao Fuyou wrote:
> > Another problem of using DNS is: name resolution itself is 
> not secure 
> > if DNSSEC is not used (true im most cases). Dependency on DNS may 
> > introduce new security vulnerable to Syslog/TLS.
> > 
> > Client should use knowledge a priori to check server's certificate, 
> > such as URL, if it is available.
> 
> Yes, you need forward DNS resolution in this case too. (e.g. 
> hostname in URL -> IP address)
> 
> --
> Bazsi
> 
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog