AcornSSL server functionality

I’ll try and add TLS support to the VNC server this weekend. In theory it’s just a couple of extra VNC handshake messages followed by the TLS negotiation, so it should be pretty easy to get working.

1. If you’re changing AcornSSL_Creat to return the underlying socket handle, that change should probably be tied to a new flag (e.g. bit 8 of R0). That way software which assumes R1 is preserved won’t break, and old versions of AcornSSL should throw an error if someone tries to use the flag.
2. The docs should clarify what type(s) of certificate are supported (I’m assuming both DER-encoded and PEM-encoded, judging by the documentation for the mbedtls_x509_crt_parse functions)

Both good points, thanks, Jeffrey.

AcornSSL_Bind and AcornSSL_Accept are not required as the listening socket has no secure layer

I would do ‘how to use’ like this:

1) Use AcornSSL_CertOp to create a certificate context and a key context.

2) Use AcornSSL_CertOp to read the certificate(s) and key into the contexts,
either by reading the files directly, or by loading the files into memory
and reading them from there.

These contexts can now be used for all client handles until the app is closed.

3) After accept Use AcornSSL_CreateSession with
      R0 = socket from accept 
      R1 = AcornSSL_NewAccept
      R2 = cert
      R3 = key
   return
      r0 = ssl_handle
      
  Exit from AcornSSL_CreateSession is the same as for AcornSSL_New 
  ie the handshake continues during the first phase of read or write.

4) Use AcornSSL_Read and AcornSSL_Write to exchange user data.

5) Use AcornSSL_Close to close the client ssl handle.

Personally I would prefer that AcornSSL_CreateSession completed the handshake then you could use it non blocking in a loop but AcornSSL doesn’t work that way.

Edit: note you need to close the socket after AcornSSL_Close when using AcornSSL_CreateSession

I just wanted to say that I like that there is a version with server functionallity now. I have some projects in the back of my mind which require this functionality but I am busy with other projects now. Anyway I downloaded the version you provided just in case it will not be available anymore in the furture. But I hope it will just find its way into RISC OS.

I tried converting a client/server demo I have but I’m stuck with AcornSSL_Handshake. How does it work – what goes in the registers? I tried ignoring it and letting AcornSSL_Read/Write do the handshaking but that failed with ‘Bad context handle’. It may be something else but I’m not getting any errors from your functions.

Re. AcornSSL_Handshake: the docs are wrong – I have no idea what happened there. Looks like the text is copied from AcornSSL_Getsockopt, but I have not the faintest idea why it would be.

The only entry parameter is the SSL handle in R0. The returned value is 0 for success, or EINPROGRESS to call again. AFAIAA you have to call AcornSSL_Handshake in order for the server handshake to take place -t’s not optional.

This is a call where I sometimes see error -76, and I have no idea why. It’s not fatal to the handshake process. I treat -76 and EINPROGRESS as saying call again. Unless someone can help me with an explanation of why I should treat error -76 any differently, I’m going to translate it to EINPROGRESS so there’s only one code to look for to try again.

note you need to close the socket after AcornSSL_Close when using AcornSSL_CreateSession

I’ve got to correct the docs again – I discovered that I need to call AcornSSL_Shutdown with R1 = 2, followed by AcornSSL_Close, to get the sockets to close. That’s what fixed the “zombie sockets” that I mentioned earlier in the thread.

AcornSSL_Bind and AcornSSL_Accept are not required as the listening socket has no secure layer

AcornSSL_Bind is much easier to call than Socket_Bind. No struggling to find how you populate structs.

As for AcornSSL_Accept: I don’t know whether it’s possible to do it like you say – maybe it is. However, one of the good things about the AcornSSL module is that you don’t need to deal with sockets, you deal only with SSL handles. The parameters to AcornSSL_Accept are SSL handles. The only reason to deal with socket handles is in the more advanced case of wanting to avoid polling, and lots of users will be happy without needing to do that.

Which reminds me: is it possible to get an application to handle an OS event? AFAIAA, the answer is no. Presumably that’s where the Socketwatch module comes in – although I’ve never used it, so I could well be wrong again.

I’ve realised that I put in the code for an AcornSSL_GetSocket SWI, but I didn’t link it to anything, thus the SWI doesn’t actually exist. Since all the AcornSSL operations that create a socket, also (can) return its handle, is there any point in adding the SWI? I think the answer is no, so I should remove the implementing code.

Since all the AcornSSL operations that create a socket, also (can) return its handle, is there any point in adding the SWI?

Can return the socket handle at the time it is created, or at a random later point in time?

I’ve gone as far as I can go with the certs I’m testing with as they fail verification – cert expired

AcornSSL_Bind is much easier to call than Socket_Bind. No struggling to find how you populate structs.

True but that is not how acornssl works. AcornSSL_Connect works like connect not mbedtls_net_connect so for consistancy AcornSSL_Bind has to work like bind doesn’t it? Basically many of the AcornSSL swis are just the same as socket functions and are just a way to pass the socket handle to socket functions. AcornSSL_Read, AcornSSL_Recv, AcornSSL_Send and AcornSSL_write are the only socket functions that have a security layer all the other calls that are the same as a socket functions are just wrappers to normal socket functions.

