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
