Hey again Mark ;-))

First of all where is the rest of the list? No blah blah?


---------------
No not all our client *need* SSL, in fact only a couple of them do. Ok a
bunch of them have an admin system that lets the login & change content.
Does that need SSL protection? In most cases no. Others have an admin that
they just log into to pick up a CSV file of feedback comments or orders.
Again is SSL required? Usually no, ask yourself if you would be happy to fax
or post this information.
---------------

To me - not ONE backdoor should be left open, not one of my clients should ever have 
to put up with a break-in to their site, no matter what site or client.

And yes, the self-signed certificates are perfect for Admin panels, but you even admit 
even then a secure process needs to be in place.

---------------

Do all these sites really need SSL? Maybe only some parts of some apps do.
Could you get a cert for one domain and then use sub domains to access the
secure bits of each site via SSL.

For example - get a cert for mydomain.com and then setup
client1.mydomain.com, client2.mydomain.com and so on to provide secure
access to your server for each of your clients.

(Is it possible to get a cert that covers a whole server not just a domain?
Not sure.)

---------------

I was just giving an example, I've had clients that had that many domains and did not 
want one associated with the other, so what your suggestion there is not an option, I 
did have into place a similiar set-up where every client could use my cert. if they 
wanted to.

---------------

The reason I don't see the use of trying is because I know for a fact that I
am not capable of implementing a better solution even if I had the time or
inclination to try. This is not "the little engine that could" (I think I
can, I think I can) - its like me saying I am not able to perform brain
surgery or design a working space craft.

---------------

I think your wrong, you probably can, if your as smart as you come across. 
Anyway, I must be that engine the little engine that could then, because in my books 
anything is possible.

---------------

On the topic of affordability - SSL itself is completely free. As I pointed
out before you can go and use it without paying anyone anything. What you
are paying for is "trust" from a "certificate authority" (CA). This means
that the CA has verified that you are who you are - this does not add
"security" it adds "trust". Basically it prevents you & me from saying we
are Westpac.

If you just need security for your clients to login & administer your sites
then "trust" is not an issue, you don't need Verisign involved & you
shouldn't have to pay anything. Just explain to them that they need to
accept your cert the first time they hit the site.

If you go into IE & go Tools/Internet Options/Content/Certificates/Trusted
Root Certificate Authorities you'll see a list of CAs that IE trusts
automatically. All of these CAs cut deals with M$ so that they could then
reseller that "trust". That is the only thing you are paying for - not
"security".

---------------

I am and was perfectly aware of that, but you should know that you have to think about 
ALL your users, not just the handfull that KNOW! When a certificate is not signed a 
nasty alert poppes up, a novice or even not novice user would be scared away 
immediately. It is ONLY an option for admin panels as you said.

---------------


I agree that security is a BIG issue. Regarding people not wanting to
discuss it publicly - most sensible people will be happy to talk about it
publicly. I do remember that conversations have in effect been shut down on
this list before, but I think (hope) that was more to do with the way things
were being discussed rather than the way in which it was being discussed.
Yes this is a fine line & I think I'm leaning more towards your point of
view on this one.

See http://en.wikipedia.org/wiki/Security_through_obscurity again. Some
people think that not talking about a vulnerability (like SQL injection)
makes it less of a problem. I completely disagree with that idea.

---------------

Agreed SQL Injection, session hijacking and XSS are not discussed enough by 
developers...
I tried a while ago, but got the cold shoulder, since then I been keeping it all to 
myself ;-))

---------------



Taco Fleur
07 3535 5072
Blog: http://www.tacofleur.com/index/blog/
Methodology: http://www.tacofleur.com/index/methodology/
Tell me and I will forget
Show me and I will remember
Teach me and I will learn

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to