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 in
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 p
openssl.org] On Behalf 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 ou
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 abl
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 credenti
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, yo
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 r
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.
> Se
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 w
On Wed, Aug 11, 2010 at 11:36 PM, sandeep kiran p
wrote:
[ ... ]
> 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 provide a certificate signe
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 operation
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 operation using user credentials (DN and password). Use
12 matches
Mail list logo
