Since v0.1.3 Speakeasy supports HTTPS.
But Speakeasy v0.1.3 still runs plain HTTP service, so you need to modify its source code to be able to serve Speakeasy NodeJS app over HTTPS, or add reverse HTTPS proxy in front of NodeJS serving HTTP (3000/tcp, usually).
Almost everyone uses the second approach.
NGINX to Speakeasy ¶
The Speakeasy source code can be obtained from the Web.
Once you do that, the next step is HTTPS.
There are many ways to do it. One common way is to use a reverse proxy such as NGINX.
- Configure NGINX (or other proxy) with TLS certificates (443/tcp)
- Use NGINX to proxy HTTPS traffic to Speakeasy’s HTTP service (3000/tcp or whatever else)
- Open firewall (443/tcp, and 80/tcp if you need it)
There’s nothing Speakeasy-specific here, just google it and do it. Here’s one good example.
TLS certificates are commonly obtained with Let’s Encrypt, but any will do.
Cloudflare to NGINX to Speakeasy ¶
Another way is to use Cloudflare as reverse HTTPS proxy. Again, there are several ways here, but one easy approach is:
- Move DNS to Cloudflare
- In Cloudflare SSL/TLS settings for the Speakeasy Web site create TLS certs for “Origin Server” in Cloudflare
- Approach A is to create a CSR on your own and sign it in the Cloudflare control panel
- Approach B is to create a certificate in the Cloudflare control panel
- Deploy that TLS cert on your NGINX or other reverse proxy sitting in front of Speakeasy
- In Cloudflare SSL/TLS Overview, set Full (Strict) TLS mode (“Encrypts end-to-end, but requires a trusted CA or Cloudflare Origin CA certificate on the server”)
This last item is why we need to create a valid TLS on the server. If you didn’t choose Full, you could expose Speakeasy on 80/tcp, or even expose NGINX with self-signed TLS on 443/tcp, but that would leave you vulnerable to MITM between Cloudflare and your site.
For Full (Strict) we could also configure Let’s Encrypt on NGINX to get and renew Let’s Encrypt certificates for you, so that you don’t have to use Cloudflare-generated certificates. I don’t like that idea (Let’s Encrypt) because it means more work and doesn’t have any benefits.
A disadvantage of the above approach (using a Cloudflare proxy with a Cloudflare-generated or Cloudflare-signed TLS certificate) is that clients accessing your host directly (i.e. not being proxied by Cloudflare) would not see a trusted TLS certificate because they’d be accessing another (not Cloudflare-managed) hostname or an IP. Whereas a Let’s Encrypt certificate on your NGINX server would let both Cloudflare and direct visitors trust it.
But since we already chose to use Cloudflare and implicitly trust it, there’s no reason to allow direct access to NGINX (or other reverse proxy colocated with your Speakeasy server) in the first place.
Speakeasy clients don’t send messages through Cloudflare. Cloudflare is there to prevent DDoS and other attacks on your server, so if you don’t need that there’s no need to use Cloudflare in the first place.