Ilya Grigorik on optimizing NGINX TLS time to first byte (TTTFB):
let’s now turn to the practical matter of picking and tuning the server to deliver the best results. One would hope that the default “out of the box” experience for most servers would do a good job… unfortunately, that is not the case. Let’s take a closer look nginx
In the simplest terms, TLS involves more work. The current realities of securing communications means we don’t have a good way to avoid doing that additional work, indeed we will be doing it more often than we ever have before. The end result is that we need to spend more time thinking about how to optimize the HTTPS experience for all users.
Many corporate firewalls will limit outgoing connections to ports 80 and 443 in a vain effort to restrict access to non-web services. You could run SSH on port 80 or 443 on a VPS or dedicated server, but if you have one of those you are probably already using it to host a small web site. Wouldn’t it be nice if your server could listen for both SSH and HTTP/S on port 80 and 443? That is where sslh comes in:
sslh accepts connections on specified ports, and forwards them further based on tests performed on the first data packet sent by the remote client.
Probes for HTTP, SSL, SSH, OpenVPN, tinc, XMPP are implemented, and any other protocol that can be tested using a regular expression, can be recognised. A typical use case is to allow serving several services on port 443 (e.g. to connect to ssh from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port.
Hence sslh acts as a protocol demultiplexer, or a switchboard. Its name comes from its original function to serve SSH and HTTPS on the same port.
Source code is available at https://github.com/yrutschle/sslh.
For small uses cases this may come in handy. If you were constantly needing to SSH to port 80 or 443 then I’d recommend just spending a few dollars a month to get a VPS dedicated to that task.
If you are stuck in a limited corporate network another tool you may find useful is corkscrew, which tunnels SSH connections through HTTP proxies.
Google has announced the move for several of their APIs to require SSL when making requests. This is a good thing.
If you aren’t planning on it already, now is a good time to expect new APIs to require SSL from the start. This is likely going to make TLS Server Name Indication an even bigger deal, as demand for SSL services increases and IP addresses become more expensive.