Git Product home page Git Product logo

bud's Introduction

Bud

Build Status NPM version

THIS PROJECT IS NOT MAINTAINED ANYMORE

A TLS terminator for superheroes.

What is bud?

Bud is a TLS terminating proxy, a babel fish decoding incoming TLS traffic and sending it in a plain text to your backend servers. Not only does it do this well, bud has a lot of useful features!

Why bud?

  • Asynchronous key/cert loading using the supplied servername extension (SNI)
  • Asynchronous selection of backend to balance (using SNI)
  • Asynchronous OCSP stapling
  • TLS ticket rotation across cluster of workers, or multi-machine cluster (needs separate utility to synchronize them, but the protocol is in-place)
  • Availability: marking backends as dead, reviving them after period of time
  • Multi-frontend mode of operation. Single bud instance might be bound to multiple different ports and interfaces
  • Proxyline support: both HAProxy format at custom BUD JSON format
  • X-Forwarded-For for first HTTP request, and custom frame for SPDY (soon HTTP2 too) connection
  • Multi-context mode of operation, each context is used for different server name. All TLS parameters may be redefined in the context
  • Support for simultaneous ECDSA and RSA certs and keys

Implementation details

Bud is implemented fully in C, with the exception to the tests which are running on node.js. The networking level is provided by libuv, and the SSL implementation by OpenSSL 1.0.2h.

Install

Requirements

You must have gcc installed. Chances are that you do, but in case you don't:

# OSX
# Command Line Tools for Xcode: xcode-select --install,
# https://developer.apple.com/downloads, or Xcode

# SmartOS
[sudo] pkgin update
[sudo] pkgin install gcc47

# Ubuntu
[sudo] apt-get update
[sudo] apt-get install build-essential

Easy Install

Bud can easily be installed using npm

[sudo] npm install -g bud

This will install the command line tool bud. Optionally, you can build Bud from source with the steps below.

Build

Preparing:

npm install

Building:

gypkg build

The result will be located at: ./out/Release/bud.

Starting

To start bud - create a configuration file using this template and then:

bud --conf conf.json

Options

Usage: bud [options]

options:
  --version, -v              Print bud version
  --config PATH, -c PATH     Load JSON configuration
  --piped-config, -p         Load piped JSON configuration
  --default-config           Print default JSON config
  --daemon, -d               Daemonize process

Configuration

Bud uses JSON as the configuration format. Run bud --default-config to get the default configuration options (with comments and description below):

