Oh, sorry for the messed markup.
The same without markup:

1) Make default TCP send buffer less than wget send buffer (which is 8192):
echo "4096 4096 4096" > /proc/sys/net/ipv4/tcp_wmem

2) Generate a sample file larger than TCP send buffer:
dd if=/dev/urandom of=./qqq.junk bs=10M count=1

3) Setup firewall rules to drop large outgoing packets to allow for successful SSL handshake while blocking bulk uploads:
iptables -I OUTPUT -d <your_https_server> -m length --length 1000:1500 -j DROP

4) Run wget to send bulk data:
wget --timeout=10 --tries=1 --post-file qqq.junk -O /dev/null --no-check-certificate 'https://<your_https_server>'

5) Observe wget ignoring the 10 second timeout.

Needs to wait on disclaimer papers. :(

I ran into this today in 1.11.  I applied John's patch, but I was seeing it hang past the handshake during reads.

To reproduce, start wget downloading over ssl with a timeout set:
 wget --timeout=10 -O /dev/null https://...
Then drop the interface:
 ifconfig eth0 down

Over http, the connection times out correctly; over https, it hangs.

Building on John's proposal to use run_with_timeout(), I wrapped openssl_read() as well.  This solves the problems I was having.  I agree that, for correctness, we should probably wrap openssl_write() as well, although I don't have a failing test case.

(file #15097)

Hello,

http://bugs.debian.org/385506

"This is easy to reproduce, just start downloading a largish file with a --read-timeout of a few seconds, and right in the middle drop traffic from that server using iptables.

Stracing an HTTP connection shows nice timeout:

20:34:04 read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 1398
20:34:04 write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1398) = 1398
20:34:04 select(5, [4], NULL, NULL, {15, 0}) = 1 (in [4], left {14, 988000})
20:34:04 read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 1398
20:34:04 write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1398) = 1398
20:34:04 select(5, [4], NULL, NULL, {15, 0}) = 0 (Timeout)
20:34:19 close(4)                       = 0

While HTTPS just sits there forever, waiting:

20:28:38 read(4, "\30.\3051\330\307L\301%\206\312\347\326\277i&\250[\025"..., 3852) = 3852
20:28:39 write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
20:28:39 write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12288) = 12288
20:28:39 select(5, [4], NULL, NULL, {15, 0}) = 1 (in [4], left {15, 0})
20:28:39 read(4, "\27\3\0011p", 5)      = 5
20:28:39 read(4, "\314\247\266\315\235?K\210\217\317\0014F\\\371J\273*\252"..., 12656) = 1735
20:28:39 read(4, "xT\263pU=\354~W\225\344\237\271\237a%\22\327\326)D\231"..., 10921) = 1398
20:28:39 read(4, "]\303\254\251\354\223#c\304\247E\260\33\326\362\376\374"..., 9523) = 1398
20:28:39 read(4,

Probably the timeout is not implemented in the routine which uses libssl...

Since the TCP internal timeout for an ESTABLISHED connection is very very large as I remember, this can be very bad for situations where wget is executed non-interactively (in my case, I update my dyndns entry using wget and reset my wireless card in a loop, in case something bad happens to the internet connection, which worked nice, until wget hanged this afternoon).
"

thx.