stunnel-users

8 participants
3311 discussions

Re: [stunnel-users] How can stunnel use openssl HW cryptodev encryption
by Eric Eberhard 28 Jan '19

28 Jan '19

I'll give you two pieces of advice that almost everyone on the list won't agree with :) 1) Make a static openssl and static stunnel and locate them someplace apart from the standard locations (/usr/local/company_name/lib is what I use). This means if anyone messes with openssl or stunnel you won't be affected - and it will always work as it is static - and part of your application - the user does not even need your libraries. I have a personal distaste for dynamic linking . mostly because I have a lot of customers that update a lot of things (including openssl - a lot - and stunnel sometimes) . and then wonder why things stop working. A 10 year old openssl and stunnel - all static - will still run and work fine past all updates and user messing around. I choose when I want to update openssl and stunnel (meaning I look to see if there is something new I need or want). As a result I missed the keep alive and poodle bugs - I did not update until after both were fixed. 2) Forget hardware implementation - geez - modern computers are so darn fast that I cannot imagine you really need that level of "speed up" versus the grief you are handling. I have customers that exchange millions (4+) XML documents a day, all through stunnel, all through inetd (also not efficient supposedly - just reliable and always works and needs no management) - and have no problems. I am using IBM p Series (AIX) and these machines even at the low level are fast . but I also use some SCO and Linux and certainly with lesser volume they are fine as well. 3) OK - 3 is really - use inetd, so much easier and always works (assuming you have Unix). If inetd crashes Unix crashes so . see number 2 for reasons :) Of course, these ideas won't help much if you don't have a Unix variation or if you are really that tight on performance (although if you are I'd suggest hardware upgrades!). Good luck with your project, Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Tamar Pedersen Sent: Wednesday, January 16, 2019 1:06 PM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] How can stunnel use openssl HW cryptodev encryption Hello, I am evaluating stunnel, to see if it is a viable solution for providing encryption in a system that contains an Atmel processor which includes a HW accelerated encryption block. I am just ramping up on stunnel, and figured I should capture what I have done so far. My questions will come towards the end of my email. My research indicates that stunnel incorporates openssl. I have been able to use openssl independently, to access the cryptodev HW encryption engine, in the Linux kernel module located in /lib/modules/4.14.79/extra/cryptodev.ko. When openssl is run without accessing the cryptodev engine (cryptodev module not loaded), I get the pure SW encryption implementation provided by default in openssl. When I run bench mark speed tests using openssl, using SW encryption, I see the following results: # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 1689887 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 64 size blocks: 568389 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 256 size blocks: 151550 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 1024 size blocks: 38599 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 8192 size blocks: 4845 aes-128-cbc's in 2.95s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_leg acy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 9165.49k 12331.15k 13107.03k 13353.17k 13454.32k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 14.81 System time (seconds): 0.10 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.06s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13376 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 145 Voluntary context switches: 0 Involuntary context switches: 721 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # When I load the cryptodev module, and take advantage of the accelerated hardware encryption the benchmark tests are significantly faster. Here is what those results look like. # modprobe cryptodev # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 44163 aes-128-cbc's in 0.12s Doing aes-128-cbc for 3s on 64 size blocks: 31345 aes-128-cbc's in 0.15s Doing aes-128-cbc for 3s on 256 size blocks: 18923 aes-128-cbc's in 0.11s Doing aes-128-cbc for 3s on 1024 size blocks: 13847 aes-128-cbc's in 0.13s Doing aes-128-cbc for 3s on 8192 size blocks: 8427 aes-128-cbc's in 0.06s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_leg acy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 5888.40k 13373.87k 44038.98k 109071.75k 1150566.40k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 0.59 System time (seconds): 8.72 Percent of CPU this job got: 61% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.11s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13792 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 144 Voluntary context switches: 41154 Involuntary context switches: 3321 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # As can be seen in the results (hi-lighted in red), the average speed to do aes-128-cbc encryption jumped from around 2.95 s to 0.10 s. Also of interest is the context switches are significantly higher when running hardware encryption, because of interrupts and overhead to use the hardware engine. I can also look at /proc/interrupts and see significant increases in atmel-aes interrupt counts when using the cryptodev HW acceleration encryption engine. This gives a good indication that the cryptodev module is in use, and is doing encryption. I would like to try to figure out how to allow stunnel to take advantage of the cryptodev HW acceleration encryption engine available in openssl. I have made some attempts, but so far, I have not been able to determine if stunnel is successfully using the cryptodev engine. Here is what I have done with stunnel. I already have a client and server successfully communicating with each other using stunnel. To verify this I used the "nc" utility to send characters back and forth between two different machines. The stunnel.conf file, on the server, is out of the box. I'm interested in encrypting on the client side. Here is my current client.conf file, in /etc/stunnel: # cat client.conf debug = 7 output = /tmp/stunnel-server.log pid = /tmp/stunnel.pid engine = cryptodev [test] verify = 1 client = yes accept = 127.0.0.1:2000 connect = 192.168.0.220:30000 CAfile = /etc/stunnel/certificate.crt engineNum = 1 # I am attempting to set up the cryptodev to be the configured engine for the client. I am able to start stunnel, using client.conf, as follows: # stunnel /etc/stunnel/client.conf # If I do a "ps" command to display processes, I can see that stunnel is running in the background. At this point, I can use "nc" to send data, as follows: # nc 127.0.0.1 2000 < /tmp/long_file.txt I am able to see the text from long_file.txt on the server, which is also running nc. The problem is that I don't see interrupts increasing in /proc/interrupts, which leaves me wondering if I have not configured stunnel correctly to use the cryptodev engine. If I try to remove the cryptodev module as this point, while stunnel is running, I receive a message that it is in use, as follows: # modprobe -r cryptodev modprobe: FATAL: Module cryptodev is in use. # If I kill the stunnel process, I am able to successfully remove the cryptodev module, which seems to suggest stunnel is the process using the cryptodev module. Also, once I have removed the cryptodev module, I can't restart stunnel. Instead, I get the following errors back: # stunnel /etc/stunnel/client.conf [.] stunnel 5.44 on arm-buildroot-linux-gnueabi platform [.] Compiled/running with OpenSSL 1.0.2p-fips 14 Aug 2018 [.] Threading:FORK Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*__errno_location ()) [.] Reading configuration from file /etc/stunnel/client.conf [.] UTF-8 byte order mark not detected [ ] Enabling support for engine "cryptodev" [!] error queue: 2606A074: error:2606A074:engine routines:ENGINE_by_id:no such engine [!] error queue: 260B6084: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found [!] error queue: 25070067: error:25070067:DSO support routines:DSO_load:could not load the shared library [!] ENGINE_by_id: 25066067: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library [!] /etc/stunnel/client.conf:5: "engine = cryptodev": Failed to open the engine # Again, this suggests stunnel is trying to use cryptodev. I just don't know how to prove I am taking advantage of the HW encryption acceleration engine. I never see interrupts updating in /proc/interrupts when using nc, while stunnel is running. So, here are my questions: 1.) Does it look like I have things set up correctly in client.conf, to use the cryptodev engine? 2.) If client.conf is correct, how can I prove that stunnel is using the cryptodev engine, since I don't see the expected interrupts? One idea is that the cryptodev module might not support the type of encryption being requested by the certificate, so openssl falls back to the pure SW encryption implementation. I know the Atmel chip in question supports the following: # openssl engine -t -c (cryptodev) cryptodev engine [RSA, DSA, DH, DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, MD5, SHA1, SHA256, SHA384, SHA512] [ available ] (dynamic) Dynamic engine loading support [ unavailable ] # I was able to decode the contents of the certificate, and it says it is sha256WithRSAEncryption. My engine supports SHA256 and RSA, but does it support combining, like SHA256WithRSA? I'm not sure. I'll keep chasing that one. Thanks for any guidance on how to use the cryptodev in stunnel. Regards, Tamar

