bumptech / stud Goto Github PK
View Code? Open in Web Editor NEWThe Scalable TLS Unwrapping Daemon
License: Other
The Scalable TLS Unwrapping Daemon
License: Other
all of a sudden I'm seeing child terminations with a SIGABRT, but I have no idea why. I checked file descriptors and that seems fine, it just started yesterday and it wasn't during any traffic peak.
This is the log output:
{core} Child 13897 was terminated by signal 6. Replacing...
This is the last lines of strace of a terminated child:
read(244, "\254%\350*KC\234n\206\376\224g\7\332A\220\235\317^\232\354o\231\206i-\265\361\363~1E"..., 656) = 656
read(1894, "\27\3\0\0\340", 5) = 5
read(1894, "+\365Z\200\345>x\225k\324\3\261CL\20\320\216\201;FDY\262\25\237\301\344\201\367\267\306\212"..., 224) = 224
read(1866, "\27\3\0\0\340", 5) = 5
read(1866, "N\265\246\302|\200\326e\230\2111\314\226/\212\17\6\357\303\303\255?*\231u\3474v\205\231\216\331"..., 224) = 224
accept(4, 0xbfb4b2dc, [128]) = -1 ECONNABORTED (Software caused connection abort)
write(2, "stud: stud.c:1144: handle_accept"..., 146) = 146
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(6982, 6982, SIGABRT) = 0
--- SIGABRT (Aborted) @ 0 (0) ---
Process 6982 detached
any idea how to get more information? I'm running the latest stud.
Hi!
Wonder if you could bundle the subj? The rationale is to ease build process for non-packaging distros
TIA,
--Vladimir
Hi!
I use ab
from apache-tools to test the performance of a site.
# stud -f \*,443 -b 127.0.0.1,8080 cert.pem
#ab -n10 -c1 https://localhost/
gives {client} Unexpected SSL error (in handshake): 1
. Sometimes errno is 5
.
update: cert.pem is of course valid in sense i can successfully open https://localhost/
in browsers.
Where to dig? Wonder if you could supply a known-to-work testing certificate?
TIA,
--Vladimir
log to syslog
Hello :)
I compiled stud with shared cache support and tried to start it with really insanely huge session cache; after eating up lots of ram stud crashed.
Command line:
./stud --ssl -c HIGH -n 2 -B 200 -f 127.0.0.1,8443 -b x.y.z.w,80 ~/config/cert.pem -k 2 -C 10000000
Stack trace:
Core was generated by `./stud --ssl -c HIGH -n 2 -B 200 -f 127.0.0.1 8443 -b x.y.z.w 80 /export/hom'.
Program terminated with signal 11, Segmentation fault.
#0 shared_context_init (ctx=0x8064640, size=10000000) at shctx.c:316
316 cur->p = prev;
(gdb) bt
#0 shared_context_init (ctx=0x8064640, size=10000000) at shctx.c:316
#1 0x0804a665 in init_openssl () at stud.c:339
#2 main (argc=17, argv=0xbffd7274) at stud.c:1385
@EmericBr I compiled my own fork of stud, but it doesn't differ very much from bumptech/stud.
In the README it is said that:
By default, stud has an overhead of ~200KB per connection--it preallocates some buffer space for data in flight between frontend and backend.
How can we change this default? 200KB per connection seems too much for me when the goal is to allow 10k connected clients. What will be the drawback of lowering this value?
Thanks.
[256971.486873] stud[26945]: segfault at 2d62f7b0 ip 000000002d62f7b0 sp 00007fff6f275ac8 error 15
Happens frequently on my servers right now.
Hi,
we rolled out stud in production last week and seeing intermittent problems in the SSL handshake from our iPhone app. Every 20th request or so just fails in the handshake, the other ones work fine. The iPhone HTTP client reports these as "Connection reset by peer", looking at them in Wireshark I see TLS alerts with "Decryption failed", there is nothing in the stud log.
I posted a tcpdump of it here: https://gist.github.com/1195215
Do you have any idea what this could be? How can I further debug it?
thanks,
Florian
The init script provided by stun retrieves the daemonized process PID as follows:
out=`${prefix} ${STUD} ${opts} 2>&1`
...
stud_pid=`echo "${out}" | tail -n 1 | cut -d " " -f5 | tr -d '.'`
But depending on the provided certificate, the first line printed to stdout by the daemonized stud process is:
{core} Note: no DH parameters found in PATH_TO_CERT_FILE
and therefore the retrieved PID would be wrong (or null).
Hi!
I have run some bench with stud and I always get a latency around 40ms with --write-proxy
. This latency disappears if this option is not present. This latency does not exist in stunnel 4.45 which features a similar functionality. I have tried to replace snprintf with strcpy (and a constant string) without any change.
I mean, with something like this, there is still the same latency:
if (OPTIONS.WRITE_PROXY_LINE) {
char *ring_pnt = ringbuffer_write_ptr(&ps->ring_down);
strcpy(ring_pnt, "PROXY TCP4 1.1.1.1 2.2.2.2 5555 443\r\n");
written = 37;
ringbuffer_write_append(&ps->ring_down, written);
ev_io_start(loop, &ps->ev_w_down);
}
Also removing ev_io_start
does not help. Any idea?
On the other hand, there is haproxy 1.5-dev7. More details on the setup here: http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
Right now, stud can sit in front of an HAProxy server and preserve original source address information.
However, one can't put stud behind an HAProxy server in TCP mode and perform that same trick.
All an implementation would need to do for pass-through PROXY when this configuration option was enabled would be to copy the contents of an inbound stream up to the first CRLF directly to output with no processing, expecting the SSL handshake to start immediately after.
In some scenarios, for example a SIP or XMPP server, it's interesting that such a server gets the certificate provided by the client (if it provides a TLS client certificate during the TLS handshake). Such a mechanism is usually used to trust and authorize the connection by validating the given certificate.
But when using Stud this is not possible since Stud ignores the client certificate. Of course I don't ask for Stud to validate the client certificate and pass the resulted validation information in some way. That should be the task of the backend server.
What I ask is for a new option (i.e.: --write-pem), so Stud writes to the backend the PEM certifcate(s) presented by the client. It would require some kind of parsing format, something like:
--------- TCP data sent by Stud to the backend when --write-proxy and --write-pem are enabled -------------
PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n
PEM_BYTES\r\n
Here the PEM certificate(s) given by the client
In this way the backend server can get, not just the source IP:port of the client, but also the public certificate presented by the client during the TLS handshake.
This would make benchmarking and tuning memory consumption vs throughput much easier.
I don't have a patch yet, but I would definitely want to tune this stuff before putting into production, so if someone else does it first, I wouldn't mind :)
Greetings, I am a newbee. I cannot figure the commands out. This is what I am giving stud.
root@302261:/keys# stud -b 192.168.1.12,3128 -f almostnatural.us,8443 /keys/almostnatural_us.pem
In the keys folder, I have:
root@302261:/keys# ls
almostnatural_us.ca almostnatural_us.pem myserver.key
When I execute it, I get:
root@302261:/keys# stud -b 192.168.1.12,3128 -f almostnatural.us,8443 /keys/almostnatural_us.pem
3074111112:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:696:Expecting: ANY PRIVATE KEY
3074111112:error:140B3009:SSL routines:SSL_CTX_use_RSAPrivateKey_file:PEM lib:ssl_rsa.c:587:
I am sure, I am doing everything wrong.
Hi,
It doesn't show the -C option anymore when compiling stud with shared session support.
I got the "-C" option when using this command (from Makefile) approx 1 month ago:
gcc -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -I/usr/include/libev -I/usr/local/include -L/usr/local/lib -Lebtree -I. -DUSE_SHARED_CACHE -o stud ringbuffer.c shctx.c stud.c -D_GNU_SOURCE -lssl -lcrypto -lev -lpthread -lebtree
But now I don't get the "-C" option when running "stud".
Is it not compiled then or just not showing the option? Because it is in the manual.
/D
The current path to install the manpage points to doc/stud.8 but doc/ does not exist.
install -m 644 doc/stud.8 $(DESTDIR)$(MANDIR)/man8
Either remove "doc/" or add the directory "doc" and move stud.8 there.
Hi,
I'm running stud (latest stud-master) using the following options (and HAProxy as the backend to stud)
stud -C 40000 -n 4 -b 127.0.0.1 81 -f 0.0.0.0 443 --write-proxy /usr/share/ssl/certs/mysite.cert
During our loadtest HAProxy reports around 300 new connections per second. After we reached ~10k connections
we start seeing these in stud's error logfile and each child dies, one by one.
{backend-connect}: Connection timed out
{backend-connect}: Connection timed out
{backend-connect}: Connection timed out
{backend-connect}: Connection timed out
{backend-connect}: Connection timed out
{backend-connect}: Connection timed out
stud: ev.c:2651: ev_io_stop: Assertion `("libev: ev_io_stop called with illegal fd (must stay constant after start!)", w->fd >= 0 && w->fd < ((loop)->anfdmax))' failed.
{core} A child (17645) died! This should not happen! Goodbye cruel world!
Running on fedora 14 64bit:
2.6.35.6-45.fc14.x86_64
/E
Can you please tag a new version? Version 0.3 does not build for me on OSX Lion and I'd like a tag to put into a build script.
Thanks!
It seems like shctx.c is written with several inline assembler parts to get atomic operations. GCC has a relatively rich set1 of these; possibly not everything that the file needs, but at least the cmpxchg() function could probably be replaced by __sync_val_compare_and_swap().
Hi!
Wonder if you could define why we have to use -f \*,443 -b 127.0.0.1,65443
inplace of more of convenience -f 0.0.0.0:443 -b 127.0.0.1:65443
?
TIA,
--Vladimir
It's very hard to correlate connection problems by comparing the stud log with the backend log:
{client} Connection closed (in data)
{backend} Connection closed
Messages like these would be much more helpful if the client IP was included, and maybe a timestamp could be added as well?
Use --client, but stud error like:
stud: stud.c:688: init_openssl: Assertion `CONFIG->CERT_FILES != ((void *)0)' failed.
Aborted (core dumped)
Must specify a cert file for init args.
it would be really helpful if the purpose and workings of the shared cache would be explained a bit more in the README. I'm also unclear if the shared cache is only useful for multi-host deployments or also when running stud with more than 1 worker process.
When running with stud with "-n 2", should I compile it with USE_SHARED_CACHE enabled or not?
Cheers,
Florian
When the limit of file descriptors is reached, stud simply crashes, giving an error similar to error #38. Stunnel and others typically give an error that the file descriptor limit has been reached, and continue running (simply dropping that connection).
I believe Stud should take a similar route.
Hi,
I'm doing some load testing in order to start using stud in our setup, and while running a 4k clients (long lived connections) test, I got this error:
stud: ev.c:2687: ev_io_stop: Assertion `("libev: ev_io_stop called with illegal fd (must stay constant after start!)", w->fd >= 0 && w->fd < ((loop)->anfdmax))' failed.
let me know if there is any more info needed, I can reproduce the error.
Regards,
Hi,
There seems to be no way to bind to exactly two IPs, e.g. “-f 129.241.93.53,443 -f 2001:700:300:1800::2011,443”. This is useful if you want to bind to both IPv4 and IPv6, but there are other things on other IPs that use port 443, and thus prohibit the use of wildcards.
I have two Stud (master) compiled in two servers and running twice in each server:
Using "wget https://IP" or a Ruby SSL client I get these results:
ERROR is always the same:<pre
stud[28247]: {client} Unexpected SSL error (in handshake): 1
NOTE: After more checking I've realized that the error does not occur if I force the client to use TLSv1, so maybe this is an openssl "change" from 0.9.8 to 1.0.0?
I read in the readme file that using the shared memory option for shared sessions adds a lot of complexity to gain some speed. This bothers me a bit and makes me feel that I should not enable this feature.
What if you just used memcached as an option for storing/retrieving shared session data? Would this make things less complex and still allow some speed gains? Or, would the overhead of interacting with memcached be too great to make this feature useless?
Anyway, I'm not a stud user yet as I am just researching, but thought I would make the suggestion.
SPDY is going in to wider use and we'd like to support it but we use stud as our TLS terminator.
I'm trying to find a good support strategy and I was thinking this might work:
--spdy option.
Do proper TLS Next Protocol Negotiation to support SPDY.
The first byte of each new TCP connection could indicate if this is a SPDY connection or not, similar to how --write-ip works so that I can route to a server that parses regular HTTP or SPDY (I'll have to route to an entirely seperate server because there is no NPN indicator to flip from HTTP to SPDY on the plain TCP side so I'll have to split between SPDY and HTTP servers).
found it - got confused by new config layout vs. what debian shows in docs.
conf file (if anyone else stumbles over this):
OPTIONS="-f *,443 -b 127.0.0.1,8445"
CERT="/etc/ssl/stud.pem"
I'm trying to compile stud with USE_SHARED_CACHE on centos 5.6
I added an option to the Makefile CFLAGS to show the compiler where to find libev (-I/usr/include/libev)
A normal make without USE_SHARED_CACHE=1 seems to work correctly
When I run make here is what I get:
[root@au-build-vm1 stud]# make clean
rm -f stud stud.o ringbuffer.o
[root@au-build-vm1 stud]# make USE_SHARED_CACHE=1
cc -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -I/usr/include/libev -DUSE_SHARED_CACHE -DUSE_SYSCALL_FUTEX -c -o stud.o stud.c
stud.c: In function ‘handle_shcupd’:
stud.c:336: warning: implicit declaration of function ‘HMAC’
stud.c: In function ‘init_openssl’:
stud.c:675: error: ‘SSL_OP_NO_TICKET’ undeclared (first use in this function)
stud.c:675: error: (Each undeclared identifier is reported only once
stud.c:675: error: for each function it appears in.)
make: ** [stud.o] Error 1*
I am on
[root@au-build-vm1 stud]# openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
[root@au-build-vm1 stud]# uname -a
Linux au-build-vm1 2.6.18-238.el5xen #1 SMP Thu Jan 13 16:41:45 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@au-build-vm1 stud]# cc -v
_Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-_cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
For instance:
pem-file = "/etc/stud/pem.d/*.pem"
For convenience in automated environments (throw a pem file in pem.d, reload stud).
Don't know what is going on here.
Everything is kosher behind stud, all requests are coming through and succeeding but all connections cause stud to print {client} Connection closed (in data)
Would love to know how to debug this better, I'm using the --ssl option and all HTTPS requests are successful.
When i start the deamon with my configfile like this:
/etc/stud/stud.conf
FRONTEND_ADDRESS="[XXXX:XXX:XX:XXXX::1],8443"
When the deamon is running, netstat -nap|grep LISTEN shows me:
tcp6 0 0 XXXX:XXX:XX:XXXX:::8443 :::* LISTEN 28937/stud
I miss the ::1 at the end. What is causing this?
Hi!
Wonder if you could support option to disable per-connection logging.
TIA,
--Vladimir
stud should support the addition of custom headers to the request, so that the backend server have a trusted way to determine whether the request has actually passed through stud or not.
For instance, I'd add a secret key as a value to a custom header in the stud configuration.
X-Secure-Conn-Key: 1234567890
Then, in the backend server I'd check for the existence of my secret header and key and in turn notify the application that the client has connected over a secure channel.
Eg, in apache, the header could be checked and, if the key matched, the variable HTTPS would be set to on (most web applications use such a variable to determine if the client connection was secure):
SetEnvIf X-Secure-Conn-Key 1234567890 HTTPS=on
I think it would be a useful feature.
PS: My use case is stud<->varnish<->apache<->fastcgi_app
Release: brew install http://git.io/stud
Head: brew install http://git.io/stud --HEAD
I'm not sure if this is considered worth doing or not?
Could assign certificates by port number (if stud parent process could bind to multiple ports), or by IP address.
I ran both 0.2
tag as well as 4a2311d in production with the following parameters:
stud --ssl -n 2 -b 127.0.0.1,8443 -f *,443 -u stud --write-proxy /etc/ssl/cert.pem
And about once every 10 minutes I would receive this in the log:
{backend} Connection closed
{backend} Connection closed
{backend} Connection closed
{backend} Connection closed
{backend} Connection closed
{client} Unexpected SSL error (in handshake): 5
{backend} Connection closed
{backend} Connection closed
{backend} Connection closed
{core} A child (25298) died! This should not happen! Goodbye cruel world!
Once that child dies then both children appear to die and stud stops accepting connections. Am I configuring something incorrectly? This appears to be a pretty major bug otherwise.
Thanks!
I am running stud under runit and I have a problem that occurs when there are lot of connections established. Trying to stop the processes leaves them orphaned (via sv stop
). They are alive, serving existing connections and bound to the port. This prevents sv start
from running new stud processes. They cannot start because they cannot listen on src port.
Everything works fine when there are no established connections. I can start and stop the service as many times as I want and get desired effect.
I can reproduce it easily:
$ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
28073 28074 28071 28071 ? -1 S 1000 0:00 \_ runsvdir /home/messem/service
28074 28083 28071 28071 ? -1 S 1000 0:00 \_ runsv stud-38081
28083 20594 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
20594 20595 28071 28071 ? -1 S 1000 0:01 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
20594 20596 28071 28071 ? -1 S 1000 0:01 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
20594 20597 28071 28071 ? -1 S 1000 0:01 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
20594 20598 28071 28071 ? -1 S 1000 0:01 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
$ sv stop ./stud-38081
ok: down: ./stud-38081: 1s, normally up
$ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
28073 28074 28071 28071 ? -1 S 1000 0:00 \_ runsvdir /home/messem/service
28074 28083 28071 28071 ? -1 S 1000 0:00 \_ runsv stud-38081
$ sv start ./stud-38081
ok: run: ./stud-38081: (pid 1500) 0s
$ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
28073 28074 28071 28071 ? -1 S 1000 0:00 \_ runsvdir /home/messem/service
28074 28083 28071 28071 ? -1 S 1000 0:00 \_ runsv stud-38081
28083 1500 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1500 1501 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1500 1502 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1500 1503 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1500 1504 28071 28071 ? -1 S 1000 0:00 \_ /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
## [Established 1000 connection with stud] ##
$ sv stop ./stud-38081
ok: down: ./stud-38081: 1s, normally up
$ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
28073 28074 28071 28071 ? -1 S 1000 0:00 \_ runsvdir /home/messem/service
28074 28083 28071 28071 ? -1 S 1000 0:00 \_ runsv stud-38081
1 20595 28071 28071 ? -1 S 1000 0:01 /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1 1501 28071 28071 ? -1 S 1000 0:01 /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1 1502 28071 28071 ? -1 S 1000 0:01 /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1 1503 28071 28071 ? -1 S 1000 0:01 /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
1 1504 28071 28071 ? -1 S 1000 0:01 /usr/bin/stud -s -n 4 -u messem -b messemhost 8081 -f messemhost 38081
As you can see in the last listing. Processes are no longer under runsv. Parent process with PID 1500 is gone but children are alive.
stud -h shows (at the end):
Special: --daemon fork into background and become a daemon --write-ip write 1 octet with the IP family followed by the IP address in 4 (IPv4) or 16 (IPv6) octets little-endian to backend before the actual data --write-proxy write HaProxy's PROXY (IPv4 or IPv6) protocol line before actual data
However the README does not show the very important --daemon option.
Running make
in FreeBSD 9.0 (stud master) fails:
> make
"Makefile", line 17: Missing dependency operator
"Makefile", line 29: Need an operator
"Makefile", line 32: Missing dependency operator
"Makefile", line 34: Need an operator
make: fatal errors encountered -- cannot continue
is it doable in stud?
i have puppetmaster deployment which relies on client certificate verification, which is deducted based on X-headers in request stream. on apache it's done with:
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
unfortunately i can't do this with stunnel.
Why do not implement the reverse part of stud (stwd) ?
Stud with Stwd could became a fast (and still light) alternative to Stunnel.
I ask this because i am searching for a fast, simple, small and secure tunneling solution for Redis traffic when VLAN or VPN is not possible / desired.
I'm seeing this in our logs and I don't know what to do with it. Is in a major problem?
Hello,
During my tests on stud+HAProxy it was found that --write-proxy option was causing 400 error answer.
Without that option everything was working as required.
Here is failed request:
stud --workers 4 --frontend [*],443 --backend [localhost],10443 --syslog --ssl --write-proxy --daemon /etc/stud/ssl.pem
OS - RHEL 6.2
libev = 4.0.0
openssl =1.0.0
ebtree = 6.0.6
stud commit is a9b5aca
Any recomendation would be appreciated.
Thanks!
I can't seem to figure out the magic recipe for the single pem-file Stud requires. If I append the private key that I used for the CSR I can at least start Stud but when omitted it dies with the "Error loading rsa private key" error. When I get it started I still receive the "self-signed" error. I used http://www.sslshopper.com/ssl-checker.html with same result.
I've tried various concatenation orders including each of 1) the domain cert delivered to me from the trusted issuer 2) their Intermediate Certificate, and 3) the private key used during CSR generation using OpenSSL.
Will Stud always produce this warning?
Hi,
Downloaded the master branch to ubuntu 12.04, when i try to make i get:
root@os-proxy-01:~/bumptech-stud-84797cc# make
cc -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -I/usr/local/include -c -o stud.o stud.c
stud.c:56:26: fatal error: openssl/x509.h: No such file or directory
compilation terminated.
make: *** [stud.o] Error 1
What am I missing here? SSL is installed.
This is extremely strange, but with "--syslog" on, I got a serious amount of dropped connections. Around 50% of curls looked like this:
→ curl -i https://domain.com
curl: (35) Unknown SSL protocol error in connection to domain.com:443
When I removed the "--syslog" flag, these went away.
Further evidence for this is that we recently switched from Stunnel to Stud. Stunnel had reached a single-core scaling limit so we switched to Stud. Stud immediately handled about 50% of the traffic as Stunnel, which was confusing. When we removed the "--syslog" flag, it went back up to prior numbers.
We run stud as follows:
stud --backend=127.0.0.1,8443 --backlog=500 --ciphers="ALL:!aNULL:!ADH:!eNULL:!MEDIUM:!LOW:!EXP:RC4 RSA: HIGH" --frontend=0.0.0.0,443 --group=stud --keepalive=1800 --quiet --ssl --write-proxy --user=stud --workers=8 /etc/ssl/web.pem
Here is more evidence:
Hi,
I start stud like this:
stud@pannekake:~$ stud -n 16 -b 127.0.0.1,80 -f 129.241.93.53,443 uka-with-chain.pem
However, when connecting with “openssl s_client -connect 129.241.93.53:443”, the server outputs
{client} Unexpected SSL error (in handshake): 1
and the client says
CONNECTED(00000003)
write:errno=104
Chrome gets the same issue; it gets error in handshake. Interestingly enough, if I choose port 8443 instead of 443, it works! It might be a privileged port thing, as 444 doesn't work either. (I run stud suid root so it can bind to port 443.)
Running from commit 4a2311d, Debian stable, 64-bit (so OpenSSL 0.9.8o-4squeeze1).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.