AcornSSL with server support

I’ve had my own version of AcornSSL with server support going for a while now. It also supports IPv6 on the ROD stack.

I’m hoping that my work will be useful to others, so I’ve put up a modified version of the AcornSSL API document with my changes, at https://davehigton.me.uk/WIP/AcornSSLDoc.txt so that my proposals can be debated. Please, if you have any interest in it, have a careful look and put your criticisms here.

Most of the changes to the API are additions. The one change (as far as I can remember!) is to add a flag bit to AcornSSL_Creat to enable returning the socket handle as well as the SSL handle. We’ve had a debate in this area before; one school of thought is that you should only use the secure handle to exchange data, therefore you don’t need the socket handle and you shouldn’t peek round the side. The other school of thought is that there is no point in peeking (or poking!) round the side since neither side will understand what the other has sent because of encryption, but the legitimate use for the socket is to use the Internet event, which works on sockets but not on SSL handles.

Really I think AcornSSL_Creat should always return the socket number in R1, without needing to set a flag bit, but R1 would be changed by the call, so it would not be not conformant with the existing API. Discuss…

There is a SWI AcornSSL_MakeDTLS, for which the doc says “This code does not yet work. Do not use it.” There is code that ought to support DTLS, and indeed DTLS has been made to work on RISC OS with the mbedTLS library, but I haven’t managed it with the AcornSSL module. I’m reluctant to remove the code, since it must be very nearly correct. If you don’t use it, nothing goes bang due to its presence.

OK, over to you all.

Oh, and if my proposals survive not too badly scathed, I’ll work towards getting the changes into git.

Nobody?

Clearly we are stunned!

Does it come with a simple server to demo it with?

To split hairs: no, but I can provide two demos, one for IPv4 and one for IPv6. I’m also happy to send out a copy of the module as it is, to enable testing.

There is a minor downside in that just using my demo apps doesn’t test it more than I already have done. I’d like to see the results of someone writing their own app. Most of all, I’d like to see WebJames updated to use AcornSSL and IPv6.

Anyone using the apps will have to have DNS (probably dynamic) pointing at their IP address, and will need certificates and private key – available free from Let’s Encrypt (and possibly other organisations). You will also need to set up a pinhole in your IPv6 firewall, or a port forward to your IPv4 address.

I have also disabled TLS versions 1.0 and 1.1 in my build of mbedTLS. Doing so enabled me to get an A rating in SSL Labs’ test. I still send and collect email and news with this version, so I don’t appear to have lost anything so far. NetSurf doesn’t use AcornSSL, so it’s unaffected; same for wget and curl. But it would be of wider interest to the community, I think, to see if any service is affected.

I think a reorganisation and some additions to my website’s WIP directory are coming up.

I did start work on a version of vncserver with SSL support, but ran into problems getting it to work reliably and never found the time to fully resolve them.

If you’ve got an up-to-date build available for testing then I can try again with the new version. The demo server would also be useful (writing a demo server to test different scenarios was on my todo list for diagnosing the VNC issues)

OK. https://davehigton.me.uk/WIP/AcornSSL.zip is my enhanced version of the AcornSSL module. https://davehigton.me.uk/WIP/IPv6.zip is the IPv6 version of the Hello World demo server.

If it doesn’t work, please complain here.

Erm… it looks like I upgraded my IPv4 version to IPv6, rather than starting from a copy, so it may be a while before I can post an IPv4 demo server. Sorry…

Newly (re-)created IPv4 version is at https://davehigton.me.uk/WIP/IPv4.zip

You will also need to set up a pinhole in your IPv6 firewall

Hmmm, I hadn’t thought about that. I can’t see any way of doing such a thing on the Livebox (other than putting the entire machine in the DMZ). There’s no IPv6 DNS, so I don’t think I should expect fancy things like coping with incoming connections…

I can’t see any way of doing such a thing on the Livebox (other than putting the entire machine in the DMZ).

Generally speaking that’s exactly where a device exposed to the outside should be, although I’d suggest that people invest in something better than the ISP provided router / “firewall”.
A bit of research in your area may well turn up a box (PC or similar) that can be rebuilt with two physical interfaces and run something like OPNsense

