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 running a validation service on each server. Fine I can do that. But how can the common name be validated? The attacker modifies the DNS SRV response and inserts a name which is similar to the common name attribute in the certificate that the malicious server forwards to the client. This name is also similar to the hostname where the malicious server is running. In such a case, even if I run some validation service, won't the names match? Thanks, Sandeep On Thu, Aug 12, 2010 at 4:25 PM, David Schwartz <dav...@webmaster.com>wrote: > 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. > > > Secondly, as you pointed out, if we were to maintain a list of > > legitimate server certs, we could have as well maintained a list of > > server names at the client. The advantage with using DNS SRV RR is, > > a domain admin can add or remove servers without having to make any > > changes to the affected client applications. > > There are a few fairly obvious solutions to this problem. Just pick > whichever one of them is the least awful for your application. > > You could, for example, reserve a particular domain name known to the > client > just for securely retrieving the list of authorized common names for > servers. The client can securely retrieve something like: > 'https://serverlist.mydomain.com/server.list.txt'. Then it can still use > SRV > records to find servers but ignore the servers if the list doesn't appear > in > the server.list file. > > This adds only a slight administrative burden in running a secure web > server > that serves the server list file and in adding a new server's name to that > file. > > You could also run a validation service on each server. The client, when > told to use a particular server, would simply confirm the validation > service > is present on that server. Just make sure the validation service can't be > MITMed. (Easily done by ensuring the validation process validates the > server's common name.) > > DS > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
