On Fri, Jul 25, 2003 at 09:18:52AM -0400, Jue (Jacky) Shu wrote: > 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'd say own keys. Sharing them is a very bad idea. Please note certificates are sent "in clear" while SSL handshake so they should be considered public info > (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. Some more passwords and keys may be used at application level to hedge the risk and they can also be lost. That is, loosing any key makes a better chance to get in trouble and it happens sometime, isnt it? Please consider signed DNS (forward-type zone) in case you'd like to verify IP address > > 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] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