{
  // Number of workers to use, if 0 - only one process will be spawned.
  "workers": 1,

  // Timeout in ms after which workers will be restarted (if they die)
  "restart_timeout": 250,

  // Logging configuration
  "log": {
    // Minimum observable log level, possible values:
    // "debug", "notice", "info" (default), "warning", "fatal"
    "level": "info",

    // syslog facility to use, could be:
    // "auth", "cron", "kern", "lpr", "mail", "news", "syslog"
    // "deamon", "uucp", "local0", ... "local7"
    "facility": "user",

    // if true - logging will be printed to standard output
    "stdio": true,

    // if true - syslog will be used for logging
    "syslog": true
  },

  // Availability of the backend
  "availability": {
    // Maximum number of backend reconnects before giving up
    "max_retries": 5,

    // Time between retries
    "retry_interval": 250,

    // How long backend should not be responding until considered to be dead -- ms
    "death_timeout": 1000,

    // Timeout in ms after which it should be revived
    "revive_interval": 2500
  },

  // Frontend configuration (i.e. TLS/SSL server)
  "frontend": {
    "port": 1443,
    "host": "0.0.0.0",

    // Alternatively you may want to specify multiple address to bind server to
    // "interfaces": [
    //   { "port": 1443, "host": "1.1.1.1" },
    //   { "port": 1444, "host": "2.2.2.2" }
    // ],

    // tcp keepalive value (in seconds)
    "keepalive": 3600,

    // if true - server listed ciphers will be preferenced
    "server_preference": true,

    // Which protocol versions to support:
    // **optional**, default: "ssl23"
    // "ssl23" (implies tls1.*): "tls1", "tls1.1", "tls1.2"
    "security": "ssl23",

    // Path to default TLS certificate
    // NOTE: Could be an array of cert strings
    // e.g. ["-----BEGIN CERTIFICATE-----...", "-----BEGIN CERTIFICATE-----..."]
    "cert": "keys/cert.pem",

    // Path to default TLS private key
    // NOTE: Could be an array of keys as file paths or strings
    "key": "keys/key.pem",

    // **Optional** Passphrase for the private key
    // NOTE: Could be an array of passphrases
    "passphrase": null,

    // **Optional** Cipher suites to use
    // Bud defaults to:
    // "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA256:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:DES-CBC3-SHA"
    "ciphers": null,

    // **Optional** ECDH Curve to use, defaults to `prime256v1
    "ecdh": "prime256v1",

    // **Optional** Path to DH parameters file
    // **Recommend** generate a file
    // openssl dhparam -out dh.key 3072
    "dh": null,

    // **Optional** Base64 encoded TLS session ticket key,
    // should decode into 48 raw bytes
    // **Recommend** Generate with:
    // node -pe "require('crypto').randomBytes(48).toString('base64')"
    //
    // **Important note**: it should not be generally set, OpenSSL will generate
    // a random value for it at start, and ticket rotation will change it after
    // some time anyway
    "ticket_key": "yzNUDktR5KmA4wX9g9kDSzEn...true randomness",

    // **Optional** Ticket timeout in seconds, default: 3600
    "ticket_timeout": 3600,

    // **Optional** Interval between rotating ticket keys.
    // NOTE: If you are deploying bud to many boxes - please contact me, I'll
    // explain how ticket may be rotated simulatenously on all of them
    "ticket_rotate": 3600,

    // **Optional** NPN protocols to advertise
    "npn": ["http/1.1", "http/1.0"],

    // NOTE: Better leave this default:

    // **Optional** Renegotiation window in seconds
    "reneg_window": 300,

    // **Optional** Maximum number of renegotiations in a window
    "reneg_limit": 3,

    // **Optional** Maximum size of TLS fragment
    "max_send_fragment": 1400,

    // **Optional** If false - close frontend connection on backend EOF
    "allow_half_open": false,

    // **Optional** If true - the clients will be requested to provide the cert
    "request_cert": true,

    // **Optional**: Either filename or array of PEM certificate chain that
    // should be used for validating client certs
    "ca": "filename"
    // "ca": [ "-----BEGIN CERTIFICATE----\n..." ]
  },

  // Balance tactic
  // **Optional** possible values: "roundrobin", "sni", or "on-fail"
  //
  // * "roundrobin" - on each new connection select next live backend
  // * "sni" - select backend list from either async sni or supplied contexts
  // * "on-fail" - select next backend in list only if the previous one is
  //   dead
  "balance": "roundrobin"

  // Unix-specific option, drop privileges after starting the process
  // **Recommend** Create a user and a group for bud.
  "user": null,
  "group": null,

  // Backend configuration (i.e. address of Cleartext server)
  "backend": [{
    "port": 8000,
    "host": "127.0.0.1",
    "keepalive": 3600,

    // if true - HAProxy compatible proxyline will be sent:
    // "PROXY TCP4 ... ... ... ..."
    // if "json":
    // 'BUD {"family":"TCP4","bud":{"host":"...","port":...},"peer":{...}'
    "proxyline": false,

    // if true:
    // - if NPN is enabled and either `spdy/3.1`, `spdy/3` or `spdy/2` is
    //   negotiated - custom `X_FORWARDED` frame will be sent on connection.
    //   see: https://groups.google.com/forum/#!topic/spdy-dev/XkdtuShtVCEadds
    //
    // - in all other cases `X-Forwarded-For: <address>` will be added right
    //   after the first line in the incoming data.
    //
    // - in order to avoid parsing each request, the `X-Forwarded-For` header
    //   will only be sent on the first client request.

    "x-forward": false,

    // *Optional key*
    // If this property is present - balancing will start from the backend,
    // which `external` value is matching server address.
    // (Useful when listening on multiple interfaces)
    "external": "[1.2.3.4]:443"
  }],

  // SNI context loading
  "sni": {
    "enabled": false,
    "port": 9000,
    "host": "127.0.0.1",

    // %s will be replaced with actual servername
    "url": "/bud/sni/%s"
  },

  // OCSP Stapling response loading
  "stapling": {
    "enabled": false,
    "port": 9000,
    "host": "127.0.0.1",

    // %s will be replaced with actual servername
    "url": "/bud/stapling/%s"
  },

  // Secure contexts (i.e. Server Name Indication support)
  "contexts": [{
    // Servername to match against
    "servername": "blog.indutny.com",

    // **Optional** balance algorithm, could not be `sni`
    "balance": "roundrobin",

    // Path to TLS certificate
    // Could be an array
    "cert": "keys/cert.pem",

    // Path to TLS private key
    // Could be an array
    "key": "keys/key.pem",

    // **Optional** Passphrase for the private key
    // Could be an array
    "passphrase": null,

    // Cipherlist to use (overrides frontend.ciphers, if not null)
    "ciphers": null,

    // ECDH curve to use, overrides frontend.ecdh
    "ecdh": null,

    // **Optional** Path to DH parameters file, overrides frontend.dh
    "dh": null,

    // TLS session ticket key to use, overrides frontend.ticket_key
    "ticket_key": null,

    // NPN protocols to advertise
    // **optional** (overrides frontend.npn, if not null)
    "npn": ["http/1.1", "http/1.0"],

    // Backends to use, works only when "balance" is set to "sni"
    "backend": [{
      "port": 8000,
      "host": "127.0.0.1",
      "keepalive": 3600
    }],

    // **Optional** If true - the clients will be requested to provide the cert
    "request_cert": true,

    // **Optional**: Either filename or array of PEM certificate chain that
    // should be used for validating client certs
    "ca": "filename"
    // "ca": [ "-----BEGIN CERTIFICATE----\n..." ]
  }]
}

