You are right. A trusted list of server names at the client (hard coded in a
config file) would be sufficient. The only downside of it would be for the
domain admin to touch up this file each time he/she modifies the LDAP SRV
list in DNS. Also note that we have absolutely no control on what goes
Hi!
* sandeep kiran p wrote on Wed, Aug 11, 2010 at 20:36 -0700:
Ours is an LDAP client application that fetches LDAP server names on
the fly using DNS SRV Resource Records. We then randomly pick one the
servers returned from DNS, establish an SSL/TLS connection with that
server and then
sandeep kiran p wrote:
Ours is an LDAP client application that fetches LDAP server names on the fly
using DNS SRV Resource Records. We then randomly pick one the servers
returned from DNS, establish an SSL/TLS connection with that server and then
perform a bind operation using user credentials
Hi there:
It would seem that the solution to this is inherent in how you built this. If
the client is in control of which trust anchors are used (and uses a
restricted set, instead of the anything goes list that you get with most
distributions and or Operating systems), then you SHOULD be able
Of sandeep kiran p
Sent: August 12, 2010 07:58
To: openssl-users@openssl.org
Subject: Re: SSL/TLS with server names picked from DNS
We dont have any control on how the server generates its certificates.
As said earlier, we only control the client portion of SSL/TLS. Sites
where our client application runs
On 12-08-2010 05:36, sandeep kiran p wrote:
Hi,
Ours is an LDAP client application that fetches LDAP server names on the fly
using DNS SRV Resource Records. We then randomly pick one the servers
returned from DNS, establish an SSL/TLS connection with that server and then
perform a bind
On Wed, Aug 11, 2010 at 11:36 PM, sandeep kiran p
sandeepkir...@gmail.comwrote:
[ ... ]
Client would then blindly establish an SSL/TLS connection with that server
and would end up handing over the user credentials to it. Note that, as part
of the SSL handshake, the malicious serve would
We dont have any control on how the server generates its certificates. As
said earlier, we only control the client portion of SSL/TLS. Sites where our
client application runs, is handed over the location where trusted CA certs
are stored and thats all we have.
Secondly, as you pointed out, if we
Sandeep Kiran P wrote:
We dont have any control on how the server generates its certificates.
As said earlier, we only control the client portion of SSL/TLS.
Sites where our client application runs, is handed over the location
where trusted CA certs are stored and thats all we have.
We will have to check if all our sites are ready to accommodate the list of
servers file which will be fetched securely. They should also be ready to
update that list each time a server is added or removed from DNS SRV
records.
I am not sure if I got your second option. You said that I should be
In the case of a DNS attack, the only information that your users can rely upon
is information which comes out of the PKI. If your attackers can attack both
DNS and the PKI, then you're 0wned, game over.
Otherwise, if DNS is completely attacked but you can still have some trust in
the PKI,
11 matches
Mail list logo
