[zorp] missing constants and methods in pssl.py
bazsi at balabit.hu
Mon Feb 18 10:02:36 CET 2008
On Sun, 2008-02-17 at 16:38 -0500, David Yerger wrote:
> Now trying to create an https proxy for Outlook Web Access with Zorp GPL
> 1. It looks like some of the constants are named differently than the
> Zorp GPL tutorial at
> http://www.balabit.hu/network-security/zorp-gateway/gpl/tutorial/, for
> example it mentions PSSL_VERIFY_NONE and PSSL_VERIFY_REQUIRED_TRUSTED in
> the example in section 5.6, but the code for the included Pssl.py v.
> 1.28 says
> SSL_VERIFY_NONE = 0
> SSL_VERIFY_OPTIONAL = 1
> SSL_VERIFY_REQUIRED_UNTRUSTED = 2
> SSL_VERIFY_REQUIRED_TRUSTED = 3
> (without the "P")
The Professional and GPLd version of the proxy are totally different
beasts and although they have some things in common, they are maintained
The "official" names of the above constants are prefixed with a P, but
this change was not commited to the GPLd version.
I've committed a fix for this.
I'm also Ccing the documentation team to clarify that the Pssl
documentation in our refguide applies to the professional version, and
how that differs from the GPLd one. The documentation of the GPLd
version is in the Pssl.py source file as text comments.
However the GPLd version should be enough for the stuff you want to
> 2. Looks like some methods and constants mentioned in the Zorp Gateway
> v3.1 SSL tutorial PDF aren't there, for example
> PSSL_METHOD_SSLV23 Permit the use of SSLv2 and v3.
> PSSL_METHOD_SSLV2 Permit the use of SSLv2 exclusively.
> PSSL_METHOD_SSLV3 Permit the use of SSLv3 exclusively.
> PSSL_METHOD_TLSV1 Permit the use of TLSv1 exclusively.
> PSSL_METHOD_ALL Permit the use of all the supported (SSLv2, SSLv3, and
> TLSv1) protocols.
This is not supported by the GPLd version, it basically always uses
"SSLv23", which is described by SSL_CTX_new(3) manual page as:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages
and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best choice
when compatibility is a concern.
> Is this because these are only defined in the Pssl module for Zorp Pro?
Yes, just as I described above, the Pssl proxy in pro is not the same as
the Pssl in the GPLd version.
I might try to convince our management to release the Pro version into
the GPLd branch if there's interest though.
> 3. Using a policy.py containing
> from Zorp.Core import *
> from Zorp.Http import *
> from Zorp.Plug import *
> from Zorp.Pssl import *
> def Zhttps():
> Service("INhttps", INhttps,
> router=DirectedRouter(SockAddrInet("10.0.0.9", 80)))
> Listener(SockAddrInet("aaa.bbb.ccc.ddd", 50443), "INhttps")
> class StrongPsslProxy(PsslProxy):
> def config(self):
> #docs say PSSL_VERIFY_NONE
> self.client_verify_type = SSL_VERIFY_NONE
> self.server_ca_directory = "/etc/ssl/certs/"
> #PDF docs want more here -
> #self.server_ssl_method = PSSL_METHOD_TLSV1
As I said, the GPLd proxy will use SSLv2, v3 and TLSv1
> #self.server_disable_proto = TRUE
The proper name for this attribute is
self.server_disable_proto_sslv2 = TRUE
e.g. you need a protocol suffix, but again this is not in the GPLd
> #self.server_ssl_cipher = PSSL_CIPHERS_HIGH
> class INhttps(StrongPsslProxy):
> def config(self):
This means that you don't want ssl encryption on the server side
> self.server_keypair_files = ("/etc/ssl/certs/owa.crt",
You probably don't need server side keys as you disabled encryption. You
want the same on the client side, e.g. you'd need client_keypair_files,
however the 'keypair' attributes were only added because of the GUI of
the professional version, you need these:
client_key_file -- [STRING:"":RW:R] Client side authentication
private key corresponding to 'client_cert_file'.
client_cert_file -- [STRING:"":RW:R] Filename of the client side
authentication certificate in PEM format.
This must be a server certificate, since
for clients the proxy behaves as it were
an SSL server.
> self.stack_proxy=(Z_STACK_PROXY, OWAHttpProxy)
> #wild guess on my part, maybe this will help
This is on by default.
> class OWAHttpProxy(HttpProxy):
> def config(self):
> I'm seeing in my logs stuff like
> Feb 17 16:09:49 localhost zorp/Zhttps: (svc/INhttps:0): Starting
> proxy instance; client_fd='15',
> client_address='AF_INET(aaa.bbb.ccc.def:3139)', client_zone='Zone(inter,
> 0.0.0.0/0)', client_local='AF_INET(aaa.bbb.ccc.ddd:443)',
> Feb 17 16:09:49 localhost zorp/Zhttps: (svc/INhttps:0/pssl):
> Server connection established; server_fd='18',
> server_address='AF_INET(10.0.0.9:80)', server_zone='Zone(intra,
> 10.0.0.0/24)', server_local='AF_INET(10.0.0.69:55718)',
> Feb 17 16:09:49 localhost zorp/Zhttps: (svc/INhttps:0/pssl): SSL
> handshake failed on the client side; error='error:1408A0C1:SSL
> routines:lib(20):SSL3_GET_CLIENT_HELLO:func(138):no shared
The reason is that you did not specify the keys for the proxy (in fact
you did, but for the wrong side, see above)
> Where 10.0.0.0 is the local network, aaa.bbb.ccc.ddd is my public IP,
> and aaa.bbb.ccc.def is the gateway address of my Snapgear (which my
> internal test client demaquerades as.)
Feel free to ask more, if you need help.
More information about the zorp