|Home||Reviews||Tools||Forums||FAQs||Find Service||ISP News||Maps||About|
how-to block ads
An SSL-encrypted HTTP session is initated by using the "https" method on the URL (Uniform Resource Locator).
Your browser connects to the web server and begins a complicated dialog to establish a secure channel and verify the site's identity.
The channel is secured using a "handshake" protocol that creates a Session. The web site server sends its "certificate" to the browser. The browser then tries to verify the validity of the certificate. If the certificate is valid, the handshake protocol performs a key exchange so that each end (the web site and server) have keys to encrypt and decrypt the data.
If you connect to a site with https: and you get a warning about the certificate, it means your web browser was unable to authenticate the web server's certificate with a recognized certificate authority. This means you cannot be absolutely certain you are talking to who you think you are. If you are certain, you can still proceed and establish the SSL Session. Your data will be encrypted just the same, but you will not have verified the remote web site server's identity.
It's unlikely (but technically possible) to steal personal information like passwords and credit card numbers by listening into web site traffic. The encryption of the data means that as web site data passes from router to router, nobody can read your credit card information until it gets through the Internet and safely to your web server.
Web site pages encrypted with a 128-bit session key are considered "computationally secure". This means that with current technology, the 128 bit session key cannot be cracked in anything less than several days.
An interesting feature of the SSL protocol allows either the client or server to request new encryption keys at any time. Nobody does this now, but it would be an extra measure of protection when computers get fast enough to crack the 128-bit SSL key.
Some people make the mistake of using the same password for sensitive logins as they do for ones where it doesn't matter. Where you don't use SSL for your "doen't need to be super secure" login process you expose those idiots passwords for all their secure sites - bank etc - to whoever decides to capture passwords from your login in the hope that the people using the page are moronic enough to have reused the same password as they used for their bank account. If it were not for such stupidity in using the same password for multiple sites where some of them do need to be super secure then it wouldn't matter. What the client is really saying in this case is that they think their users are super dumb enough that they are using passwords to access the site you built that are the same password they use for their bank account and other similar sites where security is needed and so they want you to build in that extra security layer to protect their users from their own mental incompetence. --------------------------- http://www.clickssl.com/