How does ZOPE integrate with a "SSL" secure server such as Red Hat Secure Web Server 2.0 http://www.redhat.com/product.phtml/WB2000 I have some understanding of the security offered on the server but what about security between the browser and the server? Can (and How) can SSL be integrated into the ZOPE login. The security hole that I see is entering ID and password at some remote site and after I leave, someone could reuse my ID and password for access because it's not encrypted between the browser and zope server. I understand that SSL servers are slowed down but only ID/Passwords need be SSL and after that, during the session, SSL security doesn't have to be used. I may not have a full understanding of this. Please enlighten me! -bobo connor
Zope can be used in CGI or PCGI modes with a server that does SSL. You're right about the possibility of someone sniffing the packets to your webserver looking for user IDs and passwords if they are not encrypted. However, if this is a concern to you, it is not just a problem when the user enters the password. It is for *every hit* the user makes to the server. The current implementations of HTTP do not allow for long-lived connections, so the browser sends the user name and password with each request. (The browser makes it so that the user only needs to enter it once, though.) Kevin On Mon, Jan 25, 1999 at 09:14:38AM -0500, Robert OConnor wrote: ,----- [stuff deleted] | The security hole that I see is entering ID | and password at some remote site and after I | leave, someone could reuse my ID and password | for access because it's not encrypted between | the browser and zope server. | | I understand that SSL servers are slowed down | but only ID/Passwords need be SSL and after | that, during the session, SSL security doesn't | have to be used. | | I may not have a full understanding of this. | Please enlighten me! | | -bobo connor | | `----- -- Kevin Dangoor kid@ans.net / 734-214-7349
On 25 Jan 99, at 9:51, Kevin Dangoor wrote:
server. The current implementations of HTTP do not allow for long-lived connections, so the browser sends the user name and password with each request. (The browser makes it so that the user only needs to enter it once, though.)
I don't think this is entirely true. http does allow the client and server to agree to keep the connection open. You can see this happening between iexploder and iis... Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 We must come down from our heights, and leave our straight paths, for the byways and low places of life, if we would learn truths by strong contrasts; and in hovels, in forecastles, and among our own outcasts in foreign lands, see what has been wrought upon our fellow-creatures by accident, hardship, or vice. - Richard Henry Dana, Jr. 1836
On Mon, Jan 25, 1999 at 11:49:17AM -0400, Brad Clements wrote:
On 25 Jan 99, at 9:51, Kevin Dangoor wrote:
server. The current implementations of HTTP do not allow for long-lived connections, so the browser sends the user name and password with each request. (The browser makes it so that the user only needs to enter it once, though.)
I don't think this is entirely true. http does allow the client and server to agree to keep the connection open. You can see this happening between iexploder and iis...
What you're seeing is Layer 3 persiistance, not Layer 4. What's happening is that under HTTP/1.1, the connection can support multiple HTTP transactions before you have to tear it down and rebuild it. This does not imply that there is a "session" at the application layer. By definition all HTTP operations are atomic, and do not imply any previous or subsequent operations. Chris -- | Christopher Petrilli | petrilli@amber.org
Christopher G. Petrilli wrote:
What you're seeing is Layer 3 persiistance, not Layer 4. What's happening is that under HTTP/1.1, the connection can support multiple HTTP transactions before you have to tear it down and rebuild it. This does not imply that there is a "session" at the application layer.
By definition all HTTP operations are atomic, and do not imply any previous or subsequent operations.
HTTP operations are indeed atomic (CGI a pure example of programming paradigm called continuation passing style or CPS ;) But the session that persists is the SSL session. After initial handshaking and agreeing on the keys to be used, subsequent HTTPS operations can use the established session. mod_ssl even has a special session cache for this purpose (it used to have a separate cache process, now it has bsddb bases session database) OTOH, it probably has nothing to do with HTTP/1.1 persistent connections. I'm quite sure that subsequent HTTPS requests can be serviced by different backend processes, even concurrently, and still be in the same session, so the overhead for them is just compression, not the initial key-exchange. ------- Hannu
Brad Clements wrote:
On 25 Jan 99, at 9:51, Kevin Dangoor wrote:
server. The current implementations of HTTP do not allow for long-lived connections, so the browser sends the user name and password with each request. (The browser makes it so that the user only needs to enter it once, though.)
I don't think this is entirely true. http does allow the client and server to agree to keep the connection open. You can see this happening between iexploder and iis...
Kevin's point is correct, despite how one particular browser and one particular server might maintain a persistent state. Robert is best advised to conduct his entire session via secure socket layer if the information is sensitive. Moreover, I think Robert's concern was the possible performance hit by using SSL rather than a regular socket connection. This hardly adds enough overhead to warrant dropping into an insecure session. Jeff Bauer Rubicon, Inc.
On Mon, Jan 25, 1999 at 11:35:00AM -0600, Jeff Bauer wrote:
Kevin's point is correct, despite how one particular browser and one particular server might maintain a persistent state. Robert is best advised to conduct his entire session via secure socket layer if the information is sensitive. Moreover, I think Robert's concern was the possible performance hit by using SSL rather than a regular socket connection. This hardly adds enough overhead to warrant dropping into an insecure session.
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear. Christopher -- | Christopher Petrilli | petrilli@amber.org
"Christopher G. Petrilli" wrote:
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear.
Interesting. I was estimating that our hit was more like 2:1, but I'm sure it would degrade in the absence of a multiprocessor server ;-) Are you implementing such a policy (above) using Zope? I'd be very interested to hear more. Regards, Jeff Bauer Rubicon, Inc.
On Mon, 25 Jan 1999, Christopher G. Petrilli wrote:
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear.
Sounds good, do you think it would be worth it to hash the ip address into the ticket so that you can almsot gauranty that the owner of the cookie is the same person the cookie was issued to? --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
Scott Robertson wrote:
On Mon, 25 Jan 1999, Christopher G. Petrilli wrote:
Based on real-world benchmarks, SSL generally has a order of magnitude impact (sometimes more) on performance... the key negotiation is a huge CPU burdon, and must be perfomred with the start of each SSL session (which under HTTP/1.0 is every HTTP query)... what I've recommended to a lot of people doing "high performance" servers is to use SSL to gather UID/password, then issue a "ticket" (aka cookie) that is valid, and then let the cookie be passed around. While this isn't 100%, and does allow for certain types of replay/mim vectors, it does provide a good bit more real world security than passing uids in the clear.
Sounds good, do you think it would be worth it to hash the ip address into the ticket so that you can almsot gauranty that the owner of the cookie is the same person the cookie was issued to?
I set this as a cookie with this value on the user's browser each time they visit a page requiring authentication (after they've logged in of course): userip/userid/activitytimestamp/logintmestamp/MD5(userip/userid/activitytimestamp/logintimestamp/serversecret) The activitytimestamp gets changed every time there is a succesful access. Thus, a "timeout" is established (the amount of time the activitytimestamp is set ahead from now is that timeout period). Prevents replay attacks after the timeout period, and is only valid from a particular IP. Now, there is an mitm and ip-spoofing-based attack, but the system is relatively fast. The serversecret part of the hash is known only to the server, and is used as a shortcut so that the server doesn't have to check the user's password for each hit. When the logintimestamp becomes a certain amount of time old , you then check to see if the user's authentication information has changed (without actually retrieving that authentication information). If that authentication information has changed, then you force the user to reauthenticate (and then you update logintimestamp). This lets you efficiently (ie only periodic connection to an authentication database -- and even then only to retrieve "last modified" information), and fairly surely authenticate who is using the session. -Gabe
Robert OConnor wrote:
How does ZOPE integrate with a "SSL" secure server such as
Red Hat Secure Web Server 2.0 http://www.redhat.com/product.phtml/WB2000
I have some understanding of the security offered on the server but what about security between the browser and the server?
Can (and How) can SSL be integrated into the ZOPE login.
If you use client sertificates, then you can get the SSL authenticated user from CGI variables If you use just uername/passwd then there should be no difference between HTTP and HTTPS in CGIs
I understand that SSL servers are slowed down but only ID/Passwords need be SSL and after that, during the session, SSL security doesn't have to be used.
HTTPS uses SSL for whole session. If you want just your login to be encrypted you should use challenge/response authentication. I'm not sure which browsers (except MS ones) use this. It should not be too hard to add this to ZopeServer if browser support exists. ----------------- Hannu
participants (8)
-
Brad Clements -
Christopher G. Petrilli -
Gabe Wachob -
Hannu Krosing -
Jeff Bauer -
Kevin Dangoor -
Robert OConnor -
Scott Robertson