2 2

Max Performance of Stunnel
by Luis Monteiro 21 Jan '19

21 Jan '19

I'm testing Stunnel with Ixia traffic generator (Breakingpoint Virtual Edition) and I got a limited performance of 3.5Gbps full duplex even with 6 or 9 cpu in the esxi vm. The processors are fully dedicated as well memory all reserved with passthrough od network cards intel x540 10Gbps, 2 ports. The 2 vm are similar with one running stunnel client and the other as stunnel server. The page performance of Stunnel of 5.5Gbps but doesn't inform if it's half or full since in the operation the stunnel has to deal with 2 flow coming and going. If it was 5.5Gbps total makes sense since I'm using 2 x Scalable Gold 6140 and gave me 7Gbps encryption + decryption with AES-NI I think since we are not a feasible solution to check on the fly only the overall performance. I'm using the same cipher suit of performance information of Stunnel. Does anyone know if the performance numbers is considering the total performance or full duplex? Does someone have any tip to improve the performance? Thanks, Luis Monteiro

1 0

Transparente destination
by Luis Monteiro 17 Jan '19

17 Jan '19

Sirs. I tested the stunnel client connect to a stunnel server to proxy transparent a http traffic. I used a traffic generator from Ixia (BPS), a tap to get the traffic between stunnel´s using ntop license pf_ring (Kernel bypass) with tcpdump accessing their libs and export pcaps from source and destination from Ixia. Transparent source worked flawless easily using the information on man page. Transparent destination didn´t worked. The instructions in the stunnel documentation for each are: /sbin/iptables -I INPUT -i client_interface -p tcp --dport 443 (I´m using default port os https) -j ACCEPT ----- It is filter INPUT that is executed after routing decision after nat to allow packets with destination port 443 /sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 (Destination port of http in client_interface \ -i client_interface -j DNAT --to-destination 9.0.0.2:443 (connect destination on server Stunnel) The second input in iptables is executed before the routing decision and that is the problem. Looking the hit count of in iptables the nat table PREROUTING always have a hit but the filter table filter INPUT doesn´t. I set a policy routing to delivey packets to 9.0.0.2:443 to local process and the filter table filter INPUT started to receive the hit in the counters as well but stunnel didn´t worked. If I change the connect destination address to local interface 9.0.0.1:443 I do not need the pocily routing since it´s local but Stunnel did not worked too. The stunnel configuration for the client is bellow: #setgid = root #setuid = root debug = 7 log = overwrite syslog = no output = /root/stunnel.log ;engine = ENGINE_ID ;engineCtrl = COMMAND[:PARAMETER] ;engineDefault = TASK_LIST [http] client = yes accept = 6.0.0.1:80 ;connect = 9.0.0.2:443 ciphers = AES128-GCM-SHA256 requireCert = no sslVersion = TLSv1.2 transparent = destination At the end I´d like to use both source and destination but I´m testing separated. Does anyone know if there is a bug related or if there is a version working fine? Even with a lot o resource I don´t have more what to do about and any help would be appreciated. Luis Monteiro

1 0

How can stunnel use openssl HW cryptodev encryption
by Tamar Pedersen 16 Jan '19

16 Jan '19

Hello, I am evaluating stunnel, to see if it is a viable solution for providing encryption in a system that contains an Atmel processor which includes a HW accelerated encryption block. I am just ramping up on stunnel, and figured I should capture what I have done so far. My questions will come towards the end of my email. My research indicates that stunnel incorporates openssl. I have been able to use openssl independently, to access the cryptodev HW encryption engine, in the Linux kernel module located in /lib/modules/4.14.79/extra/cryptodev.ko. When openssl is run without accessing the cryptodev engine (cryptodev module not loaded), I get the pure SW encryption implementation provided by default in openssl. When I run bench mark speed tests using openssl, using SW encryption, I see the following results: # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 1689887 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 64 size blocks: 568389 aes-128-cbc's in 2.95s Doing aes-128-cbc for 3s on 256 size blocks: 151550 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 1024 size blocks: 38599 aes-128-cbc's in 2.96s Doing aes-128-cbc for 3s on 8192 size blocks: 4845 aes-128-cbc's in 2.95s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_legacy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 9165.49k 12331.15k 13107.03k 13353.17k 13454.32k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 14.81 System time (seconds): 0.10 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.06s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13376 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 145 Voluntary context switches: 0 Involuntary context switches: 721 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # When I load the cryptodev module, and take advantage of the accelerated hardware encryption the benchmark tests are significantly faster. Here is what those results look like. # modprobe cryptodev # time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 44163 aes-128-cbc's in 0.12s Doing aes-128-cbc for 3s on 64 size blocks: 31345 aes-128-cbc's in 0.15s Doing aes-128-cbc for 3s on 256 size blocks: 18923 aes-128-cbc's in 0.11s Doing aes-128-cbc for 3s on 1024 size blocks: 13847 aes-128-cbc's in 0.13s Doing aes-128-cbc for 3s on 8192 size blocks: 8427 aes-128-cbc's in 0.06s OpenSSL 1.0.2p-fips 14 Aug 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: arm-laird-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/home/sii/wb50n_space2_legacy_6.0.0.x/wb/buildroot/output/wb50n_space2_legacy/host/arm-buildroot-linux-gnueabi/sysroot/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 5888.40k 13373.87k 44038.98k 109071.75k 1150566.40k Command being timed: "openssl speed -evp aes-128-cbc" User time (seconds): 0.59 System time (seconds): 8.72 Percent of CPU this job got: 61% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.11s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 13792 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 144 Voluntary context switches: 41154 Involuntary context switches: 3321 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # As can be seen in the results (hi-lighted in red), the average speed to do aes-128-cbc encryption jumped from around 2.95 s to 0.10 s. Also of interest is the context switches are significantly higher when running hardware encryption, because of interrupts and overhead to use the hardware engine. I can also look at /proc/interrupts and see significant increases in atmel-aes interrupt counts when using the cryptodev HW acceleration encryption engine. This gives a good indication that the cryptodev module is in use, and is doing encryption. I would like to try to figure out how to allow stunnel to take advantage of the cryptodev HW acceleration encryption engine available in openssl. I have made some attempts, but so far, I have not been able to determine if stunnel is successfully using the cryptodev engine. Here is what I have done with stunnel. I already have a client and server successfully communicating with each other using stunnel. To verify this I used the "nc" utility to send characters back and forth between two different machines. The stunnel.conf file, on the server, is out of the box. I'm interested in encrypting on the client side. Here is my current client.conf file, in /etc/stunnel: # cat client.conf debug = 7 output = /tmp/stunnel-server.log pid = /tmp/stunnel.pid engine = cryptodev [test] verify = 1 client = yes accept = 127.0.0.1:2000 connect = 192.168.0.220:30000 CAfile = /etc/stunnel/certificate.crt engineNum = 1 # I am attempting to set up the cryptodev to be the configured engine for the client. I am able to start stunnel, using client.conf, as follows: # stunnel /etc/stunnel/client.conf # If I do a "ps" command to display processes, I can see that stunnel is running in the background. At this point, I can use "nc" to send data, as follows: # nc 127.0.0.1 2000 < /tmp/long_file.txt I am able to see the text from long_file.txt on the server, which is also running nc. The problem is that I don't see interrupts increasing in /proc/interrupts, which leaves me wondering if I have not configured stunnel correctly to use the cryptodev engine. If I try to remove the cryptodev module as this point, while stunnel is running, I receive a message that it is in use, as follows: # modprobe -r cryptodev modprobe: FATAL: Module cryptodev is in use. # If I kill the stunnel process, I am able to successfully remove the cryptodev module, which seems to suggest stunnel is the process using the cryptodev module. Also, once I have removed the cryptodev module, I can't restart stunnel. Instead, I get the following errors back: # stunnel /etc/stunnel/client.conf [.] stunnel 5.44 on arm-buildroot-linux-gnueabi platform [.] Compiled/running with OpenSSL 1.0.2p-fips 14 Aug 2018 [.] Threading:FORK Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*__errno_location ()) [.] Reading configuration from file /etc/stunnel/client.conf [.] UTF-8 byte order mark not detected [ ] Enabling support for engine "cryptodev" [!] error queue: 2606A074: error:2606A074:engine routines:ENGINE_by_id:no such engine [!] error queue: 260B6084: error:260B6084:engine routines:DYNAMIC_LOAD:dso not found [!] error queue: 25070067: error:25070067:DSO support routines:DSO_load:could not load the shared library [!] ENGINE_by_id: 25066067: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library [!] /etc/stunnel/client.conf:5: "engine = cryptodev": Failed to open the engine # Again, this suggests stunnel is trying to use cryptodev. I just don't know how to prove I am taking advantage of the HW encryption acceleration engine. I never see interrupts updating in /proc/interrupts when using nc, while stunnel is running. So, here are my questions: 1.) Does it look like I have things set up correctly in client.conf, to use the cryptodev engine? 2.) If client.conf is correct, how can I prove that stunnel is using the cryptodev engine, since I don't see the expected interrupts? One idea is that the cryptodev module might not support the type of encryption being requested by the certificate, so openssl falls back to the pure SW encryption implementation. I know the Atmel chip in question supports the following: # openssl engine -t -c (cryptodev) cryptodev engine [RSA, DSA, DH, DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, MD5, SHA1, SHA256, SHA384, SHA512] [ available ] (dynamic) Dynamic engine loading support [ unavailable ] # I was able to decode the contents of the certificate, and it says it is sha256WithRSAEncryption. My engine supports SHA256 and RSA, but does it support combining, like SHA256WithRSA? I'm not sure. I'll keep chasing that one. Thanks for any guidance on how to use the cryptodev in stunnel. Regards, Tamar

1 0

Stunnel in transparent mode
by Luis Monteiro 15 Jan '19

15 Jan '19

Hi fellows. I´m from Brazil and I´m trying to use Stunnel as a TLS proxy in a bed test environment. I´m using a traffic generator from Ixia (Breakingpoint). The bed test is: |-------------------| 6.0.0.1 |-------------------|9.0.0.1 9.0.0.2|--------------------|7.0.0.2 |--------------------| | Client 6.0.0.2 |>>>>>>>>>>>>| Stunnel Client|>>>>>>>>>>>>>>>>>>| Stunnel Server|>>>>>>>>>>>>>>>>>> | Server 7.0.0.2 | |-------------------| ens224 |-------------------|ens192 ens224|--------------------|ens192 |--------------------| I´m capturing the packets in all 3 points so I can see exactly what is happening. I tested without transparent proxy and worked fine. I test with transparent = source with the additional conf bellow in both Stunnel and worked fine as well. iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 echo 0 >/proc/sys/net/ipv4/conf/lo/rp_filter iptables -t nat -A PREROUTING -i ens224 -p tcp --dport 80 -j DNAT --to-destination 6.0.0.1:8080 I tested transparent = destination with several modification from the config bellow without success. No conf delivery packets with 7.0.0.2:443 on the Stunnel Client ens192 via 9.0.0.1 to be accept on Stunnel server 9.0.0.2:443. /sbin/iptables -I INPUT -i ens192 -p tcp --dport 8080 -j ACCEPT /sbin/iptables -t nat -I PREROUTING -p tcp --dport 443 \ -i ens192 -j DNAT --to-destination 9.0.0.1:443 Any help to show me what is wrong would be appreciated. Thanks in advanced, Luis Monteiro

1 0

Re: [stunnel-users] No more addresses to connect
by Eric Eberhard 14 Jan '19

14 Jan '19

Could be the versions of communication are different – from SSLv3 to TLS1.3 … Having said that, there is NO REASON to use stunnel and a VPN – both encrypt data. You only need to encrypt it once … so I’d change your software to behave differently via VPN or not. Eric From: stunnel-users [mailto:[email protected]] On Behalf Of Ben Habel Sent: Monday, January 07, 2019 7:32 PM To: stunnel-users(a)stunnel.org Subject: [stunnel-users] No more addresses to connect I am trying to implement an openvpn + stunnel vpn with a Linux host server and a windows client, i have everything connecting when alone but when I connect openvpn over Stunnel i get and error that says: 2019.01.07 21:18:50 LOG5[0]: Service [openvpn] accepted connection from 127.0.0.1:49343 <http://127.0.0.1:49343> 2019.01.07 21:19:15 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2019.01.07 21:19:20 LOG5[2]: Service [openvpn] accepted connection from 127.0.0.1:49380 <http://127.0.0.1:49380> 2019.01.07 21:19:30 LOG3[2]: s_connect: s_poll_wait 74.215.118.189:1194 <http://74.215.118.189:1194> : TIMEOUTconnect exceeded 2019.01.07 21:19:30 LOG3[2]: No more addresses to connect And this error will loop until I disable the openvpn connection. Any help would be appreciated. Thanks

2 1

Re: [stunnel-users] older browsers, stunnel and privoxy
by Eric Eberhard 14 Jan '19

14 Jan '19

Sure it can. Inetd is simply a "server" and stunnel works in inetd mode or server mode. When not using inetd, stunnel does the server work. When using inetd then inetd does the server work. In both cases the actual "instance" of stunnel is the same. And inetd always works (or essentially Unix does not). It is milliseconds slower in inetd (and unless you are doing millions of connections nobody will notice) but way more reliable in my experience. Eric -----Original Message----- From: stunnel-users [mailto:[email protected]] On Behalf Of Peter Pentchev Sent: Friday, January 04, 2019 8:06 AM To: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] older browsers, stunnel and privoxy On Thu, Jan 03, 2019 at 02:45:30PM -0700, Eric Eberhard wrote: > Observation: you accept on port 80 ... the log says 4121 ... any > chance you have some sort of port forwarding/NAT/firewall/router issue? Just for the record (I already answered the question in another message), the log says that the client - the program that was talking to stunnel, presumably some kind of web browser - connected *to* stunnel *from* the (ephemeral) port 4121. > Second -- if you are on Unix why not just use inetd? Easy, reliable, > simple, always works (if inetd goes down you have no Unix). And you > have nothing to manage -- just logs to look at. The inetd and stunnel tools serve different purposes - inetd cannot, by itself, proxy between a plaintext and a TLS/SSL connection. > Happy New Year > > Eric Same! G'luck, Peter > -----Original Message----- > From: stunnel-users [mailto:[email protected]] On > Behalf Of kovacs janos > Sent: Saturday, December 29, 2018 7:37 PM > To: Javier <jamilist.stn(a)gmx.es> > Cc: stunnel-users(a)stunnel.org > Subject: Re: [stunnel-users] older browsers, stunnel and privoxy > > it still doesnt seem to work. i tried it with deviantart.com again. > configuration: > client = yes > accept = 127.0.0.1:80 > connect = 52.85.220.247:443 > verifyChain = yes > CAfile = ca-certs.pem > checkHost = *.deviantart.com > > the name after checkHost is the "Common Name" displayed when viewing the site's certificate in a browser(lock icon, view certificate). i also saved the certificate in case i would need to try the "certificate pinning" method. the connect IP is what 'get-site-ip.com' > says the IP of the website is. > > these are the logs: > Service [fbsd-www] accepted connection from 127.0.0.1:4121 > s_connect: connected 52.85.220.247:443 Service [fbsd-www] connected > remote server from 192.168.0.3:4122 > SSL_connect: 14077410: error:14077410:SSL > routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure > Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket > > i know i pestered everyone long enough, but i still havent been able > to connect to anything. without any verification its the same > > On 12/21/18, Javier <jamilist.stn(a)gmx.es> wrote: > > On Fri, 21 Dec 2018 13:58:35 +0200 > > Peter Pentchev <roam(a)ringlet.net> wrote: > > > >> Hm, there's no reason why stunnel would not work like that for a > >> predetermined set of hosts with known addresses. > > > > Hi, > > > > I'm just trying to avoid encouraging him on keep with his first idea > > of browsing through Stunnel, with, or without privoxy. > > > > Of course one site, one connection would work, if we forget about > > secondary issues and..., nevermind... > > > > I give up :D > > > > Regards. > > > > > > _______________________________________________ > > stunnel-users mailing list > > stunnel-users(a)stunnel.org > > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users > > > _______________________________________________ > stunnel-users mailing list > stunnel-users(a)stunnel.org > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users > > > _______________________________________________ > stunnel-users mailing list > stunnel-users(a)stunnel.org > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users -- -- Peter Pentchev roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

