AcornSSL with server support
Pages: 1 2
Dave Higton (1515) 3404 posts |
Whilst looking at the “well known ACME challenge” recently, it occurred to me that it might be useful to add a call to calculate the SHA-256 hash of arbitrary data. Any thoughts, anyone? |
Jeffrey Lee (213) 6046 posts |
Yes, it was present in your Feb 2021 versions of the module.
With the previous version, pure TLS servers would use AcornSSL_Certify → AcornSSL_Accept → AcornSSL_Handshake. Servers which use opportunistic TLS would use CreateSession_EmptyServSess → AcornSSL_Certify → AcornSSL_Handshake. In the new version Certify has been merged into AcornSSL_Accept, but CreateSession_EmptyServSess was left untouched. So maybe the fix is as simple as updating CreateSession_EmptyServSess to accept the context? |
Dave Higton (1515) 3404 posts |
It would be sensible for CreateSession_EmptyServSession to accept a context, yes. But I don’t think it answers the requirement for opportunistic TLS. The assumption has always been that, if a context is attached, encryption would be attempted from the start; the context is the controlling switch. So it seems to me that we have to be able to switch from plain to encrypted, by attaching the context, after the connection is made. Feel free to correct me; I’ve always been floundering around out of my depth. |
Jeffrey Lee (213) 6046 posts |
I missed a couple of things in the old docs, so my previous post isn’t entirely correct. With the old version, pure TLS servers would:
The new version merges steps 2-4 together so that they all happen in the AcornSSL_Accept call. Meanwhile opportunistic TLS servers would:
It’s also worth looking at how client sockets are handled; the AcornSSL docs suggest that opportunistic TLS for client connections should be implemented as follows:
With the new version, I think it makes sense for AcornSSL_CreateSession to include a reason code which accepts an existing socket and an SSL context (containing cert/keys/server names), to act as a replacement for steps 4 and 5 of the opportunistic server case. But there are a couple of questions remaining: Question 1: Does it make sense to keep the current EmptyServSess functionality? This one’s a bit hard to answer since the docs don’t make it clear what can and can’t be done with it. E.g. is it valid for a program to use EmptyServSess to pass a partially/fully initialise listen socket over to AcornSSL? For example, server programs sometimes share the same listen socket between multiple processes, either for redundancy or to allow zero-downtime restarts/upgrades. For the upgrade case it makes sense that it would be an OS socket handle that gets shared between the processes, to allow each version of the server to have free choice of SSL library instead of being locked into AcornSSL. So for that case it would be useful to have a call which allows an existing OS listen socket to be used with AcornSSL. However, if opportunistic TLS is supported, there shouldn’t be anything stopping a pure TLS server from being implemented using the opportunistic flow. I.e. use Socket_Creat, Socket_Bind, Socket_Listen and Socket_Accept to accept incoming connections, and then immediately hand the client socket over to AcornSSL to do the TLS negotiation. So for my above example of a server passing a listen socket between processes, EmptyServSess isn’t required, because identical functionality could be obtained by using the opportunistic flow, for pretty much the same amount of development effort. Question 2: What should the new/updated reason code be named? “EmptyServSess” doesn’t make sense since it won’t be an “empty” session. Since opportunistic clients use CreateSession_New, maybe it should be CreateSession_NewServer? |
Pages: 1 2