There’s no IPv6 DNS,

I think you will find Dave was actually a reference to an external (Internet) DNS record provider Dynamic DNS
Various services out there if you go looking

Since most people have tended to not host things on home kit¹, it is something most people have never looked at

¹ ADSL upload being a bit low for that kind of activity.

I think you will find Dave was actually a reference to an external (Internet) DNS record provider

I was.

There has to be a way to create a pinhole in your Livebox’s IPv6 firewall, surely?

Generally speaking that’s exactly where a device exposed to the outside should be

Ah, but can DMZ devices see the LAN? If so, opening specific ports via NAT might be better than giving the outside world unfettered access to the device.

was actually a reference to an external (Internet) DNS record provider

I know. What I was suggesting is that it looks like they have implemented the barest minimum to be able to claim IPv6 support.

Let’s try, for starters, what would be my external IP address be? If it’s the global one, doesn’t that need some sort of NAT on the LAN side?
As it happens, the No-IP stuff built into the Livebox only sets the IPv4 address so…

ADSL upload being a bit low for that kind of activity.

As computers get more capable and fibre more prevalent…

create a pinhole in your Livebox’s IPv6 firewall

Possibly by messing with the firewall itself, but that’s a bit of a “here be dragons” that I’ve left at the default settings.
I’d have hoped that this might have been a part of the NAT stuff that exposes ports to the outside world, but alas…

Maybe the more recent Livebox models are better?

Ah. IPv6 is very different from IPv4. You have a block of perhaps 2^64 addresses, all of which can (if you so choose) can be exposed to the outside world. You have a firewall, and you open a pinhole in it for one port at one IPv6 address. There is no address translation.

and you open a pinhole in it for one port at one IPv6 address.

Found it! It only appeared once there was something the might possibly require inbound connections using IPv6 on the network. I’ve set it to accept port 6502, but…
…moments after I turned on IPv6, stuff started to crash. I’m guessing I’m running the older stack on this machine.

You have a block of perhaps 2^64 addresses,

The Livebox says 2a01:xxxx:xxxx:7e00::/56.

Given all the faffing (the IPv6 DNS, the keys, updating the stack…), I will leave this for the weekend if it is rainy (if not, prolly mow the grass).
For now, having eaten three Mars to get over the shock of the quotation from the dentist for two crowns (they’d better be actual crowns with diamonds on) and telling me “don’t worry, my top-up will pick up the other €HOLYCRAP” (what’s left after the state’s tiny contribution), I think I’m going to go out and take some pictures of flowers, there ought to be some out by now. It is currently 15C (in mid-February!), so I have the doors and windows all open, warm it up in here!

Anyway, found the port opening. It was hidden until something IPv6 that wasn’t a mobile phone showed up. I guess there’s a weird sort of logic in that.

Meanwhile, my phone’s IP address is 10.138.6.131 which suggests that Orange is using some sort of massive dynamic NAT to handle mobile phone internet connectivity…

I think I’m going to go out and take some pictures of flowers, there ought to be some out by now. It is currently 15C (in mid-February!),

Our camellia is flowering, first flowers opened last week.

IPv6 info links were in a different thread.

The Livebox says 2a01:xxxx:xxxx:7e00::/56.

Perhaps Mr. Pampling can tell us what /56 means, and why it is often /56 rather than the /64 that I had expected?

Anyway: a consequence of unique addresses for each IPv6-capable piece of equipment is that a DNS entry is necessary for each. Fortunately (or perhaps also consequently) I found that dynv6.com is happy to give out multiple entries per free account.

I’ve got a little goody that might be useful for people experimenting with IPv6. It’s a little app that finds the IPv6 address of a RISC OS host and sets the variable Inet$EtherIPv6Addr accordingly, and updates my dynv6.net DNS entry automatically when the machine is given a different IPv6 address. I run it on boot-up. I’ll post again here when I’ve uploaded it to my website.

It’s perhaps worth mentioning that dynv6.net DNS entries are dead easy to update from RISC OS. All it takes is an appropriately constructed curl command.

All in all, IPv6 has been easier than I expected. I think ROD deserve a lot of credit for their work.

moments after I turned on IPv6, stuff started to crash. I’m guessing I’m running the older stack on this machine.

