AcornSSL server functionality

I’d like to break AcornSSL.

What I want to do is make the ssl_handle the socket number. This would mean you could have AcornSSL_Select. The problem is an invalid socket is -1 and an invalid ssl_handle is 0. Making the ssl_handle the socket number + 1 makes things complicated as existing select structures can’t be used. I’m wondering if there may be a way for socket num 0 never to be seen by acornssl but I can’t think how.

Not really thinking of breaking AcornSSL just exasperated on how a good idea gets spoiled by the simplest of problems.

Socket_Select.

Wow.

I’m struggling to understand it at all. The bit that I think I understand, suggests to me that it can’t be accessed from BASIC either – but if someone can show me how to do it, I’d be happy to learn.

I’m wondering if it would be possible to do an AcornSSL equivalent where, instead of an fdset, you have an array of SSL handles. There would have to be an entirely different way to give the equivalent of the FD_SET, FD_CLR etc. macros.

It looks like a right pig to use. Is there anyone reading who has ever used it? What advantages does it confer?

AntiSpam. FNselect.

Originally AntiSpam just called Socket_Connect and then went ahead with reading/writing, but that caused issues on some versions of VRPC (see AS change 201).

I’ve been reading that FreeBSD now has TLS support in the kernel, which means a secure socket can be handled in exactly the same way as a normal one after creation. If this could be included in an updated RISC OS network stack it would eliminate the need for Acorn SLL and many of the above issues.

If that happens as quickly as adding isochronous mode into the USB stack…

… I think I’ll keep on developing AcornSSL.

Seriously, isn’t there a disconnection in what you’ve just said? SSL support is in the kernel, not in the network stack?

Frank: thanks for the example, though I note that you only used it because of an apparent bug in another call on VRPC.

In any case I’ll have to study it further; argument S% can’t be a socket handle as you’re using it shifted and calling Socket_Select with S% – 1. No doubt it will all become clear eventually.

now has TLS support in the kernel

Oh my God.

I get the idea of handling an encrypted socket the same as a normal one (as best possible, there will always be implementation issues like handling dodgy certificates)…

…but isn’t the smart money on getting all this sort of crap out of the kernel?

…but isn’t the smart money on getting all this sort of crap out of the kernel?

Depends on whether you want basic network capability without the rest of what is often a lumbering juggernaught of an install.

argument S% can’t be a socket handle…

It starts as the socket descriptor and ends up being used as the ‘number of descriptors to consider in each set’ by adding (not subtracting) 1 (socket descriptors start at 0).

Just FYI: my watcher script spotted a new version 1.06 (the sixth in succession) of the AcornSSL module today. Uses mbedTLS 2.16.10 instead of 2.16.9.

It’s time I got back to AcornSSL server.

There are some goals that are pulling AcornSSL server in different directions. I might summarise them as ease of writing new apps, ease of porting existing apps, and purity.

Ease of writing new apps is best served by an API that needs as few calls as possible. It is simpler than calling the old raw sockets API, which must be – what – 40 years old now? (Not in RISC OS, of course.) If you were writing an app on another platform, I’m sure you’d be using something higher level.

Ease of porting existing apps is best served by copying the RISC OS sockets API as closely as possible. I was surprised when I updated an existing app of mine (a specialised HTTP server) to do HTTPS, and I had to scratch my head a bit to realise what chunks of code I had to delete because they were no longer used.

Purity is about using opaque SSL handles and not exposing or using the corresponding socket handles. Laudable until you consider that efficient existing apps will likely use Socketwatch, which uses the Internet event, and inevitably requires to be called with socket handles as parameters. If the new API is pure in this sense, existing apps that use Socketwatch aren’t going to work. One option is to build in equivalent functionality into AcornSSL so that the SWIs can be called via SSL handles. Easier done with new apps than with existing ones.

I hope this shows how the three goals can’t all be satisfied by the same API.

I had a look at Socketwatch’s code. It’s entirely in assembly language.

My instinct is to provide an API that’s as simple as possible (i.e. best suiting new apps), exposes the socket handles for those who want to use Socketwatch, and provide Socketwatch facilities within AcornSSL.

But that’s just my opinion. What do other app writers, potential users, think?

I cannot speak for porting things, but frankly I’d be surprised if things used low level sockets much these days, instead of some sort of library that makes things simpler.

One of the things I liked about the URL module and fetchers was the ability to knock out a hell of a lot of code and have something simpler that not only works, but is fairly agnostic to the protocol used (http or https).

I would not want to go back to handling an SSL connection myself. There’s a mechanism to make it easier, it isn’t perfect, but it’s better than all the farting around of doing custom socket code.

