Anyone had any experience trying to secure the transactions between ZEO clients and a storage server??? Our shop is already using OpenSSH, I have read some introductory information about OpenSSH. It is just not clear to me the level of effort required to implement this or if implemented, will the additional overhead further exasperate the potential for unresolved conflict errors???
Any thoughts...
Eric
Hi,
I would suggest a permanent ipsec tunnel between the servers. ipsec would be encapsulated any traffic, while ssh while only tunnel a specific traffic.
Regards, Dirk
Eric Roby schrieb:
Anyone had any experience trying to secure the transactions between ZEO clients and a storage server??? Our shop is already using OpenSSH, I have read some introductory information about OpenSSH. It is just not clear to me the level of effort required to implement this or if implemented, will the additional overhead further exasperate the potential for unresolved conflict errors???
Any thoughts...
Eric
Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Eric Roby wrote:
Anyone had any experience trying to secure the transactions between ZEO clients and a storage server??? Our shop is already using OpenSSH, I have read some introductory information about OpenSSH. It is just not clear to me the level of effort required to implement this or if implemented, will the additional overhead further exasperate the potential for unresolved conflict errors???
Any thoughts...
Let's say you have a host called "zeoclient" and "zeostorage". On zeostorage, start a ZEO server listening to some port, say 9673, making sure that it listens only on the *local* interface, usually 127.0.0.1. An example:
python lib/python/ZEO/start.py -p 9673 -h 127.0.0.1 \ -S 1=/stores/fs:Storage
Then on "zeoclient" you set up a tunnel:
ssh -f -N -L 9673:zeostorage:9673 zeostorage
Then your Zope install on zeoclient should use port 9673 on 127.0.0.1 to connect to the storage. In fact, the only piece of code that should know about the hostname "zeostorage" is the command to set up the SSH tunnel.
There are some disadvantages: anybody who has an account on either zeoclient or zeostorage has full read/write access to the database. To avoid that, you'd need to use Unix domain sockets and come up with a way to forward one securely. Also, ssh is not 100% stable as a tunnel; I've seen ssh stop just because a forwarded connection disconnected unexpectedly. You might need to watch the ssh process and restart it if it dies.
For zope.org there is a private subnet. The boxes each have two network cards AFAIK. All ZEO communication takes place on the private subnet.
A VPN would also work, but you'd still have the local access issue.
Shane
Or you could wrap ZEO traffic with SSL using stunnel or a similar program, assuming they allow restriction of traffic based on client certificates. This doesn't have the drawbacks of SSH or VPN.
On Mon, 25 Mar 2002 12:19:11 -0500, Shane Hathaway shane@zope.com wrote:
There are some disadvantages: anybody who has an account on either zeoclient or zeostorage has full read/write access to the database.
A VPN would also work, but you'd still have the local access issue.
Hmm.... in this scenario we could protect against that if zeo supported passwords. Since the channel is encrypted we could get away with a plaintext password exchange too.
Toby Dickenson tdickenson@geminidataloggers.com
For a look at why TCP over TCP is a bad idea, (e.g. ssh port forwarding)
see: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
For a solution, see: http://sites.inka.de/~bigred/devel/cipe.html
;-)
Adam
Adam Manock wrote:
For a look at why TCP over TCP is a bad idea, (e.g. ssh port forwarding)
see: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
For a solution, see: http://sites.inka.de/~bigred/devel/cipe.html
That may be true, but it also means that you need to hook in at the kernel level, if I'm not mistaken.
At 08:14 AM 3/26/02, Itamar Shtull-Trauring wrote:
Adam Manock wrote:
For a look at why TCP over TCP is a bad idea, (e.g. ssh port forwarding)
see: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
For a solution, see: http://sites.inka.de/~bigred/devel/cipe.html
That may be true, but it also means that you need to hook in at the kernel level, if I'm not mistaken.
It seems that cipe now ships integrated with RedHat Linux, since at least RH7.1 No kernel building required!
(I haven't looked at it in a while, not since I was doing a VPN for a non profit. My current employer believes in the value of low latency point to point circuits ;-)
Looks like they've made it easier to use these days ...... http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/neat-ad...
Adam
On Tue, 26 Mar 2002 07:48:56 -0500, Adam Manock abmanock@earthlink.net wrote:
For a look at why TCP over TCP is a bad idea,
yeah, TCP inside TCP is bad.
(e.g. ssh port forwarding)
but ssh port forwarding is only one layer of TCP. ssh port forwarding is good.
For a solution, see: http://sites.inka.de/~bigred/devel/cipe.html
CIPE is good too.
Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
but ssh port forwarding is only one layer of TCP. ssh port forwarding is good.
I'mp pretty sure it's TCP over TCP (ssh protocol does multiplexing). SSL OTOH is not TCP over TCP.
Itamar Shtull-Trauring wrote:
Toby Dickenson wrote:
but ssh port forwarding is only one layer of TCP. ssh port forwarding is good.
I'mp pretty sure it's TCP over TCP (ssh protocol does multiplexing). SSL OTOH is not TCP over TCP.
I think you are mistaken. :-) The site you referred to says that TCP over TCP is a bad idea because TCP always assumes an unreliable transport, and stacking the compensation results in excessive retries and a far less reliable connection. I agree, this is likely to be a problem.
But you don't need reliability compensation to multiplex. SSH assumes the transport layer is reliable. So an SSH tunnel and an SSL tunnel are virtually synonymous.
Now, if ZEO accepted SSL connections directly, it would be quite secure and easy to use. But an out-of-process SSL tunnel would suffer from exactly the same difficulties an SSH tunnel does.
The Python standard library has good support for an SSL client but not for an SSL server.
Shane
Shane Hathaway wrote:
But you don't need reliability compensation to multiplex. SSH assumes the transport layer is reliable. So an SSH tunnel and an SSL tunnel are virtually synonymous.
They're not really, but yeah, I was wrong :)
A SSL forwarder takes a packet, and then sends over another TCP connection that happens to be encrypted. It's basically a TCP port forwarder. Multiple client connections through the local SSL forwarder (e.g. stunnel) will run over *multiple* outgoing streams:
client --> stunnel on localhost ---> stunnel on www.foo.com ----> server on www.foo.com
SSH OTOH uses a multiplexing protocol, where multiple streams of data run over the same connection, and each have their own flow control. Multiple client connections over a SSH port forwarder will run over the same *single* stream.
A third thing is TCP over TCP, i.e. PPP over SSH or SSL, which functions as a full network connection.
The Python standard library has good support for an SSL client but not for an SSL server.
pyOpenSSL is good for both servers and clients. Could be better, but it's easy to start using it, especially for select() based servers (its thread-safety is iffy). Twisted's SSL stuff uses it, and latest version of pyOpenSSL may have asyncore example.
At 12:01 PM 3/27/02, Itamar Shtull-Trauring wrote:
Shane Hathaway wrote:
But you don't need reliability compensation to multiplex. SSH assumes the transport layer is reliable. So an SSH tunnel and an SSL tunnel are virtually synonymous.
They're not really, but yeah, I was wrong :)
A SSL forwarder takes a packet, and then sends over another TCP connection that happens to be encrypted. It's basically a TCP port forwarder. Multiple client connections through the local SSL forwarder (e.g. stunnel) will run over *multiple* outgoing streams:
client --> stunnel on localhost ---> stunnel on www.foo.com ----> server on www.foo.com
SSH OTOH uses a multiplexing protocol, where multiple streams of data run over the same connection, and each have their own flow control. Multiple client connections over a SSH port forwarder will run over the same *single* stream.
A third thing is TCP over TCP, i.e. PPP over SSH or SSL, which functions as a full network connection.
The Python standard library has good support for an SSL client but not for an SSL server.
pyOpenSSL is good for both servers and clients. Could be better, but it's easy to start using it, especially for select() based servers (its thread-safety is iffy). Twisted's SSL stuff uses it, and latest version of pyOpenSSL may have asyncore example.
Yes. The best solution would be for the ZEO protocol to support auth and crypto natively... The next best solution (while you wait) is to use CIPE ;-)
As far as I understand it, even regular TCP port forwarding is TCP over TCP and suffers from the unreliable carrier assumption causing excess (eg retransmit) traffic over a reliable channel.
Consider: host <--TCP--> local interface <--TCP tunnel--> local interface <--TCP--> host host <--TCP--> virtual loopback interface <--TCP--> host
In this common port forwarding scenario, the SSH or SSL tunnel creates a virtual single loopback interface that the two hosts use to talk to each other, using TCP. The transport that joins these two physical interfaces to create one virtual loopback interface is also TCP. Therefore it's TCP over TCP
How much pain this will cause you in the real world really depends on your bandwidth and packet loss rates.
If anyone is aware of any special handling that ssh or stunnel does to prevent or reduce duplicate TCP flow control / adaptive retransmission / congestion control, please let me know.
Adam
Adam Manock wrote:
Yes. The best solution would be for the ZEO protocol to support auth and crypto natively... The next best solution (while you wait) is to use CIPE ;-)
As far as I understand it, even regular TCP port forwarding is TCP over TCP and suffers from the unreliable carrier assumption causing excess (eg retransmit) traffic over a reliable channel.
Out of interest, could you elaborate that? I assume you mean port forwarding (without the TCP), which, AFAIK, just is a rewriting of some IP/UDP header information and some, uhm, forwarding. I am not aware of any encapsulation taking place. I quite sure that this isn't the case, because, after all, we can talk to a "normal" tcp/udp server on the ipaddress:port which we forward to. We can also port forward udp-traffic. SSL then adds another layer between transport and application, but it explicitly needs a reliable transport protocol underneath (e.g. TCP).
Consider: host <--TCP--> local interface <--TCP tunnel--> local interface <--TCP--> host host <--TCP--> virtual loopback interface <--TCP--> host
In this common port forwarding scenario, the SSH or SSL tunnel creates a virtual single loopback interface that the two hosts use to talk to each other, using TCP. The transport that joins these two physical interfaces to create one virtual loopback interface is also TCP. Therefore it's TCP over TCP
No, it isn't. You can use something like stunnel to https-"enable" non-https capable http-clients, stunnel -c -d 80 -r ssl-server:443 now go to http://localhost Try it, it's fun ;-).
cheers, oliver
Yes. The best solution would be for the ZEO protocol to support auth and crypto natively...
+10 (At least)
The next best solution (while you wait) is to use CIPE ;-)
Could be, if you can: a) Get your customers to run a platform it's been ported to b) Run something so low level that is esentially replacing functionality that is already in their kernels.
Anyone here want to try to explain to *ahem* technically non-expert *ahem* clients why PPTP is bad (Inspite of _all_ major and minor OS's now bundling support for it).
As far as I understand it, even regular TCP port forwarding is TCP over
TCP
and suffers from the unreliable carrier assumption causing excess (eg retransmit) traffic over a reliable channel.
By port-forwarding you mean... ? a) A firewall PC that receives an external connection and reroutes it to a machine on the inside? No, this is not TCP/TCP. b) An apache that takes a connection and forwards it to Zope? No, this is not TCP/TCP.
What "port forwarding" are we talking about here?
Consider: host <--TCP--> local interface <--TCP tunnel--> local interface <--TCP-->
host
host <--TCP--> virtual loopback interface <--TCP--> host
In this common port forwarding scenario, the SSH or SSL tunnel creates a virtual single loopback interface that the two hosts use to talk to each other, using TCP. The transport that joins these two physical interfaces to create one virtual loopback interface is also TCP. Therefore it's TCP over TCP
If you insist on using User Land utils for Kernel Land functions, this will be the result IMHO.
Just my 0.02c, YMMV
Adrian...
Toby Dickenson wrote:
On Mon, 25 Mar 2002 12:19:11 -0500, Shane Hathaway shane@zope.com wrote:
There are some disadvantages: anybody who has an account on either zeoclient or zeostorage has full read/write access to the database.
A VPN would also work, but you'd still have the local access issue.
Hmm.... in this scenario we could protect against that if zeo supported passwords. Since the channel is encrypted we could get away with a plaintext password exchange too.
Yes, you're right, thanks! We should add this to ZEO.
Shane
-
Adam Manock -
Adrian Hungate -
Dirk Datzert -
Eric Roby -
Itamar Shtull-Trauring -
Oliver Bleutgen -
Shane Hathaway -
Toby Dickenson