varnish / hitch Goto Github PK

Code is littered with SOCKERR() invocations which is merely logging of error situtations, without further handling (i.e. not followed by a shutdown_proxy()).

We should evaluate the various cases where we do SOCKERR() to make sure we don't leak resources or leave the connection in a nebulous state.

"The CERT C Secure Coding Standard" advices to explicit relinquish supplementary groups when dropping privileges by setgid/setuid. This is discussed for example at http://ow.ly/OpPFH.

I'll make a pull request with a simple patch for this, byt just doing setgroups(0, NULL)

Ingvar

Compilation fails on yosemite:

Job is here: https://jenkins.varnish-software.com/job/hitch-master-gitbuild-osx-x86_64/

+ make
/Library/Developer/CommandLineTools/usr/bin/make  all-recursive
Making all in src
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/  -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE  -g -O2 -MT configuration.o -MD -MP -MF .deps/configuration.Tpo -c -o configuration.o configuration.c
configuration.c:465:18: error: no member named 'st_mtim' in 'struct stat'
        cert->mtim = st.st_mtim.tv_sec
                     ~~ ^
configuration.c:466:11: error: no member named 'st_mtim' in 'struct stat'
            + st.st_mtim.tv_nsec * 1e-9;
              ~~ ^
configuration.c:910:46: warning: implicit declaration of function 'basename' is invalid in C99 [-Wimplicit-function-declaration]
        fprintf(out, "Usage: %s [OPTIONS] PEM\n\n", basename(prog));
                                                    ^
configuration.c:910:46: warning: format specifies type 'char *' but the argument has type 'int' [-Wformat]
        fprintf(out, "Usage: %s [OPTIONS] PEM\n\n", basename(prog));
                             ~~                     ^~~~~~~~~~~~~~
                             %d
configuration.c:1139:22: warning: format specifies type 'char *' but the argument has type 'int' [-Wformat]
                        printf("%s %s\n", basename(argv[0]), VERSION);
                                ~~        ^~~~~~~~~~~~~~~~~
                                %d
3 warnings and 2 errors generated.
make[2]: *** [configuration.o] Error 1

https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation

I'm working on a Dockerfile for building/running hitch and should have something done soon..

When implementing the automake test driver, an incorrect path error lead to the following output:

./tests/test02-simple-request: line 5: common.sh: No such file or directory
Assert error in front_arg_add(), configuration.c line 565:
  Condition((fa->port) != 0) not true.
./tests/test02-simple-request: line 8:  8570 Aborted                 (core dumped) hitch $HITCH_ARGS --backend=[hitch-tls.org]:80 "--frontend=[${LISTENADDR}]:$LISTENPORT" certs/site1.example.com
FAIL: tests/test02-simple-request

Asserting when the user calls hitch with bad arguments isn't very user friendly and should be improved.

This was on 9265839.

Not sure which part is producing the assert. Since common.sh isn't in place, the working directory is not src/tests/ so most likely certs/site1.example.com doesn't exist.

The screen-scraping method in init.hitch isn't ideal when attempting to leverage OS rc scripts. It would be better to provide native support in hitch.c to write out its PID.

I created a Docker image of Hitch, it can be found here https://hub.docker.com/r/zazukoians/hitch/

Note that this is built from my own fork of Hitch with my patch included to get it built on Alpine Linux. In case you integrate my pull-request #46 I will switch to the original master and once there is a release which builds on Alpine I will switch to that.

In my opinion it would be best if the Docker image is maintained by Varnish/hitch itself so if you are interested in taking that over I will happily create a pull request for it.

https://www.ietf.org/rfc/rfc5077.txt

Related:

• bumptech/stud#30
• bumptech/stud#50

For testing purposes I tried to start Hitch with 15.000 certificates on my local Intel NUC and it took 10 minutes to start the daemon.

The web page says:

Safe for large installations: performant up to 15 000 listening sockets and 500 000 certificates.

It seems to be eating 100% CPU on a single-core for a 10 minutes before starting.

wido@wido-desktop:~/repos/hitch/src$ time sudo ./hitch -n 4 -u nobody -g nogroup --config=/opt/hitch/hitch.conf

