mtrojnar

Did you really want to discuss your results "ahead of time"? You could easily do it before publishing them. My email address is in the manual of stunnel.

I could argue whether an old Ubuntu package is "out of the box" stunnel, or whether sending 20mbit stream of compressed video is really the most common use of stunnel...

1. It's you who started the flame by publishing your obviously unfair comparison.

2. I didn't receive your email (if you really sent it).

3. Stunnel overrides the OpenSSL default of enabling compression by default since version 4.51 released over a month ago http://www.stunnel.org/?page=sdf_ChangeLog

4. Whether compression is useful or not depends on many factors, including not only type of data, but also available bandwidth and CPU power. And data compression is not an illusion. I'd be afraid to use your products if you don't understand it.

5. Compression is indeed much slower than encryption. This is a fact. Do you really mean that your product is better just because it doesn't support compression?

6. Stunnel is indeed a performance bottleneck, but only if your internet connection is over 0.5Gbps, and your server is as slow as my desktop: http://www.stunnel.org/?page=perf

Testing results indicated that stunnel was much faster than the line speed (and thus faster than his own product), but the author simply ignored it. In fact his version of stunnel had DEFLATE/ZLIB compression enabled by default. In order to prove that his own product is better than stunnel, the author of this test decided to compare the bandwith of an uncompressed stream encrypted with his product with the bandwidth of a compressed stream encrypted with stunnel.

Real SSL clients are supposed to use SSL session resumption. Benchmarking with a client that only negotiates new sessions hardly reflects real-life usage.