Gene raises valid considerations, but I think they miss the point in this particular circumstance.
If you don't want to use SSL, don't publish https://... URLs. If you publish https://... URLs, make sure your certs are correct (i.e., that they haven't expired, that you have wildcard certs if needed, etc.). LOPSA could fix this in either of two ways: fix the certs, or fix the URLs. The latter doesn't address the URLs that they've already published; therefore, I'd say that the former is the preferable fix. It reflects badly on us (LOPSA) that we don't get this right, and damages our credibility; it's a fundamental sysadmin thing. -Brent On Thu, May 26, 2011 at 5:13 AM, <[email protected]> wrote: > Susan Baur made the following keystrokes: > >Am I the only one who finds it ironic that I need to manually > >accept an "untrusted" certificate to sign up for the security > >discussion mailing list? (The domain is lists.lopsa.org and the > >cert is only valid on lopsa.org.) > > Personal opinion only below. Sorry for the length of this. > > There are 2 camps of thought on this. > 1. SSL security is meaningful and the only way it will ever > become useful is to lead by example. Note I didn't say secure. > > 2. SSL security has never really be trustworthy and the primary reason > it exists is because there are some big companies making lots and lots > of $$$ on selling it. Why should I spend the money for "show"? > > Why should I spend $$$ on something that doesn't involve $$$ in some > form? Where is my ROI if I spend the $$ to get one? What's the > possible harm if I don't? LOPSA needs to consider this in their > overall setup. Does #1 above mean enough at this point to justify > the expense (initial and renewal) plus maint of the keys? > > What's the motivation for someone to attack it? The only thing they may > get is someones subscription on a mailing list. Granted they may be > able to harvest passwords out of the mailman setup, but hopefully nobody > is using the same password on a list server as they do for anything > more significant. This is a listserv for administrators and hopefully > people know better. It's not like going after Sony or TJMax with the > hope of getting credit card numbers. > > The reality of things is that by default most web servers still > provide access to SSL-v2 and very weak ciphers. Your browser > should negotiate the most secure of these, but the it's up > to the source to disable the insecure if they care. In most cases > you, the user will never know which is being used. Are you > really secure, or is this just another case of the 80year old > bank guard standing in the corner with a gun that has no bullets? > > I'll contend that a self signed cert on a site that is configured > to disable older protocols and weak ciphers is more secure than > many sites using various default configs. > > Next, there isn't anything from stopping a scammer from > registering a domain and getting a valid certificate for their > site. Send you a little phishing mail informing you of a > problem with your credit card and go to V1SA[.]COM > where they have mirrored the real site and chances are that > even some of those looking for the locks will fall for it. > The cert on the site is even valid, so that indicator is gone. > Don't forget these crews have lots of stolen credit cards, so > it's not costing them anything to buy a valid cert. > > As has been mentioned already, most users have been trained > to just click the proceed anyway box on their browser. Even > many of the big shopping sites get it wrong, esp when they > redirect their web pages on the back end to go off to the IP > based URL instead of their name based system. > > Try setting up a proxy service sometime that validates certificates > and see how many of your users complain they can't get to > the business needed to keep your company in operation. > > As a final thought on this, even if you have a $$$ cert and > a secure config, can the user really be trusted to have a > secure connection to your system? One of the big problems > is that most malware makes use of admin permissions to infect > the desktop. While most people think of keystroke loggers > and bot infections, we have seen where malware will replace > the DNS config to point to servers that redirect your > requests for the bank to their fake servers. Note if they > can do that, they can also replace the files on your desktop > that contains the keys to certificate verification. This is > also true for doing DNSSEC verification of the site you > are talking to. All bets are off with an infected machines. > > Again, speaking for myself, not my job. > > > /~\ The ASCII Gene Rackow email: [email protected] > \ / Ribbon Campaign Cyber Security Office voice: 630-252-7126 > X Against HTML Argonne National Lab > / \ Email! 9700 S. Cass Ave. / Argonne, IL 60439 > > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