real    9m40.088s
user    9m38.482s
sys 0m0.829s
wido@wido-desktop:~/repos/hitch/src$

Am I doing something wrong or is it normal that it takes so long to start?

wido@wido-desktop:~$ cat /opt/hitch/hitch.conf |grep "pem-file"|wc -l
15002
wido@wido-desktop:~$

wido@wido-desktop:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty
wido@wido-desktop:~$

wido@wido-desktop:~$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 69
model name  : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
stepping    : 1
microcode   : 0x16
cpu MHz     : 779.000
cache size  : 3072 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 2
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips    : 3791.17
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model       : 69
model name  : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
stepping    : 1
microcode   : 0x16
cpu MHz     : 779.000
cache size  : 3072 KB
physical id : 0
siblings    : 4
core id     : 1
cpu cores   : 2
apicid      : 2
initial apicid  : 2
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips    : 3791.17
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model       : 69
model name  : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
stepping    : 1
microcode   : 0x16
cpu MHz     : 779.000
cache size  : 3072 KB
physical id : 0
siblings    : 4
core id     : 0
cpu cores   : 2
apicid      : 1
initial apicid  : 1
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips    : 3791.17
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model       : 69
model name  : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz
stepping    : 1
microcode   : 0x16
cpu MHz     : 1300.000
cache size  : 3072 KB
physical id : 0
siblings    : 4
core id     : 1
cpu cores   : 2
apicid      : 3
initial apicid  : 3
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips    : 3791.17
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

wido@wido-desktop:~$

Hello. I noticed some unparseable / mangled HTTP Headers when using the write-ip option. I was only using it to see what it did, but noticed any HTTPS requests aren't parsing properly.

I have hitch listening on 443 in front of varnish on 80. Here's what varnishlog shows:

-   HttpGarbage    "%02k%b5%b0%fcGET / HTTP/1.1%0d%0aHost: example.com%0d%0aConnection: keep-alive%0d%0aCache-Control: max-age=0%0d%0aAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8%0d%0aUpgrade-Insecure-Requests: 1%0d%0aUser-Agent: Mozilla/5.0 (X11; Linux x86_64) Ap%00"

I noticed that this is obviously hex (an ip address before GET and hex codes for CRLF after each header line) so maybe that will help your team narrow down the issue.

I've tried the latest 1.0.1 release, as well as the current master branch.

My certificate (.pem) is self-signed, but it works fine when I use pound instead of hitch as the SSL termination.

The problem goes away if I turn off "write-ip".

Here is my hitch.conf:

frontend = "[*]:443"
backend = "[127.0.0.1]:80"

workers = 4
user = "www-data"
group = "www-data"

write-ip = on

pem-file = /var/www/example.com/private/ssl/self/example.pem

Anyway, it's not a big deal to me as I was just experimenting with the option and noticed it.

If there's any other information I can provide I would be happy to supply it.

For building the Docker image rst2man either pulls a big list of unnecessary dependencies or it's not available at all (for trimmed-down distros like Alpine Linux for example).

It would be great if there is a configure option to disable it, like --without-rst2man

When starting stud without any arguments, the following is shown:

$ ./stud
No x509 certificate PEM file specified!

It would make more sense to output the --help screen in this case.

Implementation in https://github.com/varnish/hitch/tree/parallel_tests branch works to some extent, but has issues when run on travis-ci.org.

Output seen:

PASS: tests/test01-start-and-stop
./tests/test02-simple-request: line 5: common.sh: No such file or directory
Assert error in front_arg_add(), configuration.c line 565:
  Condition((fa->port) != 0) not true.
./tests/test02-simple-request: line 8:  8570 Aborted                 (core dumped) hitch $HITCH_ARGS --backend=[hitch-tls.org]:80 "--frontend=[${LISTENADDR}]:$LISTENPORT" certs/site1.example.com
FAIL: tests/test02-simple-request
./tests/test03-multiple-listen: line 6: common.sh: No such file or directory
Assert error in front_arg_add(), configuration.c line 565:
  Condition((fa->port) != 0) not true.