To start bud - create a configuration file using this template:

bud --conf conf.json

To reload config - send SIGHUP to the bud's master process (or worker, if you wish to reload configuration only in a single process):

kill -SIGHUP <bud-master's-pid>

X-Forwarded-For

Setting backend.*.x-forward will cause an X-Forwarded-For header to be injected into the first request seen on a socket. However, subsequent requests using the same socket (via Keep-Alive), will not receive this header from bud. To remedy this, you should associate this header with the underlying socket or connection, and not expect it to be present with every HTTP request. A possible implementation in Node.JS would look like:

var http = require('http')
http.createServer(onrequest).listen(8080, 'localhost')

function onrequest(req, res) {
  // this is a previous SSL request
  if (req.connection.xForward)
    req.headers['x-forwarded-for'] = req.connection.xForward;
  // this is a new SSL request
  else if (req.headers['x-forwarded-for'])
    req.connection.xForward = req.headers['x-forwarded-for'];
  // this is not an SSL request
  else {
    // optional, but a way to force SSL
    res.writeHead(301, {
      'Location': 'https://localhost:1443'
    })
    return void res.end()
  }


  // optional, it's a good idea to send this header to
  // force SSL in modern browsers
  res.setHeader('Strict-Transport-Security', 'max-age=' + 60 * 60 * 24 * 365)

  // handle request normally now knowing that the
  // `X-Forwarded-For` header is present
}

If you use nginx, the best results are achieved with the X-Real-IP module and the proxy_protocol option. Add proxy_protocol to your nginx listen directive. You may have to add a separate server block for traffic coming from bud: the server with the proxy_protocol directive will not work with plain HTTP requests.

server {
  # Accept and parse proxyline requests
  listen 127.0.0.1:8080 default proxy_protocol;

  # Use bud's proxyline info for the request IP
  real_ip_header proxy_protocol;

  # You may want to restrict which origin IPs can use the proxyline format
  set_real_ip_from 127.0.0.1;

  # [..]
}

The bud backend must be configured to use proxyline, too:

  "backend": [{
    "port": 8080,
    "host": "127.0.0.1",
    "keepalive": 3600,

    // this is where the magic happens
    "proxyline": true,

    // and now you can turn that off
    "x-forward": false,
  }],

SNI Storage

If you have enabled SNI lookup (sni.enabled set to true), on every TLS connection a request to the HTTP server will be made (using sni.host, sni.port and sni.query as url template). The response should be a JSON of the following form:

{
  "cert": "certificate contents",
  "key": "key contents",

  // Optional
  "npn": [],

  // Optional
  "ciphers": "...",

  // Optional
  "ecdh": "..."

  // **Optional** Path to DH parameters file, overrides frontend.dh
  "dh": null
}

Or any other JSON and a 404 status code, if SNI certificate is not found.

If optional fields are not present - their value would be taken from frontend object in configuration file.

OCSP Stapling

