|
SSL - Do I always need Certificates for this?
I am pretty new to SSL - the number of jargons can be a tad overwhelming to a newish user.
I want to set up a web-page where a user can enter information in a form - this form will be post back to the server.
I would like to make the info in the form secure when sent back to the server.
Would I need certificates for this?
I would have thought not - because the user is not concerned on if he/she has reached the correct server. The concern will be that the form details are not sent in clear text.
Johnny Draxo
Monday, March 29, 2004
"I would have thought not - because the user is not concerned on if he/she has reached the correct server. The concern will be that the form details are not sent in clear text."
If you weren't concerned about what server to which some data is sent, why would you care if it were sent in plain text?
To answer your question- yes, you will need a server certificate.
ken
Monday, March 29, 2004
Ken - Thanks for your reply.
Have I made an error of judgement?
Are certificates used in SSL for purposes other than server verification?
Johnny Draxo
Monday, March 29, 2004
Ok, someone asked this on another BBS, so here is the posted explanation:
------------
Yes, you always need SSL certificates installed to the web server, in a place that the web server is configured to look. www.apache-ssl.org is for Apache but the concepts should be common to IIS.
Basically, the SSL certificates are text files encoded with the public and private key information.
Keys are used to encrypt and decrypt the data. You ALWAYS need keys if you do SSL. SSL makes no sense without encryption. So you ALWAYS need certificates because the certs contain the keys.
There is a client certificate and there is a certificate that the server (only) has access to. The client certificate contains the public key, and the server certificate contains the private key. Obviously, the pair of certificate files need to be created as a matched set. The client certificate (as I understand it) is downloaded to the web browser client when someone goes to your SSL secured page.
It's possible, using openssl, to create ad hoc certificates licensed to " Johnny Draxo's Certificate Emporium and Cut Rate Saw Sharpening Service". This is useful for testing.
But, practically all web browsers will complain when the certificate granting authority that is imprinted into the certificate is not recognized by the browser. This is indicated by the dialog boxes that pop up when you enter an SSL site asking for verification that you want to proceed. Browsers only recognize ordained "authorities" namely Verisign, et al. The issue is spoofing of the encryption process, and the certificate authority is responsible in this process for vouching for the SSL using company being who their web site claims they are. So, you are stuck with buying a certificate if you want to look legitimate to customers.
And, last but not least, Apache's ssl module (mod-ssl?) needs to be installed. I'm sure it's built into IIS or I would hope it is.
It's absolutely no big deal to get going. With Apache it just requires some diddling with httpd.conf. The service name https:// or the absolute port designator :xx at the end of the URL tell an SSL configured web server to respond SSL wise to the request.
Hope that helps.
Bored Bystander
Monday, March 29, 2004
I think you missed Johnnys question: Yes, you need it. Because encryption without authentication is basically worthless: Sending stuff encrypted won't help if you send it encrypted with the eavesdropper's key. So you need authentication to know that you're encrypting with the right key.
Jonas B.
Monday, March 29, 2004
Thanks for the explaination.
This is a great help :)
JD
Johnny Draxo
Monday, March 29, 2004
So, besides encryption, you basically need it to make sure Mr. Hacker doesnt break into your site and change the action attribute on your very important CC# laden purchase order form?
Anon-y-mous Cow-ard
Monday, March 29, 2004
My point was that, if you don't care who hears, there's no need to whisper. You say that the user doesn't care if he has reached the correct server, but that seems unlikely to me if they are posting something they want kept secret. Would you enter your credit card number on amazon if you thought that someone was spoofing their web address? Am I making sense?
ken
Monday, March 29, 2004
"you basically need it to make sure Mr. Hacker doesnt break into your site and change the action attribute on your very important CC# laden purchase order form?"
If someone could actually hack the site, they have free reign anyways--no need to direct the post somewhere else.
Server authentity certificates are moreso a concern for man-in-the-middle attacks (where someone along the way, be it a proxy, or transparent router captures all packets mid-point. In this case it could obtain a secure connection to the destination, a secure connection to the client, and then capture (or alter) all traffic even though it appears to be a secure connection to the client).
Another benefit of authenticated SSL is the vulnerability of DNS - If a DNS server at some ISP were compromised through a hack or inside activity, and someone pointed PayPal.com to their own server, without the proper SSL certificate at least the client will get a warning (which they'll likely ignore, but regardless). Getting even dumber, if someone points www.paypa1.com to their own server, sends emails out asking people to login to update their account, again the user will get an SSL warning (as Verisign is unlikely to issue a certificate for such a dubious URL unless proven to be the real company).
Of course the reality is that most people don't even check if the connection is secure, and just click away warning messages.
Dennis Forbes
Monday, March 29, 2004
In some thin client desktop apps, the customer just wants an encrypted http connection, so why not use your own home-brewed cert for that ?
OpenSSL and other libs offer such functionality, but avoid the 3rd party authentication costs (ie, Verisgn).
As long as personal finanical info (or other 'ID theft' fields) isn't involved, Verisgn authentication seems overkill.
Joe Hendricks
Monday, March 29, 2004
> My point was that, if you don't care who hears, there's no need to whisper
Good point, though it should be added that the encryption protects against passive/eavsdropping attacks and authentication protect against active MITM attacks. So depending on your threat model and the value of the data, it might be reasonable to encrypt but not authenticate. Especially if the cost of losing the data is less than the cost of getting Verisign to issue you a cert.
Brian
Monday, March 29, 2004
I want to play devil's advocate here... I don't think that you'll definately need a server cert. Skipping it can save you a little money and a lot of hassle.
First, as Joe Hendricks said above, you have the option of creating your own certificate and self signing it. That might be an option in two cases: first, you don't really care, don't expect any serious attacks and it wouldn't be tragic if they occured, e.g. testing. Second, if you have a small, closed user-base that you're planning to communicate via SSL with, you could distribute your "signing" certificate (CA) and get people to install it in their browsers. The hassle will, of course, be much worse than having to gather together the necessary documentation to renew your certificate once a year, and generally, you should never do this unless you're a serious masochist. If you're a serious masochist and are planning on using client certificates for authentication, you might as well distribute your server certificates as well.
Another option is secure hosting, if you aren't maintaining your own server, maybe your webspace provider has some kind of deal for you to use SSL over their server. Say you have www. mydomain.com at a provider, they sometimes have subdomains along the line of https://mydomain.secureprovider.com and manage the SSL stuff for you there.
That saves you the work of dealing and administering the software yourself, you have to trust your hoster to play fair with you and not steal your data anyway, and it's by far the cheapest option. Especially if you're a small outfit that doesn't have a corporate image department that cares about a the url containing a subdomain.
-tim
a2800276
Tuesday, March 30, 2004
You always need a certificate, since the public key in the certificate sent by the server is used in the set-up of the symmetric key that will be used for the session.
Wheter or not you need a 3rd party trusted root signed server certificate or you can get away with just singning your own depends on your use cases.
Just me (Sir to you)
Tuesday, March 30, 2004
 Recent Topics
Fog Creek Home
|
