On 2003-07-24 at 18:43, David Schwartz wrote: > > > Please check this url: > > http://developer.netscape.com/docs/manuals/security/sslin/contents.htm > > Server authentication, step 4 > > The only difference is that netscape just check domain name. > > "Does the domain name in the server's certificate match the domain name of > the server itself? This step confirms that the server is actually located at > the same network address specified by the domain name in the server > certificate. Although step 4 is not technically part of the SSL protocol, it > provides the only protection against a form of security attack known as a > Man-in-the-Middle Attack. Clients must perform this step and must refuse to > authenticate the server or establish a connection if the domain names don't > match. If the server's actual domain name matches the domain name in the > server certificate, the client goes on to Step 5." > > As I suspected, you misunderstood it. This is NOT ABOUT DNS. This about > confirming that the server's name (the name you think you're talking to) > matches the name in the certificate. Well, if there is no DNS, how can you connect to a machine on the internet? If the DNS has been sabotaged, it won't lead you to the machine you want to connect. Yes, you will say that you still need to check DN, But even DNs match, it is still not enough for security. What's the difference between DN and FQDN? It is applciation related. If I'm sure that my application won't move from a machine to another, why can't I use FQDN? although it will limit application to a specific machine.
> Suppose I trust 'www.amazom.com'. I try to connect to 'www.amazon.com' and > get 210.3.4.9. I am then a certificate for 'www.evilhost.com'. I compare the > name of the server I am trying to speak to 'www.amazon.com' to the name in > the certificate 'www.evilhost.com'. If they don't match, I refuse the > connection. This is exactly what I was talking about. but not just this. In case you might misunderstand my question, I'd like to rephrase it here. Suppose I want to attack an online bank and managed to get the server's key (don't ask me why, i don't know either :-)). Through the certificate, I can know this key's DN (say domainA) or some extra information. Then I'll spoof DNS, make that domainA points to my machine. I'll preset a page to simulate a login screen on my machine. The clients will think that they are connecting to the real bank server, so I record their password, finally I can login to the real bank server after I restore DNS. This is what I'm trying to prevent. after shake-hand and authentication by SSL, it is still not safe enough. because other poople and I share some common secrets (key and certificate), but if secrets are comprised, (I know that people don't like this idea of losing key, but it happened before and will happen in the future) then I'm in trouble. My question is: can we find a solution to such a scenario? Such as application level authentication. Jacky > As Netscape puts it, "does the domain name in the server's certificate" > (www.evilhost.com in my example) "match the domain name of the server > itself" (www.amazon.com in my example). In this case they don't. So the > connection is refused (or, if you prefer, considered to be to/from > 'www.evilhost.com' rather than 'www.amazon.com') regardless of what DNS > says. > > > Why I suppose someone can get clients' key? > > because in my case, my clients are people without computer background. > > I'd like to believe them know how to keep their keys. > > But in case keys are comprised, shouldn't we think about any possible > > solution to against it? > > I could spend months explaining why this is wrong. But I strongly advise > you that you should take the word of the security experts who advise you > that this argument makes no sense. I would cite as further evidence that you > are in no position to maintain this claim against experts the fact that you > misunderstand the basic machinations of how Netscape's server validation > works. > > I'm not trying to be mean or rude. I'm just trying to stop you from doing > something really, really bad. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