./tests/test03-multiple-listen: line 13:  8577 Aborted                 (core dumped) hitch $HITCH_ARGS --backend=[hitch-tls.org]:80 "--frontend=[${LISTENADDR}]:$LISTENPORT" "--frontend=[${LISTENADDR}]:$PORT2" certs/site1.example.com
./tests/test03-multiple-listen: line 14: die: command not found
./tests/test03-multiple-listen: line 17: die: command not found

It does not look like the TESTDIR set in AM_TESTS_ENVIRONMENT in src/Makefile.am is being applied, since the include path doesn't contain any sign of it. It may be that this has changed somehow since ubuntu precise that travis runs on. (not checked)

Also make distcheck is inoperable. The current TESTS content seem to refer to the sourcedir tests (../../src/tests/) and writing output there, and as such tests/ in _build (DESTDIR?) isn't written. This leads to a build error. Last paragraph of https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html#Parallel-Test-Harness talks about this magic, but unclear if this is the problem at hand.

Note to self: there is no winning with automake. you just have to live with the pain.

It took me quite a while to figure out the format for the certificate, and as you can see here http://ingvar.blog.redpill-linpro.com/2015/06/26/hitch-1-0-0-beta3-for-fedora-and-epel/ , Ingvar suggests just downloading something he made. This seems to apply to any project involving ssl/tls certificates, but the last step required for the certificates was a bit unexpected to me.

Obviously for production you need a proper certificate and whatnot, but particularly now when Hitch is young, I think it's important to make it easy for people to test.

Suggestion: Move parts of https://github.com/varnish/hitch/blob/master/src/tests/certs/README to a more discoverable place. I suggest an EXAMPLES section in the man file. (Possibly add non-Debian specific variant, until the rest of the world catches up to the brilliance of Debian).

We tried to used multiple frontend instance to enable dedicated ssl on multiple ips for legacy browser, but it wasn't working correctly. Looks like SNI is running instead. We used config like
frontend = "[10.200.4.250]:443+/etc/hitch/pems/test.com.pem"
frontend = "[10.200.4.249]:443+/etc/hitch/pems/test2.com.pem"
The ip supposed to bind to only one certificate, but they are serving both certificate.
Also hitch process start crash after reload once we enable dedicated ssl. restart works fine, but as soon as we issue a reload, process start crashing.

2016-01-05T01:40:13.237517+00:00 don-laxo abrt[2367]: Saved core dump of pid 2364 (/usr/sbin/hitch) to /var/spool/abrt/ccpp-2016-01-05-01:40:13-2364 (1097728 bytes)
2016-01-05T01:40:13.238375+00:00 don-laxo hitch[25334]: {core} Child 2364 was terminated by signal 6.
2016-01-05T01:40:13.238697+00:00 don-laxo hitch[2369]: {core} Process 3 online

A large number of options are undocumented in the man file, but documented in --help. Some only have their short option name listed. This is the list I found (might be incomplete):

• --config (and how to use it)
• --ciphers (long name)
• --ssl-engine (long name)
• -O
• --client
• -n
• -k
• --chroot (long name)
• --user (long name)
• -g
• --quiet (long name)
• --syslog (long name)
• --daemon
• --write-proxy-v1
• --write-proxy-v2
• --proxy-proxy
• --sni-nomatch--abort
• -t
• -p
• -V
• -h

(check boxes for your convenience)

Quote from hitch.c:

#define AZ(foo)     do { assert((foo) == 0); } while (0)
...
            if (CONFIG->UID >= 0)
                AZ(setgroups(0, NULL));
            if (CONFIG->GID >= 0)
                AZ(setgid(CONFIG->GID));
            if (CONFIG->UID >= 0)
                AZ(setuid(CONFIG->UID));

This will break horribly if NDEBUG is declared, since that makes the assertions vanish -- along with their contents! While building with -DNDEBUG is generally a bad idea, since it turns off assertions, it should never result in privileges not being dropped. (There are other, less lethal, ways that functional code is placed inside assert() elsewhere.)

Either stop misusing assertions, add some code to throw an error if NDEBUG is defined, or fix AZ / AN to run the code first and then assert the value later, e.g.,
#define AZ(foo) do { int success = (foo) == 0; assert(success); } while (0)

