On 7/11/06, Nagareshwar Talekar <tnagareshwar@gmail.com > wrote:
Hi List,
Thank you for the information. It was very useful especially the
BIG detailed mail
by Kevin. I think it can make up a good article on ssl validation
process..( as there is not much info on this currently on net )
I forgot to mention that I am implementing it in C/C++ on windows platform.
I read one of the ssl_mitm pdf and tried to create a self signed
certificate using SSL as mentioned in it. To my surprise I found that
user can specify all the parameters while creating the certificate and
hence attacker can create fully valid certificate.....which can defeat
the major checks such as
That's why a self signed certificate is not considered secure, and you
*should* verify the certificate is signed by a trusted CA. Just
inserting Verisign's name into a certificate is not sufficient to make
it a trusted CA certificate. You have to get Verisign's root
certificate (from their site?) and check the signature on the
certificate you are verifying with Verisign's key.
Actually, certificate verification is a long complicated procedure - I
would strongly advise using some library to do the verification for
you. I'm not very familiar with the Windows platform, so I dont' have
specific recommendations. On Unix, openssl is an excellent open source
tool (you may be able to use openssl on Windows too, but there are
probably more suitable alternatives)
Also I have got simple idea of checking for trusted certificate ( since
we don't want to cache the trusted root certificates as browsers do )
Does your application talk to lots of servers or just a one or two? If
you have only a few servers to talk to, you could install their
certificates into your client as "trusted certificates" (assuming
these are servers you really trust and you have a good way of getting
their certs). That way you have only a few trusted certificates to
cache. But this is not scaleable, and you'd still need a mechanism to
replace certificates (when they expire, for eg.)
Thanks,
Mugdha
Here it is
1) During first time connection with server , if its certificate is valid
( i.e date is valid and hostname matches ) then it will be added to the local
cache.
2) During next connection with that server, incoming certificate will be checked
against the cached certificate ( in addition to date check) , if its not same
then that means the certificate is not trusted..
It looks simple and straight forward. Do you see any flaw in this
implementation ??
Thanks for your time..!
-------------------------------------------------------------------------
Sponsored by: Watchfire
Cross-Site Scripting (XSS) is one of the most common application-level
attacks that hackers use to sneak into web applications today. This
whitepaper will discuss how traditional CSS attacks are performed, how to
secure your site against these attacks and check if your site is protected.
Cross-Site Scripting Explained - Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmr
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
Cross-Site Scripting (XSS) is one of the most common application-level
attacks that hackers use to sneak into web applications today. This
whitepaper will discuss how traditional CSS attacks are performed, how to
secure your site against these attacks and check if your site is protected.
Cross-Site Scripting Explained - Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmr
--------------------------------------------------------------------------
