AcornSSL server functionality

Partial success with VNC. CreateSession_EmptyServSess is able to take over the pre-existing socket, the TLS handshake completes, and both sides are able to talk to each other. But then something goes wrong and the VNC viewer reports a VNC-related error. So a bit of debugging is needed to try and work out what’s wrong.

Where do we get mbedTLS from? There appears to be more than one source. Depending on source, up to version 2.25.0 claims to be available. I have no idea of the differences, nor do I know whether the version number that appears in AcornSSL’s header matches the code.

As for the date of the module build, the failing link is just me forgetting to update the VersionNum file. Nothing more than that. In the proper build scheme, the file is automatically generated. I only need to manually edit it in my dev builds.

I’ve realised that the C compiler has a minor bug that I must get round to reporting (it generates a spurious warning of a variable being set but not used).

it generates a spurious warning of a variable being set but not used

That explains something I saw the other day. I have also had very occasional warnings of variables being used before being set, which I could see as true after much head scratching over the code in question.

Edit: I meant to say it was NOT true – the variable was definitely being set before use.

variable being set but not used

I get that warning with GCC 4.7.4 when the variable is declared but only used in an if function.
(when compiling Colin’s SerialTerminal)

Looks like the VNC problem might be due to the odd way that non-blocking transfers are handled by mbedTLS.

mbedtls_ssl_write:

 * \warning        This function will do partial writes in some cases. If the
 *                 return value is non-negative but less than length, the
 *                 function must be called again with updated arguments:
 *                 buf + ret, len - ret (if ret is the return value) until
 *                 it returns a value equal to the last 'len' argument.

 * \note           When this function returns #MBEDTLS_ERR_SSL_WANT_WRITE/READ,
 *                 it must be called later with the *same* arguments,
 *                 until it returns a value greater that or equal to 0. When
 *                 the function returns #MBEDTLS_ERR_SSL_WANT_WRITE there may be
 *                 some partial data in the output buffer, however this is not
 *                 yet sent.

I.e. once you start trying to send a chunk of data, you must finish sending that chunk before attempting to send any other chunks. It looks like the AcornSSL_Write implementation will take care of the above automatically if a blocking write is being performed. But for non-blocking, the caller needs to do it themselves. (Note that WANT_READ / WANT_WRITE will get reported as error number &20e23, EWOULDBLOCK).

After modifying vncserver to follow those rules it works better, but is still very unstable. More investigation required.

I don’t know how this affects the Dave’s server code but neither api_creat nor api_createsession initialise h->net.nbio (the ssl_handle structure isn’t zeroed when it is created so nbio isn’t set that way) so unless you call AcornSSL_Ioctl FIONBIO after the sslhandle is created, even if you are using select and blocking sockets, you will have problems. Having ssl nbio and socket nbio out of sync could cause of the -76 error Dave has seen. If EWOULDBLOCK is returned by the socket and the ssl layer thinks it is blocking it converts the EWOULDBLOCK error to -76 (MBEDTLS_ERR_NET_RECV_FAILED)

Basically you must call AcornSSL_Ioctl FIONBIO to synchronize socket nbio and ssl nbio whether using blocking or nonblocking sockets

once you start trying to send a chunk of data, you must finish sending that chunk before attempting to send any other chunks.

Interesting, thanks, Jeffrey. That needs to go in the docs.

It’s sort of a stricter version of what happens with some filing system operations in RISC OS, where the docs say that in some circumstances not all of the data will be transmitted in the call, but many of us (me included!) have got complacent about it because it’s in practice highly unusual for transfers to be incomplete.

Colin: good spot, thanks! The problem seems to arise because net_sockets.h conditionally adds a member “nbio” to the mbedtls_net_context:

typedef struct mbedtls_net_context
{
    int fd;             /**< The underlying file descriptor                 */
#ifdef __riscos
    int nbio;           /**< Flag to remember write only FIONBIO state      */
#endif
}
mbedtls_net_context;

but net_sockets.c, which is platform-specific for RISC OS, only initialises the “fd” member. That’s easy to fix for my dev code, but I must remember to feed that back – I was working on the basis that my changes would not affect the Lib.mbedTLS folder’s contents.

I’ve reported the spurious compiler warning as bug #506, severity minor.

spurious compiler warning

Is debug enabled for that build so that dprintf(()) generates code?

There’s something weird going on I’m testing using programs run in a taskwindow. I haven’t got round to testing an AcornSSL server at the moment as I can’t even get an AcornSSL client to work properly.

I have one program that acts like a https server and another a https client written using mbedtls. If I run the server in 1 taskwindow and the client in another the client receives data from the server. If I point the client at the BBC and run it it fetches a page from the BBC. If I keep running the client it fetches from the bbc every time. So far so good.

So I created the same programs using AcornSSL and they didn’t work. Run the mbedtls server and the AcornSSL client and the computer locks up requiring Alt break to recover. It locks up waiting to read despite being non blocking. If I point this AcornSSL client at the BBC instead of the local test server it downloads data as expected. However if I keep running the client it fails intermittently while writing with spurious errors eg errno 292 “System variable ‘vncserv_debug’ not found”.

