mholt

CT For Server (Developers)

Intro

Similar to my advice regarding OCSP Stapling for servers/server developers, based on questions I've received about "CT best practices," I wanted to write something similar for those writing server software. That is, this isn't targeted at server operators, but for those writing software like Apache, nginx, Caddy, etc.

At the most basic level, the deployment of Certificate Transparency to date has largely tried to focus the burden on CAs, rather than on server developers. If the CA is doing everything right,

mholt

// Handler that calls generate
func ok(w http.ResponseWriter, r *http.Request) {
	// res := make([]int64, 0, 100000)
	var res [100000]int64
	fibonacci.Generate(&res)
	// fmt.Println(suc)
	// fmt.Printf("%T", res)
	// fmt.Println(res[50])

	fmt.Fprintf(w, "OK")

mholt

package main

import (
	"github.com/kardianos/service"
	"log"
	"flag"
)

type Service struct {}

mholt

On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

1. Support for keeping a long-lived (disk) cache of OCSP responses.

   This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server

mholt

Date: Mon, 5 Oct 2015 16:34:03 -0700

Apache caches an OCSP response for one hour by default. Unfortunately, once the hour is up, the response is purged from the cache, and Apache doesn't attempt to retrieve a new one until the next TLS handshake takes place. That means that if there's a problem contacting the OCSP responder at that moment, Apache is left without an OCSP response to staple. Furthermore, it caches the non-response for 10 minutes (by default), so for the next 10 minutes, no OCSP response will be stapled to your

mholt

#!/bin/bash
# *As root*

cd ~
killall caddy
rm -rf ~/caddy
mkdir caddy && cd caddy
curl -SL 'https://caddyserver.com/download/build?os=linux&arch=amd64&features=hugo' > caddy.tgz
tar xzf caddy.tgz 

mholt

fff.red {
    header / {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Content-Security-Policy "default-src https:*"
        Public-Key-Pins "pin-sha256=\"ckOIjdimiwD3mfMmkmCh7uiJCBtXvoqoBoKKB1K5UIM=\"; pin-sha256=\"QiTyymM4e635OgWkx9d7nq5xvEuqmgV7HiDjIIGyymo=\"; max-age=2592000"
        X-Frame-Options SAMEORIGIN
        X-XSS-Protection "1; mode=block"
        X-Content-Type-Options nosniff
    }
}

mholt

config_server "https://etcd.local:2379"

service users {
  endpoint: "/users",
  proxy: "{{services.users.ip}}:{{services.users.port}}"
}


# In this example 'services.users' would be a directory with a json key for every user service container / application. 
# Using this we could template the proxy and any other information in the services block, and it would just work with caddy.

mholt

Supervisors

A supervisor's main task, is to start a specified process (in a specified environment), watch it running, and do something when it ends - usually based on the exit code.

Systemd

From my experience, the environment setup can be a complex task (consult some config management for the required ports, actualize the config file from the central config management...), and this is where the most featureful supervisor (systemd, AFAIK) falls short:

• it can setup & manage the listening sockets, and pass it to your app (if it can accept it - not hard, just have to be ready for it),

mholt

// Comcast Cable Communications, LLC Proprietary. Copyright 2014.
// Intended use is to display browser notifications for critical and time sensitive events.
var _ComcastAlert = (function(){
	return {
		SYS_URL: '/e8f6b078-0f35-11de-85c5-efc5ef23aa1f/aupm/notify.do'
		, dragObj: {zIndex: 999999}
		, browser: null
		, comcastCheck: 1
		, comcastTimer: null
		, xmlhttp: null