AcornSSL with server support

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?

I wasn’t aware that you were using a version of AcornSSL that had the AcornSSL_Certify SWI. Did it come from me? (My memory is getting worse, all too quickly.)

Yes, it was present in your Feb 2021 versions of the module.

Having created a fully populated context, would it make sense to add another function code to add the context to a regular socket?

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?

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.

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:

1. Use AcornSSL_Creat, AcornSSL_Bind, and AcornSSL_Listen to set up a listen socket
2. Use AcornSSL_CreateSession CreateSession_EmptyServSess to create a “client SSL handle”, with -1 as the socket handle
3. Use AcornSSL_Certify to add the certs + private keys to the client SSL handle
4. Use AcornSSL_Accept to accept an incoming connection, specifying both the listen socket and client SSL handle
5. Use AcornSSL_Handshake to wait for TLS handshaking to complete

The new version merges steps 2-4 together so that they all happen in the AcornSSL_Accept call.

Meanwhile opportunistic TLS servers would:

1. Use Socket_Creat, Socket_Bind, and Socket_Listen to set up a listen socket
2. Use Socket_Accept to accept an incoming connection
3. Use the new socket returned by Socket_Accept to do protocol-specific negotiation to decide whether TLS should be used
4. Use AcornSSL_CreateSession CreateSession_EmptyServSess to create a “client SSL handle”, passing in the client socket that was returned by Socket_Accept
5. Use AcornSSL_Certify to add the certs + private keys to the client SSL handle
6. Use AcornSSL_Handshake to wait for TLS handshaking to complete

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:

1. Use Socket_Creat, Socket_Connect to create and open the connection to the server
2. Do the protocol-specific negotiation to decide whether TLS should be used
3. Use AcornSSL_CreateSession CreateSession_New to pass the socket to AcornSSL
4. Handshaking is performed in the background; code can immediately start using AcornSSL_Read & AcornSSL_Write

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?

Now we need an https web server :)

Sorry I wanted to evaluate Daves module since a while with HTTPServ but didn’t find time to do so. And if I am now looking out of the window … 4 weeks ago I was proud that I cut the bushes so well last autumn. And now 4 warm rainy weeks later it looks more dense and higher as before the cut in last autumn to me :-(. I fear the evaluation of Daves module still has to wait for a while …

No problem. Nota. if you manage to make an auto renew tool for Let’s Encrypt certificates, you’ll be a god for many users :)

if you manage to make an auto renew tool for Let’s Encrypt certificates, you’ll be a god for many users

It would be very complicated, and it already exists on Linux, so I don’t have any impetus to do it. Sorry.

My way of renewing the certs for the RasPi at the moment is to point dynamic DNS at my Linux box, run certbot to renew the certs, then restore dynamic DNS to the RasPi and copy the new certs over. Let’s Encrypt claims to support redirects up to 10 deep, so I think I ought to be able to leave DDNS alone and get the RasPi to return a 301 redirect to the Linux box. However, when I do, certbot on the Linux box doesn’t respond the same to the redirected challenges as it does when the original challenges go straight to it, and the renewal fails. I need to investigate some more.

In summary, if I can get the Linux box to do renewals without having to mess about with DDNS, that’s as much as I think I’m prepared to do.

Sorry Dave. The message was more for Thomas and HTTPServ :)

I’ve just updated my HelloW demo (only my own version, not on my website) to respond correctly to an ACME HTTP-01 challenge. It’s easier than I thought.

Security is nowhere to be seen; any well-formed challenge will receive a response including the account thumbprint. This appears to be just the way the challenge and response work, because I copied it from a Wireshark capture of a certbot session and I recognised the thumbprint.

Curiously, a certbot dry-run requires a different thumbprint.

The only security I can see is to restrict the time for which it responds to the ACME challenge, to the time when a certbot session will run. This has to be turned on and off manually, whereas certbot on my Linux box operates as a cron job, so I don’t see when it is going to run.

I will update HelloW on my website when I’ve added the ability to turn response on and off, and I’ll post again here.

I’ve added HelloW to my web site, at https://davehigton.me.uk/WIP/IPv6NS.zip This is the non-secure version, and it can now switch on or off response to an ACME HTTP-01 challenge by means of a menu entry.

I hope it may be of use to someone.

The HTTP-01 challenge is performed plain, because it cannot be assumed that you have valid certificates, or indeed any certificates at all first time round, hence this non-secure version.

When I needed to renew certs, I used to have to alter my dynamic DNS entry to point to the Linux box (so it could respond to the challenge and thus prove my ownership of the domain), renew the certs, and then alter the dynamic DNS back again. Now there is no need to fiddle with the dynamic DNS.

I don’t suppose anyone has tried setting up demo (or even real!) IPv6 servers, including secure, have you? I may have been doing all this stuff for no-one’s benefit but my own.