However if I keep running the client it fails intermittently while writing with spurious errors eg errno 292 “System variable ‘vncserv_debug’ not found”.

The VNC server refreshes the debug state every centisecond. “*set vncserv_debug 0” should stop that error from taking up one of the MessageTrans shared error blocks. (That’s assuming you are running the VNC server in the background!)

Thanks, that just removed that error from the list of errors that intermittently appear.

Is debug enabled for that build so that dprintf(()) generates code?

Bugger. ’s obvious, innit? Thanks, Stuart.

Been there…

Where is dprintf actually defined?

I can suppress the warning if I surround the a statement with the same condition(s) that control dprintf, which is probably “#ifdef DEBUGLIB”, but I can’t be sure until I know dprintf’s definition.

debuglib.h in APCS-32.Lib.DebugLib

Sources.Lib.debuglib

dprintf disappears on the non debug version without causing problems so.

if (x) dprintf(("api","test");

becomes

if (x);

in the non debug version.

To create the debug version just run !MkDebug

if you change line

debug_set_device(PRINTF_OUTPUT);

to

debug_set_device(REPORTER_OUTPUT);

in sslmod.c then debug output will go to reporter.

*set debuglib$level_AcornSSL api,gbpb

Will filter debug output from dprintf((“api”,…)) and dprintf((gbpb",…)) lines.

There’s a new version up now. The main change to the code is to initialise h→net.nbio correctly, and it has today’s date. I’ve found and fixed several errors and inconsistencies in the docs. AcornSSL_Accept returns EWOULDBLOCK, AcornSSL_Handshake returns EINPROGRESS.

Colin, I don’t know if you’ve got a deadlock between two blocking operations. My code creates the server socket non-blocking, but NOT the client sockets (i.e. the sockets opened by the remote client), so you’d have to set them non-blocking yourself.

I did ask earlier if anyone knows any use for blocking sockets, but I haven’t had a response. Perhaps it would make more sense for the module to default them to non-blocking; of course the user can subsequently set them to blocking if required.

One other thing: I’d be grateful to everyone else who would like to test these versions of the AcornSSL module in existing client applications. I’ve tried to keep the API compatible, so it should continue to work like it used to. I keep checking it with FTPc to access my web site. It’s the version in my system resources.

Please, please, anyone who has any interest in it: take it, try it, break it, and above all comment on my proposed extensions to the API. […] I’ve tried to keep the API compatible, so it should continue to work like it used to.

Somewhat skipping over the intervening stream of consciousness, I thought it might be useful to think about the history of AcornSSL (back to its Browse days) from a philosophical point of view, as that will answer many of your own questions Dave. In no particular order:

• The equivalents of accept(), bind((), listen() should follow the familiar BSD sockets. Don’t make them RISC OS special brews.
  • You’ll likely need some sideband IOCtl or sockopt to configure the certificates
  • If it’ll fit in an IOCtl or sockopt that’s preferable to a custom SWI
• Any sideband controls should not be mapped to mbedTLS-specific functions. This is so that the API doesn’t get tied to what mbedTLS can do now (it’s already changed from OpenSSL in the past, and could change in future for TLS 1.3). For example if a SWI is needed to attach a certificate to a connection, design an API which will allow all current and future certificate types based on the respective RFCs, then pass those which mbedTLS can do and error the rest.
• Be mindful of socket ownership. It is never valid for an application to be simultaneously manipulating the raw socket and an SSL handle. A raw socket may be handed into the secure area, but then not touched again outside. This is because low level events could be management tasks like renegotiating keys, so there could be 0 bytes of application layer data, but any application snooping that exchange would get very confused and vice versa if the application tries taking bytes which aren’t its own. The clue’s in the name: secure sockets layer, no peeking round the side!
• While waiting for a handshake to complete use ENOTCONN (cf. dialup waiting for connection). This is so ported applications will work without requiring extensive modification, since their data reading/sending loop should already be structured such that the loop is retried.

Another sanity check is to think whether it’s possible to write

if (!secure)
  Socket_Blah,args
else
  AcornSSL_Blah,args

as that’s a good indicator they’re equivalent (ignoring extra any sideband calls needed).

I did ask earlier if anyone knows any use for blocking sockets, but I haven’t had a response. Perhaps it would make more sense for the module to default them to non-blocking; of course the user can subsequently set them to blocking if required.

There’s possibly been no response because the question is moot. The socket functions are blocking unless marked as not, it’s not for you to decide, someone at Xerox in the 1970’s already made the decision.

Yay! I got the AcornSSL client and server working though I had to use the new handshake swi with the client to get the client to work with either the mbedtls or acornssl server.

The clue’s in the name: secure sockets layer, no peeking round the side!

Let’s destroy this silly argument once and for all.

a) There’s no point in “peeking round the side” to look at or to insert data; they are encrypted.

b) If you want to write an application that doesn’t use polling, you need to use the Internet event (19). That, in turn, means you really want to know the socket handle, otherwise you’d be (indirectly) handling the event in your app for all sockets, not just your own.

So there is a good and legitimate need to make the socket handle available. It doesn’t oblige anyone to use it, but it’s there as a convenience for those who want it, as described above.