As for AcornSSL_Accept: I don’t know whether it’s possible to do it like you say – maybe it is. However, one of the good things about the AcornSSL module is that you don’t need to deal with sockets

Using AcornSSL is no different to sockets. AcornSSL_Connect is passed sockaddr_in, the ssl_handle is just a proxy for a socket handle. Making it work different to sockets just means if you know how to program in sockets you have to work in a different way for ssl. The first thing I did for your bind api was lookup mbedtls_net_bind to see what it does to confirm it is doing what I expect.

If you are going to convert an existing program The easiest way is to leave everything as sockets add AcornSSL_CreateSession after connect or accept and just change read/write to the ssl version and use AcornSSL_Close before your socket close/shutdown.

I noticed when testing mbedtls that mbedtls_net_bind didn’t accept an address like “192.168.16.69” like your bind function says you can use – did you cater for that? Linux allows null to be passed but that doesn’t work either – maybe mbedtls_net_bind needs fixing.

I noticed when testing mbedtls that mbedtls_net_bind didn’t accept an address like “192.168.16.69” like your bind function says you can use – did you cater for that?

“192.168.16.69” is literally what I have used all the time during testing, as it’s the IP address of the RasPi that I’m using to develop AcornSSL. I can assure you that it works for me. I can’t imagine why it doesn’t work for you.

address$ = "192.168.16.69"
port$ = "480"
SYS "AcornSSL_Bind", address$, port$, 0 TO rv%, handle%, s_skt%

The above is (apart from any typing errors, and other code between the second and third line) the exact code from my test app.

If you are going to convert an existing program The easiest way is

Ah, that explains our different thought processes. I’m looking beyond least-effort conversion of existing apps, to writing new ones using a consistent approach. AcornSSL is consistent about using opaque SSL handles for everything. I really don’t want to get into a hybrid approach where AcornSSL_ and Socket_ calls have to be mixed.

I see what you mean about AcornSSL_Connect. That’s a missed opportunity to make things easier, isn’t it?

Not that it matters but I would continue to use sockets for a new project I don’t see the point of the AcornSSL socket swis that are used prior and including connect/accept. I don’t see how returning socket handles is avoiding a hybrid approach.

“192.168.16.69” is literally what I have used all the time during testing

So it does – I don’t know what went wrong before.

Can return the socket handle at the time it is created, or at a random later point in time?

The only AcornSSL SWIs that create sockets are Creat, Bind and Accept. Bind and Accept are my additions, for server use. Creat is an original. They all return the socket handle – Creat didn’t, but I’m modifying it to do so, conditionally on a flag. So it’s all “at the time it is created”.

I don’t see how returning socket handles is avoiding a hybrid approach.

There is no need to use the socket handles to have a working client and/or server app using AcornSSL. The only reason for returning them is for the benefit of programmers who wish to write an entirely event-driven application, as the Internet event (on which they would be forced to rely, directly or indirectly) works on socket handles, not on SSL handles.

If we add an SSL event, we could write SSL apps entirely without needing to know socket handles. Anyone up for that? (I’m not.)

The only AcornSSL SWIs that create sockets are Creat, Bind and Accept. Bind and Accept are my additions, for server use.

It was an enquiry more along the lines of “How do I find the handle of an opened socket?”

Ah I see where my code may have failed, I expected CreateSession_EmptyServSess to have a socket in r0 – CreateSession was previously only for use with existing sockets. Can I have a version of AcornSSL_CreateSession preferably with reason code CreateSession_NewAccept as I outlined above or alternatively change CreateSession_EmptyServSess to take a socket in r0 – or -1 if no socket is involved

Colin, try the one that’s up there now. I’ve gone for the latter solution – you can pass a socket handle or -1 in R0 to AcornSSL_CreateSession with R1 = CreateSession_EmptyServSess.

Note: I haven’t tested this! You will no doubt let me know.

I’ve updated the docs too, though I don’t know whether I’ve fixed everything that’s been mentioned.

Damn – I keep forgetting to alter the module’s date, so it still says 18 Feb 2021. Sorry.

Pity there isn’t a DATE and TIME keyword in the ‘C’ compiler.

Didn’t Rick add something like it to add version/time to his code automatically?

Pity there isn’t a DATE and TIME keyword in the ‘C’ compiler.

printf("%s, %s\n", __TIME__, __DATE__);

Didn’t Rick add something like it to add version/time to his code automatically?

It’s just a little BASIC program that predefines strings with the application name, version, and date…and a mod to the MakeFile to ensure that it is always rebuilt every compile time.

It should auto increment the version number if the date changes, but I never got around to doing that bit. ;-) Still, it’s one single place to change where that information is used.

Damn – I keep forgetting to alter the module’s date, so it still says 18 Feb 2021.

Comment out the date-string: line in cmhg.AcornSSLHdr and ether clean before compiling for distribution or add

standalone: setdate

setdate:
        ${TOUCH} cmhg.${CMHGFILE}

to the makefile after ‘include CModule’. That will force the cmhg file to be compiled when MkRam is run. add ‘debug: setdate’ if you want to change the debug version.