fyi: apache + ssl + zope + zope management interface example
Greetings, Here is an example apache httpd.conf fragment which gets apache + ssl + zope to all play nicely together. If someone has a nicer way of doing this, chime in. The bonus in these instructions is that I also got the management interface to come up via ssl. I really struggled getting the RewriteRules to work right. These instructions worked for me using apache 2.0.20 and zope 2.6.1. Prerequisites ============= apache + mod_ssl are installed and functioning correctly. www.example.com and manage.example.com have the same ip address. zope runs on www.example.com port 8080. zope has a Virtual Host Monster object in the root folder. zope has a folder named "example" in the root folder. Warnings ======== - Understand SSL, and get your certificates and options right for your needs. - Verify that no important plaintext is transmitted. - Restrict remote access to port 8080 or else folks will be able to connect to the zope management interface remotely without using SSL. - Your mileage may vary. Usage and Indications ====================== - http://www.example.com serves content from zope's "example" folder. - https://www.example.com serves content from zope's "example" folder, via SSL. - http://www.example.com/manage is forbidden. - https://www.example.com/manage is forbidden. - https://manage.example.com/ brings up the "Zope Quick Start" page. - https://manage.example.com/manage brings up an authentication dialog box for the zope management interface. httpd.conf - virtual hosts section ========== NameVirtualHost * NameVirtualHost *:443 # NON-SSL EXAMPLE.COM SERVING CONTENT FROM THE "EXAMPLE" FOLDER # MANAGE INTERFACE FORBIDDEN <VirtualHost *> ServerName www.example.com RewriteEngine on RewriteCond %{REQUEST_URI} manage RewriteRule manage - [F] RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/http/www.example.com:80/example/Virtua... [P,L] </VirtualHost> # SSL EXAMPLE.COM SERVING CONTENT FROM THE "EXAMPLE" FOLDER # MANAGE INTERFACE FORBIDDEN <VirtualHost *:443> ServerName www.example.com # SSL SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 # REWRITE RewriteEngine on RewriteCond %{REQUEST_URI} manage RewriteRule manage - [F] RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/https/www.example.com:443/example/Virt... [P,L] </VirtualHost> # MANAGEMENT INTERFACE VIA SSL <VirtualHost *:443> ServerName manage.example.com # SSL SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 # REWRITE RewriteEngine on RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/https/manage.example.com:443/VirtualHo... [P,L] </VirtualHost> -- Ricardo Anguiano http://www.codesourcery.com
Ricardo Anguiano wrote:
- Restrict remote access to port 8080 or else folks will be able to connect to the zope management interface remotely without using SSL.
Or just bind zope to something in 127.0.0.0/8 which should obviates the need for additional access restrictions (from the outside world). (Assuming a non-routing host I suppose.)
<VirtualHost *> ServerName www.example.com RewriteEngine on RewriteCond %{REQUEST_URI} manage
The above RewriteCond is superfluous, the RewriteRule below is sufficient.
RewriteRule manage - [F] RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/http/www.example.com:80/example/Virtua... [P,L] </VirtualHost>
<VirtualHost *:443> ServerName www.example.com ... RewriteEngine on RewriteCond %{REQUEST_URI} manage
ibid
RewriteRule manage - [F] RewriteRule ^/(.*) http://localhost:8080/VirtualHostBase/https/www.example.com:443/example/Virt... [P,L] </VirtualHost>
These examples also fail to address the issues discussed in http://marc.theaimsgroup.com/?l=zope&m=104426779414836 but then, they are just examples, and nobody would dream of using them blindly without first reading the documentation right? Right. What you've done here will work ... mostly. I've even advocated it in the past, but its probably worth noting blocking 'manage' strings only works from a pragmatic sense. I believe there are management interfaces that don't have that string in them (I swear I saw one the other day though I don't remember in what now...) and as such if your goal is 100% assurance that auth headers for management never pass in the clear this config might not cut it. I've been considering an alternate approach, I'd entertain any commentary. I was thinking of using client certs with mod_ssl's FakeBasicAuth function in conjunction with a specialized UserFolder that only authenticates requests which are received via a known secure route. I've verified that when using FakeBasicAuth and mod_rewrite/proxy that the proxied request is indeed sent with an appropriately crafted WWW-Authenticate header. The problem I've been mulling over is that this means the passwords of your users are all identical in the user folder. (read up on mod_ssl if don't understand why) This means that whatever variable that holds the flag indicating the request came from a secure source must be protected from any form of duress. (Otherwise I can see a scenario where users could possibly script themselves new credentials.) To date thats about as far as I've gotten with this idea, I'm not sure what the best way to protect a variable of that much importance would be. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Jamie Heilman <jamie@audible.transient.net> writes:
[...superfluous conditions...]
Thanks for the info. I will have to test without the conditions.
These examples also fail to address the issues discussed in http://marc.theaimsgroup.com/?l=zope&m=104426779414836 but then, they are just examples, and nobody would dream of using them blindly without first reading the documentation right? Right.
I am unclear on the problem. I am not using a cache. If I was using a cache, wouldn't the "tainted" URIs just fill my cache with garbage and degrade performance? If that isn't the only impact, it looks like you provide a nice set of RewriteConds in your email which addresses this problem.
What you've done here will work ... mostly. I've even advocated it in the past, but its probably worth noting blocking 'manage' strings only works from a pragmatic sense. I believe there are management interfaces that don't have that string in them (I swear I saw one the other day though I don't remember in what now...)
AFAIK, the only zope management interface on unmodified zope, is /manage. Pointers to documentation or source code for other management interfaces are appreciated.
and as such if your goal is 100% assurance that auth headers for management never pass in the clear this config might not cut it. I've been considering an alternate approach, I'd entertain any commentary.
From SYN to FIN, tcpdump -s 100 -X just showed garbage, so that meets my needs. Can you describe a situation where the configuration is broken and allows plaintext transmissions? If the example is broken, I would like to fix it. It is important that the example not provide a false sense of security.
I was thinking of using client certs with mod_ssl's FakeBasicAuth function in conjunction with a specialized UserFolder that only authenticates requests which are received via a known secure route. I've verified that when using FakeBasicAuth and mod_rewrite/proxy that the proxied request is indeed sent with an appropriately crafted WWW-Authenticate header.
Do you have a pointer to an example?
The problem I've been mulling over is that this means the passwords of your users are all identical in the user folder. (read up on mod_ssl if don't understand why) This means that whatever variable that holds the flag indicating the request came from a secure source must be protected from any form of duress. (Otherwise I can see a scenario where users could possibly script themselves new credentials.) To date thats about as far as I've gotten with this idea, I'm not sure what the best way to protect a variable of that much importance would be.
My ssl-fu is not 31337, so I am not sure what you're your talking about with UserFolder, and you lose me after that. Apparently, I need to read the ssl documentation more carefully. If you don't trust the world to connect to your management interface because you fear exposed interfaces, client certs (or at the very least ip address based ACLS) seem like the way to go. There are a few of ways which guarantee that no plaintext is transmitted onto the network: 1) ssh (inconvenient) 2) vpn (haven't tried) 3) ssl (seems to work) SSL seems to be the broadest solution because you can get an SSL browser on almost any system. Thanks, -- Ricardo Anguiano http://www.codesourcery.com
Ricardo Anguiano wrote:
I am unclear on the problem. I am not using a cache.
If you're not using a cache then you shouldn't be vulnerable. I'd suggest using a protective configuration regardless though.
a cache, wouldn't the "tainted" URIs just fill my cache with garbage and degrade performance?
Well cache poisoning is a little bit more annoying than that--it would allow an attacker to make your site look like trash for subsequent visitors (or worse given the issues described in issue 813, but thats a different bug).
Can you describe a situation where the configuration is broken and allows plaintext transmissions?
If I can find a spot in the zope source where there exists a management method that doesn't have the word 'manage' in it, yes. I don't know of one off the top of my head though. I'm just saying that assuming that all ttw methods contain 'manage' somewhere in them may be a brash assumption. (Especially if you have 3rd party products installed.)
Do you have a pointer to an example?
Well, consider the follow apache configuration fragment: # this vhost requires a valid client cert SSLVerifyClient require # ^/zope* is proxied to a local zserver RewriteRule ^/zope(.*) http://127.0.0.1:8080/VirtualHostBase/https/example.com:443/VirtualHostRoot/... [P,L] # ^/zope* is considered a protected realm, only clients who's DN # appears in the 'passwd' file will be allowed entry, proxy requests # sent to zserver will include an auth header constructed from the DN # and the password 'password' <Location "/zope"> SSLOptions FakeBasicAuth AuthName "Zope Management" AuthType Basic AuthUserFile passwd require valid-user </Location> Now the obvious issue with this is that every user's password is "password" and their username is their DN (which tends to be long and look ugly in the ZMI, but thats just cosmetic). I dunno, I may just ditch this line of thought entirely as I can't see any way to make this a safe practice on a multiuser machine without reverting to unix domain sockets, and that requires hacking the hell out of mod_rewrite or possibly mod_proxy. This probably just isn't worth all the effort. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
participants (2)
-
Jamie Heilman -
Ricardo Anguiano