OCSP Stapling has exactly the same configuration options as SNI Storage. Main difference is that 2 requests to OCSP Stapling server could be made by bud:

  1. GET /stapling_url/<stapling_id> - to probe backend's cache
  2. POST /stapling_url/<stapling_id> with JSON body: {"url":"http://some.ocsp.server.com/","ocsp":"base64-encoded-data"}.

For the first request, if backend has cached OCSP response for given <stapling_id>, backend should respond with following JSON:

{"response":"base64-encoded-response"}

Or with a 404 status code and any other JSON.

For the second request, backend should send a POST request to the OCSP server given in the JSON body. This request should have Content-Type header set to application/ocsp-request and a decoded (from base64) ocsp field from body.

The response to bud should be the same as in the first case, base64-encoded data received from OCSP server.

Backend Example

Example OCSP+SNI backend implementation in node.js could be found here.

Generating a key and getting an ssl cert

Generating a key is easy with openssl

openssl genrsa -out server.key 2048

To generate the public certs, you'll need to buy an SSL cert from the provider of your choice. They'll ask you to upload your key file, and the .crt file generated below:

# you'll be asked for a bunch of info. The most important one is "common name"
# and this must match your domain exactly. e.g.
# example.com
# if you've bought a wildcard cert, you should use
# *.example.com
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 9999 -in server.csr -signkey server.key -out server.crt

You'll need to upload the .crt and .key files to the cert provider. What you want back from them is a .pem file that has their entire cert chain. Then in your bud config set it like this:

{
  "frontend": {
    // you generated this in the first step
    "key": "server.key",
    // this is the file you downloaded from your cert provider
    "cert": "server.pem"
  }
}

Running as monitored process

Keep bud running even after a server restart

SmartOS

touch bud.xml
read -d '' budconfig << EOF
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
        Created by Manifold
--><service_bundle type="manifest" name="bud">

    <service name="bud" type="service" version="1">

        <create_default_instance enabled="true"/>

        <single_instance/>

        <dependency name="network" grouping="require_all" restart_on="error" type="service">
            <service_fmri value="svc:/milestone/network:default"/>
        </dependency>

        <dependency name="filesystem" grouping="require_all" restart_on="error" type="service">
            <service_fmri value="svc:/system/filesystem/local"/>
        </dependency>

        <exec_method type="method" name="start" exec="/opt/local/bin/bud -c %{config_file} -d" timeout_seconds="5"/>

        <exec_method type="method" name="stop" exec=":kill" timeout_seconds="60"/>

        <property_group name="startd" type="framework">

            <propval name="duration" type="astring" value="contract"/>
            <propval name="ignore_error" type="astring" value="core,signal"/>
        </property_group>


        <property_group name="application" type="application">
            <!-- TODO: customize this path to your bud config -->
            <propval name="config_file" type="astring" value="/root/bud/bud.json"/>
        </property_group>


        <stability value="Evolving"/>

        <template>
            <common_name>
                <loctext xml:lang="C">
                    bud
                </loctext>
            </common_name>
        </template>

    </service>

</service_bundle>
EOF
echo $budconfig > bud.xml
svccfg import bud.xml
svcadm enable bud
# should be in the online state
svcs -l bud
# see the logs for details
tail /var/svc/log/bud\:default.log

Ubuntu

A docker image is avaliable

Community

Join #bud-tls on freenode IRC to discuss things with me or others!

Security

If you'd like to be notified about security releases of this software - please consider filling out this form and/or adding your company on a public wiki page.

LICENSE

This software is licensed under the MIT License.

Copyright Fedor Indutny, 2013-2016.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

bud's People

Contributors

acconut avatar bahamas10 avatar doublerebel avatar gmiroshnykov avatar indutny avatar joeybaker avatar mscdex avatar odeke-em avatar phillipp avatar rvagg avatar silverwind avatar tellnes 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

bud's Issues

ticket key rotation

Bud should be capable of synchronous tls ticket key rotation through external service. This should perhaps be done by polling an external service.

undefined reference to bud_trace_*

I'm trying to build the latest version (0.8.1) and gets some errors.

uname -a
Linux ip-10-0-0-152 3.2.0-58-virtual #88-Ubuntu SMP Tue Dec 3 17:58:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

  LINK(target) /home/ubuntu/sources/bud/out/Release/bud