1 0

Could stunnel encryption be responsible for rendering the year as "4019" instead of "2019"?
by Al Birchall 09 Jan '19

09 Jan '19

Hi All, This may be stupid question, but I'll pose it anyway! We use stunnel to encrypt communications between library self-service kiosks and a cloud-based library system. Since switching to this cloud-based library system, the self-service kiosks have been rendering the year in item due dates as "4019" instead of "2019" printed and emailed patron library account statements. Items will actually have been checked out to the correct due date in library system, with the year displayed correctly, which library staff and patrons can see is so when they access the system directly. We have fixed the problem with a work-around by configuring the kiosk software to only display the last two digits of the year. So could it be the stunnel encryption algorithms that are causing "2019" to display as "4019"? Many thanks! Alex Alex Birchall Library Systems Manager The Sheppard Library Middlesex University London NW4 4BT UK Tel: +44 (0)20 8411 5235 Mob: 07765 237 570

2 1

Internal Errors
by _ Ånüßås _ 08 Jan '19

08 Jan '19

Hello, I would like to report two bugs. I recently upgraded to stunnel 5.50 on FreeBSD 12.0 and noticed that the stunnel server service now crashes periodically. When checking the logs after a crash, I see the following error: INTERNAL ERROR: Dead canary at /usr/src/crypto/openssl/ssl/statem/extensions_sr The stunnel server service only ever talks to a stunnel client service, also running version 5.50 on FreeBSD 12.0. The server configuration is as follows. Anything in {} brackets has been redacted. I have seen this issue on multiple servers configured the same way. <config> client = no setuid = stunnel setgid = stunnel pid = {/path/to/file} output = {/path/to/file} debug = 4 socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 [server] accept = {ip}:{port} connect = {ip}:{port} ciphers = PSK PSKsecrets = {/path/to/file} </config> Additionally, I have noticed another error in the logs. Although it appears far more frequently than the error above, it does not seem to cause the server service to crash. INTERNAL ERROR: Double free attempt: ptr=0x802119050 alloc=/usr/src/crypto/openssl/crypto/stack/stack.c:198 free#1=/usr/src/crypto/openssl/crypto/stack/stack.c:376 free#2=/usr/src/crypto/openssl/ssl/ssl_sess.c:814 Please let me know if additional information is needed to fix these bugs. Thank you.

1 0

No more addresses to connect
by Ben Habel 08 Jan '19

08 Jan '19

I am trying to implement an openvpn + stunnel vpn with a Linux host server and a windows client, i have everything connecting when alone but when I connect openvpn over Stunnel i get and error that says: 2019.01.07 21:18:50 LOG5[0]: Service [openvpn] accepted connection from 127.0.0.1:49343 2019.01.07 21:19:15 LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2019.01.07 21:19:20 LOG5[2]: Service [openvpn] accepted connection from 127.0.0.1:49380 2019.01.07 21:19:30 LOG3[2]: s_connect: s_poll_wait xx.xxx.xxx.xxx:1194: TIMEOUTconnect exceeded 2019.01.07 21:19:30 LOG3[2]: No more addresses to connect And this error will loop until I disable the openvpn connection. Any help would be appreciated. Thanks

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users