Snippet from config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by hitch configure 1.1.0-beta1, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libdir=${prefix}/lib/x86_64-linux-gnu --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-sessioncache

## --------- ##
## Platform. ##
## --------- ##

hostname = vbox-wheezy00
uname -m = x86_64
uname -r = 3.2.0-4-amd64
uname -s = Linux
uname -v = #1 SMP Debian 3.2.68-1+deb7u5

End of make output

make[2]: Entering directory `/mnt/src/hitch'
Making all in src
make[3]: Entering directory `/mnt/src/hitch/src'
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c configuration.c
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c ringbuffer.c
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c hitch.c
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c vpf.c
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c flopen.c
gcc -DHAVE_CONFIG_H -I. -I..  -I/usr/include/libev/ -D_FORTIFY_SOURCE=2 -O2 -g -std=c99 -fno-strict-aliasing -Wall -W -D_GNU_SOURCE -Iebtree -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c shctx.c
shctx.c:18:29: fatal error: ebtree/ebmbtree.h: No such file or directory
compilation terminated.
make[3]: *** [shctx.o] Error 1
make[3]: Leaving directory `/mnt/src/hitch/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/mnt/src/hitch'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mnt/src/hitch'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2

Have a look at the different versions of libev in rhel6/7, debian 7/8 and ubuntu 12.04/14.04. See if there is anything we should know about.

The logging code only handles AF_INET addresses. When the connection is over IPv6, we merely output the dotted-decimal formatted upper 32 bits of the IPv6 address.

https://en.wikipedia.org/wiki/OCSP_stapling

Put the code through scan-build&friends, and see what pops out.

This cert will then be the default cert for connection over that endpoint.

The idea is to help non-SNI users, to permit multi-homed setups with a separate cert for each listen endpoint.

This is for version 1.1.0. When I run hitch --config=hitch/hitch.rsa.conf --help, hitch segfaults during the help message.

server:~/scripts$ hitch --config=hitch/hitch.rsa.conf --help
Usage: hitch [OPTIONS] PEM

This is hitch, The Scalable TLS Unwrapping Daemon.

CONFIGURATION:

        --config=FILE      Load configuration from specified file.

ENCRYPTION METHODS:

      --tls                   TLSv1 (default. No SSLv3)
      --ssl                   SSLv3 (enables SSLv3)
  -c  --ciphers=SUITE         Sets allowed ciphers (Default: "ALL:!MEDIUM:!LOW:!WEAK:!EXPORT:!DES:!PSK")
  -e  --ssl-engine=NAME       Sets OpenSSL engine (Default: "")
  -O  --prefer-server-ciphers Prefer server list order

SOCKET:

  --client                      Enable client proxy mode
  -b  --backend=[HOST]:PORT     Backend [connect] (default is "[127.0.0.1]:8080")
Segmentation fault

From https://jenkins.varnish-software.com/view/hitch/job/hitch-master-gitbuild-el7-x86_64/67/console :

 > git checkout -f 479cdaaabca3cd8362ad821456d176ebd737f2ee
[..]
+ ./runtests
test01-start-and-stop   

OK
test02-simple-request   OK
test03-multiple-listen  OK
test04-listen-with-own-certs    OK
test05-multiple-listen-SNI  OK
test06-ticket-resume    OK
test07-nomatch-abort    OK
test08-test-configs FAILED: Valid config test08c.cfg unparseable?
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE

An extra null pointer check is not needed in a function like "config_destroy".

hitch-1.0.0-beta4 segfaults when enabling syslog. Tested on f22 and el7.

$ hitch-openssl -s /etc/pki/tls/private/default.example.com.pem
20150803T164745.923021 [ 3017] {core} Using OpenSSL version fbad2084.
Segmentation fault (core dumped)

Removing commit 8389be5 fixes it.

Note that running without syslog works fine:

$ hitch-openssl /etc/pki/tls/private/default.example.com.pem
20150803T164707.994662 [ 3008] {core} Using OpenSSL version 100010bf.
20150803T164707.995170 [ 3008] {core} Listening on 0.0.0.0:8443
20150803T164707.995260 [ 3008] {core} Listening on [::]:8443
20150803T164707.999503 [ 3008] {core} Using DH parameters from /etc/pki/tls/private/default.example.com.pem
20150803T164708.001633 [ 3008] {core} DH initialized with 1024 bit key
20150803T164708.003292 [ 3008] {core} ECDH Initialized with NIST P-256
20150803T164708.003571 [ 3009] {core} Process 0 online
20150803T164708.003620 [ 3009] {core} Successfully attached to CPU #0
^C
20150803T164709.254673 [ 3008] {core} Received signal 2, shutting down.

The -b seems to insist on the ipv6-like square brackets, which makes sense for IPv6, but is uncommon for anything else. The documentation says the format is --backend=[HOST]:port, but this can easily be read as "host is an optional part" (I'm fairly sure there's a remote proxy that'll allow -a :6081 for instance, so this is not completely unreasonable to assume).

I'm not entirely sure why square brackets are required except for IPv6, but at the very least, the documentation should to be clearer on this point.

Can we get a link to a SSL Server Test using default hitch settings.

Thanks.

configure.ac should use PKG_CHECK_MODULES when possible and not AC_CHECK_LIB.
AC_CHECK_LIB relies on the linker library search path. In systems where libev is installed in a non-standard path (or when the path is not in the linker's default path) compilation will fail.

configure:4391: checking for ev_default_loop in -lev
configure:4416: cc -o conftest -g -O2   conftest.c -lev   >&5
/usr/bin/ld: cannot find -lev
cc: error: linker command failed with exit code 1 (use -v to see invocation)

The same applies to the ssl check.

I created a Dockerfile for Hitch so I can use it in our setup. It pulls the 1.0.1 tar and builds the image. It's not perfect yet but it's a start. Before I brush it (aka small it after uninstalling all the build tools), what distro do you guys prefer? I can do it either in Centos or Debian/Ubuntu.

I'm more a BSD guy so I really don't care about which Linux base docker image I use :)

Also if I build that stuff will you take over maintenance and push it to Dockerhub? Because I'm not really too much interested in doing this :)

I'm using hitch to terminate a https connection which is sent to Varnish and then to the backend. In my use case I do a GET on https://gont.ch/Municipality. It seems that the backend does not see that this was coming from https. I expected that some header is set, for example x-forwarded-proto or the new Forwarded: proto=https defined in RFC7239. For my use case this is crucial as my middleware needs to know the exact URI from the request, including the protocol.

In tcpdump I see:

# tcpdump -i lo -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
21:52:08.269198 IP localhost.54990 > localhost.9501: Flags [P.], seq 271356757:271357093, ack 670393674, win 342, options [nop,nop,TS val 159634882 ecr 159634882], length 336
E...F.@.@.............%..,.U'.eJ...V.x.....
        ...     ...GET /Municipality HTTP/1.1
Host: gont.ch
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
X-Forwarded-Port: 80
X-Forwarded-For: ::1
X-Varnish: 588473128
Accept-Encoding: gzip

But it seems this is already the request Varnish sends to the configured backend.

In Varnish log I see:

# varnishncsa                                                                                         
::1 - - [26/Aug/2015:21:59:00 +0200] "GET http://gont.ch/Municipality HTTP/1.1" 404 399 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0"

The 404 is what the backend sends because Varnish requested the http resource and not the https one.

So what I am trying to understand is do I have to change something in hitch/Varnish or do I get something wrong here?

Also where would I have to sniff to see the request between hitch and Varnish?

ssia

It would be nice to have some Varnishesque utilities like hitchadm, hitchlog etc to manage and monitor hitch.

ssia

From the current:

#define CFG_CIPHERS "ciphers"
#define CFG_SSL_ENGINE "ssl-engine"
#define CFG_PREFER_SERVER_CIPHERS "prefer-server-ciphers"
#define CFG_BACKEND "backend"
...

We could instead do something like:

CFG(CIPHERS, "ciphers")
CFG(SSL_ENGINE, "ssl-engine")
CFG(PREFER_SERVER_CIPHERS, "prefer-server-ciphers")
CFG(BACKEND, "backend")
...

We could then reuse the table in configuration.c as it is currently used and also to generate documentation (I have hitch(5) in mind). Of course the table could also include a long description and maybe more.

Thoughts?

I have several sets of frontend/backend port pairs for which I want to run hitch on the same machine (using the same certificate). Can I do this, or do I need to start a process for each one?

Rather than using the client's destination IP (from the accept(2)'ed socket), stud instead hardcodes its own listen address in the PROXY header.

It should be possible to change the list of certificates during normal operations. Normal way of signalling this from outside would be through SIGHUP.

On a SIGHUP with a valid configuration file read, we should signal the children to finish up connections and die, and fork off new ones with the fresh configuration.

This will lead to potentially many extra hitch processes hanging around waiting for slow connections to finish, but this seems preferable to aborting/closing off connections. (either immediately or in n seconds.)

Open question is what to do if we can't bind to new socket given in the new configuration file.

When parsing/loading the configured certificates, stud currently only keeps track of a single name (SubjAltName/CN) from each cert for SNI matching.

ref: https://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/

Hitch looks great. What is Hitch's philosophy on cipher suites configuration?

I believe it would be good to provide a default configuration with strong defaults. I don't think any sysadmin should make a personal assessment of what cipher suite to use.

I think the default configuration should at least use PFS cipher suites only and have absolutely no RC4 or weak DHs.

I can do a pull-request with a document set of cipher suites if that's something you would be interested in.

It would be nice to be able to use external dh-params like in pound or in nginx. On our systems we rotate the params once in a while for security reasons and it would be very inconvenient to extract and add these every time to every certificate.

in pound this can be configured with
DHParams "/etc/pki/tls/private/dhparam4096.pem"

This is more an idea, may or may not be useful. It's 3AM so I may be brainfarting. There are other ways to deal with this, say dedicating a IP for sites supporting TLS.

An ability to drop the connection rather than choosing a default cert if there is no matching certificate can be useful when you share an IP address with both TLS and non-TLS sites. The connection would have to be killed off before the cert is exchanged, of course. This would stop people from randomly adding https in their address bar and get a privacy warning -- and actually work around a "feature" in Apple Mail. To avoid problems with non-SNI clients one could only have this policy applied if SNI is sent.

Rather TLS would simply be rendered "unavailable", which it was probably meant to be anyway.

Apple Mail has this quirk where when you set up a new account it will take the domain part of the address, and attempt HTTPS on port 443 on it to see if it can auto configure Exchange even if all you want to set up is IMAP/SMTP.
If that domain has no certificate, but the IP serves up a mismatched cert, it will present a big privacy warning that users will confuse with their email being MITM-ed (well, if they are "smart").

In any case avoidable certificate warnings is no good.

As far as I can see, Hitch only supports having certificate and private key (and dhparams) all in one file. While there's a nice simplicity to this, all other tools I've worked expects (and in many case, only supports) having the key in a separate file from the cert.

Especially with new tools like Let's Encrypt, Hitch's unique demand for monolithic files is irksome, as you need to regenerate the cert every four months (which is relatively painless, if you're using their scripts, since they provide symlinks to the current cert + key that are automatically updated when the cert is regenerated). It would be great if Hitch could support a similar setup to other software using TLS.

Running 1.0.0-beta2 on EL7:

[root@el7 hitch]# /usr/sbin/hitch-openssl -t --config=/etc/hitch/hitch.conf
Trying to initialize SSL contexts with your certificatesSegmentation fault

[root@el7 hitch]# /usr/sbin/hitch-openssl --config=/etc/hitch/hitch.conf -t
Trying to initialize SSL contexts with your certificatesSegmentation fault

[root@el7 hitch]# gdb --args /usr/sbin/hitch-openssl --config=/etc/hitch/hitch.conf -t
[..]
Program received signal SIGSEGV, Segmentation fault.
0x0000000000407f16 in load_cert_ctx ()
Missing separate debuginfos, use: debuginfo-install varnish-plus-addon-ssl-1.0.0-0beta2.el7.x86_64
(gdb) bt full
#0  0x0000000000407f16 in load_cert_ctx ()
No symbol table info available.
#1  0x000000000040b660 in init_openssl ()
No symbol table info available.
#2  0x00000000004076e6 in config_parse_cli ()
No symbol table info available.
#3  0x000000000040397a in main ()
No symbol table info available.