/home/ubuntu/sources/bud/out/Release/obj.target/bud/src/avail.o: In function `bud_client_connect_cb':
avail.c:(.text+0x763): undefined reference to `bud_trace_backend_connect'
/home/ubuntu/sources/bud/out/Release/obj.target/bud/src/client.o: In function `bud_client_create':
client.c:(.text+0x5d0): undefined reference to `bud_trace_frontend_accept'
/home/ubuntu/sources/bud/out/Release/obj.target/bud/src/client.o: In function `bud_client_close_cb':
client.c:(.text+0xbad): undefined reference to `bud_trace_end'
collect2: ld returned 1 exit status
make: *** [/home/ubuntu/sources/bud/out/Release/bud] Error 1
make: Leaving directory `/home/ubuntu/sources/bud/out'

JSON parse fails with leading newline

If the json config specified by --conf has a leading newline it fails to parse.

Not a huge issue, just an interesting side effect of some JSON stringification/template logic I'm using.

bud on multiple boxes

We're going to deploy bud on multiple boxes in different DCs for DNS round-robin failover.

In the docs is a hint that ticket rotation will be a problem in this case (if I understand correctly). What is the setup for synchronized ticket rotation?

And: will there be any other problems?

bud leaks file descriptiors (heavily)

So a few hours ago we got the first symptoms of a new problem where clients can't connect to bud anymore. The debug output from cul looks like this:

* About to connect() to system-zeus.lima-city.de port 443 (#0)
*   Trying 212.83.45.137... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to system-zeus.lima-city.de:443 
* Closing connection #0

Bud debug output says:

(dbg) [3436] client 0x61b9640 on backend connecting to 127.0.0.1:10010
(dbg) [3436] client 0x61b9640 on frontend close_cb
(dbg) [3436] received handle on ipc
(dbg) [3436] client 0x61b9640 on backend connecting to 127.0.0.1:10010
(dbg) [3436] client 0x61b9640 on frontend close_cb
(dbg) [3436] received handle on ipc
(dbg) [3436] client 0x61b9640 on backend connecting to 127.0.0.1:10010
(dbg) [3436] client 0x61b9640 on frontend close_cb
(dbg) [3436] received handle on ipc
(dbg) [3436] client 0x61b9640 on backend connecting to 127.0.0.1:10010
(dbg) [3436] client 0x61b9640 on frontend close_cb
(dbg) [3436] received handle on ipc

Other workers seem to work normally. Over time more and more of the workers start to do the same.

So I was thinking that some problem occurred in the requests before and left the worker in a bad state, and found that bud opens too many files (output from the same worker before):

(dbg) [3436] received handle on ipc
(dbg) [3436] client 0x5fc5390 on backend connecting to 127.0.0.1:10010
(dbg) [3436] client 0x5fc5390 on frontend new
(dbg) [3436] client 0x5fc5390 on backend connect 0
(dbg) [3436] client 0x5fc5390 on frontend SSL_read() => -1
(dbg) [3436] client 0x5fc5390 on frontend after read_cb() => 222
(dbg) [3436] client 0x5fc5390 on backend ssl_cert_cb {0}
(ntc) [3436] client 0x5fc5390 on frontend failed to request SNI: "uv_tcp_connect(http_req) returned -24 (too many open files)"
(dbg) [3436] client 0x5fc5390 on frontend SSL_read() => -1
(ntc) [3436] client 0x5fc5390 on frontend closed because: SSL_read(client) - 1 (cert cb error)
(dbg) [3436] client 0x5fc5390 on frontend force closing (and waiting for other)
(dbg) [3436] client 0x5fc5390 on backend force closing (and waiting for other)
(ntc) [3436] client 0x5fc5390 on frontend closed because: SSL_read(client) - 1 ((null))
(dbg) [3436] client 0x5fc5390 on frontend close_cb

So as this problem started only after #76 was fixed, maybe the fix introduced a new bug that leads to HTTP requests no longer closed and thus leaking file descriptors. Could that be possible, that the fix introduced that problem? Right now the problem seems to emerge very fast as we see a worker hit the ulimit (1024) in only a couple of minutes.

It is possible though that there is another problem as I see strange debug output from the workers:

(dbg) [20210] received handle on ipc
(dbg) [20210] client 0x4182a80 on backend connecting to 127.0.0.1:10010
(dbg) [20210] client 0x4182a80 on frontend new
(dbg) [20210] client 0x4182a80 on backend connect 0
(dbg) [20210] client 0x4182a80 on frontend SSL_read() => -1
(dbg) [20210] received handle on ipc
(dbg) [20210] client 0x41a1720 on backend connecting to 127.0.0.1:10010
(dbg) [20210] client 0x41a1720 on frontend new
(dbg) [20210] received handle on ipc
(dbg) [20210] client 0x41b2550 on backend connecting to 127.0.0.1:10010
(dbg) [20210] client 0x41b2550 on frontend new
(dbg) [20210] client 0x41a1720 on backend connect 0
(dbg) [20210] client 0x41a1720 on frontend SSL_read() => -1
(dbg) [20210] client 0x41b2550 on backend connect 0
(dbg) [20210] client 0x41b2550 on frontend SSL_read() => -1
(dbg) [20210] received handle on ipc
(dbg) [20210] client 0x41dfca0 on backend connecting to 127.0.0.1:10010
(dbg) [20210] client 0x41dfca0 on frontend new
(dbg) [20210] client 0x41dfca0 on backend connect 0
(dbg) [20210] client 0x41dfca0 on frontend SSL_read() => -1
(dbg) [20210] received handle on ipc
(dbg) [20210] client 0x41fef60 on backend connecting to 127.0.0.1:10010
(dbg) [20210] client 0x41fef60 on frontend new
(dbg) [20210] client 0x41fef60 on backend connect 0
(dbg) [20210] client 0x41fef60 on frontend SSL_read() => -1

So something is going on there that may be the cause of the leak. Any ideas?

glibc: corrupted double-linked list

In one of your deployments we saw that all SSL websites stopped working. Attempts to connect failed:

curl -v https://www.[foobar].net/
* About to connect() to www.[foobar] port 443 (#0)
*   Trying 91.216.248.**... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to www.[foobar].net:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to www.[foobar].net:443 

The bud log showed the following output:

(wrn) [9845] client 0x4c9acd0 on frontend SNI from json failed: "Failed to load or parse JSON: <SNI Response>"
*** glibc detected *** bud: corrupted double-linked list: 0x00000000116daa00 ***

Kernel ring buffer/dmesg:

[345812.084141] traps: bud[3256] general protection ip:5cad48 sp:7fffdcf1ca30 error:0 in bud[400000+2ae000]

A rebstart of bud solved the problem. What do you need to dig further into the problem?

npm install on linux (ubuntu) hangs

The npm based install hangs forever after printing out:

> [email protected] preinstall /usr/local/lib/node_modules/bud-tls
> node-gyp configure && node-gyp rebuild && node npm/locate.js

gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/root/.node-gyp/0.10.33"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/bud-tls/.node-gyp"

Compiling from source works fine.

x-forwarded-for

I'd love to see the ability for x-forwarded-for, etc. headers to be injected into the backend request.

Admittedly, I'm unfamiliar with the code base, so I don't know if the request is parsed via HTTP or not (i see http_parser.c as a dep) but if it is, i'd love to see the ability to inject these (or other) headers to the backend.

If the response is not HTTP parsed, then the overhead from this maybe to substantial to be worth it.

TLS false start & SSL_MODE_HANDSHAKE_CUTTHROUGH

Perhaps more of a question / clarification... My understanding is that there is nothing to enable on the server to support false-start -- this is a client-side decision? E.g. Chrome requires forward secrecy + NPN.

/* Enable TLS False Start */
- perhaps I'm wrong, but this seems unnecessary. The config flag in bud is what threw me off, as I didn't expect to see that there... Am I missing something?

http://boinc.berkeley.edu/android-boinc/libssl/patches/handshake_cutthrough.patch

Error code when cyaSSL tries to connect to bud

When using cyaSSL (https://github.com/cyassl/cyassl) as a client, I get an error code returned, saying "INCOMPLETE_DATA".
Any way, bud-tls works as expected. It is the first time I encounter such a problem.

  • Steps to reproduce :
git clone https://github.com/cyassl/cyassl.git
cd cyassl
./autogen.sh
./configure --enable-debug --disable-shared
make test
### Test against a bud-tls server
./examples/client/client -h {yourserver.xyz} -p {port_number} -d -g
  • In cyaSSL, the "INCOMPLETE_DATA" error is related to :

        /* make sure can read the message */
    if (*inOutIdx + size > totalSz)
        return INCOMPLETE_DATA;

    in src/internal.c.

  • bud-tls 0.34.2 running on Centos 6.6, with node v0.12.1 and npm v2.5.1 (same with node v0.10.6 and npm v1.3.6)

Bud sends no X-Forwarded-For for a portion of the Chrome requests

We have a working bud setup now but we are seeing some connections where the first requests don't have an X-Forwarded-For header.

This very rare but breaks quite a lot of stuff when it happens.

Setup is a "normal" bud setup on 1.2.4 and a nginx-lua backend that reads and sets the X-Forwarded-For header into a SHM dictionary on the first request. To make sure we don't miss the first request we added a "seen" key that is set on the first request of the connection. We additionally dump all headers.

After a while I noticed that I can't reproduce with curl or Firefox, only in chrome. The headers confirmed that only chrome (like Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36) is affected.
Accept-Encoding is always "gzip, deflate, sdch" (maybe helpful?), and we strip the Accept-Encoding at the nginx layer because of legacy system behaviour.

Reproduction is simple: just hit F5 a few times in chrome and on a few requests the IP is not set.

Any ideas?

Documentation for testing

Mostly just an FYI until I can make a PR.

  • Raise ulimit
  • ab on OSX is borked
  • use ab -f tls1 or ab -f ssl3

OpenSSL Engine Support

It would be awesome if bud supported changing the OpenSSL engine at runtime. For example, we currently utilize a hardware security module which implements an SSL engine so that keys are stored in hardware, but can be utilized by any program which uses OpenSSL (and allows for the engine to be set). Would it be possible to add another configuration item for bud?

Proxyline is broken when using workers

proxyline_fmt is an empty string when bud_client_prepend_proxyline are using it. It does look like bud_server_format_proxyline is not called in the workers or it is called after the configuration is passed to the workers.

Proxyline works if I sett workers to zero in the configuration.

benchmarks

It'd be nice to see some kind of numbers with regards to how bud compares performance-wise to some popular TLS/SSL terminators like pound, stud, nginx, haproxy, etc.

Do we have proxy chain support?

Let's say we are already behind a proxy(In my case Cloudflare) and it has added x-forwarded headers. In that case, does bud build a proxy chain for x-forwarded like this.

headers['x-forwarded-for'] = 'client-ip, cloudflare-ip';

Connection reset by peer

Hi,
we have bud in production for quite some time now and we're pretty happy with it (still waiting for a core dump on #74).

There is one customer who complains about regular "Connection reset by peer" errors. We were unable to reproduce that with our monitoring, but our monitoring is not a demanding as a browser.

I'm pretty clueless how we could best debug this. There are quite some -104 errors in the logs:

Sep 22 16:55:19 ssl-fe01 bud[1981]: client 0x1135e260 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[1981]: client 0x1135e260 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[9625]: client 0xdbfb300 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[19663]: client 0xe55b760 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[1997]: client 0xe064170 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[1981]: client 0x1142c490 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[19663]: client 0xe6d4a90 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:55:40 ssl-fe01 bud[1997]: client 0xe104e10 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 16:56:41 ssl-fe01 bud[1981]: client 0x113ac260 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:01:39 ssl-fe01 bud[1981]: client 0x11468170 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:01:47 ssl-fe01 bud[19663]: client 0xe871e60 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:01:49 ssl-fe01 bud[1981]: client 0x114a8ca0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:01:49 ssl-fe01 bud[1997]: client 0xe22a8a0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:03:29 ssl-fe01 bud[19663]: client 0xe8f8c00 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:07:45 ssl-fe01 bud[1981]: client 0x1142c490 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:07:47 ssl-fe01 bud[9625]: client 0xdb3bf30 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:07:56 ssl-fe01 bud[19663]: client 0xe6d4a90 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:08:10 ssl-fe01 bud[19663]: client 0xe8adff0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:10:12 ssl-fe01 bud[9625]: client 0xd9807b0 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:11:26 ssl-fe01 bud[19663]: client 0xe6d4a90 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:19:15 ssl-fe01 bud[16419]: client 0x14b2400 on frontend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:19:25 ssl-fe01 bud[16419]: client 0x14b2400 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:21:19 ssl-fe01 bud[16418]: client 0x1e4a1b0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)

When I see that correctly the client and/or bud closes or drops the connection and then bud tries to communicate on that connection, gets the -104 error and forcefully closes the client and backend connection.

I checked with nginx (backend):

  • There is no "Bad request" (not fully received/processed HTTP request) in the access logs
  • There is not single error for any connection received from bud recorded in the nginx error.log

I'm pretty baffled because on plain HTTP we don't see any connection resets by nginx and I can't find any clues in the nginx logs. Dropped connections by iptables or conntrack etc is unlikely because we monitor the relevant stats. Timing from the logs (everything from backend connect and frontend new to the force close happens in the same second) suggests that no timeouts are involved.

Sample los:

Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend connecting to 127.0.0.1:10010
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend new
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend after read_cb() => 517
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend uv_write(137) iovcnt: 1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend immediate write
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend write_cb => 137
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend recycle
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend connect 0
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend after read_cb() => 1158
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => 1078
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend uv_write(1129) iovcnt: 1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend immediate write
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend write_cb => 1129
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend recycle
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend after read_cb() => -104
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend SSL_read() => -1
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend closed because: uv_read_start(client) cb returned -104 (connection reset by peer)
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend force closing (and waiting for other)
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on backend force closing (and waiting for other)
Sep 22 17:21:19 ssl-fe01 bud[16419]: client 0x15016b0 on frontend close_cb

Any ideas how to debug this further?

Bud binds after dropping privileges

Hi,
thanks for your great work!

I have noticed that if I run bud with privilege dropping enabled that it appears to bind after dropping privileges. So it is not possible to use bud on port 443 without running as root, but that's IMHO not acceptable for a public facing server.

I thought that it would be possible to bind to 1443 and forward the packets with iptables, but that sounds like a crazy hack to me. I'd rather see that bud can listen on 443 and drop privileges. Is that possible or is there a special problem that prevents bud from doing so?

Btw the output with the user config option set looks like this:

(dbg) [15057] master starting
uv_tcp_bind(server) returned -13
permission denied

support passphrases

Please add support for SSL certs that have passphrases. Ideally it would have a mechanism like apache where it can execute a file or that echos the phrase via a bash script or something. Although folks I am sure would like it just in plaintext in the config as well depending on their security model.

allow cli to accept a piped config file

It would be great if we could pipe the contents of the config json to the cli instead of passing a file path. This would allow for dynamic configuration.

e.g. instead of

bud -c bud.json

this would be great

# or similar…
cat bud.json | bud -c 

handshake failures produce strange log output

I've got Bud running in front of a CouchDb instance. Curling it like so:

curl -X HEAD https://<couchurl>

results in the following bud log…

(ntc) [1] client 0x1b9bc70 on frontend closed because: uv_shutdown(client) cb returned -107 (socket is not connected)

…and eventually, the following curl response:

curl: (18) transfer closed with 61 bytes remaining to read

Yet,

curl https://<couchurl>

…works just fine.

I'm not 100% sure this is a bud error, so maybe this is a support request to explain the error message? :)

x-forward option not working

It looks like my backend is never receiving the x-forwarded-for header.

Headers it does get:

{ host: 'localhost:1443',
  connection: 'keep-alive',
  'cache-control': 'max-age=0',
  accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2046.3 Safari/537.36',
  'accept-encoding': 'gzip,deflate,sdch',
  'accept-language': 'en-US,en;q=0.8',
  dnt: '1' }

My config: https://gist.github.com/joeybaker/c7746eab0cce51dee3e2

Segmentation fault (core dumped)

$ gdb --args ./out/Release/bud --config default-config.json
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/christian/bud/out/Release/bud...done.
(gdb) run
Starting program: /home/christian/bud/out/Release/bud --config default-config.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000054a048 in uv__loop_alive (loop=0x0) at ../deps/uv/src/unix/core.c:252
252       return uv__has_active_handles(loop) ||
(gdb) backtrace
#0  0x000000000054a048 in uv__loop_alive (loop=0x0) at ../deps/uv/src/unix/core.c:252
#1  0x000000000054a0a0 in uv_run (loop=0x0, mode=UV_RUN_NOWAIT) at ../deps/uv/src/unix/core.c:262
#2  0x000000000040aa22 in bud_config_destroy ()
#3  0x000000000040abdf in bud_config_free ()
#4  0x000000000040968f in bud_config_cli_load ()
#5  0x0000000000405069 in main ()

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.