Coder Social home page Coder Social logo

stud's Introduction

STATUS

Stud is now officially abandonware, thanks for playing.

Recommended alternative: https://github.com/varnish/hitch

More info: https://blog.jamwt.com/2016/03/21/stud-no-more/

stud - The Scalable TLS Unwrapping Daemon

stud is a network proxy that terminates TLS/SSL connections and forwards the unencrypted traffic to some backend. It's designed to handle 10s of thousands of connections efficiently on multicore machines.

It follows a process-per-core model; a parent process spawns N children who each accept() on a common socket to distribute connected clients among them. Within each child, asynchronous socket I/O is conducted across the local connections using libev and OpenSSL's nonblocking API. By default, stud has an overhead of ~200KB per connection--it preallocates some buffer space for data in flight between frontend and backend.

stud has very few features--it's designed to be paired with an intelligent backend like haproxy or nginx. It maintains a strict 1:1 connection pattern with this backend handler so that the backend can dictate throttling behavior, maxmium connection behavior, availability of service, etc.

stud will optionally write the client IP address as the first few octets (depending on IPv4 or IPv6) to the backend--or provide that information using HAProxy's PROXY protocol. When used with the PROXY protocol, stud can also transparently pass an existing PROXY header to the cleartext stream. This is especially useful if a TCP proxy is used in front of stud. Using either of these techniques, backends who care about the client IP can still access it even though stud itself appears to be the connected client.

Thanks to a contribution from Emeric at Exceliance (the folks behind HAProxy), a special build of stud can be made that utilitizes shared memory to use a common session cache between all child processes. This can speed up large stud deployments by avoiding client renegotiation.

Releases

Please be aware of the policy regarding releases, code stability, and security:

  • In git, the tip of the master branch should always build on Linux and FreeBSD, and is likely to be as stable as any other changeset. A careful review of patches is conducted before being pushed to github.
  • Periodically, a version tag will be pushed to github for an old(er) changeset--0.1, 0.2, etc. These tags mark a particular release of stud that has seen heavy testing and several weeks of production stability. Conservative users are advised to use a tag.
  • stud has an optional build that utilizes shared memory-based SSL contexts and UDP peer communication to keep a session cache between many child processes running on many machines. The use of this build can dramatically speed up SSL handshakes on many-core and/or clustered deployments. However, it's important to acknowledge the inevitable theoretical security tradeoffs associated with the use of this (substantially more complex) binary. Therefore, the deeply paranoid are advised to use only the standard stud binary at the cost of some performance.

Requirements and Limitations

stud requires:

libev >= 4
openssl (recent, >=1.0.0 recommended)

Stud currently works on Linux, OpenBSD, FreeBSD, and MacOSX. It has been tested the most heavily on Linux/x86_64.

While porting it to other POSIX platforms is likely trivial, it hasn't be done yet. Patches welcome!

If you're handling a large number of connections, you'll probably want to raise ulimit -n before running stud. It's very strongly recommended to not run stud as root; ideally, it would be run as a user ("stud", perhaps) that does nothing but run stud. Stud will setuid (using -u) after binding if you need to bind to a low port (< 1024).

Installing

To install stud:

$ make
$ sudo make install

Usage

The only required argument is a path to a PEM file that contains the certificate (or a chain of certificates) and private key. If multiple certificates are given, stud will attempt to perform SNI (Server Name Indication) on new connections, by comparing the indicated name with the names on each of the certificates, in order. The first certificate that matches will be used. If none of the certificates matches, the last certificate will be used as the default.

Detail about the entire set of options can be found by invoking stud -h:

CONFIGURATION:

        --config=FILE      Load configuration from specified file.
        --default-config   Prints default configuration to stdout.

ENCRYPTION METHODS:

      --tls                   TLSv1 (default)
      --ssl                   SSLv3 (implies no TLSv1)
  -c  --ciphers=SUITE         Sets allowed ciphers (Default: "")
  -e  --ssl-engine=NAME       Sets OpenSSL engine (Default: "")
  -O  --prefer-server-ciphers Prefer server list order

SOCKET:

  -b  --backend=HOST,PORT     Backend [connect] (default is "[127.0.0.1]:8000")
  -f  --frontend=HOST,PORT    Frontend [bind] (default is "[*]:8443")

PERFORMANCE:

  -n  --workers=NUM          Number of worker processes (Default: 1)
  -B  --backlog=NUM          Set listen backlog size (Default: 100)
  -k  --keepalive=SECS       TCP keepalive on client socket (Default: 3600)

SECURITY:

  -r  --chroot=DIR           Sets chroot directory (Default: "")
  -u  --user=USER            Set uid/gid after binding the socket (Default: "")
  -g  --group=GROUP          Set gid after binding the socket (Default: "")

LOGGING:
  -q  --quiet                Be quiet; emit only error messages
  -s  --syslog               Send log message to syslog in addition to stderr/stdout
  --syslog-facility=FACILITY Syslog facility to use (Default: "daemon")

OTHER OPTIONS:
      --daemon               Fork into background and become a daemon (Default: off)
      --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
                             (Default: off)
      --write-proxy          Write HaProxy's PROXY (IPv4 or IPv6) protocol line
                             before actual data
                             (Default: off)
      --proxy-proxy          Proxy HaProxy's PROXY (IPv4 or IPv6) protocol line
                             before actual data
                             (Default: off)

  -t  --test                 Test configuration and exit
  -V  --version              Print program version and exit
  -h  --help                 This help message

