I have the following kind of test environment: SSL clients call a public ip address from which the calls are forwarded to a linux server with Stunnel. The linux server is in a private network. Stunnel decrypts the data and sends it forward.
I have been testing this with a browser, monitoring the traffic on the server to see that Stunnel forwards the calls. Some strange things happen there that I can't explain. First of all: sometimes the calls go through the server as expected, sometimes the server doesn't respond in any way to the client. If I have two terminal windows open, one with tcpdump and another with tail -f stunnel.log - nothing comes into the log in spite of the incoming connections attempts.
Then on other occasions when the calls come to the server, it forwards them beautifully to the address and port set in the configuration file.
Does anyone have any clue, what this could be due to? I haven't been able to explain why it sometimes works and sometimes doesn't.
Another thing that bothers me is, that sometimes there are TCP frames with incorrect checksum. I've monitored with Ethereal and tcpdump. Both show incorrect frames, and they are always from the stunnel-end of the connection. What could be the cause of those broken frames?
Tommi Nieminen
-------------------------------------------------------- My stunnel.conf looks like this: (any constructive criticism would be welcome :-))
CAfile = /home/tommi/cert/7/demoCA/cacert.pem cert = /home/tommi/cert/7/newcert.pem key = /home/tommi/cert/7/newkey.pem
socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1
output = /var/log/stunnel/stunnel.log pid = /var/run/stunnel/stunnel.pid debug = 7 client = no
[https] accept = 443 connect = 192.168.10.17:5010 TIMEOUTclose = 0
-------------------------------------------------------- A succesful connection from stunnel.log:
2006.10.09 18:01:43 LOG7[11889:3083744960]: https accepted FD=7 from 131.177.254.92:2689 2006.10.09 18:01:43 LOG7[11889:3083742128]: https started 2006.10.09 18:01:43 LOG7[11889:3083742128]: FD 7 in non-blocking mode 2006.10.09 18:01:43 LOG7[11889:3083742128]: TCP_NODELAY option set on local socket 2006.10.09 18:01:43 LOG5[11889:3083742128]: https connected from 131.177.254.92:2689 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): before/accept initialization 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 read client hello A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 write server hello A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 write certificate A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 write server done A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 flush data 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 read client key exchange A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 read finished A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 write change cipher spec A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 write finished A 2006.10.09 18:01:43 LOG7[11889:3083742128]: SSL state (accept): SSLv3 flush data 2006.10.09 18:01:43 LOG7[11889:3083742128]: 2 items in the session cache 2006.10.09 18:01:43 LOG7[11889:3083742128]: 0 client connects (SSL_connect()) 2006.10.09 18:01:43 LOG7[11889:3083742128]: 0 client connects that finished 2006.10.09 18:01:43 LOG7[11889:3083742128]: 0 client renegotiations requested 2006.10.09 18:01:43 LOG7[11889:3083742128]: 8 server connects (SSL_accept()) 2006.10.09 18:01:43 LOG7[11889:3083742128]: 7 server connects that finished 2006.10.09 18:01:43 LOG7[11889:3083742128]: 0 server renegotiations requested 2006.10.09 18:01:43 LOG7[11889:3083742128]: 4 session cache hits 2006.10.09 18:01:43 LOG7[11889:3083742128]: 1 session cache misses 2006.10.09 18:01:43 LOG7[11889:3083742128]: 1 session cache timeouts 2006.10.09 18:01:43 LOG6[11889:3083742128]: SSL accepted: new session negotiated 2006.10.09 18:01:43 LOG6[11889:3083742128]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 2006.10.09 18:01:43 LOG7[11889:3083742128]: FD 8 in non-blocking mode 2006.10.09 18:01:43 LOG7[11889:3083742128]: https connecting 192.168.10.17:5010 2006.10.09 18:01:43 LOG7[11889:3083742128]: connect_wait: waiting 10 seconds 2006.10.09 18:01:43 LOG7[11889:3083742128]: connect_wait: connected 2006.10.09 18:01:43 LOG7[11889:3083742128]: Remote FD=8 initialized 2006.10.09 18:01:43 LOG7[11889:3083742128]: TCP_NODELAY option set on remote socket 2006.10.09 18:02:45 LOG7[11889:3083742128]: Socket closed on read 2006.10.09 18:02:45 LOG7[11889:3083742128]: SSL write shutdown 2006.10.09 18:02:45 LOG7[11889:3083742128]: SSL alert (write): warning: close notify 2006.10.09 18:02:45 LOG7[11889:3083742128]: SSL_shutdown retrying 2006.10.09 18:02:45 LOG7[11889:3083742128]: SSL doesn't need to read or write 2006.10.09 18:02:45 LOG6[11889:3083742128]: s_poll_wait timeout: connection close 2006.10.09 18:02:45 LOG5[11889:3083742128]: Connection closed: 0 bytes sent to SSL, 405 bytes sent to socket 2006.10.09 18:02:45 LOG7[11889:3083742128]: https finished (0 left)
(and the failed connections leave also no mark in the log, but tcpdump sees the attempts on the server)
-------------------------------------------------------- A sample of tcpdump's output with incorrect checksum:
18:02:45.150656 IP (tos 0x0, ttl 64, id 11218, offset 0, flags [DF], proto: TCP (6), length: 77) 192.168.20.18.https > 131.177.254.92.2689: P, cksum 0x5708 (incorrect (-> 0xf1bf), 1035:1072(37) ack 756 win 7504