Still, I’d think a persistent connection (with, say, a 30-second timeout) would nicely reduce the amount of data sent over the wire. If nothing else, the server-push would facilitate a significant response time improvement.
I’m not sure I understand where you’re coming from on this. Most clients only make a connection to Let’s Encrypt once every 60 days. How would maintaining millions of persistent connections be less taxing than this?
It seems like both of these properties could also be achieved with HTTP/2 and would probably be less of a deviation from what we’re doing now than raw TCP or WebSockets.
For both ideas (HTTP/2 or raw TCP/WS) I think the primary “catch” (other than the usual constraints of limited dev/ops resources) is the CDN we have in between Boulder and ACME clients. I know of at least one CDN that outright doesn’t support WebSockets. I don’t know what the state of HTTP/2 is for our current CDN.
This is likely alleviated somewhat by TLS session resumption.
Let’s say that a given ACME session consists of 4 HTTP transactions, which consists of some delays to allow the server to do DCV.
Compare that scenario to a persistent connection, where the issued cert can be sent immediately to the client. The client would then close the connection. This “happy path” scenario is a clear win since there’s only 1 handshake, and the client can get the DCV-OK notice and certificate without polling.
There is obvious potential for abuse, but as with HTTP keep-alive, a simple timeout should solve this.
RE: handshakes, I believe HTTP/2 implements connection multiplexing to use one TCP connection for many requests.
RE: Certificate push, I think HTTP/2 server push might be something that could be used for this.
I admit I haven’t actually thought very hard about it and I’m by no means an HTTP/2 expert
I do think SSE/EventSource could work for the envisioned purpose and would gain the benefit of HTTP/2 multiplexing. I’ve not played with this kind of setup myself, but if WebSocket doesn’t work for LE then SSE over HTTP/2 might do the trick.
SSE is actually very simple. It’s just a stream of “messages”, in the same format as HTTP headers, delineated by 2 CRLFs. It’s simple enough that it “just works” on top of HTTP/2 as well as 1.1.
For clients, being able just to “wait” for the certificate rather than polling would probably significantly improve the response time. For individuals that wouldn’t matter much, but for large servers with thousands of vhosts it could be significant.