Has there ever been discussion of raw TCP (or WebSocket) access to ACME APIs?
This could significantly reduce overhead since there wouldn’t need to be a separate HTTP handshake every time the client has something to say to the server.
The server could also then push the certificate immediately rather than having the client poll, which would both reduce server load and improve the response time for the client.
The HTTP connection isn’t the heavy part; the TLS handshake is. That would exist no matter what - Let’s Encrypt isn’t going to start providing an unencrypted endpoint.
Do most client implementations use keep-alive?
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?
Not that I'm aware of 
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.
I’d be curious how you have in mind that HTTP/2 would implement this? Maybe some sort of SSE-alongside-multiplexing?
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
My understanding is that HTTP/2 server push isn’t for sending notifications; it’s for preemptively sending resources (e.g., JavaScript) that the client needs without waiting for the client to request them.
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.
Yes - I think you're right about that 
I'm not familiar with this feature of HTML5. It seems like it might be a lot of complexity to take on to save some polling GET requests. These aren't a cause of significant load on the server.
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.
Anyway … thank you for the discussion. 
Interesting! I should do some reading
Thanks for asking the question. @jsha might have some thoughts here as well.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.