The released version of the stack is stable. I recommend anyone who has any earlier one to update.

and why it is often /56 rather than the /64 that I had expected?

Because “Sixteen million addresses ought to be enough for anybody”? ;)

a consequence of unique addresses for each IPv6-capable piece of equipment

Seems that my stuff typically has three such addresses. An actual one (that doesn’t change), one that changes, and… I dunno, a spare?

I think ROD deserve a lot of credit for their work.

Certainly. And to keep it largely compatible with the old API as well, that’s pretty impressive.

I noticed in the recent show review, some work on supporting WiFi.
Which stack is that for?

The released version of the stack is stable.

That’s what I thought, just need to get this machine updated…

I noticed in the recent show review, some work on supporting WiFi. Which stack is that for?

That will come out in the ROD stack at some point.

Seems that my stuff typically has three such addresses. An actual one (that doesn’t change), one that changes, and… I dunno, a spare?

My Linux box is like that. There’s one that begins with fe80, which is only valid locally, i.e. not routable. The other two… I dunno why, but only one is visible from outside.

Perhaps Mr. Pampling can tell us what /56 means,

56 bit mask

For less stress on brain cells a typical /24 on an IPv4 would be 192.168.1.0/24 where 24 of the 32 bits are masked to be the same for all IP’s belonging to that subnet so you have FF_H +1 variable bit combinations 0 – 255. The 0 is the net address, the 255 is the broadcast address.
Switch to a /23 subnet mask and your 192.168.1.0/23 now has twice as many IPs and because I picked 192.168.1 rather than 192.168.0 the net address went down (to 192.168.0.0 and the broadcast stayed up at 192.168.1.255)¹

You will have noticed that the IPv6 addresses are strings of hex characters, what you may not have noted is some abbreviating in the stuff you’ve quoted – look at the colons :: where a string of 0’s would be
These are big numbers, so a bit of shorthand tends to be used.

Generally speaking you shouldn’t try to subnet down from /64 as that /64 is the smallest supported if you want the autoconfig to work.
Why they selected /64 (i.e. 2⁶⁴ addresses) I don’t know.
So, handing out a /56 block gives you 256 /64 nets to play with, much like a /24 allocation gave you 256 IPs (if you count 0)

¹ Lesson, take care when planning IPv4 scopes that might need to be super scopes in the future. There’s a spreadsheet at work that dates back to 2003 when I planned out the then impending new network schema. Yes, the first allocations had what other people considered inexplicable jumps between allocated ranges. By the time 20 years had passed, people sort of appreciated those gaps that got filled with expansions. Plus the routing of particular blocks was easier to summarise.

I’ve got a little goody that might be useful for people experimenting with IPv6

I promised to post again when it’s on my website. It is now, at https://davehigton.me.uk/WIP/Dynv6.zip

I hope someone finds it useful.

Well, has anyone played with any of the goodies?

Just as a reminder, there’s enough there for you to set up demo IPv4 and IPv6 HTTPS servers on your home machines. Plus VNC with SSL support. Plus updating IPv6 dynamic DNS if you get it from dynv6.com.

Apologies for taking a while to look at it.

What happened to AcornSSL_Certify? The flow the VNC server was using was:

1. Set up a regular listen socket
2. Accept an incoming connection
3. Send some VNC messages back and forth to agree with the client on upgrading to TLS
4. Use AcornSSL_CreateSession + AcornSSL_Certify + AcornSSL_Handshake to upgrade the regular socket to an SSL one
5. Use the upgraded socket to finish VNC authentication & serve the VNC session

(aka opportunistic TLS)

Is it still possible to do that using the new API?

Good question. I don’t think it is. To my way of thinking, AcornSSL_Certify is just a way to create, modify or delete a certificate context. There was a way of doing it when there was only a certificate (or cert chain) and a private key, but when I learned about Server Name Indication, it seemed such a close relative of certs and key that it belonged in there – and I didn’t want users to be messing about with 4 arguments (context, cert(s), key, server name) so I changed the way it worked.

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.)

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

I tend to think of the process as adding the cert/key/name context on the AcornSSL_Accept SWI, but perhaps this is too late.