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, you can find some other way to ensure that the clients have the correct IPs. c:\windows\system32\drivers\etc\hosts or /etc/hosts would be good locations to consider modifying for this purpose. -Kyle H On Thu, Aug 12, 2010 at 8:20 PM, sandeep kiran p <sandeepkir...@gmail.com> wrote:
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-us...@openssl.org Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME Cryptographic Signature