I don’t know if I even have SocketWatch here, but it seems to me that if SocketWatch is an important thing, it is highlighting an obvious deficiency in how RISC OS does networking. Maybe this is functionality that ought to be directly provided by the OS?

If it is necessary to extract a socket handle, there perhaps ought to be a SWI to accept the opaque handle and return the underlying socket handle. Now I know some will baulk at the idea, but it’s a mentality like that which leads to people making assumptions (such as “the opaque handle is an address and three words on is the socket handle” sort of thing) which potentially complicates future changes. Where there’s a will, there’s a way. Let’s make it the right way.

If it is necessary to extract a socket handle, there perhaps ought to be a SWI to accept the opaque handle and return the underlying socket handle.

I think it should be simpler than that – any SWI that returns an SSL handle (except one that converts an existing socket to secure) also returns the socket handle. No extra call to make.

If you don’t like the AcornSSL API write a different module. Canibalise AcornSSL if you need to.

If the only reason for exposing the socket handle is for socketwatch that functionality is easily added to the AcornSSL module it only sets a pollword on an internet event.

Encapsulation (purity) is a good thing it stops you doing silly things like setting a socket as non blocking using a socket handle instead of doing it with the AcornSSL handle which results in the secure api not knowing that a socket is blocking.

If the only reason for exposing the socket handle is for socketwatch that functionality is easily added to the AcornSSL module it only sets a pollword on an internet event.

That could be a simple extension to the API I would have thought, so that you could pass in the address of the pollword.

Colin, eventually I agree with you about cert/key ops. I’m thinking about a drastic simplification. Tell me what you all think.

AcornSSL_CertOp
On entry
R0 → cert chain file name, or
= 0 to make no change to the cert(s), or
= -1 to delete the cert(s)
R1 → private key file name, or
= 0 to make no change to the key, or
= -1 to delete the key
R2 → certificate and key context, or
= 0 to get AcornSSL to allocate one
On exit
R0 = 0 if no error, or
→ error block
R2 → certificate and key context

The straightforward use of this is with R0 and R1 pointing to the file names. The values of 0 and -1 allow changes to one or the other of the cert and key. I only see that as being useful during experiments and debugging.

Finally, -1 on both allows to deallocate the context.

Note that calling successively with multiple cert file names will cause certs to be added to the chain, whereas any call with a key filename will cause the key to be replaced. This is because there can only be one key – you can’t have a chain of keys.

AFAICS that removes the need for reason codes.

I don’t think there’s any point in supporting adding certs and keys from memory.

I’ve made the above changes. There’s a corresponding small change in AcornSSL_Accept, to use a combined cert+key context instead of separate contexts. Seems to work, but I need to test some more.

It reduces the number of operations necessary to create the cert and key contexts from 4 to 1, and operations to free them from 2 to 1.

How can I get debug output from the mbedtls code?

I’ve got it from the AcornSSL code by simply building and running the !MkDebug file to build it, but that doesn’t enable output from the mbedtls code.

It’s not that I want to make any alterations to mbedtls. My code is not working, and I need to see deeper inside.

I’ve found the missing call that my code should have made. Since then, it’s dead easy to set up a server with the API I have now: call AcornSSL_Bind with a cert and key context prepared earlier, call AcornSSL_Accept, then call AcornSSL_Handshake until it returns 0. It’s about as simple as it could be.

However, the simplicity comes at a cost. The bind operation currently opens a stream socket, binds it to an IP address and port, sets it non-blocking and sets it listening. This makes it impossible to create a DTLS socket, for example. So I’m going to rethink the API yet again.

The worrying part is that AcornSSL_Send and AcornSSL_Recv both call the internal function handshake_sslhandle, which calls mbedtls_ssl_handshake_step in a loop. That’s probably fine in the client case, with one SSL handle, but AFAICS it’s likely to be problematic in the server case with multiple handles. It looks like I need to get them to call different code if the handle is marked as a server.

I changed handshake_sslhandle by adding an argument to loop or not. The existing client calls are modified to call with loop true, so existing operation is unchanged. The handshake SWI calls it with loop false, so it can’t block in a loop – just call it repeatedly until it succeeds or errors out. This is what server code would use, so it should permit multiple handles to be opened by the server without problems caused by blocking.

It seems a pragmatic solution.

Does anyone know why api_connect() calls connect() rather than mbedtls_net_connect()?

I’m working again on adding server functionality to AcornSSL. I’ve just got some test code working again, this time with an API closer to the Socket API. At least, it’s working with IPv4; there are one or two places that, I think, will need some small changes to work with IPv6 too.

I’ve got IPv6 server functionality going too in AcornSSL for the first time. This certainly doesn’t count as exhaustively tested yet, of course…

Edit: the accept operation only returns a struct sockaddr_in* when it should return a sockaddr_in6*.