Configuration File

Stud can also use a configuration file that supports all the same options as the command-line arguments. You can use stud --default-config to generate the default configuration on stdout; then, customize your configuration and pass it to stud --config=FILE.

Serving HTTPS

If you're using stud for HTTPS, please make sure to use the --ssl option!

Diffie–Hellman

To use DH with stud, you will need to add some bytes to your pem file:

% openssl dhparam -rand - 1024 >> PEMFILE

Be sure to set your cipher suite appropriately: -c DHE-RSA-AES256-SHA

Authors

stud was originally written by Jamie Turner (@jamwt) and is maintained by the Bump (http://bu.mp) server team. It currently (12/11) provides server-side TLS termination for over 85 million Bump users.

Special thanks to Colin Percival (@cperciva) for an early security audit and code review.

Finally, thank you to all the stud contributors, who have taken the program from a good start to a solid project:

https://github.com/bumptech/stud/contributors

stud's People

Contributors

aleksi avatar blovett avatar bpineau avatar carl-stripe avatar crucially avatar denik avatar dpaneda avatar dvv avatar gyepisam avatar ice799 avatar jamesgolick avatar jameslittle avatar jbuchbinder avatar jedisct1 avatar joewilliams avatar macros avatar mattsta avatar mqudsi avatar neopallium avatar saaros avatar stash avatar vincentbernat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

stud's Issues

Give clear error message if file descriptors limit is reached

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.

Alter default 200KB of overhead per connection

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.

Child was terminated by signal 6

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.

Connection reset by peer

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

disable logging fprintf

Hi!

Wonder if you could support option to disable per-connection logging.

TIA,
--Vladimir

using memcached for storing shared sessions

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.

"Unexpected SSL error (in handshake): 1" when using port 443 and TLS

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).

How to give stud the right cert/pem

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.

shctx.c could use less assembler

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().

ipv6 front address in configfile wrong when deamon starts

When i start the deamon with my configfile like this:

/etc/stud/stud.conf

stud listening address

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?

stud.init, wrong PID when "no DH parameters found"

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).

How to avoid untrusted issuer warnings with https (The certificate is self-signed, etc)

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?

bundle libev >= 4

Hi!

Wonder if you could bundle the subj? The rationale is to ease build process for non-packaging distros

TIA,
--Vladimir

Clarify the shared cache

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

Stud dies during loadtest

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

Latency of 40ms when using `--write-proxy`

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

Compiling with shared session don't show -C option

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

Dropped connections with "--syslog" enabled

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:

Graphs

README does not include --daemon option

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.

Print client IP on logs

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?

TLS error using openssl 0.9.8

I have two Stud (master) compiled in two servers and running twice in each server:

  • Server 1: openssl 0.9.8o-4squeeze7 (Debian)
    • Stud SSL: with --ssl option
    • Stud TLS: without --ssl option
  • Server 2: openssl 1.0.0e-2ubuntu4.2 (Ubuntu)
    • Stud SSL: with --ssl option
    • Stud TLS: without --ssl option

Using "wget https://IP" or a Ruby SSL client I get these results:

  • Connection from Server 1 to Stud SSL in Server 1 => OK
  • Connection from Server 1 to Stud TLS in Server 1 => ERROR
  • Connection from Server 1 to Stud SSL in Server 2 => OK
  • Connection from Server 1 to Stud TLS in Server 2 => ERROR
  • Connection from Server 2 to Stud SSL in Server 2 => OK
  • Connection from Server 2 to Stud TLS in Server 2 => OK
  • Connection from Server 2 to Stud SSL in Server 1 => OK
  • Connection from Server 2 to Stud TLS in Server 1 => OK

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?

stud segfaulting

[256971.486873] stud[26945]: segfault at 2d62f7b0 ip 000000002d62f7b0 sp 00007fff6f275ac8 error 15

Happens frequently on my servers right now.

Tag a new version.

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!

Cannot make with USE_SHARED_CACHE on Centos/rhel 5.6

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)

--write-proxy option return 400 error

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!

Support the addition of a custom header to the client request

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

how to test with ab

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

Major issue: "Child Died!" Stud Dies

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!

Segfault when using shared session cache with large value

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.

Makefile errors in FreeBSD 9.0

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

[feature] clientcertificate verification + X-headers

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.

Wrong path of man in Makefile

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.

Support for multiple certificates

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.

SPDY support

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).

Make ring buffer sizes configurable from cmdline

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 :)

process terminated, reason: "ev_io_stop: Assertion `("libev: ev_io_stop called with illegal fd..."

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,

Support option to copy PROXY header directly through

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.

Client mode still needs a cert file

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.

Add an option to also pass the PEM certificate presented by the client

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

Here the real data sent 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.

Missing build instructions / openssl

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.

stwd - Scalable TLS Wrapping Daemon ?

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.

vanilla notation

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

Orphaned processes are left when stopped by runit (runsvdir / runsv)

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.

No way to bind to exactly two IPs

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.

example config file for squeeze 0.3-1

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"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.