Re: [Zope] Zope security management
"Phil Harris" <phil.harris@zope.co.uk> writes:
I agree with the fact that why bother with MD5 when SSL is available, however not everyone using Zope has that capability available to them.
Everybody who uses one of the free secure Apache servers has SSL available to them; is this not the case for other servers that Zope can run behind?
For instance, I've recently seen a posting on slashdot.org where some people are questioning the pricing of SSL certificates, these people are living in Asia where the price of certificates equates to a few months salary.
That Slashdot discussion unsurprisingly only said half of the story. SSL certs are free; becoming your own certificate authority and signing your own certificates is free, and even documented by mod_ssl. I have a personal zope site that protects BasicAuth with SSL, and I didn't pay for any bits. The only reason to pay for a CA to sign your cert is to have that CA vouch that the cert is yours; Netscape accepts those certs without a dialog box. There's probably other advangates, like insurance, as well, I dunno. But thats what the official CAs provide; it's not Zope's job. This doesn't address the original problem - if you allow nonsecure authorization to a page, eventually someone will forget to access it via SSL and will send the password across in the clear. That's a valid point. Personally, I'm paranoid that my browser or proxy will send my credentials without being asked for, which IIRC they are allowed to do; so once I send credentials to my site, I always use SSL for other URLs. This is annoying, but wouldn't client certificates solve this problem? -- Karl Anderson karl@digicool.com
Karl, At no point in this discussion did I assert that it was Zopes job to supply a SSL implementation or become a CA. I totally agree that this is better handled by a layer in front of Zope. Yeah, I know you can sign your own certificates, but for some environments (e.g. eCommerce) surely you can agree that having VeriSign or Thawte vouch for your certificate would inspire more confidence than one signed by Phil Harris, web-odd-job-man. I myself also use self-signed certificates but only for testing sites. My employers take offence (in aesthetic terms) to the silly messages that Netscape/Mozilla/IE (moz in particular) show users when the certificate is self-signed. We have a captive audience (academic) to a certain degree, so can get away with it, others are not so fortunate. Now onto something related but not strictly on topic. There are also other ways to put a SSL frontend to Zope than to use Apache, take a look at http://www.stunnel.org or http://www.delegate.org for instance. I use them with some success to put SSL fronts to all sorts of things including HTTP, LDAP, POP3,NNTP etc. and also use them in client mode to connect non-SSL clients to SSL-enabled servers. Anyway enough rambling. See ya Phil ----- Original Message ----- From: "Karl Anderson" <karl@digicool.com> To: "Phil Harris" <phil.harris@zope.co.uk> Cc: "The Famous Brett Watson" <famous@nutters.org>; <zope@zope.org> Sent: Tuesday, March 20, 2001 10:19 PM Subject: Re: [Zope] Zope security management
"Phil Harris" <phil.harris@zope.co.uk> writes:
I agree with the fact that why bother with MD5 when SSL is available, however not everyone using Zope has that capability available to them.
Everybody who uses one of the free secure Apache servers has SSL available to them; is this not the case for other servers that Zope can run behind?
For instance, I've recently seen a posting on slashdot.org where some people are questioning the pricing of SSL certificates, these people are living in Asia where the price of certificates equates to a few months salary.
That Slashdot discussion unsurprisingly only said half of the story. SSL certs are free; becoming your own certificate authority and signing your own certificates is free, and even documented by mod_ssl. I have a personal zope site that protects BasicAuth with SSL, and I didn't pay for any bits.
The only reason to pay for a CA to sign your cert is to have that CA vouch that the cert is yours; Netscape accepts those certs without a dialog box. There's probably other advangates, like insurance, as well, I dunno. But thats what the official CAs provide; it's not Zope's job.
This doesn't address the original problem - if you allow nonsecure authorization to a page, eventually someone will forget to access it via SSL and will send the password across in the clear. That's a valid point. Personally, I'm paranoid that my browser or proxy will send my credentials without being asked for, which IIRC they are allowed to do; so once I send credentials to my site, I always use SSL for other URLs. This is annoying, but wouldn't client certificates solve this problem?
-- Karl Anderson karl@digicool.com
----- Original Message ----- From: "Karl Anderson" <karl@digicool.com>
This doesn't address the original problem - if you allow nonsecure authorization to a page, eventually someone will forget to access it via SSL and will send the password across in the clear. That's a valid point. Personally, I'm paranoid that my browser or proxy will send my credentials without being asked for, which IIRC they are allowed to do; so once I send credentials to my site, I always use SSL for other URLs. This is annoying, but wouldn't client certificates solve this problem?
The idea of client certificates is a nice one, but IIRC client certificates is something that needs to be looked at more in terms of "how will my organisation support client certs and how will we deploy them, what are the consequences, how much administration will this require, etc, etc..." I am just now starting to look deeper into using SSL with Zope, since we are going to re-implement a lot of things done with Oracle's Web PL/SQL toolkit and our own Apache::OWA perl module, in Zope. We are planning to run Zope behind Apache using it as a proxy. Currently we have the option of configuring Apache to accept SSL-only connections for a given URI (I think this is done in the Alias section) but this is not an option for the things we do since a large part of our site does not really need to be encryted; we only want to provide encrypted access after you have logged in, and then we want to ensure that the parts that do require authentication are only accessible through SSL. In Oracles Oracle's Web PL/SQL toolkit there is no simple way of knowing if a request is done with SSL or not, but I can see through which port a request was made. I have a method which gets called for every request, that checks if the request came in thru a "valid" port; port 443 is in the list of "valid" ports. This I "know" since, in our setup, we use Apache SSL on port 443. It is also possible to use several ports that are known to use SSL, so it is quite flexible. I am considering setting up something like this in Zope, that I want to couple with the built in user management system in conjunction with LoginManager or something similar. Would this be possible? Can I force Zope to call a "verify port" method on every request? Thanks, /dario - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services
I have a method which gets called for every request, that checks if the request came in thru a "valid" port; port 443 is in the list of "valid" ports. This I "know" since, in our setup, we use Apache SSL on port 443. It is also pos- sible to use several ports that are known to use SSL, so it is quite flexible.
I forgot to mention that user-credentials passing part. After we have established an SSL-connection, we use a forms based login procedure, that sends, in cleartext but over an encrypted ssl-connection, the username and password. We also make sure that the login form can only be used over SSL. On the server side, we authenticate and make some user-group checks; when we have indentified the user, we generate a random cookie that we send back to the client. The expiry date on the cooke is not set, if IIRC, or it is set to some date in the past, to ensure that the well-behaved browser does not store it to disk, but keeps it in RAM. We also have a time-out on the sessions, so if someone goes away from their computer while logged in, their session expires after a specific amount of time. This won't let us achieve 100% security, but at least the user won't stay logged on forever, and we minimize the time frame on which a security breach can happen. On the server side, we store the value of the cookie, along with the username and the expiry date of the session (the cookie's value is the actual session id). On every request, we ask the client for our cookie, and then we look it up on the server, check the expiry date and if it is still valid, then we know the username of who made the request and can consider him/her to be authenticated. We update the expiry date of the session and e wait for the next request. This way we send transfer our credentials once and only once over an encrypted channel, and then we just retrieve the cookie. If you want more security it is of course possible to set a new random cookie with every request, so that the cookie is only valid for a single request, thus ensuring that the cookie can't ever be re-used. We also have a logout procedure that resets the cookie on the client to a non-sense value, and we then delete the session info on the server. This is also what happens when the session times out. The reason we use a formsbased login is precisely to avoid having users credentials passed along with every request. Digest authentication is available, but not all browsers support it. We are deploying DCE/DFS on campus now, and ideally we'd like to have a DCE enabled browser; if we did, we could perhaps adapt Zope to use DCE credentials... but i'll guess we'll have to wait a bit longer for that. BTW - has anyone used Zope alogn with Kerberos authentication? /dario
Please share with us how you make sure that the login form can only be used over SSL. Bill. On Wed, 21 Mar 2001, Dario Lopez-K�sten wrote:
After we have established an SSL-connection, we use a forms based login procedure, that sends, in cleartext but over an encrypted ssl-connection, the username and password. We also make sure that the login form can only be used over SSL.
Midn you this is not in Zope yet, I am working o making it so Here's how I do it in PLSQL: Two steps: 1) the form action element calls the login method using https:// <form method="post" action="https://...../mts2.login"> This is not necessary however, you could still use <form method="post" action="mts2.login"> becuase 2) The login method checks to see if it is called from a valid port. This is the first statement in the method (or procedure as it is called in plsql-ish): ----- Original Message ----- From: "Bill Welch" <bill@carbonecho.com> To: <zope@zope.org> Sent: Thursday, March 22, 2001 8:16 PM Subject: Re: [Zope] Zope security management
Please share with us how you make sure that the login form can only be used over SSL.
Bill.
On Wed, 21 Mar 2001, Dario Lopez-Kästen wrote:
After we have established an SSL-connection, we use a forms based login procedure, that sends, in cleartext but over an encrypted ssl-connection, the username and password. We also make sure that the login form can only be used over SSL.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (4)
-
Bill Welch -
Dario Lopez-K�sten -
Karl Anderson -
Phil Harris