Re: Avoiding man in the middle attacks
That is impossible. If you can't secure your Win9x client then you can never ever establish any kind of secure communication from that client. Security has to begin at the end points. After you secure the client's cerificate store you then use those certificates to secure the communication. Amanda. On Thu, 26 Oct 2000, Darío Mariani wrote: I'm still learning SSL. I still do no understand how does or if SSL/TSL prevents from a "man in the middle" attack. If the certificates are good, no problem. But, how does a client, or what must I do for a client to check the validity of a certificate, even a signed one from a trusted CA? My problem is this: I'm developing a client-server application (not web based), the clients will be in computers with Win9x, and for simplicity, the users won't know to wich server they are connecting to (they do not need to). I could have the server certificate and the server address in files in the client computer, but as Win9x security does not exist, nothing prevents someone from replacing these file for another server. I would apreciate any coments, thanks.
RE: Avoiding man in the middle attacks
Title: As somebody stated there is difference between authentication and authorization. Servers should be protected from "man in the middle" attacks via "Access Control" software which authorize access to files, servers, etc. via a triple combination of keys: FQDN (fully qualified domain name), TCP-IP address and user name (UID in Unix). Salvatore Ilardohttp://www.rokeby.com[EMAIL PROTECTED] -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]On Behalf Of Michael SierchioSent: Friday, October 27, 2000 3:30 PMTo: Greg StarkCc: [EMAIL PROTECTED]Subject: Re: Avoiding "man in the middle" attacksGreg Stark wrote: You need one more check. You need to check that the cert you are getting comes from the site you wanted to connect to.That's not part of the protocol, it's something browsers do forthe naive user -- and has nothing to do with the man-in-the-middleattack. If you accept the DN presented in the cert, and that'swho you want to communicate with, the DNS name is rather irrelevant.And the integrity of DNS is far less sound than the cert identityof the presenter.__OpenSSL Project http://www.openssl.orgUser Support Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
RE: Avoiding man in the middle attacks
Greg Stark wrote: As somebody stated there is difference between authentication and authorization. Servers should be protected from "man in the middle" attacks via "Access Control" software which authorize access to files, servers, etc. via a triple combination of keys: FQDN (fully qualified domain name), TCP-IP address and user name (UID in Unix). None of those things provide any protection from man-in-the-middle attacks. Just because I attempted to connect to 1.2.3.4, www.foo.com doesn't mean the machine I'm actually talking to is 1.2.3.4, www.foo.com. You have to assume the man in the middle has complete control over the middle. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Avoiding man in the middle attacks
Darío Mariani wrote: Hello: I'm still learning SSL. I still do no understand how does or if SSL/TSL prevents from a "man in the middle" attack. If the certificates are good, no problem. But, how does a client, or what must I do for a client to check the validity of a certificate, even a signed one from a trusted CA? 1) verify the signature on the cert to be sure it's a valid binding of the public key to the entity; 2) (optionally) check the latest CRL from the issuer to see if the cert has been revoked -- alternatively, use OCSP or Valicert for this; otherwise, assume (as browsers do) that the cert is valid if it is within the validity period. 3) a man in the middle can't provide POP (proof of possession of the private key), nor can he produce a valid MAC/signature for any message. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]